Как браузер отображает веб-страницу? - DOM, CSSOM и рендеринг

Веб-разработка

Как браузер отображает веб-страницу? - DOM, CSSOM и рендеринг

В этой статье мы глубоко погрузимся в DOM и CSSOM, чтобы понять, как браузер отображает веб-страницу. Браузер блокирует отрисовку веб-страницы до тех пор, пока сначала не будут загружены определенные ресурсы, а другие ресурсы загружаются асинхронно.

Каждый раз, когда вы разрабатываете веб-сайт, есть определенные вещи, которые очень важны для хорошего взаимодействия с пользователем. Некоторые из распространенных проблем, с которыми может столкнуться веб-сайт, могут быть медленной загрузкой ресурсов, ожиданием загрузки ненужных файлов при первоначальном рендеринге, вспышкой нестилизованного содержания ( FOUC) и т. Д. Чтобы избежать таких проблем, нам нужно понимать жизненный цикл того, как браузер отображает типичную веб-страницу.

Во-первых, нам нужно понять, что такое DOM. Когда браузер отправляет серверу запрос на выборку HTML-документа, сервер возвращает HTML-страницу в формате двоичного потока, который в основном представляет собой текстовый файл с заголовком ответа Content-Type, установленным на значение text/html; charset=UTF-8.

Здесь text/html - это MIME-тип, который сообщает браузеру, что это документ HTML, а charset=UTF-8 сообщает браузеру, что он закодирован в символе UTF-8. кодирование. Используя эту информацию, браузер может преобразовать двоичный формат в читаемый текстовый файл. Это показано ниже на скриншоте.

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

В приведенном выше документе наша веб-страница зависит от style.css для предоставления стилей HTML-элементам и от main.js для выполнения некоторых операций JavaScript. С некоторыми изящными стилями CSS наша веб-страница будет выглядеть так.

Но все еще остается вопрос: как браузер отображает эту красивую веб-страницу из простого HTML-файла, который не содержит ничего, кроме текста? Для этого нам нужно понять, что такое DOM, CSSOM и дерево рендеринга?

Объектная модель документа (DOM)

Когда браузер читает HTML-код, всякий раз, когда он встречает такой HTML-элемент, как html, body, div и т. Д., Он создает объект JavaScript под названием Узел. В конце концов, все элементы HTML будут преобразованы в объекты JavaScript.

Поскольку каждый элемент HTML имеет разные свойства, объект Node будет создан из разных классов (функций-конструкторов). Например, объект Node для элемента div создается из HTMLDivElement, который наследует класс Node. Для нашего более раннего HTML-документа мы можем визуализировать эти узлы, используя простой тест, как показано ниже.

Браузер имеет встроенные классы, такие как HTMLDivElement, HTMLScriptElement, Node и т. Д.

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

Дерево DOM для нашего более раннего HTML-документа выглядит так, как показано выше. Дерево DOM начинается с самого верхнего элемента, который является html элементом, и разветвляется в соответствии с вхождением и вложенностью элементов HTML в документ. При обнаружении элемента HTML он создает объект узла DOM (Node) из своего соответствующего класса (функция-конструктор).

💡 Узел DOM не всегда должен быть элементом HTML. Когда браузер создает дерево DOM, он также сохраняет такие вещи, как комментарии, атрибуты, текст как отдельные узлы в дереве. Но для простоты мы просто рассмотрим узлы DOM для HTML-элементов AKA DOM element. Здесь - список всех типов узлов DOM.

Вы можете визуализировать дерево DOM в консоли Google Chrome DevTools, как показано ниже. Это покажет вам иерархию элементов DOM (высокоуровневое представление дерева DOM) со свойствами каждого элемента DOM.

JavaScript не понимает, что такое DOM, это не часть спецификаций JavaScript. DOM - это высокоуровневый веб-API, предоставляемый браузером для эффективной визуализации веб-страницы и публичного предоставления ее разработчику для динамического управления элементами DOM для различных целей.

💡 Используя DOM API, разработчики могут добавлять или удалять элементы HTML, изменять их внешний вид или связывать прослушиватели событий. Используя DOM API, элементы HTML можно создавать или клонировать в памяти и манипулировать ими, не затрагивая визуализированное дерево DOM. Это дает разработчикам возможность создавать высокодинамичные веб-страницы с богатым пользовательским интерфейсом.

