2016-07-13 9 views
4

Google Pagespeed жалуется, когда вы блокируете CSS во внешнем файле. В HTTP/1 это, вероятно, имеет смысл, но как насчет HTTP/2?Имеет ли значение критический уровень CSS?

Если вы встроили критический CSS (над словом), то эти байты по-прежнему нужно загружать, анализировать и все остальное, все перед оформлением документа.

С помощью протокола HTTP/2 нет необходимости создавать другое соединение, так как оно может быть использовано повторно, поэтому это не накладные расходы. Кроме того, при нажатии на сервер вы даже можете нажать файл CSS до его запроса.

Итак ... вкратце критический CSS все еще рекомендуется?


Я согласен с тем, что на тяжелых сайтах вы, вероятно, не хотите загружать все CSS. Например, если вы посещаете галерею, вам понадобится только gallery.css, а не profile.css, а не forum.css и т. Д. Но это управляемо с кусками и другими методами (и все еще используя внешние файлы css, нет необходимости встроить их)

Вложение также делает CSS не кэшируемым.

У меня пропало что-то?


Это не имеет ничего общего с возможным дубликатом вопросом. Тот, кто отметил это как дублирующийся, не знает, что такое критический CSS или, возможно, даже не прочитал этот вопрос.

+0

Этот вопрос является слишком широким, основанным на мнениях или требует обсуждения, и поэтому не относится к теме для переполнения стека. Если у вас есть конкретная, ответственная, проблема с программированием, предоставьте полную информацию. –

+0

Его не собираются загружать все файлы, о том, сколько времени требуется для загрузки этих файлов. – bobbybackblech

+0

Я спрашиваю, стоит ли использовать критический CSS для использования при использовании HTTP2. Этот вопрос не требует обсуждения вообще, кто-то может ответить на него, не будучи основанным на мнениях. –

ответ

0

Его не собираются загружать все файлы, о том, сколько времени требуется для загрузки этих файлов.

Если вы используете критический CSS, то CSS (Design) показан непосредственно, поэтому его действительно быстрее, чем сначала загружать файлы CSS, потому что CSS находится непосредственно в <head> вашей страницы, так что страница отображается напрямую, не блокируя ресурсы (например, загрузите большой файл CSS).

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

+0

Те же байты должны быть загружены любым способом. При нормальном методе (не вписывая критический путь) вы все равно можете иметь critical.css и main.css. И вы можете блокировать при загрузке критического.css внутри (те же байты должны загружаться против метода inlining) и отложить main.css для загрузки async с помощью js. Поэтому вложение не приносит никакой пользы. Одинаковые байты для загрузки. Inline = нет кеша. Нет встроенного с http2 = никаких новых подключений в любом случае + нажимать сервер –

+0

Как я уже сказал, это не о загрузке его о том, как рендеринг заблокирован, загрузив CSS с его дополнительным запросом.Если у меня есть встроенный CSS с, например, с 100 байтами для необходимых свойств CSS для отображения представления, это не блокирует рендеринг браузера. Поэтому представление отображается быстрее. CSS нужно загружать, конечно, конечно, но в это время сайт уже показан, потому что встроенный CSS и браузер не должны ждать, пока загрузится дополнительный файл CSS. – bobbybackblech

0

Да, он все еще может помочь. Много.

При загрузке HTML вам все равно нужно дождаться загрузки, затем обработать его, а затем сделать еще один запрос на файл CSS и дождаться загрузки.

Хотя загрузка дополнительных ресурсов происходит быстрее по протоколу HTTP/2, и при использовании большого количества дополнительных ресурсов для скачивания при использовании этого файла CSS-файл не может быть запрошен до тех пор, пока HTML файл загружен и обработан. Кроме того, файл CSS обычно определяется приоритетом браузера, поскольку он блокирует рендеринг, поэтому обычно это будет один из первых запрошенных ресурсов, что означает, что предотвращение заголовка блокировки строки для HTTP/2 не так полезно для ресурсов CSS.

Когда HTTP/2 Push становится более распространенным местом, он может не иметь такого большого влияния, как запросы на HTML-страницу также могут подтолкнуть файл CSS, необходимый для этого, но это добавило сложности, и есть еще некоторые вопросы относительно того, как это будет (например, если в браузере уже есть файл CSS, сервер должен каким-то образом не знать его).

Я написал сообщение в блоге на эту тему, если вы хотите более подробно об этом (и это на сайте HTTP/2): https://www.tunetheweb.com/blog/inlining-css-is-not-for-me/.Я все еще не большой поклонник этого процесса, как я объясняю в этой статье ...

1

Не встраивайте его, если это не имеет смысла. Я предполагаю, что вложение десяти строк css не убьет вас, но вложение эквивалента 18 kb сжатого gzip CSS - это просто безумие.

Просто используйте HTTP/2 Push, чтобы убедиться, что браузер получает CSS как можно раньше.

Худший случай HTTP/2 Push будет нажимать ресурс несколько раз, но браузеры сбросят токовые потоки, которые они считают свежими в кеше (используйте etags). Так что худший случай HTTP/2 Push все еще немного лучше, чем inlining.

Проблема кэша с HTTP/2 Клавишей в значительной степени ослабляется с использованием кэша дайджестов polyfill (до реальной вещи будет доступен в браузерах):

Мы используем его в производстве, и мы очень довольны.

Как правило, принимайте рекомендации по автоматической оптимизации с содержанием соли до тех пор, пока они не перейдут на HTTP/2.

1

Мне ничего не хватает?

Вы правы в общем, для современных браузеров и http 2. Для мобильных и старых браузеров, для gprs или других медленных соединений с высокой задержкой - не совсем. В некоторых случаях вы можете получить преимущество от меньшего количества загруженных документов и улучшить скорость разбора браузера, введя вложение .css. Кроме того, если вы динамически добавляете .css, и что-то пойдет не так, inlined .css все равно работает, то же самое верно для любых ресурсов, которые могут быть встроены в html.