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

Google PageSpeed ​​a menudo sugiere que optimizar la entrega de CSS. Se me ocurrió que reduciría los viajes de ida y vuelta de la red para alinear todo el 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>

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

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

Incluir todo su CSS significa que no se puede almacenar en caché, por lo que cada carga de una sola página contendrá todo el CSS requerido, y cuando usa bibliotecas grandes, eso realmente puede ser una gran cantidad de ancho de banda desperdiciado. Por ejemplo, Bootstrap ronda los 120k. Tenga en cuenta que el enlace de Google que compartió especifica lo siguiente (énfasis mío):

Si los recursos CSS externos son pequeñospuede insertarlos directamente en el documento HTML, lo que se denomina inserción.

Por lo tanto, la carga de una sola página puede ser más rápida, pero en general es probable que sea 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 único viaje adicional al servidor para su CSS y todas las páginas futuras solicitadas por el navegador no necesitará volver a solicitarlos.

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 pensar la página 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 página se cargue más rápido. Desde la perspectiva de la experiencia del usuario, esto es mucho más importante que hacer que la carga tarde menos tiempo. No importa si toda la página tarda 500 ms en cargarse, porque de todos modos un humano no puede analizarla tan rápido. 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 muestre correctamente. Es decir, hay algunas reglas de css que hacen que las imágenes tengan el tamaño correcto, que hacen que las cosas floten correctamente, que evitan esa apariencia horrible del contenido de la página saltando alrededor de la página mientras el SDK de Facebook termina su trabajo. 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 coloque en línea todo el css. Puede haber otros 100kb que se carguen más tarde, si ese css solo diseña el contenido que se carga de forma asíncrona 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.

No entendiste la sugerencia de PageSpeed. La recomendación es para archivos CSS pequeños:

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

De hecho, el artículo más adelante sugiere un enfoque equilibrado para archivos CSS grandes: CSS crítico en línea y carga diferida del 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 duplicas el <style>...</style> etiqueta a través de las páginas. Esto significa que proporciona 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 almacenen en caché el archivo CSS en la vista de la primera página y que 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.

El 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 (p. ej., IIS) y software (p. ej., 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 (p. ej., archivos CSS). Esta es otra razón más por la que debe mantener CSS en un archivo separado.

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

* No debe confundirse con estilos en línea

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