Объектная модель CSS (CSSOM)
Когда мы разрабатываем веб-сайт, мы стремимся сделать его как можно более красивым. И мы делаем это, предоставляя некоторые стили HTML-элементам. На странице HTML мы предоставляем стили для элементов HTML с помощью CSS, что означает каскадные таблицы стилей. Используя селекторы CSS, мы можем настроить таргетинг на элементы DOM и установить значение для свойства стиля, например color или font-size.

Существуют различные методы применения стилей к элементам HTML, например использование внешнего файла CSS, встроенного CSS с использованием тега <style>, встроенного метода с использованием атрибута style в элементах HTML или использования JavaScript. Но, в конце концов, браузеру приходится делать тяжелую работу по применению стилей CSS к элементам DOM.

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

После построения модели DOM браузер считывает CSS из всех источников (внешних, встроенных, встроенных, пользовательских агентов и т. Д.) и создает CSSOM. CSSOM означает объектную модель CSS, которая представляет собой древовидную структуру, аналогичную DOM.

Каждый узел в этом дереве содержит информацию о стиле CSS, которая будет применяться к элементам DOM, на которые он нацелен (заданный селектором). CSSOM, однако, не содержит элементов DOM, которые нельзя распечатать на экране, например <meta>, <script>, <title> и т. Д.

Как мы знаем, большая часть браузера поставляется со своей собственной таблицей стилей, которая называется таблицей стилей пользовательского агента, браузер сначала вычисляет окончательные свойства CSS для элемента DOM, переопределяя стили пользовательского агента с помощью CSS, предоставленного свойства разработчика (с использованием правил специфичности), а затем построить узел.

Даже если свойство CSS (например display) для конкретного элемента HTML не определено ни разработчиком, ни браузером, его значение устанавливается на значение по умолчанию для это свойство, как указано в стандарте W3C CSS. При выборе значения по умолчанию для свойства CSS используются некоторые правила наследования, если свойство соответствует требованиям наследования, как указано в Документации W3C.

Например, color и font-size среди прочего наследуют значение родительского элемента, если эти свойства отсутствуют для элемента HTML. Итак, вы можете представить, что эти свойства есть у элемента HTML и всех его дочерних элементов, наследующих его. Это называется каскадированием стилей, поэтому CSS является аббревиатурой от каскадных таблиц стилей. Именно по этой причине браузер создает CSSOM, древовидную структуру для вычисления стилей на основе правил каскадирования CSS.

💡 Вы можете увидеть вычисленный стиль элемента HTML с помощью консоли Chrome DevTools на панели Элементы. Выберите любой элемент HTML на левой панели и нажмите вкладку вычислено на правой панели.

Мы можем визуализировать дерево CSSOM для нашего предыдущего примера, используя приведенную ниже диаграмму. Для простоты мы проигнорируем стили пользовательского агента и сосредоточимся на стилях CSS, упомянутых ранее.

Как видно из приведенной выше диаграммы, наше дерево CSSOM не содержит элементов, которые не выводятся на экран, например <link>, <title>, <script> и т. Д. Значения свойств CSS в красных цветах каскадируются сверху вниз, а значения свойств в gray переопределяют унаследованные значения.

Дерево рендеринга

Render-Tree также представляет собой древовидную структуру, созданную путем объединения деревьев DOM и CSSOM. Браузер должен рассчитать макет каждого видимого элемента и нарисовать их на экране, поскольку он использует это дерево рендеринга. Следовательно, если Render-Tree не построено, ничего не будет напечатано на экране, поэтому нам нужны деревья DOM и CSSOM.

Поскольку Render-Tree представляет собой низкоуровневое представление того, что в конечном итоге будет напечатано на экране, оно не будет содержать узлов, которые не удерживают какую-либо область в матрице пикселей. Например, display:none; элементы имеют размеры 0px X 0px, поэтому они не будут присутствовать в Render-Tree.

Как видно из приведенной выше диаграммы, Render-Tree объединяет DOM и CSSOM для создания древовидной структуры, содержащей только элементы, которые будут напечатаны на экране.

