Critical rendering pathРешил я на этой неделе чуть больше погрузиться в тему critical rendering path (по сути порядок действий, по которому HTML с сервера превращается в пиксели на экране) и подготовить наглядный пример, на котором можно было бы объяснять эту тему.
До этого читал не мало статей на эту тему. Но, как оказалось, в реальности процесс немного более интересный, чем об этом рассказывается в большинстве ресурсов.
В целом, если погуглить данную тему, то инфа будет примерно такая:
- Получаем HTML, начинаем парсинг, инкрементально строим DOM
- Если встретили CSS - делаем запрос на загрузку
- Если встретили JS - делаем запрос на загрузку. Если скрипт блокирующий (без async/defer), то останавливаем всю работу, пока не загрузится скрипт.
- Как получили весь CSS - строим CSSOM
- Запускаем JS
- Строим render tree
- Дальше уже Layout, Paint, Composite и отображение финального результата
В целом верхнеуровнево все верно. Но когда я начал реально экспериментировать, то понял, что есть некоторые особенности и оптимизации браузеров, о которых я никогда раньше не слышал.
Забегая вперед скажу, что во время поиска объяснений несостыковкам между моим пониманием вопроса и реальностью, нашел статью от гугла, где все подробно рассказывается и объясняется. Всем рекомендую)
Дальше уже буду говорить о тех моментах, которые были для меня открытием:
1) Parser-blocking скрипты (без async/defer) на самом деле не создают лесенку запросов. Да, как только браузер их видит, дальнейшее построение DOM останавливается и соответственно весь процесс подготовки документа к рендерингу. Но, загрузка ресурсов после блокирующего скрипта все равно произойдет с помощью отдельного парсера (проверил этот момент в Chrome и Safari, и там и там одинаковое поведение).
А вот отрывок из статьи на эту тему:
Blocking the parser can have a huge performance cost—much more than just blocking rendering. For this reason, browsers will try to reduce this cost by using a secondary HTML parser known as the preload scanner to download upcoming resources while the primary HTML parser is blocked. While not as good as actually parsing the HTML, it does at least allow the networking functions in the browser to work ahead of the blocked parser, meaning it will be less likely to be blocked again in the future.
2) Хоть CSS и считается render-blocking ресурсом, но в зависимости от браузера он может блокировать рендеринг не всей страницы, а только контента, который находится под ним. Проверил Chrome — в нем как раз все работает именно так (в статье говорят, что у Firefox идентичное поведение). В Safari ждет пока все загрузится, прежде чем что-то показывать.
Render-blocking resources, like CSS, used to block all rendering of the page when they were discovered. This means that whether some CSS is render-blocking or not depends on whether the browser has discovered it. Some browsers (Firefox initially, and now also Chrome) only block rendering of content below the render-blocking resource.
То же самое касается и скриптов без async/defer. Chrome отрендерит тот контент, что у него есть до момента, когда он встретил блокирующий скрипт.
Parser-blocking resources are effectively render-blocking as well. Since the parser can't continue past a parsing-blocking resource until it has been fully processed, it can't access and render the content after it. The browser can render any HTML received so far while it waits, but where the critical rendering path is concerned, any parser-blocking resources in the <head> effectively mean that all page content is blocked from being rendered.
В целом не думаю, что кто-то ставит стили вне head'а, поэтому в большинстве случаев это будет не заметно. Но поведение скриптов меня удивило. То есть большие скрипты внизу body (будь это defer или вообще блокирующие) не будут мешать Chrome/FF отрендерить весь контент страницы.
![Frontender's notes [ru] Telegram Channel](/avatar/1306/1306975317.jpg)
![Node.JS [ru] | Серверный JavaScript Telegram Channel](/avatar/1370/1370900400.jpg)
