Как браузер отображает страницу

Обновлено: 21.11.2024

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

Многое из этого основано на фантастическом (и БЕСПЛАТНО!) курсе по оптимизации производительности веб-сайтов Ильи Григорика и Кэмерона Питтмана на Udacity. Я настоятельно рекомендую проверить это.

Также очень полезной оказалась статья Пола Айриша и Тали Гарсиэль «Как работают браузеры: за кулисами современных веб-браузеров». Он выпущен в 2011 году, но многие основы работы браузеров остаются актуальными на момент написания этой записи в блоге.

Хорошо, поехали. Процесс можно разбить на следующие основные этапы:

1. Начать анализ HTML

Когда браузер начинает получать HTML-данные страницы по сети, он немедленно запускает анализатор для преобразования HTML в объектную модель документа (DOM).

Объектная модель документа (DOM) — это представление данных объектов, составляющих структуру и содержимое документа в Интернете.

Первым этапом этого процесса синтаксического анализа является разбиение HTML на маркеры, представляющие начальные теги, конечные теги и их содержимое. Из этого он может построить DOM.

2. Получить внешние ресурсы

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

Файлы JavaScript немного отличаются: по умолчанию они блокируют синтаксический анализ HTML, пока файл JavaScript загружается, а затем анализируется. Есть два атрибута, которые можно добавить к тегам script, чтобы смягчить это: defer и async . Оба позволяют продолжить синтаксический анализатор, пока файл JavaScript загружается в фоновом режиме, но они работают по-разному в том, как они выполняются. Об этом чуть позже, но вкратце:

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

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

Предварительная загрузка ресурсов

Кроме того, современные браузеры будут продолжать сканировать HTML-код, пока он заблокирован, и «просчитывать» появление внешних ресурсов, а затем предположительно загружать их. То, как они это делают, различается в разных браузерах, поэтому нельзя полагаться на то, что они будут вести себя определенным образом. Чтобы пометить ресурс как важный и, следовательно, с большей вероятностью загрузить его в начале процесса рендеринга, можно использовать тег ссылки с rel="preload".

3. Разобрать CSS и создать CSSOM

Возможно, вы уже слышали о DOM, но слышали ли вы об CSSOM (объектной модели CSS)? Прежде чем я начал исследовать эту тему некоторое время назад, я этого не знал!

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

CSOM вместе с DOM строит дерево рендеринга, которое, в свою очередь, используется браузером для компоновки и рисования веб-страницы.

Подобно файлам HTML и DOM, когда файлы CSS загружаются, они должны быть проанализированы и преобразованы в дерево — на этот раз в CSSOM. Он описывает все селекторы CSS на странице, их иерархию и свойства.

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

4. Выполнить JavaScript

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

Загрузить события

После того, как синхронно загруженные JavaScript и DOM будут полностью проанализированы и готовы, будет сгенерировано событие document.DOMContentLoaded. Для любых сценариев, которым требуется доступ к модели DOM, например, для того, чтобы каким-либо образом манипулировать ею или прослушивать события взаимодействия с пользователем, рекомендуется сначала дождаться этого события перед выполнением сценариев.

После завершения загрузки всего остального, например асинхронного JavaScript, изображений и т. д., запускается событие window.load.

5. Объединить DOM и CSSOM для построения дерева рендеринга

Дерево рендеринга представляет собой комбинацию DOM и CSSOM и представляет все, что будет отображаться на странице. Это не обязательно означает, что все узлы в дереве рендеринга будут визуально присутствовать, например, узлы со стилями непрозрачности: 0 или видимости: скрытые будут включены и могут быть прочитаны программой чтения с экрана и т. д., в то время как те, для которых настроено отображение : none не будет включено. Кроме того, такие теги, как те, которые не содержат никакой визуальной информации, всегда будут опущены.

Как и в случае с механизмами JavaScript, разные браузеры имеют разные механизмы рендеринга.

6. Рассчитать макет и нарисовать

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

После того, как это будет завершено, последний шаг – взять информацию о макете и нарисовать пиксели на экране.

И вуаля! После всего этого у нас есть полностью визуализированная веб-страница!

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

