использовать один процесс рендеринга в браузере что это
Рендеринг WEB-страницы: что об этом должен знать front-end разработчик
Приветствую вас, уважаемые хабравчане! Сегодня я бы хотел осветить вопрос рендеринга в веб-разработке. Конечно, на эту тему уже написано много статей, но, как мне показалась, вся информация довольно разрознена и отрывочна. По крайней мере, чтобы собрать всю картину в своей голове и осмыслить её, мне пришлось проанализировать немало информации (в основном — англоязычной). Именно поэтому я решил формализовать свои знания в статью, и поделиться результатом с сообществом Хабра. Думаю, информация будет полезна как начинающим веб-разработчикам, так и более опытным, чтобы освежить и структурировать свои знания.
Данное направление можно и нужно оптимизировать на этапе вёрстки/frontend-разработки, поскольку, очевидно, что разметка, стили и скрипты принимают в рендеринге непосредственное участие. Для этого соответствующие специалисты должны знать некоторые тонкости.
Отмечу, что статья нацелена не на точную передачу механики работы браузеров, а, скорее, на понимание её общих принципов. Тем более, разные браузерные движки сильно отличаются в алгоритмах работы, поэтому охватить все нюансы в рамках одной статьи не представляется возможным.
Процесс обработки WEB-страницы браузером
Для начала, рассмотрим последовательность работы браузера при отображении документа:
Repaint
Reflow
Если же изменения затрагивают содержимое, структуру документа, положение элементов — происходит reflow (или relayout). Причинами таких изменений обычно являются:
Оптимизация со стороны браузера
Браузеры по возможности локализуют repaint и reflow в пределах элементов, подвергнувшимися изменению. Например, изменение размеров абсолютно или фиксировано спозиционированного элемента затронет только сам элемент и его потомков, в то время как изменение статично спозиционированного — повлечет reflow всех элементов, следующих за ним.
Ещё одна особенность — во время выполнения JavaScript браузеры кэшируют вносимые изменения, и применяют их в один проход по завершению работы блока кода. Например, в ходе выполнения данного кода произойдет только один reflow и repaint:
Однако, как описано выше, обращение к свойствам элементов вызовет принудительный reflow. То есть, если мы в приведённый блок кода добавим обращение к свойству элемента, это вызовет лишний reflow:
В итоге мы получим 2 reflow вместо одного. Поэтому, обращения к свойствам элементов по возможности нужно группировать в одном месте, дабы оптимизировать производительность (см. более подробный пример на JSBin).
Затем, попробуем реализовать задуманное следующим образом:
Данное решение не будет работать, как ожидается, т.к. изменения кэшируются и применяются только в конце блока кода. Нас выручит принудительный reflow, в результате код приобретёт следующий вид, и будет в точности выполнять поставленную задачу:
Практические советы по оптимизации
На основе данной статьи, а также других статей на Харбе, где освещается вопрос оптимизации клиентской части, можно вывести следующие советы, которые пригодятся при создании эффективного фронтенда:
Надеюсь, каждый читатель извлёк из статьи что-нибудь полезное. В любом случае — спасибо за внимание!
UPD: Спасибо SelenIT2 и piumosso за верные замечания по поводу эффективности обработки CSS-селекторов.
Устройство современного веб-браузера Chrome (часть 3/4)
Это третья часть из 4-х, посвященных работе браузеров. Ранее мы рассматривали многопроцессорную архитектуру и навигацию. В этом посте мы рассмотрим, что происходит внутри *рендер-процесса (renderer process).
*Рендер-процесс затрагивает многие аспекты производительности веб. Так как внутри *рендер-процесса происходит много чего, этот пост является лишь общим обзором. Если вы хотите копнуть глубже, то в разделе «Производительность» Web Fundamentals есть гораздо больше ресурсов.
*Рендер-процессы обрабатывают веб-контент
*Рендер-процесс отвечает за все, что происходит внутри вкладки. В *рендер-процессе главный поток обрабатывает бОльшую часть кода, который вы посылаете пользователю. Иногда части вашего JavaScript обрабатываются рабочими потоками, если вы используете web worker или *сервис-воркер (service worker). *Композ-потоки (compositor threads) и *растр-потоки (raster threads) также запускаются внутри *рендер-процессов для эффективного и гладкого рендеринга страницы.
Основная задача *рендер-процесса — превратить HTML, CSS и JavaScript в веб-страницу, с которой пользователь может взаимодействовать.
Рисунок 1: *Рендер-процесс с главным потоком, worker потоками, *композ-потоком, и *растр-потоком внутри
Парсинг
= Конструкция DOM
Когда процесс рендеринга получает сообщение о необходимости выполнить навигацию и начинает получать HTML-данные, главный поток начинает разбирать текстовую строку (HTML) и превращать ее в Document Object Model (DOM).
DOM — это внутреннее представление страницы браузером, а также структура данных и API, с которым веб-разработчик может взаимодействовать через JavaScript.
Преобразование HTML-документа в DOM определяется стандартом HTML. Вы могли заметить, что приход HTML в браузер никогда не приводит к ошибке. Например, отсутствующий закрывающий тег
= Загрузка подресурсов
Рисунок 2: Главный поток парсит HTML и строит DOM дерево
Русские Блоги
Принцип рендеринга браузера, о котором вы не знаете
Предисловие
В этой статье мы берем Webkit в качестве примера для проведения глубокого анализа процесса рендеринга в современных браузерах.
Если хотите читать больше качественных статей, ткните пожалуйстаБлог GitHub。
Процесс загрузки страницы
Перед тем как представить процесс рендеринга в браузере, мы кратко познакомим вас с процессом загрузки страницы, который поможет лучше понять последующий процесс рендеринга.
Основные моменты заключаются в следующем:
Браузер получает IP-адрес доменного имени в соответствии с DNS-сервером;
Отправить HTTP-запрос на эту IP-машину;
Сервер получает, обрабатывает и возвращает HTTP-запрос;
Браузер получает возвращенный контент.
Сервер получает HTTP-запрос, а затем после расчета (отправка разного контента разным пользователям) возвращает HTTP-запрос. Возвращаемое содержимое выглядит следующим образом:
Фактически, это набор строк формата HMTL, потому что только браузеры формата HTML могут правильно анализировать его, что является требованием стандарта W3C. Следующим шагом является процесс рендеринга в браузере.
Процесс рендеринга в браузере
Процесс рендеринга в браузере примерно разделен на следующие три части:
1) Браузер проанализирует три вещи:
2) После завершения анализа движок браузера построит дерево рендеринга через дерево DOM и дерево правил CSS.
Дерево рендеринга Дерево рендеринга не эквивалентно дереву DOM.Дерево рендеринга включает только узлы, которые необходимо отобразить, и информацию о стиле этих узлов.
Дерево правил CSS в основном предназначено для завершения сопоставления и присоединения правила CSS к каждому элементу (то есть каждому кадру) в дереве рендеринга.
Затем вычислите положение каждого кадра, что также называется процессом компоновки и перекомпоновки.
3) Наконец, нарисуйте, вызвав API собственного графического интерфейса операционной системы.
Далее мы подробно расскажем о важных шагах, которые мы прошли.
Постройте DOM
Браузер выполнит ряд шагов для преобразования файлов HTML в деревья DOM. Макроскопически его можно разделить на несколько этапов:
Браузер считывает необработанные байты HTML с диска или сети и преобразует их в строки в соответствии с указанной кодировкой файла (например, UTF-8).
Контент, передаваемый по сети, на самом деле представляет собой данные размером 0 и 1 байт. Когда браузер получает эти байтовые данные, он преобразует байтовые данные в строку, которая и является кодом, который мы написали.
Преобразуйте строку в токен, например: \u0026lt;html\u0026gt; 、 \u0026lt;body\u0026gt; Подождите.Токен будет определять, является ли текущий токен «начальным тегом», «конечным тегом» или «текстом», а также другой информацией.。
В это время у вас должны возникнуть вопросы, как сохранить связь между узлами?
Фактически, это роль Token для идентификации «начального тега» и «конечного тега». Например, узел между начальным тегом и конечным тегом токена «title» должен быть дочерним узлом «head».
На рисунке выше показана взаимосвязь между узлами. Например, токен «Hello» расположен между начальным тегом «title» и конечным тегом «title», что указывает на то, что токен «Hello» является дочерним узлом токена «title». Точно так же токен «title» является дочерним узлом токена «head».
Фактически, в процессе построения DOM, вместо ожидания преобразования всех токенов, создаются объекты узлов. Вместо этого генерируются токены при использовании токенов для создания узловых объектов. Другими словами, после того, как каждый токен сгенерирован, токен будет немедленно использован для создания объекта узла.Примечание. Токен с закрывающим тегом не создает объект узла.
Далее мы приводим пример, предполагая, что есть текст HTML:
Приведенный выше HTML проанализирует это:
Создать CSSOM
DOM захватит содержимое страницы, но браузер также должен знать, как отображать страницу, поэтому необходимо создать CSSOM.
В этом процессе браузер будет определять стиль каждого узла, и на самом деле этот процесс очень ресурсоемкий. Потому что вы можете установить стиль для узла самостоятельно или получить его через наследование. В этом процессе браузер должен повторно просмотреть дерево CSSOM, а затем определить, в каком стиле находится конкретный элемент.
Постройте дерево рендеринга
После того, как мы сгенерируем дерево DOM и дерево CSSOM, нам нужно объединить два дерева в дерево отрисовки.
У нас могут возникнуть сомнения:Что делать, если браузер обнаруживает JS-файлы во время рендеринга？
Другими словами, если вы хотите отобразить первый экран быстрее, на первом экране должно быть загружено меньше файлов JS, поэтому рекомендуется размещать тег скрипта внизу тега body. Конечно, на данный момент это не означает, что тег скрипта должен быть размещен внизу, потому что вы можете добавить атрибуты defer или async к тегу скрипта (разница между ними будет представлена ниже).
Файлы JS не только блокируют построение DOM, но и заставляют CSSOM блокировать построение DOM.。
Первоначально построение DOM и CSSOM не влияло друг на друга. Однако, как только был введен JavaScript, CSSOM начал блокировать построение DOM. Только после создания CSSOM DOM возобновляет построение DOM.
Это связано с тем, что JavaScript может не только изменять DOM, но и изменять стиль, то есть изменять CSSOM. Поскольку неполный CSSOM нельзя использовать, если JavaScript хочет получить доступ к CSSOM и изменить его, то при выполнении JavaScript он должен иметь возможность получить полный CSSOM. Таким образом, это приводит к явлению: если браузер не завершил загрузку и построение CSSOM, а мы хотим запустить скрипт в это время, браузер задержит выполнение скрипта и построение DOM до тех пор, пока не завершит загрузку и построение CSSOM. Другими словами,В этом случае браузер сначала загрузит и создаст CSSOM, затем выполнит JavaScript и, наконец, продолжит построение DOM.。
Макет и чертеж
После того, как браузер сгенерирует дерево рендеринга, оно будет расположено в соответствии с деревом рендеринга (также называемое перекомпоновкой). На этом этапе браузер должен определить точное положение и размер каждого узла на странице. Обычно такое поведение также называется «автоматическая перестановка».
Результатом процесса макета является «блочная модель», которая точно фиксирует точное положение и размер каждого элемента в области просмотра, а все относительные измерения будут преобразованы в абсолютные пиксели на экране.
После завершения макета браузер немедленно выдаст события «Paint Setup» и «Paint» для преобразования дерева рендеринга в пиксели на экране.
Выше мы подробно рассказали о важных этапах рабочего процесса браузера, а затем обсудим несколько связанных вопросов:
Несколько дополнительных примечаний
1. Какова роль async и defer? Какая разница?
Затем давайте сравним разницу между атрибутами defer и async:
Синяя линия представляет загрузку JavaScript; красная линия представляет выполнение JavaScript; зеленая линия представляет анализ HTML.
1) Ситуация 1 \u0026lt;script src=\u0026quot;script.js\u0026quot;\u0026gt;\u0026lt;/script\u0026gt;
Без defer или async браузер сразу загрузит и выполнит указанный сценарий, что означает, что он загрузит и выполнит элемент документа, не дожидаясь последующей загрузки.
2) Ситуация 2 \u0026lt;script async src=\u0026quot;script.js\u0026quot;\u0026gt;\u0026lt;/script\u0026gt; (Асинхронная загрузка)
3) Ситуация 3 \u0026lt;script defer src=\u0026quot;script.js\u0026quot;\u0026gt;\u0026lt;/script\u0026gt; (Отсроченное исполнение)
Атрибут defer представляет отложенное выполнение введенного JavaScript, то есть HTML не прекращает синтаксический анализ, когда этот JavaScript загружен, и два процесса являются параллельными. После того, как весь документ проанализирован и загружен defer-script (порядок этих двух вещей не имеет значения), весь код JavaScript, загруженный defer-script, будет выполнен, а затем будет запущено событие DOMContentLoaded.
2. Почему манипулировать DOM медленно?
Думайте о DOM и JavaScript как об отдельных островах, соединенных между собой платным мостом. —— «Высокопроизводительный JavaScript»
3. Вы действительно разбираетесь в перерисовке и перерисовке?
Процесс рендеринга в основном выглядит следующим образом (четыре шага желтого цвета на рисунке ниже):
1. Расчет стиля CSS
2. Постройте дерево рендеринга
3.Координаты и размер макета-позиционирования
4. Официально приступить к покраске
Примечание. В приведенном выше процессе есть много соединительных линий, что означает, что Javascript динамически изменяет атрибуты DOM или свойства CSS, что приведет к повторному макету, но некоторые изменения не будут повторять макет. Это стрелки, указывающие на небо на изображении выше, например изменение Следующее правило CSS не соответствует элементу.
Перерисовка: когда наша модификация DOM вызывает изменение стиля, но не влияет на его геометрические свойства (например, изменение цвета или цвета фона), браузеру не нужно пересчитывать геометрические свойства элемента и напрямую рисовать новый элемент. Стиль (пропустите ссылку переформатирования, показанную на рисунке выше).
Reflow: когда наша модификация DOM вызывает изменение геометрического размера DOM (например, изменение ширины, высоты или скрытых элементов элемента), браузеру необходимо пересчитать геометрические свойства элемента (геометрические свойства и положение других элементов также будут затронуты соответствующим образом. Затронуто), а затем нарисовать результаты вычислений.Этот процесс называется перекомпоновкой (также называемой перегруппировкой).
Мы знаем, что при создании веб-страницы она будет отображаться как минимум один раз. В процессе доступа пользователя он будет продолжать перерисовку. Повторный рендеринг будет повторять перерисовку + перерисовку или только перерисовку.
Reflow обязательно вызовет перерисовку, а перерисовка не обязательно вызовет перерисовку. При установке стилей узлов часто происходит перерисовка и перекомпоновка, что также сильно влияет на производительность. Стоимость перекомпоновки намного выше, чем стоимость перерисовки. Изменение дочерних узлов в родительском узле может вызвать серию перекомпоновок родительского узла.
1) Общие атрибуты и методы, вызывающие переформатирование
Любая операция, изменяющая геометрическую информацию элемента (положение и размер элемента), вызовет перекомпоновку,
Добавить или удалить видимые элементы DOM;
Изменения содержимого, например, ввод текста пользователем в поле ввода;
Вычислить свойства offsetWidth и offsetHeight;
Установите значение атрибута стиля.
2) Общие атрибуты и методы, вызывающие перерисовку
3) Как уменьшить переформатирование и перерисовку
Используйте преобразование вместо вершины;
Замените display: none на видимость, потому что первый вызовет только перерисовку, а второй вызовет перекомпоновку (измените макет);
Не помещайте значение атрибута узла в цикл как переменную в цикле.
Не используйте макет таблицы, небольшое изменение может привести к изменению макета всей таблицы;
Выбор скорости реализации анимации, чем выше скорость анимации, тем больше времени перекомпоновки, вы также можете использовать requestAnimationFrame;
Селектор CSS сопоставляет и выполняет поиск справа налево, чтобы избежать слишком большого количества уровней узлов;
Задайте узел, который часто перерисовывается или перекомпоновывается, как слой.Слой может предотвратить влияние режима визуализации узла на другие узлы. Например, для тега видео браузер автоматически превратит узел в слой.
Стратегия оптимизации производительности
На основе представленного выше принципа рендеринга браузера, последовательности построения DOM и структуры CSSOM, инициализация может оптимизировать рендеринг страницы и повысить производительность страницы.
Оптимизация JS: \u0026lt;script\u0026gt; Тег плюс атрибут defer и атрибут async используются для управления загрузкой и выполнением скрипта без блокировки синтаксического анализа документа страницы.
Атрибут Defer: используется для запуска нового потока для загрузки файла сценария и выполнения сценария после анализа документа.
Атрибут async: новый атрибут HTML5, используемый для асинхронной загрузки файлов сценария и немедленного объяснения и выполнения кода после загрузки.
Оптимизация CSS: \u0026lt;link\u0026gt; Установка значения атрибута в атрибуте rel тега как preload позволяет вам указать на вашей HTML-странице, какие ресурсы необходимы сразу после загрузки страницы, оптимально настроить порядок загрузки и улучшить производительность отрисовки.
подводить итоги
Подводя итог, мы приходим к такому выводу:
CSSOM заблокирует рендеринг, и только когда CSSOM будет построен, он перейдет на следующий этап построения дерева рендеринга.
Обычно DOM и CSSOM строятся параллельно, но когда браузер встречает тег скрипта без атрибутов defer или async, построение DOM приостанавливается. Если случится так, что браузер еще не завершил загрузку и построение CSSOM, потому что JavaScript может изменять CSSOM, поэтому вам нужно дождаться сборки CSSOM перед выполнением JS и, наконец, перестроить DOM.
Как работает JS: движки рендеринга веб-страниц и советы по оптимизации их производительности
Сегодня, в переводе одиннадцатой части серии материалов, посвящённых JavaScript, мы поговорим о подсистемах браузера, ответственных за рендеринг веб-страниц. Они играют ключевую роль в деле преобразования описаний документов, выполненных с помощью HTML и CSS, в то, что мы видим на экране.
Автор материала говорит, что в компании SessionStack приходится уделять рендерингу огромное внимание. В этой статье он поделится советами, касающимися оптимизации веб-страниц с учётом особенностей их визуализации.
Обзор
Создавая веб-приложения, мы не пишем изолированный JS-код, который занимается исключительно какими-то собственными «внутренними» делами. Этот код выполняется в окружении, предоставляемом ему браузером, взаимодействует с ним. Понимание устройства этого окружения, того, как оно работает, из каких частей состоит, позволяет разработчику создавать более качественные программы, даёт ему возможность предусмотреть возникновение возможных проблем с приложением, которое вышло в свет.
На рисунке ниже показаны основные компоненты браузера. Давайте поговорим о том, какую роль они играют в процессе обработки веб-страниц.
Основные компоненты браузера
О различных движках рендеринга
Главная задача движка рендеринга заключается в том, чтобы вывести запрошенную страницу в окне браузера. Движок может выводить HTML-документы, XML-документы, изображения. При использовании дополнительных плагинов движок может визуализировать и материалы других типов, например — PDF-документы.
Мы знаем, что существуют различные JS-движки, которые используют различные браузеры. То же самое справедливо и для движков рендеринга. Вот несколько популярных движков:
Процесс рендеринга веб-страницы
Движок рендеринга получает содержимое запрошенного документа от сетевого уровня браузера. Процесс рендеринга выглядит так, как показано на рисунке ниже.
Процесс рендеринга веб-страницы
Вот основные этапы этого процесса:
Создание дерева DOM
Первый этап работы движка рендеринга заключается в разборе HTML-документа и преобразовании того, что у него получилось, в узлы DOM, размещённые в дереве DOM. При этом веб-страница, которая представлена в виде HTML-кода, преобразуется в структуру, подобную той, которая показана на рисунке ниже.
Каждый элемент этого дерева, содержащий вложенные элементы, является для них родительским. Это справедливо для всех уровней вложенности.
Создание дерева CSSOM
Как и в случае с HTML, движку нужно конвертировать CSS в нечто, с чем может работать браузер — в CSSOM. В результате получается дерево CSSOM, представленное на следующем рисунке.
Кроме того, обратите внимание на то, что вышеприведённое дерево не является полным CSSOM-деревом. Тут показаны лишь стили, которые мы, в нашем CSS-файле, решили переопределить. У каждого браузера имеется стандартный набор стилей, применяемый по умолчанию, известный ещё как «стили пользовательского агента» (user agent styles). Именно результаты применения этих стилей можно видеть на странице, не имеющей связанных с ней CSS-правил. Наши же стили просто переопределяют некоторые из стандартных стилей браузера.
Создание дерева рендеринга
Инструкции о внешнем виде элементов, представленные в HTML, скомбинированные с информацией об их стилизации из дерева CSSOM, используются для формирования дерева рендеринга.
Что это такое? Это — дерево визуальных элементов, созданных в том порядке, в котором они будут выводиться на экран. Это — визуальное представление HTML-кода страницы, отражающее влияние соответствующих этой странице CSS-правил. Цель этого дерева заключается в том, чтобы обеспечить вывод элементов правильном порядке.
Узел дерева рендеринга известен в движке WebKit как «renderer» или «render object» (мы будем называть их «объектами рендеринга»).
Вот как будет выглядеть дерево рендеринга для деревьев DOM и CSSOM, показанных выше.
Вот общее описание действий браузера, выполняемых им при создании дерева рендеринга.
Формирование макета страницы
После того, как объект рендеринга создан и добавлен в дерево, ему пока ещё не назначены позиция и размер. Вычисление этих значений и называется формированием макета страницы.
Процесс формирования макета означает задание каждому узлу точной позиции, в которой он должен появиться на странице.
Визуализация дерева рендеринга
На данном этапе осуществляется обход дерева рендеринга и вызов методов paint() объектов рендеринга, которые и выполняют вывод графического представления объектов на экран.
Визуализация, или отрисовка, может быть глобальной или инкрементной (так же выполняется и формирование макета страницы).