Встроенный только критический CSS или все 15 КБ CSS, когда первое представление страницы является наиболее важным?

Question

Мне было интересно, будет ли хорошей идеей разделить мой CSS на две части: встроенную критическую и отложенную внешнюю.

Весь мой CSS - 15kb (минимизированный). Критический CSS, который дает мне онлайновый анализатор "Critical Path CSS Generator", составляет 1 КБ, но когда я проверяю свой код, я действительно считаю, что 5 КБ CSS необходимо для рендеринга всего вышеперечисленного сгибаемого контента на экране 1920x1080. Итак, мое первое беспокойство: стоит ли разделять CSS, когда одна треть от него нужна как критический CSS, или я просто добавлю весь CSS, учитывая, что он не такой большой (15 КБ)?

С другой стороны, на чем я сконцентрировался, это одна часть нашего веб-сайта, на которой пользователям предлагается выполнить действие, а действие - перейти на другую часть веб-сайта, на которой установлена ​​другая CMS. Итак, для этой части, о которой я говорю, количество просмотров страниц для каждого пользователя не так велико: около 70% людей открывают здесь только одну страницу, а 92% открывают менее 4 страниц. Поэтому, я думаю, наличие внешнего кэшируемого CSS может быть менее важным в нашей ситуации. Наконец, у меня есть ощущение, что просмотр первой страницы - самый важный; если мы сможем немного увеличить его скорость, даже если он снизит скорость следующих страниц, это того стоит. Тем не менее, я не знаю, действительно ли наличие встроенного CSS вместо внешнего действительно влияет на скорость при использовании HTTP/2.

Итак, что бы вы предложили? Лучше ли разделить мой CSS и вставить только критическую часть или просто встроить весь файл? Спасибо за помощь.

Answer 1

Общее правило - отправляйте столько, сколько вам нужно - зачем отправлять ненужные данные и тратить время на загрузку и трафик? Так что, если вы можете встроить только свой критический CSS для 1 КБ, то сделайте это, если вам нужно 5 КБ, то продолжайте. Основная причина для включения полных 15 КБ состоит в том, чтобы избежать сложности определения критического или необходимого CSS, но вы, похоже, решили эту проблему.

Некоторые также спорят о сохранении критических данных для первой краски (включая встроенные CSS и HTML) в первых 14 КБ страницы - это связано с тем, как работает TCP, и с тем, что он может отправлять 10 пакетов первоначально, прежде чем он ожидает какой-либо подтверждение. Таким образом, все, что больше, чем 14 КБ, потребует подтверждения и так туда и обратно, и поэтому задержка. После этого сумма, которую TCP может отправить, прежде чем требовать подтверждения (CWND), растет в геометрической прогрессии, но начинается с малого. Лично я не уверен, что число 14 КБ остается верным; Для согласования SSL/TLS (при условии, что вы используете HTTPS) требуется часть из того, что 14 КБ также требуют обходов, а затем для HTTP/2 (опять же, при условии, что вы используете это) требуются дополнительные килобайты и обходы для отправки исходных сообщений, все до Ваш HTTP-запрос отправлен и получен. Таким образом, к тому времени, когда все это произойдет, размер окна будет либо частью 14 КБ, либо уже увеличился в геометрической прогрессии до большего размера. Тем не менее, общий принцип сохранения его как можно меньшего размера, чтобы позволить большей части страницы загружаться быстрее, все еще действителен - просто не обязательно фиксировать на этом числе 14 КБ.

Решите ли вы встроить CSS вообще, зависит только от вас. Увеличение скорости впечатляет, и вы правы в том, что первые просмотры страниц, как правило, более важны, но есть и недостатки, в том числе тот факт, что требуется шаг сборки, чтобы выяснить, какой CSS включить, а затем включить, факт дублирует данные на страницах, тот факт, что вам может понадобиться выпустить все веб-страницы с указанием их, если вы когда-нибудь измените свой CSS (в отличие от простого выпуска файла CSS)... и т. д. Лично, если только вы не очень занят и супер оптимизирован сайт (например, домашняя страница Google), я думаю, что сложность не стоит. Больше моих мыслей об этом здесь: https://www.tunetheweb.com/blog/inlining-css-is-not-for-me/

Меняется ли это в HTTP/2? Ну да и нет. Теоретически , мультиплексирование HTTP / 2 означает, что несколько запросов могут быть в движении одновременно, поэтому вам не нужно запускать другое соединение, чтобы запросить CSS, поэтому вам вообще может не потребоваться встроенное соединение. Тем не менее, для получения кода CSS после получения HTML-кода все еще требуется двусторонняя передача, поэтому он не такой быстрый, как встраивание, даже если он быстрее, чем HTTP/1.1 (где вам нужно будет дождаться полного завершения загрузки HTML-кода, чтобы разрешить подключение к использоваться для запроса CSS или запускать другое соединение с задержками TCP и HTTPS, что влечет за собой).

HTTP / 2 Push должен был решить эту проблему - сохранить CSS в виде отдельного файла, но когда запрашивается HTML, ответьте файлом HTML и файлом CSS (нажмите файл CSS). Никакой задержки туда и обратно и все же отдельный файл CSS - лучший из обоих миров. Реальность, как всегда, немного сложнее. Основная проблема заключается в том, как избежать повторного нажатия CSS для всех последующих страниц (что имеет те же недостатки, что и встраивание). Есть разные способы сделать это, но реализация на основе файлов cookie, вероятно, является лучшей и наиболее практичной на данный момент. Даже с этим есть другие сложности и ошибки, чтобы рассмотреть. Из-за этого HTTP/2 push не смогла по-настоящему стать заменой.