предисловие
Браузер — важный инструмент для нашего повседневного развития, так что вы знаете браузер? Даже на фронтенд-интервью мы часто сталкиваемся: что происходило в процессе от ввода url-адреса в адрес браузера до появления страницы? Внедрить перерисовку и перекомпоновку? Этот тип вопросов касается браузеров. Мы можем знать общую схему, но не так ясно о конкретных деталях, поэтому сегодня мы начнем с состава браузера, чтобы понять механизм рендеринга браузера.
Состав браузера
Браузер в основном состоит из 7 частей:
- Пользовательский интерфейс: определяет некоторые общие компоненты браузера, такие как адресная строка, возврат, закладки и т. д.
- Настойчивость данных: относится к файлованию Browser, локальное хранилище и другие компоненты.
- Механизм браузера: соответствующий интерфейс приложения платформы, который передает инструкции между пользовательским интерфейсом и механизмом рендеринга.
- Механизм рендеринга: обрабатывает синтаксический анализ и рендеринг HTML и CSS.
- Интерпретатор JavaScript: анализ и выполнение кода JavaScript
- UI Backend: относится к графической библиотеке браузера и т. д.
- Сеть: используется для сетевых вызовов, таких как HTTP-запросы.
ядро браузера
Ядра браузера состоят из двух частей: механизмов рендеринга (Layout Engineer или Rendering Engine) и JS Engine.
- Механизм рендеринга: отвечает за получение содержимого веб-страницы (HTML, XML, изображения и т. д.), организацию информации (например, добавление CSS и т. д.), вычисление метода отображения веб-страницы и последующий ее вывод. к монитору или принтеру
- Движок JS: отвечает за разбор и выполнение javascript для достижения динамических эффектов веб-страниц. Разные ядра браузеров по-разному интерпретируют синтаксис веб-страниц, поэтому эффекты рендеринга также будут разными. Для всех веб-браузеров, почтовых клиентов и других приложений, которым необходимо редактировать и отображать веб-контент, требуется ядро. Сначала механизм рендеринга и механизм JS не были четко разграничены. Позже механизм JS становился все более и более независимым, и ядро, как правило, относится только к движку рендеринга
Распространенные ядра браузеров: Trident (IE), Gecko (Firefox), Blink (Chrome, Opera), Webkit (Safari)
Процесс загрузки страницы
Прежде чем понять процесс рендеринга браузера, давайте сначала разберемся с процессом загрузки страницы. Помогает лучше понять последующий процесс рендеринга. От адреса браузера, от ввода URL-адреса до рендеринга страницы, будет проходить следующий процесс. 1. URL-адрес, введенный браузером, анализируется DNS для получения соответствующего IP-адреса. 2. Инициируйте трехстороннее рукопожатие TCP с сервером. 3. После того, как ссылка установлена, браузер отправляет http-запрос на IP-адрес 4. Сервер получает запрос и возвращает кучу строковых кодов в формате HMTL. 5. Браузер получает HTML-код и преобразует его в DOM-дерево. 6. Получите CSS и создайте CSSOM 7. Объедините DOM с CSSOM для создания дерева рендеринга. 8. Найдите, где находится весь контент на веб-странице, и разложите дерево рендеринга. 9. Наконец нарисуйте страницу
Механизм рендеринга в браузере
Основные этапы процесса рендеринга браузера, которые мы представим, составляют 5-9 шагов, которые можно визуально отобразить на следующем рисунке.
Разобрать HTML в дерево DOM
Процесс анализа можно условно разделить на несколько этапов:
Примечание. Токены, помеченные конечными тегами, не создают узловых объектов. Шаг 4: Определите и свяжите отношения между узлами с помощью «начального тега» и «конечного тега». Когда все токены сгенерированы и использованы, мы получаем полное DOM-дерево.
Но теперь возникает вопрос, как поддерживается связь между узлами? Выше мы упоминали, что токен будет определять, является ли он «начальным тегом» или «конечным тегом». Следующий рисунок является примером: токен «Hello» расположен между начальным тегом «title» и конечным тегом «title», указывая что токен «Hello» является «заголовком» «дочерним узлом токена. Точно так же токен «title» является дочерним узлом токена «head».
Построить CSSOM
Поскольку есть HTML-анализ, анализ CSS также важен. Процесс разбора CSS для создания CSSOM очень похож на процесс строительства DOM. Когда браузер получает кусок CSS, первое, что нужно сделать браузер, это идентифицировать токен, затем создать узел и генерировать CSSOM
Сопоставление HTML-элементов с помощью CSS — довольно сложная и проблематичная вещь. Поэтому дерево DOM должно быть небольшим, CSS должен максимально использовать идентификатор и класс и не каскадироваться вниз. Следовательно, скорость загрузки CSS и скорость построения CSSOM будут напрямую влиять на скорость рендеринга первого экрана, поэтому по умолчанию CSS рассматривается как ресурс, блокирующий рендеринг.
Построить дерево рендеринга
После того, как мы сгенерируем дерево DOM и дерево CSSOM, нам нужно объединить два дерева в дерево рендеринга.В процессе построения дерева рендеринга браузер должен сделать следующее:
- Пройдите каждый видимый узел, начиная с корня дерева DOM.
- Некоторые узлы не видны (например, токены скриптов, мета-токены и т. д.) и игнорируются, поскольку они не будут отражены в отображаемом выводе.
- Некоторые узлы скрыты CSS и поэтому также игнорируются в дереве рендеринга. Например, для некоторых узлов установлено свойство display: none.
- Для каждого видимого узла найдите адаптированные правила CSSOM и примените их.
блокировка рендеринга
В процессе рендеринга, когда встречается тег script, рендеринг будет остановлен, файл скрипта будет запрошен и файл скрипта будет выполнен, потому что рендеринг в браузере и выполнение JS используют один и тот же поток, и это должен быть один поток. многопоточная операция будет генерировать конфликты Render DOM. Загрузка, синтаксический анализ и выполнение JavaScript могут серьезно заблокировать построение DOM. Только после того, как файл сценария будет выполнен, он продолжит построение DOM.
js не только заблокирует построение DOM, но и заставит CSSOM заблокировать построение DOM. DOM, пока его CSSOM не будет завершен. Загрузите и создайте, затем выполните JavaScript и, наконец, продолжите сборку DOM.
Поэтому расположение скрипта очень важно, и в процессе фактического использования соблюдаются следующие два принципа:
- Сначала CSS: в порядке введения ресурсы CSS предшествуют ресурсам JavaScript.
- JS после: Обычно мы размещаем код JS внизу страницы, а JavaScript должен как можно меньше влиять на построение DOM.
макет и рисунок
После того, как браузер получит дерево рендеринга, он перейдет от корневого узла дерева рендеринга, а затем определит точный размер и положение каждого объекта узла на странице, обычно это поведение также называется «автоматической перекомпоновкой». Результатом этапа компоновки является блочная модель, которая точно фиксирует точное положение и размер каждого элемента на экране, а все относительные измерения преобразуются в абсолютные пиксели на экране. Этот процесс также известен как оплавление
Сразу после завершения компоновки браузер генерирует события «Paint Setup» и «Paint» для преобразования дерева рендеринга в пиксели на экране.
стратегия оптимизации производительности
После того, как мы поймем механизм рендеринга браузера, порядок построения структур DOM и CSSOM, мы можем дать некоторые решения по оптимизации производительности для повышения производительности страницы.
1. Перекомпоновать и перекрасить
Когда стиль элемента изменяется, браузер должен инициировать обновление, перерисовывая элемент. В этом процессе есть два типа операций, а именно перерисовка и перекомпоновка.
- Перерисовать (перерисовать): когда изменение не влияет на макет элементов стиля, браузер будет использовать для перерисовки обновляемых элементов, только на этот раз из-за необходимости перерисовки уровня пикселей пользовательского интерфейса и, следовательно, меньшего износа и рвать
- Перекомпоновка: при изменении размера, структуры или определенных свойств элемента браузер повторно отображает страницу, что называется перекомпоновкой. В это время браузеру необходимо произвести перерасчет, а после расчета ему необходимо переразметить страницу, так что это более тяжелая операция. Действия, вызывающие перекомпоновку:
- Добавить или удалить видимые элементы DOM
- Положение элемента меняется
- Изменяются размеры элемента (включая поля, внутренние границы, размер границы, высоту и ширину и т. д.)
- Изменения содержимого, такие как изменение текста или замена изображения другим изображением другого размера.
- При первом отображении страницы (это определенно неизбежно)
Примечание: перекомпоновка определенно вызовет перерисовку, но перерисовка не обязательно приведет к перерисовке.Накладные расходы на перерисовку невелики, а стоимость перекомпоновки высока.
Поэтому, чтобы уменьшить оптимизацию производительности, мы можем попытаться избежать операций перекомпоновки или перерисовки. css
- Избегайте использования макета таблицы
- Примените эффект анимации к элементу, свойство position которого является абсолютным или фиксированным.
javascript
- Избегайте частого шаблона работы, можно изменить после единой сводки
- Попробуйте использовать класс для модификации стиля
- Чтобы уменьшить количество добавлений и удалений DOM, вы можете использовать строку или documentFragment для вставки за один раз.
- Во время экстремальной оптимизации модификация стиля может быть изменена после display: none
- Избегайте запуска вышеупомянутых методов, которые будут запускать перекомпоновку несколько раз.Если возможно, попробуйте использовать переменные для их хранения.
Какова роль асинхронности и отсрочки? Какая разница?
Разница между атрибутами defer и async:
2) Случай 2 (асинхронная загрузка) Атрибут async означает асинхронное выполнение входящего JavaScript, отличие от defer в том, что если он был загружен, он начнет выполняться — будь то на этапе парсинга HTML или после срабатывания DOMContentLoaded. Следует отметить, что JavaScript, загруженный таким образом, все равно будет блокировать событие загрузки. Другими словами, асинхронный скрипт может выполняться до или после срабатывания DOMContentLoaded, но он должен выполняться до срабатывания загрузки.
3) Случай 3
По сравнению с обычным скриптом, defer имеет два отличия:
- Синтаксический анализ HTML не блокируется при загрузке файла JavaScript, а фаза выполнения размещается после завершения синтаксического анализа тега HTML;
- При загрузке нескольких JS-скриптов асинхронная загрузка выполняется непоследовательно, а отложенная — последовательной.
js может добавлять атрибуты отсрочки и асинхронные атрибуты к тегам скрипта, чтобы контролировать загрузку и выполнение скриптов, не блокируя синтаксический анализ документа страницы.
Другое: установка значения атрибута в атрибуте rel тега CSS на предварительную загрузку позволяет указать на HTML-странице, какие ресурсы необходимы сразу после загрузки страницы, оптимально настроить порядок загрузки и повысить производительность рендеринга.
Оптимизированная загрузка выше сгиба
- Уменьшите количество вычислений CGI на первом экране: например, при разработке H5 безналичного дня WeChat 8.8 внешний интерфейс надеется получить три типа данных: личную информацию пользователей, записи о потреблении и ранжирование. один CGI используется для обработки, то время отклика серверной части определенно будет больше, потому что первый экран H5 содержит только информацию о пользователе, а записи потребления и рейтинги находятся на втором и третьем экранах, в это время, записи о потреблении и данные ранжирования могут быть получены асинхронным способом.
- Уменьшение страницы: сжатие HTML, CSS, JavaScript.
- Уменьшите количество запросов: количество файлов CSS и JavaScript должно быть как можно меньше.Даже если кодов CSS и JS не так много, вы можете рассмотреть возможность непосредственного встраивания кода в страницу.
- Многоцелевое кэширование. Кэширование может значительно сократить время, когда страницы не загружаются в первый раз.
- Используйте меньше макета таблицы, браузер будет потреблять больше ресурсов при рендеринге таблицы, и только если в таблице будет небольшое изменение, вся таблица будет перерисована.
- Сделайте предварительную загрузку: часть страницы H5 выше сгиба, возможно, захочет загрузить больше статических ресурсов, таких как изображения, на этот раз, чтобы избежать «уродства» при загрузке страницы, чтобы сделать переход с предварительно загруженным (загрузка способ)
Суммировать
Мы уже узнали о механизме рендеринга браузера, не только узнали некоторые схемы оптимизации производительности, но и можем сделать выводы: Критический путь для браузерного рендеринга состоит из пяти шагов:
Build DOM -> Build CSSOM -> Build Render Tree -> Layout -> Draw
Ссылка на ссылку