Как происходит загрузка страницы в браузере

Обновлено: 05.01.2025

Процесс загрузки ресурсов страницы браузера и оптимизация

Одним из основных элементов оценки производительности страницы являетсяСкорость загрузки страницы,а такжеСкорость загрузки страницыКлючЗагрузка ресурсов страницы. В этой статье будет проанализирован процесс загрузки ресурса страницы браузера из браузера для перехода на страницу.Критический путь запросаКонцепция и как оптимизироватьКритический путь запросаНекоторые методы. Следующий связанный контент представлен на примере браузера Chrome. Между разными браузерами могут быть небольшие различия, но основной процесс одинаков.

Процесс загрузки ресурсов браузера

Сначала задайте два вопроса:

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

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

Шаг 1. Классификация ресурсов

Браузер Chrome делит ресурсы на 14 категорий, как показано в следующей таблице.

Виды	Введение
kMainResource	А именно основной ресурс, файловый ресурс страницы html принадлежит к этому типу
kImage	Различные ресурсы изображений
kCSSStyleSheet	Как следует из названия, это ресурс css каскадных таблиц стилей.
kScript	Ресурсы скрипта, такие как ресурсы js
kFont	Ресурсы шрифтов, например наборы шрифтов, обычно используемые на веб-страницах. Ресурсы Woff
kRaw	Ресурсы смешанного типа, наиболее распространенный запрос ajax относится к этому типу ресурса
kSVGDocument	Ресурсы файлов масштабируемой векторной графики SVG
kXSLStyleSheet	Расширенный язык таблиц стилей XSLT - это язык преобразования. Вы можете обратиться к w3c XSL для этого типа.
kLinkPrefetch	Предварительная выборка ссылок страницы HTML5, например dns-prefetch. Ниже будет подробное введение
kTextTrack	ресурсы субтитров для видео, а именно <track> этикетка
kImportResource	HTML Imports, импортируйте HTML-файл в другие HTML-документы, например <link href="import/post.html" rel="import" /> . Подробнее см. В соответствующих документах.
kMedia	К этому типу ресурсов относятся мультимедийные ресурсы, видео или аудио.
kManifest	Ресурсы кеша приложения HTML5
kMock	Зарезервированный тип теста

Шаг 2. Проверка политики безопасности

Процесс Второй - передать <meta> Ярлык, который нужно установить. <meta> Он настроен по принципу "ключ-значение". Вот несколько конкретных примеров применения.

Используется для блокировки смешанного содержимого:

Шаг третий: расчет приоритета ресурса

Приоритет ресурсов делится на5 уровень. Различная информация об этом5 уровеньОписание наименования может быть другим. В основном потому, что сами данные могут быть изСетевой уровень，Ядро браузераилиОтображение клиентской консолиПо одному из этих трех направлений. Хотя эти три направления5 уровеньИмена разные, но все они однозначно соответствуют друг другу. Сетевой уровень, 5 уровней: наивысший, средний, низкий, самый низкий, бездействие; Ядро браузера, 5 уровней: очень высокий, высокий, средний, низкий, очень низкий; Отображение клиентской консоли, 5 уровней: самый высокий, высокий, средний, низкий, самый низкий;

СледующееЯдро браузераВ качестве направления исследования мы представим процесс расчета приоритета ресурсов браузера:

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

