¿Cuáles son los inconvenientes de enviar XML a los navegadores y dejar que apliquen XSLT?

Contexto

Trabajando como desarrollador independiente, a menudo creé sitios web completamente basados ​​en XSLT. En otras palabras, en cada solicitud, se genera un archivo XML que contiene todo lo que necesitamos saber sobre el contenido de la página: el nombre del usuario actualmente conectado, las entradas del menú superior, si este menú es dinámico / configurable, el texto para mostrar en un área específica de la página, etc. Luego lo procesa XSL (cachés, etc.) a la página HTML / XHTML para enviar al navegador.

Tiene un buen punto para facilitar la creación de sitios web a pequeña escala, especialmente con PHP. Es una especie de motor de plantillas, pero que prefiero a otros motores de plantillas porque es mucho más potente que la mayoría de los motores de plantillas, y porque lo conozco mejor y me gusta. También es posible, cuando sea necesario, dar acceso a datos XML sin procesar a pedido para un acceso automatizado, sin la necesidad de crear API separadas.

Por supuesto, fallará por completo en cualquier sitio web de mediana o gran escala, ya que, incluso con buenas técnicas de almacenamiento en caché, XSL todavía degrada el rendimiento general del sitio web y requiere más CPU en el lado del servidor.

Pregunta

Los navegadores modernos tienen la capacidad de tomar un archivo XML y transformarlo con un archivo XSL asociado declarado como XML <?xml-stylesheet href="demo.xslt" type="text/xsl"?>. Firefox 3 puede hacerlo. Internet Explorer 8 también puede hacerlo.

Significa que es posible migrar el procesamiento XSL del servidor al lado del cliente para el 50% de los usuarios (de acuerdo con las estadísticas del navegador en varios sitios web en los que podría querer implementar esto). Significa que el 50% de los usuarios recibirán solo el archivo XML en cada solicitud, reduciendo así el ancho de banda de ellos y del servidor (el archivo XML es mucho más corto que su análogo HTML procesado) y el uso de la CPU del servidor.

¿Cuáles son los inconvenientes de esta técnica?

Pensé en varios, pero no se aplica en esta situación:

• Implementación difícil y la necesidad de elegir, en función de la solicitud del navegador, cuándo enviar XML sin formato y cuándo transformarlo a HTML. Obviamente, el sistema no será mucho más difícil que el actual. El único cambio a realizar es agregar un enlace de archivo XSL a cada XML y agregar una verificación del navegador.
• Más IO y uso de ancho de banda, ya que el archivo XSLT será descargado por los navegadores, en lugar de ser almacenado en caché por el servidor. No creo que sea un problema, ya que el archivo XSLT será almacenado en caché por los navegadores (como las imágenes o CSS, o los archivos JavaScript están almacenados en caché).
• Posiblemente algunos problemas en el lado del cliente, como quizás problemas al guardar una página en algunos navegadores.
• Dificultad para depurar código: es imposible obtener una fuente HTML que el navegador esté utilizando, ya que la única fuente que se muestra es el XML descargado. Por otro lado, rara vez busco código HTML en el lado del cliente y, en la mayoría de los casos, no se puede usar directamente (se elimina el espacio en blanco).

Los navegadores no pueden renderizar XSLT progresivamente

Esto significa que nada más se carga y no se muestra nada hasta que se carguen y procesen todos los datos y toda la hoja de estilo.

Te estás perdiendo el renderizado progresivo y la captación previa de imágenes, CSS y JS.

La carga inicial se retrasa por otra solicitud

Para los archivos de ish pequeños (<20kb), el número de solicitudes, no el ancho de banda, es el cuello de botella para el rendimiento front-end, y la mayoría de las páginas y hojas de estilo se incluirán en esta categoría.

Si tiene páginas grandes, entonces es aún peor: vea el primer punto.

Probablemente no esté ahorrando ancho de banda

