Sitelerin neden her bir parçanın büyük bölümlerini yükleyen ajax işlevselliği ile geliştirilmemesi gerektiğine dair sağlam bir neden var mıdır (başlık, gezinme vb. Gibi aynı kalan öğeler olduğu varsayılarak)?

Sunucunun her sayfada görünen içeriği sunması gerekmediğinden, hem ana makineye hem de son kullanıcıya fayda sağladığından, kaynak yoğunluğu daha az olacaktır.

Soruyu dikkate alarak cevaplayın:

• Sitelerin javascript davranışı her durumda incelikle düşer

• Sorum için bu davranışın kapalı yerine uygulanabileceği yeni sitelerden bahsediyorum, bu yüzden teknik olarak herhangi bir paraya mal olmuyor - onu uygulamak için bitmiş bir ürüne geri dönmüyoruz.

İçeriğe JavaScript etkinleştirilmeden erişilebiliyorsa sorunuz herhangi bir anlam ifade etmiyor. İçeriğe başka yollarla ulaşabiliyorsanız "tamamen Ajaxified" değildir. Gerçekten, sorduğunuz şey "Kullanıcılarımın Ajax aracılığıyla deneyimini geliştirmek doğru mu?" Cevap açıkçası "evet".

Düzenle

Google, taranabilir Ajax teklifiyle çıktığında, gerçekten kötü bir fikir olarak tarandı . İlginç bir okuma yapar.

Her şey sırayla

Profesyoneller

• AJAX, ortak bir "temel" sayfa kullanmanıza ve sayfanın büyük bir kısmı zaten yüklendiğinden kullanıcılar için yükleme süresini kısaltabilen içerik alanlarını yüklemenize izin verebilir.
• İçerik alanının içeri ve dışarı solması gibi bazı göz şekerlerine izin verebilir.

Eksiler

• Sayfa indirilirse iyi oynatılmaz.
• Engellilik cihazlarıyla uğraşabilir.
• Javascript kapalı olan görüntüleyenler, javascript olmayan bir sürüm de kullanılmadıkça içeriği kullanamazlar.
• Çok daha fazla iş (gerçekten söylenmesi gerekiyor mu?).

Şimdi sorunuz için

Sitenizin Javascript içermeyen kullanıcılar için zarif bir şekilde düştüğü varsayıldığında, bunun ne kadar iyi olduğu, nasıl yapıldığına bağlıdır. Örneğin, yalnızca javascript olmayan bir sürümün bağlantısını mavi renkten çıkarırsanız, bu görüntüleyenlerin başka bir bağlantıyı tıklamaları zor olabilir. Öte yandan, geleneksel bağlantılar kullanan bir noscript "ana sayfası" varsa, çoğu kullanıcı için daha iyi çalışır, ancak yine de engelli cihazları kullanan kullanıcılar için destek yoktur, kullanıcının belirli bir "sayfa" bağlantı vb.

Sonuçta, giderek daha hızlı web bağlantısı dünyasında, küçük bir dosya boyutunu kesmeyi gerçekten haklı çıkarmıyor (tüm Javascript'in kendisini, CSS'yi ve görüntüleri önbelleğe alabilir ve önbelleğe alacağız. "temel" sayfanın kendisi baytları kaydetmek için), yani ekstra zorluk (her zaman bir çelişki iyi olmasa da) ve bazı kullanıcılar için verebileceği destek eksikliği için.

Sonuçta, size bağlı olduğunu söyleyebilirim, muhtemelen oldukça iyi çalışır ve kullanıcıların büyük çoğunluğu için, siteyi amaçlandığı gibi görürler, ancak kişisel olarak, söyleme rahatsız etmek, çünkü dosya boyutunda böyle marjinal bir iyileşme için sorun değil.

Check out http://gawker.com/ - işten geçtikten sonra bu site neredeyse tamamen yükler. http://mydomain.com/#!some_sectionHangi içerik sayfasının yüklenmesi gerektiğini belirlemek için "hashbangs" ( ) kullanırlar, ana gezinme durağan kalır.