В глубоком понимании мы обнаружили том, как на основании HTML- и CSS-файлов строятся модели DOM и CSSOM. Эти независимые друг от друга модели реагирования на разные аспекты страницы: DOM содержит содержание, а CSSOM - стили, которые не проявляются к применению. Рассмотрим, как происходят эти модели и выводит страницу на экран.

  • Браузер инцидента DOM и CSSOM, формирующая модель расследования.
  • Модель содержит только те объекты, которые необходимы для вывода на экран.
  • Далее получается образец, отражающий расположение и размер каждого объекта.
  • Наконец, объекты находятся на экране.

Для начала формирует модель ранней, в которой видимым всем объектом из моделей DOM осваиваются наборы стилей из моделей CSSOM.

Для формирования модели быстрого выполнения действий:

  1. Начинается с основания модели DOM, находит все видимые объекты.
    • Этот этап не содержит элементов, которые не удаляются на странице, например, теги, скрипты, метатеги и т.д. п.
    • Они также не содержат объекты, помеченные как невидимые с помощью CSS. Просмотрите приведенную выше схему: объект span отсутствует в модели повышенной опасности, потому что ему присвоен параметр display: none .
  2. Находит в CSSOM наборы стилей и осваивает свой подходящий объект.
  3. Формирует модель из видимых объектов, их содержание и стиль.

Создав модель неожиданно, приближался путь к выходу страницы на экран! Теперь можно приступить к формированию макета.

Браузер уже определил, какие объекты будут скрыты на странице и какие стили необходимо им присвоить. Пришло время создать макет, т. е. Каковы их размеры?

Для этого вычисляется геометрическая форма объектов, анализируется модель возникновения с самого начала. Рассмотрим простой пример:

В теле этой страницы есть два блока div. Ширина используемого блока - 50% от области просмотра, а вложенного - 50% от потребляемого, т.е. е. 25% экрана.

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

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

Как вы наверняка заметили, необходимо принимать участие в массовых действиях, на которые зачастую уходит мало времени. Чтобы изменить время загрузки, продолжительность каждой стадии можно использовать с помощью инструментов разработчика в Chrome. Рассмотрим этап формирования макета нашего первого представления Hello World:

  • Событие Layout на вкладке Timeline время изготовления, затраченное на изготовление макета, а также определение положения и размера объектов.
  • Сформировал макет, выполняя несколько этапов Paint Setup и Paint для преобразования моделей в пиксели.

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

Тема времени, визуализация охватилась, и наша страница появилась в области просмотра!

Давайте напоминать, какие действия выполнили:

  1. Обработка HTML-разметки и создание модели DOM.
  2. Обработка CSS-файла и создание модели CSSOM.
  3. Создание модели раннего развития из DOM и CSSOM.
  4. Определение формы и местоположения объектов, создание макета.
  5. Вывод объектов на экран.

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

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

Если не указано иное, содержимое этой страницы предоставляется по лицензии Creative Commons Attribution 4.0, а образцы кода — по лицензии Apache 2.0. Подробнее см. в Правилах сайта Google Developers. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.

Я хочу подчеркнуть, что когда вы пишете HTML, CSS и JS и пытаетесь открыть файл HTML в своем браузере, браузер считывает необработанные байты HTML с вашего жесткого диска (или из сети). ).

Понял? Браузер читает необработанные байты данных, а не фактические символы кода, который вы написали. Идем дальше.

Браузер получает байты данных, но ничего с ними сделать не может; необработанные байты данных должны быть преобразованы в форму, которую он понимает. Это первый шаг.

От необработанных байтов HTML к DOM

То, с чем объект браузера должен работать, — это объект объектной модели документа (DOM). Итак, как создается объект DOM? Ну, довольно просто.

Сначала необработанные байты данных преобразуются в символы.

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

На данный момент браузер перешел от необработанных байтов данных к фактическим символам в файле. Персонажи великолепны, но они не являются конечным результатом. Эти символы далее анализируются в нечто, называемое токенами.

Итак, что это за токены?

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

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