Три типа ресурсов: html, css и font имеют наивысший приоритет;
Затем предварительно загрузите ресурсы (через <link rel=“preload"> Предварительная загрузка метки), скрипт, запрос xhr;
Затем есть изображения, голоса и видео;
Самый низкийprefetchПредварительно загруженные ресурсы.

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

заXHR запросРесурсы: WillСинхронный запрос XHRПриоритет установлен на самый высокий. Запросы XHR можно разделить на синхронные запросы и асинхронные запросы. Браузер повысит приоритет синхронных запросов до самого высокого уровня, чтобы получить данные как можно скорее и ускорить отображение страницы.
заобразРесурс: приоритет будет изменен в зависимости от того, находится ли изображение в видимой области экрана. По умолчанию для ресурсов изображений установлен низкий приоритет. Чтобы улучшить впечатление пользователя от первого экрана, современные браузеры будут вычислять, находится ли ресурс изображения в пределах видимого представления первого экрана во время рендеринга. Если это так, приоритет этой части ресурса изображения области просмотра (изображение в области просмотра) будет повышен до высокого. .
засценарийРесурсы: браузер разделит сценарий на три категории в соответствии с тегами местоположения и атрибутов сценария и установит приоритет соответственно. Прежде всего, приоритет скриптов с добавленными тегами атрибутов defer / async будет снижен до низкого. Затем для сценариев, в которых этот атрибут не добавлен, в зависимости от того, находится ли положение сценария в документе до или после первого изображения, отображаемого браузером, его можно разделить на две категории. Перед (Отмечено как раннее **) Будет установлен высокий приоритет после (Отмечено поздно **) Будет установлен средний приоритет. На следующем рисунке показаны приоритеты различных ресурсов после расчета приоритета ресурсов, в частности, выделены три общих ресурса, упомянутых выше. Красное поле - это тип сценария, фиолетовое поле - тип изображения, а синее поле - запрос XHR. Источник изображениякликните сюда。 Процесс

Шаг 4: Загрузите или заблокируйте ресурсы в соответствии с политикой безопасности и приоритетом, рассчитанными выше.

Цепочка критических запросов и оптимизация

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

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

Как найти страницуЦепочка критических запросов

Получите ресурсы ключевого изображения с помощью первого снимка экрана. Как показано на рисунке ниже, мы используем первый снимок экрана для получения ресурсов изображения, которые будут загружены на первом экране. (В красном поле) Процесс
отLightHouseПлагин получает ресурсы ключей js и css в цепочке запросов ключей. LightHouseПодробное использование можно щелкнутьВотПридите понять. Наконец, можно создать отчет, запустив плагин, который содержит всесторонние отчеты и предложения по производительности страницы. Отчет о цепочке запросов ключей показан на рисунке ниже: Процесс
Просмотр приоритета каждого запроса через консоль браузера Откройте консоль Chrome, перейдите на вкладку «Сеть», и вы сможете просмотреть приоритет ресурса (Priority). Если столбец «Приоритет» отсутствует, щелкните правой кнопкой мыши и выберите «Приоритет» в раскрывающемся меню. Как показано на рисунке ниже: Процесс

оптимизацияЦепочка критических запросов

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

Первый тип: использованиеPreloadс участиемPrefetch。

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

Полить холодной водой: ПосколькуPrefetchс участиемPreloadЭффект настолько мощный, можем ли мы использовать его с уверенностью? Но на самом деле, помимо dns-prefetch, очень беспокоит другая совместимость. В частности, в Safari, из-за высоких требований Apple к безопасности, практически ни одна из этих технологий предварительной загрузки не была реализована. PreloadКак показано на рисунке ниже, поддержка новой версии Chrome оказалась лучше, но Safari был уничтожен. Процесс dns-prefetchПоддержка неплохая. Процесс PrefetchТот же Safari был уничтожен. Процесс

WeChat: Используйте LS для кеширования файлов js. Как показано на рисунке ниже, с помощью браузера открыть статью общедоступного аккаунта WeChat, открыть консоль и обнаружить, что файл js в сети не нужно загружать? Вы смущаетесь!

Tmall: Используйте LS для кэширования ключевых асинхронных запросов XHR. вTmall Супермаркет ДомНапример: Как показано на рисунке ниже, проверьте LS и обнаружите, что он кэширует карусель на первом экране и данные 10 записей классификации.

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

Простыми словами объясняем, как браузер подключается и общается с сервером.

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

Такая информация хранится в распределенной системе серверов — DNS (Domain Name System). Система работает как общая «контактная книга», хранящаяся на распределенных серверах и устройствах в интернете.

Однако перед тем, как обращаться к DNS, браузер пытается найти запись об IP-адресе сайта в ближайших местах, чтобы сэкономить время:

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

Не обнаружив подходящих записей в кэше, браузер формирует запрос к DNS-серверам, расположенным в интернете.

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

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

Например, для установки соединения между браузером и сервером в стандарте TCP используется система «трёх рукопожатий». Работает она так:

Устройство пользователя отправляет специальный запрос на установку соединения с сервером — называется SYN -пакет.
Сервер в ответ отправляет запрос с подтверждением получения SYN-пакета — называется SYN/ACK -пакет.
В конце устройство пользователя при получении SYN/ACK-пакета отправляет пакет с подтверждением — ACK -пакет. В этот момент соединение считается установленным.

Задача браузера — как можно подробнее объяснить серверу, какая именно информация ему нужна .

Сервер получил запрос от браузера с подробным описанием того, что ему требуется. Теперь ему нужно обработать этот запрос. Этой задачей занимается специальное серверное программное обеспечение — например, nginx или Apache. Чаще всего такие программы принято называть веб-серверами.

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

👉 Чтобы обмен данными был быстрым, браузер и сервер обмениваются сразу множеством небольших пакетов данных — как правило, в пределах 8 КБ. Все пакеты имеют специальные номера, которые помогают отслеживать последовательность отправки и получения данных. 8. Браузер обрабатывает полученный ответ и «рисует» веб-страницу

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

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

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

Как только рендеринг завершен — пользователю отобразится полностью загруженная страница сайта.

Эта статья — короткий и простой перевод статьи « What happens when… », опубликованной на Гитхабе. В ней автор подробно рассказывает, что именно происходит внутри компьютера, когда мы вводим в браузере адрес сайта и нажимаем энтер. Мы убрали излишние технические подробности вроде IRQ-прерываний и ARP-запросов и добавили картинки, чтобы было проще понять суть.

Начало

Мы ввели адрес сайта — thecode.media — и нажали энтер. Что происходит дальше?

Поиск сервера в интернете

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

👉 Проще говоря, когда вы садитесь в такси и говорите «Мне в „Мегу“», вы назвали водителю не адрес, а доменное имя. Водитель уже сам должен знать, где в вашем городе «Мега».

Так вот: теперь задача браузера — определить по доменному имени адрес, на который отправлять запрос. В мире интернета этот адрес называется IP-адресом. Он есть у каждого сервера и выглядит, например, так:

Сначала смотрит, посещали мы этот сайт раньше или нет. Если посещали — возьмёт IP-адрес из истории. Так же, как водитель, который тысячу раз ездил в «Мегу».
Если не посещали — посмотрит в конфигурационных файлах операционной системы. Иногда для ускорения работы некоторые IP-адреса можно прописать в конфигурации компьютера, чтобы он сразу знал, куда обращаться.
Если в настройках такого нет, браузер смотрит недавние адреса в роутере, через который компьютер подключается к интернету.
Если и там нет, то браузер отправляет запрос на DNS-сервер. Там точно всё есть, но результат получится медленнее, чем в остальных способах.

DNS-сервер — это такая служба в интернете, которая отвечает всем желающим на вопрос «Какой IP у такого-то домена?». Таких серверов в интернете много, и каждый из них знает про свою часть сети. Если у ближайшего сервера нет записей о нашем домене, то он отвечает «Я не знаю, спроси у DNS-сервера покрупнее, вот его адрес». В итоге браузер найдёт DNS-сервер, который знает то, что нам нужно, и получит IP-адрес сервера с сайтом.

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

Обо всех этих процессах мы поговорим подробнее в нашей статье. Но начать стоит не с этого.

Сетевые модели передачи данных и архитектура браузера

Для объяснения процесса передачи данных по сети используются различные модели. Одной из самых распространённых таких моделей, которая понятна даже людям, далеким от хакерства и IT, считается модель OSI – модель взаимосвязанных открытых систем.

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

Есть и более старая модель взаимодействия – так называемая TCP/IP. Она точнее описывает процессы, о которых мы говорим в нашей статье. Такая модель используется как для моделирования интернет-архитектуры, так и для установки правил для всех форм передачи данных в сети. Именно к ней мы и будем обращаться в этой статье.

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

Ниже мы приводим общую схему такого взаимодействия.

Еще одно понятие, которое поможет вам дальше разбираться в работе веб-браузера – это высокоуровневая архитектура самого браузера. Если описывать кратко, то она состоит из:

Завершая нашу вступительную часть, помните, что описанные здесь модели и архитектура – это очень общая концепция. Не все браузеры следуют моделям OSI/TCP-IP, не у всех архитектура отвечает нашему описанию. А теперь перейдём непосредственно к путешествию нашей веб-страницы.

Шаг 1: Навигация

Итак, далее происходит разрешение веб-адреса - процесс DNS (O RTT). Как это работает?

Проверяется кэш браузера и ОС.
Браузер отправляет запрос на распознавание DNS.
DNS-преобразователь проверяет свой кэш, возвращает ответ, если IP-адрес найден.
Преобразователь DNS отправляет запрос корневым серверам имен.
Корневой сервер имен отвечает преобразователю DNS IP-адресом сервера имен TLD.
Преобразователь DNS отправляет ещё один запрос, теперь на сервер имён TLD, спрашивая, знают ли они, что это за IP.
Сервер имён TLD отвечает преобразователю DNS IP-адресом полномочного сервера имен.
DNS-преобразователь отправляет последний запрос авторитетному серверу имен, запрашивая IP.
Полномочный сервер имен просканирует файлы зон, чтобы найти сопоставление имя домена: ipaddress, и вернёт, существует оно или нет, на преобразователь DNS.
Наконец, преобразователь DNS теперь ответит браузеру IP-адресом сервера, с которым браузер пытается связаться.

Далее следует установка соединения с сервером (1 RTT). Производится она по принципу «тройного рукопожатия» TCP. Это позволяет установить надёжное соединение, в котором обе стороны синхронизированы (SYN) и опознаны друг другом (ACK). Соответственно соединение производится в три шага: SYN, SYN-ACK, ACK.

Как только соединение установлено, ACK обычно следуют для каждого сегмента. В конечном итоге соединение завершится RST (сбросить или разорвать соединение) или FIN (корректно завершить соединение).

В итоге для сайтов, на которые вы заходите впервые, процесс DNS может занимать целых 4 RTT, в то время, как для уже знакомых страниц он сокращается до 2 RTT.

Шаг 2: Получение

GET - запрашивает информацию с заданного сервера, используя унифицированный идентификатор ресурса (URI). Спецификация правильных реализаций метода GET только извлекает данные и не вызывает изменений в исходном состоянии. Независимо от того, сколько раз вы запрашиваете один и тот же ресурс, вы никогда не вызовете изменения состояния. Есть и другие методы, но нас интересует непосредственно GET.

Шаг 3: Парсинг

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

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

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

Что же происходит дальше? А дальше браузер начинает строить дерево DOM. Анализ HTML включает токенизацию и построение дерева.

Токенизация - это лексический анализ, разбивающий элементы на токены.
Постройка дерева - это, по сути, создание дерева на основе проанализированных токенов и того, на чем мы будем сосредоточены - дерева DOM.

Дерево DOM описывает содержимое документа. В нём также указываются взаимосвязи и иерархия различных тегов. Теги, которые расположены внутри других тегов называются «дочерними» узлами. Чем больше узлов DOM, тем дольше происходит построение дерева.

Следующий этап в этом шаге – обработка CSS и построение дерева CSSOM. Браузер строит «узловую» модель дерева точно так же, как в случае с DOM: формирует родительские, дочерние, сиблинговые узлы. Тут дело идёт проще, ведь в отличие от HTML, CSS имеет контекстно-свободную грамматику и анализируется с помощью стандартных методов синтаксического анализа CFG. Как и с HTML, браузеру нужно преобразовать полученные правила во что-то, с чем он сможет работать. И тут он снова обращается к процессу преобразования HTML в объект, но уже для CSS.

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

Начиная с корня DOM-дерева, проходит по каждому видимому узлу. Некоторые узлы могут быть не видны (например, теги сценария, метатеги и т. д.) И опускаются, поскольку они не отражаются в визуализированном выводе. Некоторые узлы скрыты с помощью CSS и также не отображаются в дереве рендеринга; например, узел span - в приведённом выше примере - отсутствует в дереве визуализации, потому что у нас есть явное правило, которое устанавливает для него свойство «display: none».
Для каждого видимого узла находит соответствующие правила CSSOM и применяет их.
Выпускает видимые узлы с содержимым и их вычисленными стилями.

Конечный результат - это визуализация, в которой есть как содержимое, так и информация о стиле всего видимого на экране. Установив дерево рендеринга, мы можем перейти к этапу «разметки».

Одновременно с построением дерева рендеринга браузер использует ещё одного незаменимого помощника – сканер предзагрузки, который подготовит запрос на выборку с высоким приоритетом для таких ресурсов, как CSS, JavaScript и веб-шрифты. Это оптимизация, добавленная на этапе синтаксического анализа, поскольку выполнение этих запросов займёт слишком много времени, поскольку синтаксический анализатор находит на них ссылки.
Браузер также строит дерево доступности, которое вспомогательные устройства используют для анализа и интерпретации контента. Объектная модель доступности (AOM) похожа на семантическую версию DOM. Браузер обновляет дерево доступности при обновлении DOM. Дерево доступности не может быть изменено самими вспомогательными технологиями. Пока модель AOM не построена, контент не будет отображен на экране.

Шаг 4: Рендеринг

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

Теперь самое время познакомить вас с понятием критического пути рендеринга. Лучше всего это визуализировать с помощью инфографики:

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

И, наконец, мы переходим к самому рендерингу.

Макет - это первый этап рендеринга, на котором определяется геометрия и расположение узлов. Макет рекурсивно строится через часть или всю иерархию кадров, вычисляя геометрическую информацию для каждого средства визуализации, которому она требуется. Чтобы не делать полный макет для каждого небольшого изменения, браузеры используют систему «грязных битов». Изменённый или добавленный рендерер помечает себя и его дочерние элементы как «грязные».
Рисование – следующий этап рендеринга. Браузер преобразует каждый блок, вычисленный на этапе макета, в фактические пиксели на экране. Рисование включает в себя визуализацию всех элементов на экране. Браузеру нужно обрабатывать всё это очень быстро. Этот этап может разбивать элементы в дереве компоновки на слои. Размещение содержимого в слоях на графическом процессоре (вместо основного потока на центральном процессоре) улучшает производительность рисования и перерисовки. Слои действительно повышают производительность, но являются дорогостоящими, когда дело доходит до управления памятью, поэтому не следует злоупотреблять ими в рамках стратегий оптимизации веб-производительности.
В ряде случаев при рендеринге страницы потребуется компоновка или выстраивание композиции. Когда разделы документа отрисовываются на разных слоях, перекрывая друг друга, наложение необходимо для обеспечения того, чтобы они отображались на экране в правильном порядке и содержимое отображалось правильно.

Шаг 5: Финальный

Если вы думаете, что после полной отрисовки всё уже готово, можем вас разочаровать: в случае, когда загрузка JS была отложена, потребуется ещё время на её завершение. Нередко в таких случаях оценивается TTI – время до ответа пользователю. Если браузер занят построением деревьев, загрузкой JavaScript и отрисовкой, он просто не сможет в это же время отвечать на клики пользователя. Чаще всего TTI составляет около 50 мс.

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

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