Поскольку в CSSOM элемент p, расположенный внутри div, имеет display:none; стиль, он и его дочерние элементы не будут присутствовать в дереве рендеринга, так как он не занимает места на экране. Однако, если у вас есть элементы с visibility:hidden или opacity:0, они будут занимать место на экране, следовательно, они будут присутствовать в дереве рендеринга.

В отличие от DOM API, который предоставляет доступ к элементам DOM в дереве DOM, созданном браузером, CSSOM скрыт от пользователя. Но поскольку браузер объединяет DOM и CSSOM для формирования дерева рендеринга, браузер предоставляет доступ к узлу CSSOM элемента DOM, предоставляя высокоуровневый API для самого элемента DOM. Это позволяет разработчику получать доступ к свойствам CSS узла CSSOM или изменять их.

💡 Поскольку управление стилями элемента с помощью JavaScript выходит за рамки этой статьи, вот ссылка на замечательную Статью о хитростях CSS, которая охватывает широкий спектр CSSOM. API. У нас также есть новый API Типизированный CSS-объект в JavaScript, который является более точным способом манипулирования стилями элемента.

Последовательность рендеринга

Теперь, когда у нас есть хорошее представление о том, что такое DOM, CSSOM и Render-Tree, давайте разберемся, как при просмотре отображается типичная веб-страница с их использованием. Минимальное понимание этого процесса имеет решающее значение для любых веб-разработчиков, поскольку это поможет нам разработать наш веб-сайт для максимального удобства работы пользователей (UX) и производительности.

Когда веб-страница загружается, браузер сначала считывает текст HTML и строит из него дерево DOM. Затем он обрабатывает CSS независимо от того, является ли он встроенным, встроенным или внешним, и строит из него дерево CSSOM.

После того, как эти деревья построены, он строит из них Render-Tree. Как только дерево рендеринга построено, браузер запускает печать отдельных элементов на экране.

Макет операции

Первый браузер создает макет каждого отдельного узла Render-Tree. Макет состоит из размера каждого узла в пикселях и того, где (положение) он будет напечатан на экране. Этот процесс называется макетом, поскольку браузер вычисляет информацию о макете каждого узла.

Этот процесс также называется перекомпоновкой или перекомпоновкой браузера, и он также может происходить, когда вы прокручиваете, изменяете размер окна или манипулировать элементами DOM. Вот список событий, которые могут запускать макет / перекомпоновку элементов.

💡 Мы должны избегать многократных операций макета веб-страницы по незначительным причинам, поскольку это дорогостоящая операция. Здесь - это статья Пола Льюиса, в которой он рассказывает о том, как можно избежать сложных и дорогостоящих операций по макету, а также перебоя с макетом.

Операция покраски

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

Создание слоев помогает браузеру эффективно выполнять операции рисования на протяжении всего жизненного цикла веб-страницы, например, при прокрутке или изменении размера окна браузера. Наличие слоев также помогает браузеру правильно рисовать элементы в порядке наложения (по оси z), как это было задумано разработчиком.

Теперь, когда у нас есть слои, мы можем комбинировать их и рисовать на экране. Но браузер не рисует все слои за один раз. Каждый слой сначала рисуется отдельно.

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

Аналогия со слоями в Photoshop может быть применена и к тому, как браузер отображает веб-страницу. Вы можете визуализировать различные слои на веб-странице с помощью Chrome DevTools. Откройте DevTools и в разделе Дополнительные инструменты выберите Слои. Вы также можете визуализировать границы слоя на панели Визуализация.

💡 Растеризация обычно выполняется в ЦП, что делает ее медленной и дорогостоящей, но теперь у нас есть новые методы, позволяющие сделать это в графическом процессоре для повышения производительности. В этой статье подробно рассматривается тема рисования, ее необходимо прочитать. Чтобы понять концепцию слоев более подробно, необходимо прочитать статью this.

Операция компоновки

До сих пор мы не рисовали ни одного пикселя на экране. У нас есть разные слои (растровые изображения), которые нужно рисовать на экране в определенном порядке. В операциях наложения эти слои отправляются в графический процессор, чтобы окончательно отрисовать их на экране.

Отправка целых слоев для рисования явно неэффективна, потому что это должно происходить каждый раз, когда выполняется перекомпоновка (макет) или перерисовка. Таким образом, слой разбивается на разные плитки, которые затем отображаются на экране. Вы также можете визуализировать эти плитки на панели рендеринга Chrome DevTool.

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

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

