Каков критический путь рендеринга?
Оптимизация этих событий приводит к значительному ускорению веб-страниц.
Критический путь рендеринга может сделать очень замечательную вещь...
Это дает вам возможность сделать большую веб-страницу с большим количеством ресурсов загружаемой быстрее, чем небольшую веб-страницу с небольшим количеством ресурсов. Мне нравится такой расклад.
Поскольку большинство веб-страниц имеют множество различных компонентов, не всегда возможно просто удалить все, чтобы страница загружалась быстрее. Если вы когда-нибудь задавались вопросом: «Что еще я могу сделать, чтобы мои страницы работали быстро?» или «Как Google ожидает, что страницы будут загружаться за одну секунду?» то эта концепция для вас.
Оптимизация критического пути рендеринга
Чтобы было ясно, давайте определим несколько вещей:
Другими словами, путь рендеринга — это просто серия событий, которые происходят, чтобы ваша веб-страница отображалась в браузере.
Поскольку практически каждый веб-сайт в Интернете требует ненужных шагов для рендеринга, именно здесь может произойти действительно значимая и заметная оптимизация.
Оптимизация критического пути рендеринга может сократить время загрузки страницы на несколько секунд. Это действительно самый быстрый путь к более быстрым веб-страницам.
Путь
Чтобы отобразить веб-страницу, браузер должен получить все ресурсы, которые вызывает веб-страница. Простым примером может быть веб-страница с одним изображением, одним файлом css и одним файлом javascript.
Давайте посмотрим на путь, который проходит эта страница, прежде чем она будет отображена....
- браузер скачивает html файл
- браузер читает html и видит, что есть один файл css, один файл javascript и одно изображение
- браузер начинает загрузку изображения
- браузер решает, что он не может отображать веб-страницу без предварительного получения css и javascript
- браузер загружает файл CSS и читает его, чтобы убедиться, что больше ничего не вызывается
- браузер решает, что он все еще не может отображать веб-страницу, пока не будет установлен javascript
- браузер загружает файл javascript и читает его, чтобы убедиться, что больше ничего не вызывается
- Браузер теперь решает, что может отображать веб-страницу
Путь выше предназначен для очень простой веб-страницы, теперь представьте, как должен выглядеть ваш путь.
Вероятно, у вас есть социальные кнопки, несколько файлов CSS, несколько файлов javascript, множество изображений, виджетов и, возможно, аудио или видео.
Это означает, что ваш путь рендеринга, вероятно, представляет собой большой беспорядок.
Большинство веб-сайтов имеют совершенно ужасные пути рендеринга, потому что они вызывают так много вещей, которые браузер должен загрузить, прежде чем веб-страница может быть отображена.
Это ваше преимущество перед другими. Если вы сделаете свои страницы быстрее, чем ваши конкуренты, вы сделаете посетителей счастливыми (Google любит, когда вы это делаете).
Рендеринг
Есть определенные типы ресурсов, которые вызывают наши веб-страницы, которые фактически блокируют рендеринг наших веб-страниц.
Двумя наиболее распространенными являются файлы CSS и файлы javascript.
Независимо от того, сколько из них у вас есть, браузер должен загрузить и проанализировать каждый из этих файлов, прежде чем он сможет что-либо показать пользователю. Давайте рассмотрим самый распространенный сценарий...
Блоги Wordpress используют темы. Почти каждая тема WordPress имеет несколько файлов css.
У многих есть шесть или семь файлов css (вот почему существует руководство по скорости страницы «объединять внешние файлы CSS»). Весь этот CSS может быть только в одном файле, но когда вы добавляете свою тему, дело в том, что она имеет несколько файлов CSS. Таким образом, прежде чем отобразится хотя бы одна буква вашего блога, браузер должен загрузить и проанализировать (прочитать) каждый из этих файлов, что означает шесть или семь циклов обращения к серверу только для того, чтобы начать работу. Это известно как блокировка рендеринга css.
Посетитель вашей страницы смотрит на пустой белый экран, пока это происходит, потому что ничего не появится, пока не будут выполнены эти «критические» шаги.
Но даже после того, как ваш css загружен, ваш блог еще не может отображаться, потому что темы WordPress, как известно, также содержат несколько файлов javascript. Страница по-прежнему не будет отображаться, так как во многих случаях она получает файлы javascript. Это называется блокировкой рендеринга javascript.
Таким образом, для типичного рендеринга страницы блога WordPress может потребоваться двадцать с лишним циклов, чтобы просто получить основные файлы CSS и javascript. Но подождите, теперь у вас также есть социальные кнопки или виджеты... о, о, для каждого из них также необходимы несколько ресурсов CSS и javascript.
Вы можете загрузить десятки вещей, прежде чем ваш пост увидит пользователь. Ой.
Но это касается не только WordPress, я просто использую их в качестве примера. Довольно часто бывает несколько запросов на ресурсы, необходимые для первоначального просмотра веб-страницы.
Эти задержки рендеринга вашего контента можно контролировать, это и есть критический путь рендеринга.
Критический
До сих пор я нарисовал очень мрачную картину, но хорошая новость заключается в том, что вы можете вызвать миллион вещей для своей веб-страницы, и она может иметь 12000 изображений, 200 файлов javascript, и страница все еще может загружаться за секунду или около того.
Как это достигается?
Понимая, что критично для вашей веб-страницы, чтобы отображать вышеуказанное содержимое сгиба / начального просмотра.
Оптимизация пути рендеринга
На самом деле есть только три вещи, на которых нужно сосредоточиться 1...
Примеры
Изображения. Даже если на странице 12 000 изображений, только одно или два из них, скорее всего, будут видны в верхней части сгиба (критично). Это означает, что если мы сконцентрируемся на этих двух изображениях, мы сможем значительно ускорить начальную загрузку страницы. Нам не нужно показывать 12000 изображений, нам нужно показать только те одно или два, которые есть в исходном виде. Остальные могут быть отложены или загружены лениво.
Файлы Javascript. Их тоже может быть 12 000, но сначала мы должны загружать только те, которые имеют решающее значение для отображения верхней части нашей веб-страницы, а остальные 11 998 файлов javascript можно отложить.
CSS-файлы. Лучший способ минимизировать CSS-файлы — это не онлайн-инструмент, а в первую очередь не использовать их слишком много. Вполне вероятно, что ваши страницы используют менее 20% вашего CSS. Хотя есть варианты. Объединяя некоторые из ваших внешних файлов CSS, вы можете уменьшить количество файлов, необходимых для рендеринга. Вы также можете встроить часть вашего CSS в свой html. Независимо от того, насколько большой или маленький ваш CSS, вашим пользователям придется ждать, пока он загрузится, чтобы увидеть вашу страницу.
Ниже мы рассмотрим веб-страницу и посмотрим, как мы можем использовать наши знания о критическом пути, чтобы значительно ускорить ее загрузку.
Понимание измерения скорости страницы
Когда Google говорит о скорости страницы, они не имеют в виду общее время, необходимое для загрузки веб-страницы. Что их волнует, так это то, как быстро пользователь начинает видеть контент на этой странице (первоначальный просмотр) и как быстро пользователь может начать взаимодействовать с этим контентом.
Причина, по которой Google начал использовать скорость страницы в качестве фактора ранжирования 2 , основана на удовлетворенности их пользователей. Это не очень хороший опыт для тех, кто ищет что-то в Google, когда их отправляют на страницу, которая загружается вечно.
Люди жалуются на это в Google, мол "Почему ты отсылаешь меня на страницу, которая ооочень медленно загружается?". Это известно как воспринимаемая скорость.
Если пользователь просматривает пустую белую веб-страницу в течение 10 секунд, ожидая ее загрузки, это плохо, и Google не хочет показывать эту страницу в своих результатах. Если бы эта же веб-страница отображала информацию в первую секунду, это было бы здорово, и Google хотел бы, чтобы она отображалась в их результатах.
Наша главная забота, когда мы говорим о скорости веб-страницы, заключается в том, чтобы как можно быстрее доставить контент пользователю в начальном виде.
Реальный пример оптимизации критического пути рендеринга
Веб-страница, которую вы сейчас читаете, будет нашим примером. Эта страница отображается менее чем за полсекунды, но она выполняет довольно много функций, которые делают ваши веб-страницы.
Я покажу вам две версии этой веб-страницы, одна версия не будет оптимизирована для критического пути рендеринга, а другая версия (страница, которую вы читаете) оптимизирована.
Это даст вам отличное сравнение того, насколько значительными могут быть изменения. Это также хорошо иллюстрирует, как Google измеряет загрузку страницы, что интересно и полезно знать.
Эта страница использует несколько вызовов javascript, довольно распространенных, давайте посмотрим, что использует эта страница...
Короче говоря, я использую основные вещи, которые нужны людям на их веб-страницах (изображения, css, мониторинг, аналитика). Вероятно, вы используете одни и те же материалы на своих страницах. Оптимизируя критический путь, я на самом деле собираюсь сократить все эти вызовы и все эти вещи до одного запроса. Все, что нужно браузеру для отображения этой страницы — это html-файл. Один-единственный маленький файл размером 12 КБ, и эта страница загружается почти сразу.
С другой стороны, неоптимизированная версия этой страницы будет делать десятки запросов и обращений туда и обратно, загрузка на настольных компьютерах займет больше времени, а загрузка на мобильных устройствах займет значительно больше времени... Тем не менее, две версии этого страница будет иметь точно такой же контент и делать то же самое!
Давайте включим нашего гика и покажем результат...
Неоптимизированная версия этой страницы
Время рендеринга: 2,1 секунды.
Примечание. Страница отображается пользователю только после того, как все эти файлы будут загружены (представлено светло-голубой вертикальной линией в крайнем правом углу изображения).
Справа вы увидите, сколько запросов делает неоптимизированная версия этой страницы. Неоптимизированная версия загружается за 2,1 секунды, и ее можно найти здесь , если вы хотите увидеть исходный варинат и то, как загружается страница. Страница представляет собой довольно простую статическую веб-страницу, но для ее загрузки по-прежнему требуется 20 запросов. Это означает, что страница должна дождаться загрузки 20 файлов, прежде чем пользователь сможет ее увидеть.
Обратите внимание, что браузер сначала загружает html, затем css, затем изображения, затем переходит к файлам javascript, которые все должны быть загружены и проанализированы до того, как пользователь увидит страницу.
Эта неоптимизированная версия вообще не обращает внимания на критический путь рендеринга, поэтому в основном все вызываемые файлы должны быть загружены до рендеринга страницы.
Оптимизированная версия этой страницы
Время рендеринга: 0,25 секунды (250 миллисекунд)
Примечание. Страница отображается пользователю после загрузки всего одного файла (обозначается светло-голубой вертикальной линией в середине изображения).
Оптимизированная версия этой страницы (та, которую вы сейчас читаете) делает только один вызов для начального просмотра страницы. Страница показывается пользователю в пять раз быстрее (обозначена светло-голубой вертикальной линией на диаграмме), но выполняет все то же самое. Он по-прежнему загружает большинство тех же файлов, использует те же javascripts, но разница в том, что пользователю показывается страница всего за 250 миллисекунд (четверть секунды). Это в пять раз быстрее, чем неоптимизированная страница. Если ваша страница загружается 5 секунд, вы, вероятно, можете сделать так, чтобы она загружалась менее чем за секунду. Похоже на магию, да?
Как я исправил свою веб-страницу?
Я посмотрел на свою страницу и спросил себя: «Что действительно нужно этой странице, чтобы загружать только то, что находится выше содержимого сгиба?» Я понял, что следующие вещи определенно были выше сгиба на экране рабочего стола:
Это означало, что следующие вещи не были нужны для первоначального просмотра страницы...
Затем я посмотрел на водопад (изображение, показывающее, что загружала страница) и понял, что то, что мне не нужно было загружать, на самом деле загружалось больше всего. Поэтому, если бы я мог каким-то образом переместить эти ненужные вещи за пределы пути рендеринга, моя страница загружалась бы значительно быстрее.
Оптимизация, которую я выполнил
Результатом этих оптимизаций стало то, что я убрал все, что мог, из пути рендеринга. Фактически, я сократил критический путь рендеринга до одного вызова, фактического html-файла, в котором было все, что нужно браузеру для отображения веб-страницы пользователю.
CSSOM
Более технический взгляд на критический путь рендеринга включает базовое понимание CSSOM. CSSOM — это объектная модель CSS.
CSSOM — это по сути, карта ваших стилей и того, куда эти стили должны идти.
Если вы действительно хотите что-то тонко настроить, понимание CSSOM имеет основополагающее значение для этого.
Ключевые моменты
- Критический путь рендеринга — это цепочка событий, которые должны произойти для отображения веб-страницы.
- Способ улучшить путь рендеринга — удалить или отложить сделанные вызовы, которые не нужны для начального просмотра страницы.
- Большинство вещей, для которых вы используете javascript, вероятно, могут быть отложены для загрузки после просмотра страницы (например, кнопки социальных сетей, аналитика и т. д.).
- Я изучил свою страницу, приняв во внимание, что нужно странице, чтобы загрузить вышеприведенное содержимое сгиба (таким образом, определив, что странице не нужно загружать, чтобы показать начальный вид)
- Я использовал оптимизацию скорости страницы , чтобы удалить или отложить все файлы, которые странице не нужно было загружать для вышеприведенного содержимого сгиба.
Примечание: я сделал некоторые оптимизации, которые были далеко не идеальными, чтобы указать на мощь критического пути рендеринга. (lazy load/ленивая загрузка добавила много байтов в мой html, создав HTML-файл слишком большого размера - он все еще был всего 19 КБ, но идеальный html был бы меньше 14 КБ)
