Javascript y el rendimiento de análisis de CSS

Question

Estoy tratando de mejorar el rendimiento de una aplicación web. Tengo métricas que puedo usar para optimizar el tiempo necesario para devolver la página HTML principal, pero me preocupan los archivos CSS y JavaScript externos que se incluyen en estas páginas HTML. Estos se sirven de forma estática, con encabezados de HTTP Expires, pero se comparten entre todas las páginas de la aplicación.

Me preocupa que el navegador tenga que analizar estos archivos CSS y JavaScript para cada página que se muestra y tener todos los CSS y JavaScript compartidos en archivos comunes afectará negativamente el rendimiento. ¿Debería tratar de dividir estos archivos para vincular desde cada página solo el CSS y JavaScript necesarios para esa página, o obtendría poco rendimiento por mis esfuerzos?

¿Hay alguna herramienta que pueda ayudarme a generar métricas para esto?

Answer 1

Contexto: Si bien es cierto que los gastos generales HTTP es más significativo que el análisis JS y CSS, ignorando el impacto de analizar el rendimiento del navegador (incluso si tiene menos de un mega de JS) es una buena manera de conseguirse en problemas.

YSlow, Fiddler y Firebug no son las mejores herramientas para controlar la velocidad de análisis. A menos que se hayan actualizado recientemente, no separan la cantidad de tiempo requerida para obtener JS sobre HTTP o cargar desde la memoria caché en comparación con la cantidad de tiempo dedicado al análisis de la carga real de JS.

La velocidad de Parse es un poco difícil de medir, pero hemos seguido esta métrica varias veces en proyectos en los que he trabajado y el impacto en las cargas de página fue significativo incluso con ~ 500k de JS. Obviamente, los navegadores más antiguos son los que más sufren ... con suerte Chrome, TraceMonkey y otros similares ayudan a resolver esta situación.

Sugerencia: Dependiendo del tipo de tráfico que tiene a su sitio, puede ser bien vale la pena su tiempo para dividir su carga útil JS por lo que algunas grandes trozos de JS que nunca serán usados ​​en una de las páginas más populares nunca se envían al cliente. Por supuesto, esto significa que cuando un nuevo cliente acceda a una página donde se necesita este JS, deberá enviarlo por cable.

Sin embargo, puede ser que, por ejemplo, el 80% de sus usuarios nunca necesite el 50% de sus JS debido a sus patrones de tráfico. Si esto es así, definitivamente debes utilizar cargas útiles JS más pequeñas y empaquetadas solo en las páginas donde el JS es necesario. De lo contrario, el 80% de los usuarios sufrirán penalizaciones de análisis de JS innecesarias en por cada carga de página.

línea de base: Es difícil encontrar el equilibrio adecuado de JS almacenamiento en caché y, cargas útiles envasados ​​más pequeños, pero dependiendo de su patrón de tráfico que es definitivamente vale la pena considerar una técnica que no sea rompiendo todas sus JS en cada pageload.

Answer 2

Creo que YSlow lo hace, pero tenga en cuenta que a menos que todas las solicitudes se realicen a través de una conexión de bucle invertido, no debe preocuparse. La sobrecarga HTTP de los archivos divididos tendrá un impacto en el rendimiento ahora más que en el análisis, a menos que los archivos CSS/JS excedan varios megabytes.

Answer 3

Para agregar a la gran respuesta de kamen, diría que en algunos navegadores, el tiempo de análisis para recursos js más grandes crece de forma no lineal. Es decir, un archivo JS de 1 meg tardará más en analizar que dos archivos de 500k. Por lo tanto, si gran parte del tráfico es de gente que probablemente almacenará en caché su JS (visitas de retorno) y todos sus archivos JS son estables en caché, puede tener sentido dividirlos incluso si termina cargando todos ellos en cada página vista.