velocidad test sitio rocket rapido plugin para pagina optimizar metrix cargar carga aumentar acelerar c# html css asp.net-mvc pagespeed

c# - sitio - test de velocidad pagina web



¿Debo alinear todos los archivos CSS mediante programación para optimizar la velocidad de carga de la página? (4)

Google PageSpeed ​​a menudo sugiere optimizar la entrega de CSS . Se me ocurrió que reduciría los viajes de ida y vuelta de la red para alinear todos los CSS de esta manera:

<style type="text/css"> @{ var bootstrap = File.ReadAllText(Server.MapPath("bootstrap.min.css")); var bootstrapTheme = File.ReadAllText(Server.MapPath("theme.min.css")); var fontAwesome = File.ReadAllText(Server.MapPath("font-awesome.min.css")); var bigfont = File.ReadAllText(Server.MapPath("bigfont.min.css")); var bigfontPrint = File.ReadAllText(Server.MapPath("bigfont-print.min.css")); } @Html.Raw(bootstrap) @Html.Raw(bootstrapTheme) @Html.Raw(fontAwesome) @Html.Raw(bigfont) @Html.Raw(bigfontPrint) </style>

Esto parece ser una solución razonable al problema de la carga lenta de la página y ha aumentado mi puntaje de PageSpeed ​​a 95 de 88.

Dejando a un lado el estilo de código por el momento, ¿qué razones técnicas, si las hay, existen para NO incluir todo CSS de esta manera?


Al incluir todo su CSS significa que no se puede almacenar en caché, por lo que cada carga de la página contendrá todo el CSS requerido, y cuando use bibliotecas grandes, realmente se puede desperdiciar mucho ancho de banda. Por ejemplo, Bootstrap es de alrededor de 120k. Tenga en cuenta que el enlace de Google que compartió especifica lo siguiente (el énfasis es mío):

Si los recursos externos de CSS son pequeños , puede insertarlos directamente en el documento HTML, que se denomina en línea.

Por lo tanto, una sola carga de página puede ser más rápida, pero en general es más lenta.

Personalmente, me mantendría alejado de hacer eso. Sin embargo, una cosa que puede hacer es agrupar todo su CSS en una sola solicitud (está utilizando MVC, por lo que es relativamente simple), por lo que solo tiene que hacer un solo viaje adicional al servidor para su CSS y todas las páginas futuras solicitadas por el navegador no tendrá que volver a solicitarlos.


Esto es demasiado largo para caber en un comentario. Allí donde trabajo, utilizamos directivas de encabezado de Política de seguridad de contenido (específicamente style-src ) para prohibir explícitamente el uso de CSS en línea. La razón de no utilizar CSS en línea en este caso es minimizar los riesgos de inyección de CSS para páginas creadas dinámicamente. OWASP tiene información detallada sobre este tema, incluidas muestras de exploits: https://www.owasp.org/index.php/Testing_for_CSS_Injection_(OTG-CLIENT-005) . Si solo se sirve contenido estático en el navegador, no debería haber ningún riesgo.


Nadie ha mencionado el caso de uso previsto para esta técnica, que definitivamente no es cargar el 100% de su CSS. Más bien, esta técnica está destinada a hacer que los usuarios piensen que la página se ha cargado más rápido.

Cuando hablamos de hacer que las páginas se carguen más rápido, el objetivo real generalmente es hacer que la carga de la página parezca más rápida. Desde la perspectiva de la experiencia del usuario, esto es mucho más importante que hacer que la carga tome menos tiempo. No importa si la página completa tarda 500 ms en cargarse, porque un humano no puede analizarla tan rápido de todos modos. Lo que importa es qué tan rápido parece haberse cargado la página.

Entonces, el uso apropiado de esta técnica es cargar, de inmediato, el CSS absolutamente esencial para que la página se procese correctamente. Es decir, hay algunas reglas CSS que hacen que las imágenes tengan el tamaño correcto, que hacen que las cosas floten correctamente, que evitan la horrible aparición del contenido de la página saltando mientras el SDK de Facebook termina su negocio. Ese código debe estar presente en el mismo instante en que se carga el marcado. Solución: en línea ese css crítico.

Pero definitivamente NO alinee todos los css. Puede haber otros 100kb que se carguen más tarde, si ese CSS solo estiliza el contenido que se está cargando de forma asincrónica de todos modos. Pero si hay una estructura de página que debe estar en la forma correcta después de 25 ms, ese CSS debe estar en línea.


Usted no entendió la sugerencia de PageSpeed. La recomendación es para pequeños archivos CSS:

Si los recursos externos de CSS son pequeños, puede insertarlos directamente en el documento HTML, que se denomina en línea. [...] Tenga en cuenta que si el archivo CSS es grande, alinear completamente el CSS puede hacer que PageSpeed ​​Insights advierta que la parte superior de la página de su página es demasiado grande a través de Priorizar contenido visible.

De hecho, el artículo más tarde sugiere un enfoque equilibrado para archivos CSS grandes: CSS crítico en línea y diferir-cargar el archivo CSS restante.

Ahora, incluso si PageSpeed ​​le da una puntuación decente después de incluir grandes archivos CSS *, podría ser una mala idea:

Redundancia

Los archivos CSS en línea significan que duplica la etiqueta <style>...</style> en las páginas. Esto significa que sirve datos redundantes para vistas de página posteriores o repetidas. Los datos redundantes cuestan ancho de banda y aumentan el tiempo de descarga.

El archivo CSS separado junto con fuertes encabezados de almacenamiento en caché le permiten eliminar la redundancia. Los encabezados de almacenamiento en caché indican a los navegadores que guarden en caché el archivo CSS en la vista de la primera página y lo reutilicen en vistas de página posteriores o repetidas.

Contenido vs datos

Los archivos CSS en línea reducen la proporción de contenido "real" en la página. Los archivos CSS en línea requieren que inserte el CSS sobre el contenido, mientras que la mayoría de nosotros nos esforzamos por colocar el contenido real cerca del HTML superior.

CSS en línea también hará que el navegador descargue bytes adicionales antes de permitirle descargar otros recursos como JavaScript e imágenes.

Costo de compresión

Si su página HTML se genera dinámicamente, lo más probable es que se sirva sin comprimir. Algunos servidores (por ejemplo, IIS) y software (por ejemplo, Wordpress) permiten la compresión de contenido dinámico, pero requieren más CPU + Memoria en comparación con la compresión de contenido estático (por ejemplo, archivos CSS). Esta es otra razón por la que debe mantener CSS en un archivo separado.

Por las razones anteriores, mantendría mi CSS combinado, minimizado, comprimido y en caché, en un archivo separado, incluso para sitios web de una página.

* No debe confundirse con los estilos en línea.