Синтаксический анализатор понимает каждую строку в угловых скобках (например, ,

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

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

Если вы помните из веб-дизайна 101, вы не открываете файл CSS или JS в браузере для просмотра веб-страницы. Нет — вы открываете файл HTML, чаще всего в форме index.html. Именно поэтому вы делаете это: браузер должен преобразовать необработанные байты данных HTML в DOM, прежде чем что-либо произойдет.

В зависимости от размера HTML-файла процесс создания модели DOM может занять некоторое время. Независимо от размера файла, это занимает некоторое время.

Но подождите, а как насчет загрузки CSS?

DOM создан. Отлично.

Обычный HTML-файл с некоторыми элементами CSS будет иметь связанную таблицу стилей, как показано ниже:

Пока браузер получает необработанные байты данных и запускает процесс построения DOM, он также делает запрос на получение связанной таблицы стилей main.css. Как только браузер начинает анализировать HTML, обнаружив тег ссылки на файл CSS, он одновременно отправляет запрос на его получение.

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

От необработанных байтов CSS к CSSOM

Видите ли, аналогичный процесс с необработанными байтами HTML также инициируется, когда браузер получает необработанные байты CSS.

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

Что такое древовидная структура? Ну, большинство людей знают, что есть нечто, называемое DOM. Точно так же существует древовидная структура CSS, называемая объектной моделью CSS (CSSOM).

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

В CSS есть нечто, называемое каскадом. Каскад — это то, как браузер определяет, какие стили применяются к элементу. Поскольку стили, влияющие на элемент, могут исходить от родительского элемента (т. е. путем наследования) или быть заданы для самого элемента, древовидная структура CSSOM становится важной.

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

Все хорошо. Браузер имеет объекты DOM и CSSOM. Можем ли мы сейчас что-нибудь отобразить на экране?

Дерево визуализации

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

Древовидные структуры DOM и CSSOM — это две независимые структуры.DOM содержит всю информацию о взаимосвязях HTML-элементов страницы, а CSSOM содержит информацию о стилях элементов.

Хорошо, теперь браузер объединяет деревья DOM и CSSOM в нечто, называемое деревом рендеринга.

Дерево рендеринга содержит информацию обо всем видимом содержимом DOM на странице и всю необходимую информацию CSSOM для различных узлов. Обратите внимание, что если элемент был скрыт с помощью CSS (например, с помощью display; none ), узел не будет представлен в дереве рендеринга.

Скрытый элемент будет присутствовать в модели DOM, но не в дереве рендеринга. Это связано с тем, что дерево рендеринга объединяет информацию как из DOM, так и из CSSOM, поэтому оно знает, что не следует включать скрытый элемент в дерево.

После построения дерева рендеринга браузер переходит к следующему шагу: компоновке!

Создание дерева рендеринга

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

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

На экране отображаются простой текст и изображение. Из предыдущих объяснений браузер считывает необработанные байты HTML-файла с диска (или из сети) и преобразует их в символы.

Что произойдет с этим потоком, когда мы представим JavaScript? Что ж, одна из самых важных вещей, которую следует помнить, это то, что всякий раз, когда браузер встречает тег скрипта, построение DOM приостанавливается! Весь процесс построения DOM останавливается до завершения выполнения скрипта.

Это связано с тем, что JavaScript может изменять как DOM, так и CSSOM. Поскольку браузер не уверен, что будет делать этот конкретный JavaScript, он принимает меры предосторожности, полностью останавливая построение DOM целиком.

Насколько это может быть плохо? Давайте посмотрим.

В базовом HTML-документе, которым я поделился ранее, давайте добавим тег скрипта с базовым кодом JavaScript:

В теге script я обращаюсь к DOM для узла с идентификатором и заголовком , а затем вывожу его в консоль.

Это работает нормально, как показано ниже:

Тем не менее, вы заметили, что этот тег скрипта расположен в нижней части тега body? Поместим его в голову и посмотрим, что получится:

Как только я это сделаю, переменная заголовка будет преобразована в null .

Почему? Довольно просто.

Пока анализатор HTML создавал DOM, был обнаружен тег скрипта. На данный момент тег body и все его содержимое не были проанализированы. Построение DOM останавливается до завершения выполнения скрипта:

К моменту, когда скрипт попытался получить доступ к узлу DOM с идентификатором header , он еще не существовал, потому что DOM еще не завершила синтаксический анализ документа!

Это подводит нас к еще одному важному моменту: расположение вашего скрипта имеет значение.

И это еще не все. Если вы извлечете встроенный скрипт во внешний локальный файл, поведение будет точно таким же. Построение DOM все еще остановлено:

Опять же, это еще не все! А если это приложение.js не был локальным, и его нужно было загрузить из Интернета?

Критический путь рендеринга (CRP)

Все это время мы обсуждали этапы между получением байтов HTML, CSS и JS и преобразованием их в визуализированные пиксели на экране.

Весь этот процесс называется критическим путем рендеринга (CRP). Оптимизация ваших веб-сайтов для повышения производительности — это оптимизация CRP. Хорошо оптимизированный сайт должен подвергаться прогрессивному рендерингу и не блокироваться весь процесс.

Это разница между веб-приложением, воспринимаемым как медленное или быстрое.

Продуманная стратегия оптимизации CRP позволяет браузеру загружать страницу как можно быстрее, определяя приоритет загружаемых ресурсов и порядок их загрузки.

Отслеживайте, как отображаются ваши приложения

LogRocket похож на видеорегистратор для веб-приложений, который записывает буквально все, что происходит на вашем сайте. Вместо того, чтобы гадать, как ваше приложение или веб-сайт отображается в конкретных браузерах, вы можете точно увидеть, что испытал пользователь. С помощью LogRocket вы можете понять, как пользователи взаимодействуют с компонентами, и обнаружить любые ошибки, связанные с неправильным отображением элементов.

Кроме того, LogRocket регистрирует все действия и состояние в ваших хранилищах Redux. LogRocket позволяет вашему приложению записывать запросы/ответы с заголовками и телами. Он также записывает HTML и CSS на странице, воссоздавая идеальные до пикселя видеоролики даже самых сложных одностраничных приложений. Модернизируйте способы отладки приложений React — начните мониторинг бесплатно.

Заключение

Поняв основы того, как браузер отображает HTML, CSS и JS, я прошу вас уделить время изучению того, как вы можете воспользоваться этими знаниями для оптимизации скорости своих страниц.

Хорошее место для начала – раздел производительности документации Google Web Fundamentals.

LogRocket: легче отлаживать ошибки JavaScript благодаря пониманию контекста

Отладка кода всегда утомительна. Но чем лучше вы понимаете свои ошибки, тем легче их исправить.

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

LogRocket записывает журналы консоли, время загрузки страниц, трассировку стека, медленные сетевые запросы и ответы с заголовками и телами, метаданными браузера и пользовательскими журналами. Понимание влияния вашего кода JavaScript никогда не будет таким простым!

В этой статье мы рассмотрим действия, выполняемые браузером для отображения веб-страницы.

🎯 Этапы рендеринга HTML-страницы:

  1. Построение DOM
  2. Построение CSSOM
  3. Построение дерева рендеринга
  4. Этап макета
  5. Этап рисования

🎯 Построение DOM

Браузер получает от сервера HTML-документ в формате двоичного потока , который представляет собой текстовый файл с заголовком ответа Content-Type = text/html; кодировка=UTF-8 .

Когда браузер читает документ HTML, всякий раз, когда он встречает элемент HTML, он создает объект JS, который называется Node. В конце концов, все элементы html будут преобразованы в узел.

После того как браузер создал узлы из HTML-документа, он должен создать "древовидную" структуру этих узловых объектов.

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

🎯 Построение CSSOM

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

Каждый узел в этом дереве содержит информацию в стиле CSS, которая будет скопирована в целевой элемент DOM.

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

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

DOM и CSSOM объединяются вместе, чтобы сформировать дерево рендеринга, содержащее узлы, которые должны отображаться на странице.

Из корня дерева DOM просматривается каждый видимый узел и применяется соответствующее правило CSSOM. Наконец, это дает дерево рендеринга, содержащее видимые узлы с содержимым и стилем.

Это низкоуровневое представление того, что в конечном итоге будет напечатано на экране, оно не будет содержать узлов, которые не занимают какую-либо область в пиксельной матрице (например, теги head , meta , link).

Как вы заметили выше, узлы, содержащие свойства CSS display: none, не являются частью дерева рендеринга.

🎯 Этап макета

Этот этап можно назвать этапом геометрии, на котором мы вычисляем геометрию узлов.

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

🎯 Этап рисования

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

🎯 Заканчиваем!!

Это все для этой статьи. Спасибо за уделенное время!! Давайте общаться, чтобы учиться и расти вместе.

Читайте также: