Quels sont les inconvénients de l'envoi de XML aux navigateurs et de les laisser appliquer XSLT?

Le contexte

En tant que développeur indépendant, j'ai souvent créé des sites Web entièrement basés sur XSLT. En d'autres termes, à chaque demande, un fichier XML est généré, contenant tout ce que nous devons savoir sur le contenu de la page: le nom de l'utilisateur actuellement connecté, les entrées du menu supérieur, si ce menu est dynamique / configurable, le texte à afficher dans une zone spécifique de la page, etc. Ensuite, XSL le traite (caches, etc.) vers la page HTML / XHTML pour l'envoyer au navigateur.

Il a un bon point pour faciliter la création de sites Web à petite échelle, en particulier avec PHP. C'est une sorte de moteur de modèle, mais que je préfère aux autres moteurs de modèle parce qu'il est beaucoup plus puissant que la plupart des moteurs de modèle, et parce que je le connais mieux et j'aime ça. Il est également possible, en cas de besoin, de donner accès à des données XML brutes à la demande pour un accès automatisé, sans avoir besoin de créer des API distinctes.

Bien sûr, il échouera complètement sur n'importe quel site Web à moyenne ou grande échelle, car, même avec de bonnes techniques de mise en cache, XSL dégrade toujours les performances globales du site Web et nécessite plus de CPU côté serveur.

Question

Les navigateurs modernes ont la possibilité de prendre un fichier XML et de le transformer avec un fichier XSL associé déclaré en XML comme <?xml-stylesheet href="demo.xslt" type="text/xsl"?>. Firefox 3 peut le faire. Internet Explorer 8 peut également le faire.

Cela signifie qu'il est possible de migrer le traitement XSL du serveur vers le côté client pour 50% des utilisateurs (selon les statistiques du navigateur sur plusieurs sites Web sur lesquels je souhaiterais implémenter cela). Cela signifie que ces 50% d'utilisateurs ne recevront que le fichier XML à chaque demande, réduisant ainsi leur bande passante et celle du serveur (le fichier XML étant beaucoup plus court que son analogue HTML traité), et réduisant l'utilisation du processeur du serveur.

Quels sont les inconvénients de cette technique?

J'en ai pensé à plusieurs, mais cela ne s'applique pas dans cette situation:

• Implémentation difficile et nécessité de choisir, en fonction de la demande du navigateur, quand envoyer du XML brut et quand le transformer en HTML à la place. De toute évidence, le système ne sera pas beaucoup plus difficile que le système actuel. La seule modification à apporter consiste à ajouter un lien de fichier XSL à chaque XML et à ajouter une vérification de navigateur.
• Plus d'ES et d'utilisation de la bande passante, car le fichier XSLT sera téléchargé par les navigateurs, au lieu d'être mis en cache par le serveur. Je ne pense pas que ce sera un problème, car le fichier XSLT sera mis en cache par les navigateurs (comme les images, ou CSS, ou les fichiers JavaScript sont effectivement mis en cache).
• Peut-être quelques problèmes côté client, comme peut-être des problèmes lors de l'enregistrement d'une page dans certains navigateurs.
• Difficulté à déboguer le code: il est impossible d'obtenir une source HTML que le navigateur utilise réellement, car la seule source affichée est le XML téléchargé. En revanche, je vais rarement regarder le code HTML côté client, et dans la plupart des cas, il est directement inutilisable (les espaces sont supprimés).

Les navigateurs ne peuvent pas afficher progressivement XSLT

Cela signifie que rien d' autre ne se charge et que rien n'est affiché tant que toutes les données et toute la feuille de style ne sont pas chargées et traitées.

Vous manquez le rendu progressif et la prélecture des images, CSS et JS.

Le chargement initial est retardé par une autre demande

Pour les fichiers de petite taille (<20 Ko), le nombre de demandes, et non la bande passante, est le goulot d' étranglement pour les performances frontales, et la plupart des pages et des feuilles de style tomberont dans cette catégorie.

Si vous avez de grandes pages, c'est encore pire - voir le premier point.

Vous n'économisez probablement aucune bande passante

