Jakie są wady wysyłania XML do przeglądarek i pozwalają im stosować XSLT?

Kontekst

Pracując jako niezależny programista, często tworzyłem strony internetowe całkowicie oparte na XSLT. Innymi słowy, na każde żądanie generowany jest plik XML zawierający wszystko, co musimy wiedzieć o zawartości strony: nazwa aktualnie zalogowanego użytkownika, wpisy w górnym menu, jeśli to menu jest dynamiczne / konfigurowalne, tekst do wyświetlać w określonym obszarze strony itp. Następnie przetwarza XSL (pamięci podręczne itp.) na stronę HTML / XHTML, aby wysłać do przeglądarki.

To ma sens, aby ułatwić tworzenie małych stron internetowych, szczególnie w PHP. Jest to rodzaj silnika szablonów, ale ja wolę inne silniki szablonów, ponieważ jest on znacznie bardziej wydajny niż większość silników szablonów, a ponieważ znam go lepiej i podoba mi się. W razie potrzeby można również zapewnić dostęp do surowych danych XML na żądanie w celu zautomatyzowanego dostępu, bez potrzeby tworzenia osobnych interfejsów API.

Oczywiście zawiedzie całkowicie na każdej stronie internetowej na dużą lub dużą skalę, ponieważ nawet przy dobrych technikach buforowania, XSL nadal obniża ogólną wydajność strony i wymaga większej ilości serwerów po stronie procesora.

Pytanie

Nowoczesne przeglądarki mają możliwość pobierania pliku XML i przekształcania go za pomocą powiązanego pliku XSL zadeklarowanego w formacie XML <?xml-stylesheet href="demo.xslt" type="text/xsl"?>. Firefox 3 może to zrobić. Internet Explorer 8 też to potrafi.

Oznacza to, że możliwe jest migrowanie przetwarzania XSL z serwera na stronę klienta dla 50% użytkowników (zgodnie ze statystykami przeglądarki na kilku stronach internetowych, na których mogę chcieć to zaimplementować). Oznacza to, że tych 50% użytkowników otrzyma tylko plik XML na każde żądanie, zmniejszając w ten sposób przepustowość ich i serwera (plik XML jest znacznie krótszy niż przetworzony analog HTML) i zmniejszając użycie procesora przez serwer.

Jakie są wady tej techniki?

Myślałem o kilku, ale nie dotyczy to tej sytuacji:

• Trudna implementacja i potrzeba wyboru, na podstawie żądania przeglądarki, kiedy wysłać surowy XML, a kiedy zamiast tego przekształcić go w HTML. Oczywiście system nie będzie o wiele trudniejszy niż rzeczywisty. Jedyną zmianą, którą należy wprowadzić, jest dodanie linku do pliku XSL do każdego pliku XML i dodanie testu przeglądarki.
• Więcej operacji we / wy i przepustowości, ponieważ plik XSLT zostanie pobrany przez przeglądarki, a nie buforowany przez serwer. Nie sądzę, że będzie to problem, ponieważ przeglądarki będą buforować plik XSLT (np. Obrazy, CSS lub pliki JavaScript są buforowane).
• Być może niektóre problemy po stronie klienta, na przykład problemy podczas zapisywania strony w niektórych przeglądarkach.
• Trudność z debugowaniem kodu: nie można uzyskać źródła HTML, którego faktycznie używa przeglądarka, ponieważ jedynym wyświetlanym źródłem jest pobrany plik XML. Z drugiej strony rzadko patrzę na kod HTML po stronie klienta, aw większości przypadków nie można go bezpośrednio używać (usuwa się białe spacje).

Przeglądarki nie mogą stopniowo renderować XSLT

Oznacza to, że nic więcej się nie ładuje i nic nie jest wyświetlane, dopóki wszystkie dane i cały arkusz stylów nie zostaną załadowane i przetworzone.

Brakuje Ci progresywnego renderowania i pobierania obrazów, CSS i JS.

Pierwsze ładowanie jest opóźnione przez kolejne żądanie

W przypadku małych plików (<20 kb) liczba żądań, a nie przepustowość, stanowi wąskie gardło w zakresie wydajności frontonu, a większość stron i arkuszy stylów należy do tej kategorii.

Jeśli masz duże strony, jest jeszcze gorzej - zobacz pierwszy punkt.

Prawdopodobnie nie oszczędzasz żadnej przepustowości

Sama XSLT jest dość gadatliwa i może wymagać szablonów dla całej witryny i logiki dla wszystkich rzadkich przypadków, nie tylko rzeczy używanych na bieżącej stronie.

