Was sind die Nachteile beim Senden von XML an Browser und beim Anwenden von XSLT?

Kontext

Als freiberuflicher Entwickler habe ich oft Websites erstellt, die vollständig auf XSLT basieren. Mit anderen Worten, bei jeder Anforderung wird eine XML-Datei generiert, die alles enthält, was wir über den Seiteninhalt wissen müssen: den Namen des aktuell angemeldeten Benutzers, die obersten Menüeinträge, wenn dieses Menü dynamisch / konfigurierbar ist, den Text zu Anzeige in einem bestimmten Bereich der Seite usw. Anschließend wird sie von XSL-Prozessen (Caches usw.) an HTML / XHTML-Seiten gesendet, um sie an den Browser zu senden.

Es hat einen guten Grund, die Erstellung kleinerer Websites zu vereinfachen, insbesondere mit PHP. Es ist eine Art Template-Engine, die ich aber anderen Template-Engines vorziehe, weil sie viel leistungsfähiger ist als die meisten Template-Engines und weil ich sie besser kenne und mag. Es ist auch möglich, bei Bedarf einen Zugriff auf XML-Rohdaten für einen automatisierten Zugriff bereitzustellen, ohne dass separate APIs erstellt werden müssen.

Natürlich wird es auf jeder mittelgroßen oder großen Website vollständig versagen, da XSL trotz guter Caching-Techniken die Gesamtleistung der Website beeinträchtigt und mehr CPU-Server erfordert.

Frage

Moderne Browser haben die Möglichkeit, eine XML-Datei aufzunehmen und mit einer zugehörigen, in XML deklarierten XSL-Datei zu transformieren <?xml-stylesheet href="demo.xslt" type="text/xsl"?>. Firefox 3 kann das. Internet Explorer 8 kann das auch.

Dies bedeutet, dass es für 50% der Benutzer möglich ist, die XSL-Verarbeitung vom Server auf die Clientseite zu migrieren (entsprechend der Browserstatistik auf mehreren Websites, auf denen ich dies möglicherweise implementieren möchte). Dies bedeutet, dass diese 50% der Benutzer bei jeder Anforderung nur die XML-Datei erhalten, wodurch die Bandbreite ihrer Benutzer und des Servers (die XML-Datei ist viel kürzer als das verarbeitete HTML-Analog) und die CPU-Auslastung des Servers verringert werden.

Was sind die Nachteile dieser Technik?

Ich habe über mehrere nachgedacht, aber das trifft in dieser Situation nicht zu:

• Schwierige Implementierung und die Notwendigkeit, basierend auf der Browseranforderung zu entscheiden, wann unformatiertes XML gesendet und stattdessen in HTML umgewandelt werden soll. Offensichtlich wird das System nicht viel schwieriger sein als das eigentliche. Die einzige Änderung, die vorgenommen werden muss, ist das Hinzufügen einer XSL-Dateiverknüpfung zu jeder XML-Datei und das Hinzufügen einer Browserprüfung.
• Mehr IO- und Bandbreitennutzung, da die XSLT-Datei von den Browsern heruntergeladen wird, anstatt vom Server zwischengespeichert zu werden. Ich denke nicht, dass es ein Problem sein wird, da XSLT-Dateien von den Browsern zwischengespeichert werden (wie Bilder oder CSS oder JavaScript-Dateien werden tatsächlich zwischengespeichert).
• Möglicherweise einige Probleme auf der Client-Seite, z. B. Probleme beim Speichern einer Seite in einigen Browsern.
• Schwierigkeiten beim Debuggen von Code: Es ist unmöglich, eine HTML-Quelle zu erhalten, die der Browser tatsächlich verwendet, da die einzige angezeigte Quelle das heruntergeladene XML ist. Auf der anderen Seite schaue ich selten auf HTML-Code auf der Clientseite und in den meisten Fällen ist er direkt unbrauchbar (Leerzeichen werden entfernt).

Browser können XSLT nicht progressiv rendern

Dies bedeutet, dass nichts anderes geladen und nichts angezeigt wird, bis alle Daten und das gesamte Stylesheet geladen und verarbeitet wurden.

Sie verpassen das progressive Rendern und Prefetching von Bildern, CSS und JS.

Das erstmalige Laden wird durch eine andere Anforderung verzögert

Bei kleinen Dateien (<20 KB) ist die Anzahl der Anforderungen, nicht die Bandbreite, der Engpass für die Front-End-Leistung, und die meisten Seiten und Stylesheets fallen in diese Kategorie.

Wenn Sie große Seiten haben, ist es noch schlimmer - siehe den ersten Punkt.

Sie sparen wahrscheinlich keine Bandbreite

