Должен ли я встроить все файлы CSS программно, чтобы оптимизировать скорость загрузки страницы?

Google PageSpeed часто предлагает оптимизировать доставку CSS. Мне пришло в голову, что это уменьшит количество поездок в сети, чтобы встроить все CSS следующим образом:

<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>

Это, кажется, разумное решение проблемы медленных нагрузок страниц и увеличило мою оценку по параметрам PageSpeed до 95 из 88.

Надевая код в сторону на данный момент, какие технические причины, если таковые имеются, существуют для НЕ ПОДКЛЮЧЕНИЯ всех CSS таким образом?

Ответ 1

Вложение всех ваших CSS означает, что он не может быть кэширован, поэтому каждая загрузка одной страницы будет содержать весь необходимый CSS, а также когда вы используете большие библиотеки, которые действительно могут быть большой тратой впустую. Например, Bootstrap составляет около 120 тыс. Обратите внимание, что ссылка Google, которую вы использовали, указывает следующее (основное внимание):

Если внешние ресурсы CSS небольшие, вы можете вставить их непосредственно в HTML-документ, который называется inlining.

Таким образом, загрузка одной страницы может быть более быстрой, но в целом она, вероятно, будет медленнее.

Лично я бы держался подальше от этого. Тем не менее, одна вещь, которую вы можете сделать, это расслоение всего вашего CSS на один запрос (вы используете MVC так, чтобы это было относительно просто), поэтому вам нужно сделать только одну дополнительную поездку на сервер для вашего CSS и всех будущих страниц, запрошенных браузеру не нужно будет запрашивать их снова.

Ответ 2

Никто не упомянул предполагаемый прецедент для этого метода, который определенно не загружает 100% вашего css. Скорее, эта техника призвана заставить пользователей думать, что страница загрузилась быстрее.

Когда мы обсуждаем, как быстрее загружаются страницы, реальная цель состоит в том, чтобы сделать загрузку страницы быстрее. С точки зрения пользовательского опыта это гораздо важнее, чем на самом деле сделать нагрузку меньше времени. Не имеет значения, загружается ли вся страница на 500 мс, потому что человек не может ее разобрать так быстро. Важно то, как быстро загрузилась страница.

Таким образом, соответствующее использование этого метода заключается в том, чтобы немедленно загрузить абсолютно необходимый css, чтобы сделать страницу рендерингом правильно. То есть, есть некоторые правила CSS, которые делают изображения правильными, что делает вещи плавать правильно, чтобы избежать этого ужасного появления содержимого страницы, прыгающего по странице, в то время как facebook SDK заканчивает свой бизнес. Этот код должен присутствовать в тот же момент, когда загружается разметка. Решение: встроенный критический css.

Но определенно НЕ Встраивайте все css. Может быть еще 100 килобайт, который загружается позже, если этот CSS-контент содержит только стили, которые по-прежнему загружаются асинхронно. Но если структура страницы должна быть в правильной форме после 25 мс, то css должен быть встроен.

Ответ 3

Вы неправильно поняли предложение PageSpeed. Рекомендация заключается в небольших файлах CSS:

Если внешние ресурсы CSS невелики, вы можете вставить их напрямую в HTML-документ, который называется inlining. [...] Иметь ввиду если файл CSS большой, полностью инкрустировать CSS может PageSpeed Insights, чтобы предупредить, что вышеприведенная часть вашего страница слишком велика, выбрав "Приоритеть видимого содержимого".

В самом деле, статья позже предлагает сбалансированный подход для больших файлов CSS: встроенный критический CSS и отложить загрузку оставшегося файла CSS.

Теперь, даже если PageSpeed дает вам приличный результат после вложения больших файлов CSS *, это может быть плохой идеей:

Избыточность

Встроенные CSS файлы означают дублирование тега <style>...</style> на разных страницах. Это означает, что вы обслуживаете избыточные данные для последующих или повторных просмотров страниц. Избыточные данные требуют пропускной способности и увеличения времени загрузки.

Отдельный файл CSS вместе с сильными заголовками кеширования позволяет устранить избыточность. Заголовки кэширования дают указание браузерам кэшировать файл CSS при просмотре первой страницы и повторное использование при последующих или повторных просмотрах страниц.

Содержимое vs Datah3 >

Встроенные файлы CSS уменьшают долю "фактического" содержимого на странице. В строковых CSS файлах вам нужно вставлять CSS над содержимым, в то время как большинство из нас стремится разместить фактическое содержимое возле верхнего HTML.

Inline CSS также заставит браузер загружать дополнительные байты, прежде чем позволить ему загружать другие ресурсы, такие как JavaScript и изображения.

Стоимость сжатия

Если ваша HTML-страница генерируется динамически, то, скорее всего, она будет подана без сжатия. Некоторые серверы (например, IIS) и программное обеспечение (например, Wordpress) позволяют сжимать динамический контент, но требуют большего количества памяти CPU + по сравнению со сжатием статического содержимого (например, файлов CSS). Это еще одна причина, почему вы должны сохранять CSS в отдельном файле.

По вышеуказанным причинам я бы сохранил свой CSS комбинированный, миниатюрный, сжатый и кэшированный в отдельном файле даже для веб-сайтов с одной страницей.

* Не путать с встроенными стилями

Ответ 4

Это слишком долго, чтобы вписаться в комментарий. Там, где я работаю, мы используем директивы заголовка Content Security Policy (в частности style-src), чтобы явно запретить использование встроенного CSS. Обоснованием не использовать встроенный CSS в этом случае является минимизация рисков внедрения CSS для динамически создаваемых страниц. OWASP имеет подробную информацию об этой теме, включая примеры использования: https://www.owasp.org/index.php/Testing_for_CSS_Injection_(OTG-CLIENT-005). Если в браузер используется только статический контент, риск не должен быть.