Nadal musisz uwzględnić wszystkie dane zaznaczone w głównym pliku XML, który wysyłasz, np. Jeśli wysyłasz post na blogu, nie ma magii, którą XSLT może zrobić, aby znacznie go zmniejszyć. Jeśli wysyłasz złożone dane, i tak będzie to oznaczać wiele znaczników.

Skrytki są przereklamowane

Pamięci podręczne przeglądarki nie są tak świetne :

40–60% użytkowników Yahoo! Ma pustą pamięć podręczną, a ~ 20% wszystkich wyświetleń strony odbywa się przy pustej pamięci podręcznej.

a na urządzeniach mobilnych, gdzie opóźnienie sprawia, że ​​dodatkowe żądania są najdroższe, pamięci podręczne są jeszcze gorsze .

Sprawdź współczynnik odrzuceń - są to użytkownicy, którzy nie korzystają z XSLT z pamięci podręcznej, a nawet płacą dodatkową cenę, aby pobrać arkusz stylów i czekać na jego przetworzenie.

gzip jest odwrotnym XSLT

Większość transformacji dokonanych za pomocą XSLT sprowadza się do zmiany krótkich znaczników na bardziej szczegółowe i dodawania powtórzeń. Ale gzip jest świetny w usuwaniu powtórzeń / redundancji z plików!

W każdym razie powinieneś używać gzip (wysyłanie pliku XML bez kompresji) jest niepotrzebne. Jest bardzo prawdopodobne, że rozmiar skompresowanego gzip przetworzonego dokumentu będzie mniej więcej taki sam, jak rozmiar skompresowanego gzip nieprzetworzonego XML - ale nie będziesz musiał wysyłać dodatkowego XSLT, a przeglądarki będą mogły rozpocząć renderowanie, jak tylko pojawią się pierwsze pakiety.

Klienci mogą być powolni

Nawet przy założeniu najlepszego przypadku ładowania z pamięci podręcznej przetwarzanie XSLT po stronie klienta jest szybsze tylko wtedy, gdy procesor użytkownika jest szybszy, a silnik XSLT jest szybszy.

Po stronie serwera możesz wykonywać wszelkiego rodzaju sztuczki optymalizacyjne (np. Buforować przetworzone fragmenty, a nawet całe strony). Możesz użyć najnowszego, najszybszego procesora XSLT (przeglądarki mają tylko XSLT 1.0 i prawdopodobnie niezbyt zoptymalizowane). Twój serwer ma prawdopodobnie mocniejszy procesor niż wiele tanich komputerów biurowych, telefonów itp.

Nie ma powodu, dla którego robienie tego na serwerze nie powinno skalować się tak dobrze, jak bezpośrednie generowanie HTML. Nie ma też wielu powodów dużego stałego obciążenia w porównaniu do PHP. Najwyraźniej istnieją kompilatory XSLT> JVM / CLR i przypuszczam, że można nawet przetłumaczyć go na kod macierzysty.

Jednak pomysł oddzielnego transportu danych i struktury prezentacji jest dobry jako taki.
Może zaoszczędzić dużo przepustowości, a nawet wydajności serwera. Ale pomeL wspomniał o kilku kwestiach.

Dla prawidłowego wsparcia w różnych przeglądarkach xslt.js może pomóc.

Osobiście nie jestem fanem XML, więc zamiast tego użyłbym JSON i silnika szablonów JS, który będzie działał w przeglądarce. Lub jakiś silnik szablonów, który konwertuje znaczniki szablonów do wykonywalnych plików js po stronie serwera, które są używane do renderowania po stronie klienta.
JavaScript jest dość szybki i dostępny praktycznie wszędzie. JSON i JS są znacznie bardziej kompaktowe niż XML i XSLT.

Wysyłanie kompaktowego pliku XML i buforowanie XSLT na kliencie może nawet zaoszczędzić przepustowość.

Pomijasz przeglądarki, które nie obsługują XSLT, takie jak smartfony. Ale i tak powinieneś stworzyć specjalną wersję dla nich.

Główny problem polegał na tym, że tylko kilka przeglądarek dobrze to obsługiwało, więc nie było problemu, aby stworzyć nową platformę do obsługi. Ponadto starsze wersje IE nie obsługiwały tego dobrze, a jeśli dobrze pamiętam, co najmniej jeden IE miał inny dialekt XSLT, co powodowało wiele zabawnych problemów.