XSLT en sí es bastante detallado y podría necesitar contener plantillas para todo el sitio y lógica para todos los casos raros, no solo los elementos utilizados en la página actual.

Todavía tiene que incluir todos los datos marcados en el archivo XML principal que está enviando, por ejemplo, si está enviando una publicación de blog, entonces no hay magia que XSLT pueda hacer para hacerlo sustancialmente más pequeño. Si está enviando datos complejos, tendrá muchas marcas de todos modos.

Los cachés están sobrevalorados

Las memorias caché del navegador no son tan buenas :

El 40-60% de los usuarios de Yahoo! Tienen una experiencia de caché vacía y ~ 20% de todas las visitas a la página se realizan con una caché vacía.

y en dispositivos móviles, donde la latencia hace que las solicitudes adicionales sean más caras, los cachés son aún peores .

Verifique su tasa de rebote: esos son usuarios que no se benefician de XSLT en caché e incluso pagan un precio adicional para descargar la hoja de estilo y esperar a que se procese.

gzip es un XSLT inverso

La mayoría de las transformaciones realizadas a través de XSLT se reducen a cambiar el marcado conciso a uno más detallado y agregar repetición. ¡Pero gzip es excelente para eliminar la repetición / redundancia de los archivos!

Debería usar gzip de todos modos (es un desperdicio enviar XML sin comprimir). Es muy probable que el tamaño comprimido del documento procesado sea aproximadamente igual al tamaño comprimido del XML no procesado, pero no tendrá que enviar XSLT adicional, y los navegadores podrán comenzar a procesar tan pronto como lleguen los primeros paquetes.

Los clientes pueden ser lentos

Incluso suponiendo el mejor caso de carga desde la caché, el procesamiento XSLT en el lado del cliente es más rápido solo si la CPU del usuario es más rápida y su motor XSLT es más rápido.

En el lado del servidor, puede hacer todo tipo de trucos de optimización (por ejemplo, fragmentos procesados ​​en caché o incluso páginas enteras). Puede usar el procesador XSLT más reciente y más rápido (los navegadores solo tienen XSLT 1.0 y probablemente no estén muy optimizados). Y su servidor probablemente tenga una CPU más robusta que muchas computadoras de oficina, teléfonos, etc.

No hay ninguna razón por la cual hacer este lado del servidor no debería escalar tan bien como generar HTML directamente. Tampoco hay muchas razones para una gran sobrecarga constante en comparación con PHP. Aparentemente hay compiladores XSLT> JVM / CLR y supongo que incluso podría traducirlo a código nativo.

Sin embargo, la idea de transportar datos y estructura de presentación por separado es buena como tal.
Puede ahorrar mucho ancho de banda e incluso el rendimiento del servidor. Pero pomeL ha mencionado varios puntos.

Para el soporte adecuado al otro lado de los navegadores, xslt.js podrían ayudar.

Personalmente, no soy fanático de XML, por lo que usaría JSON en su lugar y un motor de plantillas JS, que se ejecutará en el navegador. O algún tipo de motor de plantillas, que convierte el marcado de plantillas en js ejecutables en el lado del servidor, que se usa para renderizar en el lado del cliente.
JavaScript es razonablemente rápido y está disponible prácticamente en todas partes. JSON y JS son mucho más compactos que XML y XSLT.

Enviar XML compacto y tener un XSLT en caché en el cliente puede incluso salvar su ancho de banda.

Dejas de lado cualquier navegador que no sea compatible con XSLT, como los teléfonos inteligentes. Pero debe crear una versión especializada para estos de todos modos.

El problema principal solía ser que solo unos pocos navegadores lo soportaban bien, por lo que no valía la pena crear una nueva plataforma de soporte. Además, las versiones anteriores de IE no admitían esto bien, y si recuerdo correctamente, al menos un IE tenía un dialecto XSLT diferente que causaba todo tipo de problemas divertidos.