XSLT lui-même est assez verbeux et pourrait avoir besoin de contenir des modèles pour l'ensemble du site et de la logique pour tous les rares cas, pas seulement les éléments utilisés sur la page actuelle.

Vous devez toujours inclure toutes les données marquées dans le fichier XML principal que vous envoyez, par exemple si vous envoyez un article de blog, alors il n'y a aucune magie que XSLT puisse faire pour le réduire considérablement. Si vous envoyez des données complexes, elles auront quand même beaucoup de balisage.

Les caches sont surfaits

Les caches de navigateur ne sont pas très bien :

40 à 60% des utilisateurs de Yahoo! Ont une expérience de cache vide et ~ 20% de toutes les pages vues sont effectuées avec un cache vide.

et sur mobile, où la latence rend les demandes supplémentaires plus coûteuses, les caches sont encore pires .

Vérifiez votre taux de rebond - ce sont des utilisateurs qui ne bénéficient pas du XSLT mis en cache, et payent même un prix supplémentaire pour télécharger la feuille de style et attendre qu'elle soit traitée.

gzip est un XSLT inversé

La plupart des transformations effectuées via XSLT se résument à changer le balisage laconique en un plus verbeux et à ajouter de la répétition. Mais gzip est excellent pour supprimer la répétition / redondance des fichiers!

Vous devriez quand même utiliser gzip (c'est inutile d'envoyer du XML non compressé). Il est très probable que la taille compressée du document traité sera à peu près la même que la taille compressée du XML non traité - mais vous n'aurez pas à envoyer de XSLT supplémentaire, et les navigateurs pourront commencer le rendu dès l'arrivée des premiers paquets.

Les clients peuvent être lents

Même en supposant le meilleur cas de chargement à partir du cache, le traitement XSLT côté client n'est plus rapide que si le processeur de l'utilisateur est plus rapide et que son moteur XSLT est plus rapide.

Côté serveur, vous pouvez effectuer toutes sortes d'astuces d'optimisation (par exemple, mettre en cache des fragments traités ou même des pages entières). Vous pouvez utiliser le processeur XSLT le plus récent et le plus rapide (les navigateurs n'ont que XSLT 1.0 et probablement pas très optimisés). Et votre serveur a probablement un processeur plus costaud que de nombreux ordinateurs de bureau, téléphones, etc. bon marché.

Il n'y a aucune raison de ne pas faire évoluer ce côté serveur et générer directement du HTML. Il n'y a pas non plus beaucoup de raisons pour une grosse surcharge constante par rapport à PHP. Apparemment, il existe des compilateurs XSLT> JVM / CLR et je suppose que vous pourriez même les traduire en code natif.

Cependant, l'idée de transporter les données et la structure de présentation séparément est bonne en tant que telle.
Il peut économiser beaucoup de bande passante et même les performances du serveur. Mais pomeL a mentionné un certain nombre de points.

Pour une prise en charge appropriée sur tous les navigateurs, xslt.js pourrait vous aider.

Personnellement, je ne suis pas fan de XML, donc j'utiliserais plutôt JSON et un moteur de modèle JS, qui s'exécutera dans le navigateur. Ou une sorte de moteur de modèle, qui convertit le balisage de modèle en js exécutable côté serveur, qui est utilisé pour le rendu côté client.
JavaScript est relativement rapide et disponible pratiquement partout. JSON et JS sont beaucoup plus compacts que XML et XSLT.

L'envoi de XML compact et le fait d'avoir un XSLT mis en cache sur le client peuvent même économiser votre bande passante.

Vous omettez tous les navigateurs qui ne prennent pas en charge XSLT, comme les smartphones. Mais vous devriez quand même créer une version spéciale pour ces derniers.

Le principal problème était que seuls quelques navigateurs le supportaient bien, donc cela ne valait pas la peine de créer une nouvelle plate-forme à prendre en charge. De plus, les anciennes versions d'IE ne le supportaient pas bien, et si je me souviens bien, au moins un IE avait un dialecte XSLT différent donnant toutes sortes de problèmes amusants.