Tarayıcılara XML göndermenin ve XSLT uygulamalarına izin vermenin sakıncaları nelerdir?

bağlam

Serbest çalışan bir geliştirici olarak çalışırken, genellikle tamamen XSLT tabanlı web siteleri yaptım. Diğer bir deyişle, her istek üzerine, sayfa içeriği hakkında bilmemiz gereken her şeyi içeren bir XML dosyası oluşturulur: şu anda oturum açmış olan kullanıcının adı, üst menü girişleri, eğer bu menü dinamik / yapılandırılabilir ise, Ardından XSL'yi tarayıcıya göndermek için HTML / XHTML sayfasına (önbellekler vb.) işleyin.

Özellikle PHP ile küçük ölçekli web siteleri oluşturmayı kolaylaştırmak için iyi bir noktaya sahiptir. Bu bir tür şablon motorudur, ancak diğer şablon motorlarına tercih ederim, çünkü şablon motorlarının çoğundan çok daha güçlüdür ve daha iyi biliyorum ve beğendim. Ayrıca, gerektiğinde, ayrı API'ler oluşturmaya gerek kalmadan otomatik erişim için isteğe bağlı ham XML verilerine erişim vermek de mümkündür.

Tabii ki, herhangi bir orta ölçekli veya büyük ölçekli web sitesinde tamamen başarısız olacaktır, çünkü iyi önbellekleme teknikleriyle bile, XSL hala genel web sitesi performansını düşürür ve daha fazla CPU sunucu tarafı gerektirir.

Soru

Modern tarayıcılar, bir XML dosyası alma ve XML gibi bildirilen ilişkili bir XSL dosyasıyla dönüştürme yeteneğine sahiptir <?xml-stylesheet href="demo.xslt" type="text/xsl"?>. Firefox 3 bunu yapabilir. Internet Explorer 8 de bunu yapabilir.

Bu, XSL işlemeyi kullanıcıların% 50'si için sunucudan istemci tarafına geçirmenin mümkün olduğu anlamına gelir (bunu uygulamak isteyebileceğim birkaç web sitesindeki tarayıcı istatistiklerine göre). Bu, kullanıcıların% 50'sinin her istekte yalnızca XML dosyasını alacağı ve böylece sunucularının ve bant genişliklerinin azaltılacağı (XML dosyası, işlenen HTML analogundan çok daha kısa olacak) ve sunucunun CPU kullanımını azaltacağı anlamına gelir.

Bu tekniğin dezavantajları nelerdir?

Birkaçını düşündüm, ancak bu durumda geçerli değil:

• Zor uygulama ve tarayıcı isteğine bağlı olarak ham XML ne zaman gönderileceğini ve ne zaman HTML'ye dönüştürüleceğini seçme ihtiyacı. Açıkçası, sistem gerçek sistemden çok daha zor olmayacaktır. Yapılması gereken tek değişiklik, her XML'e XSL dosya bağlantısı eklemek ve bir tarayıcı denetimi eklemektir.
• XSLT dosyası, sunucu tarafından önbelleğe alınmak yerine tarayıcılar tarafından indirileceğinden, daha fazla IO ve bant genişliği kullanımı. XSLT dosyası tarayıcılar tarafından önbelleğe alınacağından (görüntüler veya CSS gibi veya JavaScript dosyaları gerçekten önbelleğe alındığından) bunun bir sorun olacağını düşünmüyorum.
• Muhtemelen istemci tarafında bazı sorunlar, örneğin bazı tarayıcılarda bir sayfayı kaydederken karşılaşılan sorunlar gibi.
• Kodda hata ayıklama zorluğu: Görüntülenen tek kaynak indirilen XML olduğundan tarayıcının gerçekte kullandığı bir HTML kaynağı elde etmek mümkün değildir. Öte yandan, nadiren istemci tarafında HTML koduna bakıyorum ve çoğu durumda, doğrudan kullanılamaz (boşluk kaldırılıyor).

Tarayıcılar giderek XSLT oluşturamaz

Bu , tüm veriler ve tüm stil sayfası yüklenip işlenene kadar başka hiçbir şeyin yüklenmediği ve hiçbir şeyin görüntülenmediği anlamına gelir .

Görüntülerin aşamalı olarak oluşturulması ve önceden getirilmesi, CSS ve JS'yi kaçırıyorsunuz.

İlk yükleme başka bir istek tarafından ertelendi

Küçük boyutlu dosyalar için (<20kb) istek sayısı, bant genişliği değil, ön uç performans için bir darboğazdır ve çoğu sayfa ve stil sayfası bu kategoriye girer.

Büyük sayfalarınız varsa, o zaman daha da kötüdür - ilk noktaya bakın.