Check out http://mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/ Gawker kullanılan kavramı üzerinde kısa bir öğretici için.

Artıları ve eksileri vardır, arama motorlarını (bkz. Http://code.google.com/web/ajaxcrawling/docs/getting-started.html ), javascript'i devre dışı bırakılmış kişileri ve çok fazla test yapmayı düşünmelisiniz .

Tüm bunlarla birlikte, onlara karşı en büyük argüman, muhtemelen bir kullanıcı bir sayfanın yüklenmesini beklediğinde, daha fazla yükleme için beklemek zorunda kalmasıdır. Benim görüşüme göre, en iyi uygulama ana siteyi, navigasyonu ve birincil içeriği bir geçişte (istek üzerine) yüklemek ve gerekli olmayan olaylar için AJAX'ı kaydetmek. Bu, aşamalı geliştirme fikri ile çalışır ve her iki yaklaşımın en iyisini karıştırır.

Çünkü muhtemelen gerekli değildir.
Temel HTML belgelerini yüklemek basittir ve işe yarar. Ajax'ın tanıtımı, Javascript, arka uç şeyler, garip hashbang URL'leri vb. İçin tarayıcılar, kod ve bakım için başka bir işlem katmanı ekler. Bazen bu haklı olabilir, bazen değil. Size bazı sunucu kaynaklarını kurtarabilir (olabilir), ancak bu bakımı telafi etmek için yeterli olacak mı? Bunu proje başına değerlendirmelisiniz.

Örnek olarak, Twitter en son yeniden tasarımını elde ettiğinde, sadece bir web (sayfa) sitesi değil, bir uygulama olduğu ve her şeyin çok Ajax tabanlı olduğu yaklaşımını benimsedi. düzenli sayfa istekleri ile ele alınmalıdır. Hala çok daha az olsa da meydana gelen en büyük sorunlardan biri, Ajax'ta bir şey başarısız olduğu için oraya gelip boş bir sayfa ile karşılanıyor.

Uygulamada, özellikle çok karmaşık olan büyük web siteleri için 'tamamen AJAX' web sitesi üretmek çok iştir. Bunu deneyen bazı web siteleri Google ve Facebook'tur, ancak onlar bile mükemmel bir şekilde yapmazlar.

Sık karşılaşılan sorunlar gezinme (ileri ve geri) ve yer imi olmaktır, ancak birçok geliştiricinin uğraşmak zorunda kalmayacağı birçok hata vardır. Temel olarak, Javascript ve javascript olmayan kullanıcılarla uyumlu olmak için web sitesinin iki sürümünü oluşturmak anlamına gelir (ve kötü AJAX desteğine sahip tüm tarayıcılar için düzeltmeler).

Evet öyle olmalı, ancak tam tersi olmalı.

Sayfanın ortak bölümleri HTTP üzerinden gönderilmelidir. Daha sonra küçük bir ajax (veya daha iyi websockets) kontrolü dinamik içeriği eşzamansız olarak yükler.

Tabii ki önce javascript'in etkin olup olmadığını (çerezle) tespit etmeniz ve bu yöntemi sadece etkinleştirilmişse kullanmanız gerekir.

Bu yüzden normal tam HTTP yoluna ve sonra bir websockets yoluna ihtiyacınız vardır. Node.js gibi bir araç kullanmadığınız sürece kod çoğaltması gerekir

Çoğu insan bunun fazladan çabaya değmeyeceğini düşünür. Ve bazen değil.

Bir kenara bir çok insan sayfaları yanlış ajaxify. Aslında, bir javascript sürümüne ihtiyacınız olmadığına ve tüm bu garip karma patlama URL'lerine ve kırık ileri / geri düğmelerine ihtiyacınız olduğuna karar verirler. Ajax'ın doğru şekilde yapılması HTML5 geçmişini gerektirir (IE9'da yoktur). Ayrıca geliştiricinin web sitenizin sürümlerini tamamlaması gerekir.

Javascript devre dışı bırakılmış ziyaretçiler için nazikçe bozulacağını belirttiğiniz için, ortaya çıkabilecek yalnızca iki gerçek sorun (ve bir olası sorun) görebiliyorum.

Erişilebilirlik İçin Kötü

Ekran okuyucular ve diğer yardımcı teknolojiler genellikle dinamik DOM değişiklikleri tarafından atılır. Sayfayı doğrusal bir şekilde işler ve okurlar ve yüklendikten sonra sayfanın içeriğini değiştirmek doğru şekilde işlenmeyebilir.

Bu sorunun üstesinden gelmek için teknikler olabilir, ama bunu çok iyi incelemedim.

Artan Karmaşıklık

Bu tür bir siteyi korumak zor olabilir. Bir örnek: Yeni bir düzen oluşturduysanız ve AJAX bağlantılarınızla değiştirdiğiniz içerik alanının kimliğini değiştirdiyseniz, gezinme düzeninizi oldukça şaşırtıcı bir şekilde bozabilir.

Bu tür AJAX davranışı, yapmış olabileceğiniz trafik analizlerini de karmaşık hale getirir; Google Analytics, bu AJAX yüklerini manuel arama yapılmadan düzgün şekilde kaydetmez pageTracker._trackPageview('this_page');.

Sayfanızın çalışma biçimine daha fazla karmaşıklık eklemek, yeni geliştiriciler için de çıtayı yükseltiyor; sitede çalışan herkes muhtemelen bu davranışın sayfa yüklerini nasıl etkilediği konusunda bilgilendirilmelidir.

Mümkün: İlk Ziyarette Yavaş Sayfa Yükü

Bir şeyleri nasıl yapılandırdığınıza bağlı olarak, AJAX kodunu getiren bu sayfa ancak belge tamamen yüklendikten sonra devreye girebilir. Bu nedenle, yalnızca ziyaretçiniz sayfanın tamamını ve ardından Javascript'i (harici bir dosyaysa) ve tarayıcılarını oluşturduktan ve AJAX aracılığıyla içeriği getirdikten sonra, sayfa içeriğini görürler.

Sonraki her tıklanan bağlantı daha hızlı olur, ancak bir kullanıcının ziyaret ettiği ilk sayfayı getirmek aslında statik bir sürümden daha uzun sürer.

Bunu olası bir sorun olarak etiketlememizin nedeni, ilk sayfayı her zaman statik olarak gönderebilmenizdir (statik sürümü zaten bir yedek olarak kullanacağınız için) ve ardından sonraki bağlantılar için AJAX'ı kullanmanızdır.

Değeri için, bu benim için korkunç bir fikir gibi gelmiyor - özellikle mobil sayfalar gibi bant genişliğine duyarlı kullanımlar için. Yine de sizin durumunuzda buna değdiğinden emin olmak için dezavantajları dikkatlice tartmanız gerekir.

Bir sayfada ajax öğelerinin olması, küçük bir kullanıcı tabanınız olduğunda, ancak daha fazla trafiğiniz olduğunda iyidir; kaynak kötüye kullanımını azaltmak için daha statik bir yaklaşım kullanmak istersiniz.

Örneğin: saniyede bir sayfaya erişmeye çalışan 200 kişiniz olduğunu varsayalım. Ajax çağrılarınız için yaklaşık 7 veritabanı sorgunuz var; yani 1400 veritabanı bir saniyeyi çağırır.

Daha yüksek trafik için tasarlanması gereken bir web sitesinde, statik bir şekilde görüntülenebilen içerik için statik dışa dönük sayfalar olmalıdır. Bu, son kullanıcı için getirilen statik sayfayı yeniden oluşturmak için her saniye çalışan bir sunucu tarafı komut dosyası kullanılarak gerçekleştirilir ve böylece yükünüzü saniyede 1400 veritabanı çağrısından 7'ye düşürdünüz.

Bu bir olan SOA web sitesi binaya yaklaşım.