¿Cuáles son los inconvenientes de enviar XML a los navegadores y permitirles aplicar XSLT?

14

Context

Trabajando como desarrollador independiente, a menudo hice 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 que está conectado actualmente, las entradas del menú superior, si este menú es dinámico / configurable, el texto que se mostrará en un área específica de la página, etc. Luego, XSL lo procesa (almacena en caché, etc.) a la página HTML / XHTML para enviarlo 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 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 en bruto bajo demanda para un acceso automatizado, sin la necesidad de crear API separadas.

Por supuesto, fallará completamente en cualquier sitio web de mediana o gran escala, ya que, incluso con buenas técnicas de almacenamiento en caché, XSL sigue degradando el rendimiento general del sitio web y requiere más CPUs del servidor.

Pregunta

Los navegadores modernos tienen la capacidad de tomar un archivo XML y transformarlo con un archivo XSL asociado declarado en XML como <?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 donde es posible que desee implementar esto). Significa que el 50% de los usuarios solo recibirán el archivo XML en cada solicitud, lo que reducirá su ancho de banda y el del servidor (el archivo XML será mucho más corto que su analógico HTML procesado) y reducirá 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 procesar y cuándo transformarlo en HTML en su lugar. Obviamente, el sistema no será mucho más difícil que el actual. El único cambio que se debe hacer es agregar el enlace del archivo XSL a cada XML y agregar una comprobación del navegador.
  • Más uso de IO y 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 los archivos XSLT se almacenarán en caché (como imágenes, o CSS, o los archivos JavaScript se almacenarán en caché en realidad).
  • Posiblemente algunos problemas en el lado del cliente, como problemas al guardar una página en algunos navegadores.
  • Dificultad para depurar el código: es imposible obtener una fuente HTML que el navegador realmente está usando, ya que la única fuente mostrada es el XML descargado. Por otro lado, rara vez veo el código HTML en el lado del cliente y, en la mayoría de los casos, no se puede usar directamente (se eliminan los espacios en blanco).
pregunta Arseni Mourzenko 27.12.2010 - 13:20

4 respuestas

26

Los navegadores no pueden mostrar XSLT progresivamente

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

Te estás perdiendo la reproducción progresiva y la captura previa de imágenes, CSS & JS.

La carga inicial se retrasa por otra solicitud

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

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

Probablemente no estés guardando ningún ancho de banda

XSLT en sí mismo es bastante detallado y es posible que deba contener plantillas para todo el sitio y lógica para todos los casos raros, no solo las cosas utilizadas en la página actual.

Aún debe 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 hacerla sustancialmente más pequeña. Si está enviando datos complejos, de todos modos, tendrá un montón de marcado.

Los cachés están sobrevalorados

Los cachés del navegador son no tan bueno :

  

40-60% de los usuarios de Yahoo! tienen una experiencia de caché vacía y ~ 20% de todas las vistas de 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: son usuarios que no se benefician con 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 el mismo que el tamaño comprimido comprimido del XML no procesado, pero no tendrá que enviar XSLT extra, y los navegadores podrán comenzar a renderizar tan pronto como lleguen los primeros paquetes.

Los clientes pueden ser lentos

Incluso suponiendo el mejor caso de carga desde la memoria 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, caché de fragmentos procesados 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. baratos

    
respondido por el Kornel 27.12.2010 - 14:17
3

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

Sin embargo, la idea de transportar los datos y la estructura de la 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 obtener asistencia adecuada en los navegadores, xslt.js podría ayudar.

Personalmente, no soy un fan de XML, así que usaría JSON y un motor de plantillas JS, que se ejecutará en el navegador. O algún tipo de motor de plantilla, que convierte el marcado de plantilla 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 virtualmente en todas partes. JSON y JS son mucho más compactos que XML y XSLT.

    
respondido por el back2dos 27.12.2010 - 16:16
2

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

Se omite cualquier navegador que no sea compatible con XSLT, como los teléfonos inteligentes. Pero debería crear una versión especializada para estos de todos modos.

    
respondido por el 9000 27.12.2010 - 13:33
1

El problema principal solía ser que solo algunos navegadores admitían este problema, por lo que no merecía la pena crear un nuevo soporte. Además, las versiones anteriores de IE no eran compatibles con esto, y si recuerdo correctamente, al menos un IE tenía un dialecto XSLT diferente que le daba todo tipo de problemas divertidos.

    
respondido por el user1249 27.12.2010 - 13:40

Lea otras preguntas en las etiquetas