Muhtemelen herhangi bir bant genişliğinden tasarruf etmiyorsunuz

XSLT'nin kendisi oldukça ayrıntılıdır ve sadece mevcut sayfada kullanılanlar değil, tüm site için şablonlar ve tüm nadir durumlar için mantık içermesi gerekebilir.

Gönderdiğiniz ana XML dosyasında işaretlenmiş tüm verileri yine de eklemeniz gerekir; örneğin, bir blog gönderisi gönderiyorsanız, XSLT'nin bunu önemli ölçüde daha küçük yapmak için yapabileceği hiçbir sihir yoktur. Karmaşık veriler gönderiyorsanız, yine de çok fazla biçimlendirme olacaktır.

Önbellekler abartılıyor

Tarayıcı önbellekleri o kadar da iyi değil :

Kullanıcılarının% 40-60'ında boş bir önbellek deneyimi vardır ve tüm sayfa görüntülemelerinin ~% 20'si boş bir önbellek ile yapılır.

ve gecikmenin ekstra talepleri en pahalı hale getirdiği mobil cihazlarda önbellekler daha da kötüdür .

Hemen çıkma oranınızı kontrol edin - önbelleğe alınmış XSLT'den yararlanmayan kullanıcılar ve hatta stil sayfasını indirmek ve işlenmesini beklemek için ekstra ücret ödeyen kullanıcılar.

gzip bir ters XSLT

XSLT aracılığıyla yapılan çoğu dönüşüm, daha ayrıntılı bir hale getirmek ve tekrar eklemek için keskin işaretlemeyi değiştirir. Ancak gzip, dosyalardan tekrarlama / artıklığı kaldırmada harika!

Yine de gzip kullanıyor olmalısınız (XML'i sıkıştırılmamış olarak göndermek israftır). İşlenen belgenin gzip boyutunun, işlenmemiş XML'in gzip boyutuyla hemen hemen aynı olması muhtemeldir - ancak ekstra XSLT göndermek zorunda kalmazsınız ve tarayıcılar ilk paketler gelir gelmez oluşturmaya başlayabilir.

Müşteriler yavaş olabilir

Önbellekten en iyi yükleme durumunda bile, istemci tarafında XSLT işleme yalnızca kullanıcının CPU'su daha hızlı ve XSLT motoru daha hızlıysa daha hızlıdır.

Sunucu tarafında her türlü optimizasyon hilesi yapabilirsiniz (örneğin, önbelleğe işlenmiş parçalar veya hatta tüm sayfalar). En yeni, en hızlı XSLT işlemcisini kullanabilirsiniz (tarayıcılarda yalnızca XSLT 1.0 vardır ve muhtemelen çok optimize edilmemiştir). Ve sunucunuz muhtemelen birçok ucuz ofis bilgisayarından, telefondan vb.

Bu serveride yapmanın doğrudan HTML oluşturmanın yanı sıra ölçeklendirmemesi için hiçbir neden yoktur. PHP ile karşılaştırıldığında sabit bir sabit yük için fazla bir neden yoktur. Görünüşe göre XSLT> JVM / CLR derleyicileri var ve sanırım yerel koda bile çevirebilirsiniz.

Ancak veri ve sunum yapısını ayrı ayrı taşıma fikri bu şekilde iyidir.
Çok fazla bant genişliği ve hatta sunucu performansından tasarruf edebilir. Ancak pomeL birkaç noktadan bahsetmiştir.

Tarayıcılar arasında doğru destek için xslt.js yardımcı olabilir.

Şahsen ben XML hayranı değilim, bu yüzden tarayıcıda çalışacak yerine JSON ve bir JS şablon motoru kullanırdım. Veya şablon işaretlemesini, sunucu tarafında yürütülebilir js'ye dönüştüren ve istemci tarafında oluşturma için kullanılan bir çeşit şablon motoru.
JavaScript oldukça hızlıdır ve neredeyse her yerde kullanılabilir. JSON ve JS, XML ve XSLT'den çok daha kompakttır.

Kompakt XML göndermek ve istemcide önbelleğe alınmış bir XSLT'ye sahip olmak bant genişliğinizi bile koruyabilir.

Akıllı telefonlar gibi XSLT'yi desteklemeyen tarayıcıları hariç tutarsınız. Ama yine de bunlar için özel bir sürüm oluşturmalısınız.

Birincil sorun eskiden sadece birkaç tarayıcının bunu iyi desteklemesiydi, bu yüzden destekleyecek yeni bir platform oluşturma zahmetine değmezdi. Ayrıca eski IE sürümleri bu iyi desteklemiyordu ve doğru hatırlıyorsam en az bir IE farklı türde XSLT lehçesi vardı eğlenceli her türlü sorunları veren.