💡 Марико Косака написала красивую статью об этом процессе с классными иллюстрациями и более широкими объяснениями каждой концепции. Настоятельно рекомендуется.

Браузерные движки

Работа по созданию дерева DOM, дерева CSSOM и логики обработки обработки выполняется с помощью программного обеспечения, называемого движок браузера (, также известный как механизм рендеринга или Layout Engine), который находится внутри браузера. Этот движок браузера содержит все необходимые элементы и логику для рендеринга веб-страницы от HTML-кода до фактических пикселей на экране.

Если вы слышали, что люди говорят о WebKit, они говорят о движке браузера. WebKit используется браузером Apple Safari и был механизмом рендеринга по умолчанию для браузера Google Chrome. На данный момент проект Chromium использует Blink в качестве механизма рендеринга по умолчанию. Вот список различных браузерных движков, используемых некоторыми ведущими веб-браузерами.

Процесс отображения в браузерах

Все мы знаем, что язык JavaScript стандартизирован с помощью стандарта ECMAScript, фактически, поскольку JavaScript является зарегистрированным товарным знаком, мы сейчас называем его просто ECMAScript. Следовательно, каждый поставщик движка JavaScript, такой как V8, Chakra, Spider Monkey и т. Д., Должен подчиняться правилам этот стандарт.

Наличие стандарта дает нам согласованный опыт работы с JavaScript во всех средах выполнения JavaScript, таких как браузеры, Node, Deno и т. Д. Это отлично подходит для последовательной и безупречной разработки приложений JavaScript (и веб) для нескольких платформ.

Однако это не относится к тому, как браузер отображает данные. HTML, CSS или JavaScript, эти языки стандартизированы какой-либо организацией. Однако то, как браузер управляет ими вместе, чтобы отображать объекты на экране, не стандартизирован. Механизм браузера Google Chrome может работать иначе, чем движок браузера Safari.

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

Несмотря на эти несоответствия, есть некоторые общие принципы, которые обычно одинаковы для всех браузеров. Давайте разберемся с общим подходом браузера к отображению объектов на экране и событиями жизненного цикла этого процесса. Чтобы понять этот процесс, я подготовил небольшой проект для тестирования различных сценариев рендеринга (ссылка ниже).

Парсинг и внешние ресурсы

Разбор - это процесс чтения HTML-содержимого и построения из него DOM-дерева. Следовательно, этот процесс также называется синтаксическим анализом DOM, а программа, которая его выполняет, называется анализатором DOM.

Большинство браузеров предоставляют DOMParser веб-API для построения дерева DOM из HTML-кода. Экземпляр класса DOMParser представляет парсер DOM, и с помощью метода прототипа parseFromString мы можем анализировать необработанный текст HTML (код) в дерево DOM (как показано ниже).

Когда браузер запрашивает веб-страницу и сервер отвечает некоторым текстом HTML (с заголовком Content-Type, установленным на text/html), браузер может начать анализ HTML, как только появится несколько символов. или доступны строки всего документа. Следовательно, браузер может строить дерево DOM постепенно, по одному узлу за раз. Браузер анализирует HTML снизу вверх, а не в середине, поскольку HTML представляет собой вложенную древовидную структуру.

В приведенном выше примере мы получили доступ к файлу incremental.html с нашего сервера Node и установили скорость сети только на 10 кбит / с (на панели Сеть). Поскольку браузеру потребуется много времени для загрузки (загрузки) этого файла (поскольку он содержит 1000 h1 элементов), браузер создает дерево DOM из первых нескольких байтов и печатает их на экране (по мере загрузки оставшегося содержимого HTML-файла в фоновом режиме).

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

💡 Используйте значок ⟳ на вкладке "Производительность", чтобы зафиксировать профиль производительности.

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

FCP - это аббревиатура от First Contentful Paint, которая означает время, когда браузер визуализировал первый пиксель контента, например текст или изображение . LCP - это аббревиатура от Самая большая содержательная краска, которая означает время, когда браузер визуализировал большие фрагменты текста или изображения.

document.addEventListener( 'DOMContentLoaded', function(e) {
    console.log( 'DOM is fully parsed!' );
} );

window.addEventListener( 'load', function(e) {
  console.log( 'Page is fully loaded!' );
} )