XSLT selbst ist recht ausführlich und muss möglicherweise Vorlagen für die gesamte Site und Logik für alle seltenen Fälle enthalten, nicht nur für die auf der aktuellen Seite verwendeten Elemente.

Sie müssen weiterhin alle Daten einschließen, die in der von Ihnen gesendeten XML-Hauptdatei markiert sind. Wenn Sie z. B. einen Blog-Beitrag senden, kann XSLT diese Datei nicht wesentlich verkleinern. Wenn Sie komplexe Daten senden, wird es trotzdem viele Markups geben.

Caches werden überbewertet

Browser-Caches sind nicht so toll :

40-60% der Yahoo! -Nutzer haben einen leeren Cache, und ~ 20% aller Seitenaufrufe werden mit leerem Cache ausgeführt.

Auf Mobilgeräten, bei denen die Latenz zusätzliche Anforderungen am teuersten macht, sind die Caches sogar noch schlechter .

Überprüfen Sie Ihre Absprungrate - dies sind Benutzer, die nicht von zwischengespeichertem XSLT profitieren und sogar einen Aufpreis zahlen, um das Stylesheet herunterzuladen und auf die Verarbeitung zu warten.

gzip ist eine umgekehrte XSLT

Die meisten Transformationen, die über XSLT ausgeführt werden, bestehen darin, das knappe Markup in ein ausführlicheres zu ändern und Wiederholungen hinzuzufügen. Aber gzip ist großartig, um Wiederholungen / Redundanzen aus Dateien zu entfernen!

Sie sollten ohnehin gzip verwenden (es ist verschwenderisch, XML unkomprimiert zu senden). Es ist sehr wahrscheinlich, dass die komprimierte Größe des verarbeiteten Dokuments in etwa der komprimierten Größe von nicht verarbeitetem XML entspricht. Sie müssen jedoch kein zusätzliches XSLT senden, und Browser können mit dem Rendern beginnen, sobald die ersten Pakete eintreffen.

Clients sind möglicherweise langsam

Selbst wenn der beste Fall für das Laden aus dem Cache angenommen wird, ist die XSLT-Verarbeitung auf der Clientseite nur dann schneller, wenn die CPU des Benutzers schneller und die XSLT-Engine schneller ist.

Auf der Serverseite können Sie alle Arten von Optimierungstricks ausführen (z. B. im Cache verarbeitete Fragmente oder sogar ganze Seiten). Sie können den neuesten, schnellsten XSLT-Prozessor verwenden (Browser haben nur XSLT 1.0 und sind wahrscheinlich nicht sehr optimiert). Und Ihr Server hat wahrscheinlich eine leistungsstärkere CPU als viele billige Bürocomputer, Telefone usw.

Es gibt keinen Grund, warum diese Serverseite nicht skaliert und HTML nicht direkt generiert werden sollte. Es gibt auch nicht viel Grund für einen großen konstanten Overhead im Vergleich zu PHP. Anscheinend gibt es XSLT> JVM / CLR-Compiler und ich nehme an, Sie könnten es sogar in nativen Code übersetzen.

Die Idee, Daten und Präsentationsstruktur getrennt zu transportieren, ist jedoch als solche gut.
Es kann viel Bandbreite und sogar Serverleistung sparen. Aber pomeL hat eine Reihe von Punkten erwähnt.

Für eine ordnungsgemäße Unterstützung in allen Browsern kann xslt.js hilfreich sein.

Ich persönlich bin kein Fan von XML, daher würde ich stattdessen JSON und eine JS-Template-Engine verwenden, die im Browser ausgeführt wird. Oder eine Art Template-Engine, die das Template-Markup auf der Serverseite in ausführbare js konvertiert, die für das Rendern auf der Clientseite verwendet werden.
JavaScript ist relativ schnell und praktisch überall verfügbar. JSON und JS sind wesentlich kompakter als XML und XSLT.

Wenn Sie kompaktes XML senden und einen zwischengespeicherten XSLT auf dem Client haben, können Sie sogar Bandbreite sparen.

Sie lassen alle Browser wie Smartphones aus, die XSLT nicht unterstützen. Sie sollten jedoch trotzdem eine spezielle Version für diese erstellen.

Das Hauptproblem bestand früher darin, dass nur wenige Browser dies gut unterstützten, so dass sich die Mühe nicht lohnte, im Wesentlichen eine neue zu unterstützende Plattform zu erstellen. Außerdem haben ältere Versionen von IE dies nicht gut unterstützt, und wenn ich mich richtig erinnere, hatte mindestens ein IE einen anderen XSLT-Dialekt, der alle möglichen unterhaltsamen Probleme bereitete.