предисловие

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

Разработчиков в интервью могут спросить:

Что произошло между моментом, когда вы ввели URL-адрес в браузере, и моментом, когда содержимое страницы было полностью отображено?

Это действительно старомодный вопрос, но ответ на него не единственный: возможно, три-пять лет назад на этот вопрос был бы «относительно» стандартный ответ.

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

Браузерный движок браузера проанализирует этот URL-адрес, если есть кеш "cache-control" и срок его действия не истек, он извлечет файл из локального кеша (From Memory Cache, код возврата 200), если кеш " cache-control" не существует или срок его действия истек, браузер инициирует удаленный запрос

Получите IP-адрес, соответствующий адресу веб-сайта, разрешив доменное имя через DNS, и отправьте запрос GET на этот IP вместе с файлом cookie браузера, userAgent и другой информацией.

Далее идет классическое «трехстороннее рукопожатие», сеанс по протоколу HTTP, и клиент-браузер отправляет сообщение на веб-сервер для связи и передачи данных.

Введите в задневские услуги сайта, например Tomcat, Apache и т. Д., А также популярные серверы Node.js в последние годы, на котором развернут код приложения, и есть много языков, таких как Java, PHP , C ++, C # и JavaScript.

Сервер выполняет соответствующую логику внутреннего приложения в соответствии с URL-адресом, во время которого используется «кеш сервера» или «база данных».

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

Браузер получает возвращаемую информацию и начинает загрузку HTML-файла (без кеша, код возврата 200) или извлекает файл из локального кеша (с кешем, код возврата 304)

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

Механизм рендеринга расширяет дерево DOM в дерево рендеринга в соответствии с правилами стиля CSS, а затем перекомпоновывает и перерисовывает.

Если он содержит файлы JS, он будет выполняться для выполнения операций Dom, чтения и хранения кеша, привязки событий и других операций. Последняя страница будет отображаться в браузере.

Этот ответ кратко суммирует весь процесс «базового шаблона MVC» и реакцию браузера на ранние веб-приложения. С развитием клиентских технологий также были введены «разделение внешнего и внутреннего интерфейса», «прямое промежуточное программное обеспечение» и «режим MNV *». Когда мы говорим об этом вопросе, ответ будет другим.

Возьмем, к примеру, «разделение внешнего и внутреннего интерфейса», после шага 4 приведенного выше ответа он не будет напрямую попадать на внутренний сервер. Вместо этого он будет перехвачен HTTP и обратными прокси-серверами, такими как Ngnix.

Предварительные шаги 1, 2, 3, 4

Ngnix прослушивает запросы HTTP (порт 80) или HTTPS (порт 443), распределяет услуги в соответствии с URL-адресом и распределяет (перезаписывает) на внутренний сервер или сервер статических ресурсов.Запрос домашней страницы в основном распространяется на статический сервер. и возвращает HTML-файл

Шаги 7, 8, 9, 10

Выполните JS-скрипт, инициируйте запросы POST и GET с помощью асинхронного ajax и выборки, повторно введите дистрибутив Ngnix, на этот раз распределите на внутренний сервер, шаг 5, 6, 7, а затем верните сообщение в формате xml или json, обычно содержащий код (код возврата) и результат (информацию о зависимости)

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

Из приведенных выше шагов можно обнаружить, что браузер может запускать две перерисовки, что может легко вызвать «белый экран» или «дрожание страницы».Чтобы решить эту проблему, появился режим «промежуточного программного обеспечения». Кроме того, чтобы расширить фронтенд-лагерь и поглотить IOS и Android, Google разработал «режим MNV*», типичным представителем которого является ReactNative, но этот режим был отделен от браузера, поэтому он не будет быть продлен здесь.

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

Структура браузера

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

Пользовательский интерфейс- Включая адресную строку, кнопки назад/вперед, каталог закладок и т. д., то есть то, что вы видите кроме окна отображения страницы
браузерный движок- Он может передавать инструкции между пользовательским интерфейсом и механизмом рендеринга или читать и записывать данные в локальный кеш клиента, который является ядром связи между различными частями браузера.
движок рендеринга- Анализировать документы DOM и правила CSS и вводить содержимое в браузер для отображения стилизованного интерфейса.Это также называется механизмом набора текста.Ядро браузера, о котором мы часто говорим, в основном относится к механизму рендеринга.
Интернет- Модули, используемые для совершения сетевых вызовов или загрузки ресурсов
Серверная часть пользовательского интерфейса- Используется для рисования основного окна браузера внутри элементов управления, таких как входные поля, кнопки, радиопередачи и т. Д., В зависимости от визуальных эффектов браузера по-разному, но функция одинакова.
JS-интерпретатор- Модули, используемые для интерпретации и выполнения сценариев JS, такие как движок V8, JavaScriptCore
хранилище данных- Браузер сохраняет различные данные, такие как файлы cookie и localStorage, на жестком диске, которые можно вызывать через API, предоставляемый движком браузера.

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

движок браузерного рендеринга

Механизм рендеринга браузера разработан крупными производителями браузеров в соответствии со стандартом W3C и также называется «ядром браузера».

В настоящее время на рынке существует 5 основных типов ядер браузеров: Trident, Gecko, Presto, Webkit и Blink.

Trident: широко известные как ядро IE, также известное как механизм MSHTML, браузеры, используемые в настоящее время, представляют собой IE11 и совместимые с IE модули в различных отечественных многоядерных браузерах. Кроме того, браузер Microsoft Edge больше не использует движок MSHTML, а использует новый движок, такой как EdgeHTML.

Gecko: Общеизвестное как ядро Firefox, ядро принято Netscape6, а более поздний Mozilla FireFox (браузер Firefox) также принял это ядро.Gecko характеризуется полным раскрытием кода, поэтому его степень разработки очень высока, и программисты во всем мире могут написать для него код, добавить функционал. Поскольку это ядро с открытым исходным кодом, его предпочитают многие люди, и есть много браузеров с ядром Gecko, что также является важной причиной, по которой ядро Gecko может быстро увеличить свою долю на рынке, несмотря на его молодой возраст.

Presto: Opera pre-kernel, почему именно pre-kernel? Поскольку Opera 12.17 использует ядро Google Chrome Blink, это ядро не имеет поддержки.

Webkit: ядро Safari также является прототипом ядра Chrome, в основном ядром, используемым браузером Safari, и ядром браузера с улучшенными функциями. Он также широко используется в мобильных браузерах.

Blink: Разработан Google и Opera Software и используется в браузерах Chrome (28 и новее), Opera (15 и новее) и Яндекс. Blink на самом деле является ответвлением Webkit, добавляющим некоторые новые оптимизированные функции, такие как межпроцессный iframe, перенос DOM в JavaScript для повышения скорости доступа JavaScript к DOM и т. д. В настоящее время многие мобильные приложения имеют встроенные ядра браузера. принять Blink.

Рабочий процесс движка рендеринга

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

渲染引擎工作流程 — Рабочий процесс движка рендеринга

Анализ HTML При построении дерева DOM механизм рендеринга будет анализировать элемент note в файле HTML на несколько узлов объекта элемента DOM, и эти узлы будут формировать древовидную структуру в соответствии с отношениями родитель-потомок. В то же время файл CSS анализируется в таблицу правил CSS, а затем каждое правило CSS обратно сопоставляется в дереве DOM справа налево для создания дерева рендеринга DOM с описаниями правил стиля. Следующим шагом будет разметка и отрисовка дерева рендеринга. Во-первых, в соответствии с правилами стиля в дереве рендеринга DOM позиционируются размер и положение элементов DOM.Ключевые атрибуты следующие:position;width;margin;padding;top;border;..., а затем в соответствии с правилами стиля элементаcolor;background;shadow;...Правила нарисованы.

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

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

Различия между различными ядрами браузера

Под разными ядрами браузера процесс рендеринга страницы браузера немного отличается

webkit 内核工作流程 — рабочий процесс ядра webkit

Geoko 内核工作流程 — Рабочий процесс ядра Geoko

На двух рисунках выше показан рабочий процесс рендеринга DOM в ядрах Webkit и Geoko. Разница между ними в основном заключается во времени синтаксического анализа таблиц стилей CSS. В ядре Webkit синтаксический анализ файлов HTML и CSS выполняется синхронно, а Geoko В ядре файл CSS должен ждать, пока файл HTML не будет проанализирован в приемнике контента, прежде чем анализировать.

Кроме того, термины описания различны, но процесс в основном одинаков.Три наиболее важные части: «Синтаксический анализ HTML», «Синтаксический анализ CSS» и «Создание дерева рендеринга». Принципы этих трех частей относительно глубоки и предполагают знание таких структур данных, как «лексический анализ», «грамматический анализ», «преобразование» и «интерпретация», которые относительно скучны. Чтобы понять это. Студенты, которые хотят понять больше, могут прочитать этот перевод,Как работают браузеры, в котором подробно объясняется процесс и принцип работы трех вышеперечисленных частей. Я не буду здесь вдаваться в подробности.

О сопоставлении правил CSS

Как мы упоминали выше, правила CSS обратно сопоставляются в дереве DOM «справа налево», и, наконец, генерируется дерево рендеринга DOM с описанием правил стиля.

Но знаете ли вы, почему вы хотите выполнить обратное сопоставление «справа налево»?

Давайте вернемся к [блок-схеме работы ядра webkit]

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

Возьмем один из самых простых каштанов:

<template>
<div>
  <div class="t">
    <span>test</span>
    <p>test</p>
  <div>
</div>
</template>

<style>
div{ color: #000; }
div .t span{ color: red; }
div .t p{color: blue; }
</style>

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

Здесь будут матчи 4 * 3. Если вы выполняете прямой матч, когда вы сталкиваетесь с<span>Сопоставление теговdiv .t p{ color: red; }Когда дело доходит до совпадения, компьютер сначала находит<span>Родительский тег и родительский тег тега, чтобы определить, удовлетворяют ли ониdiv .tправила, а затем сопоставьте<span>ЭтоpЯрлык, совпадение здесь неудачное, что приводит к трем потерям.

Если время повернуть вспять, то первое сравнение<span>ЭтоpМетка может исключить это правило, что более эффективно.

Если структура HTML становится более сложной, а таблица правил CSS становится больше, преимущество «обратного сопоставления» намного больше, чем «прямого сопоставления», потому что ситуация совпадения намного ниже, чем ситуация несовпадения. Кроме того, если в конце селектора будет добавлен подстановочный знак «*», преимущество «обратного сопоставления» будет значительно уменьшено, поэтому во многих принципах оптимизации упоминается «старайтесь избегать добавления подстановочных знаков в конце селектора». .

Думайте до предела, если наша таблица стилей не имеет вложенных отношений, как показано ниже:

<template>
  <div class="t">
    <span class="div_t_span">test</span>
    <p class="div_t_p">test</p>
  <div>
</template>

<style>
div{ color: #000; }
.div_t_span{ color: red; }
.div_t_p{color: blue; }
</style

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

Связанные оптимизации производительности

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

Примерно следующее

Уменьшите влияние загрузки JS на рендеринг Dom.

Загрузите файл JS после документа HTML или загрузите код JS асинхронно.

Избегайте перекомпоновки, уменьшите количество перерисовок

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

Сокращение использования реляционных таблиц стилей

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

Уменьшить уровень DOM

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

уведомление

"Серия переднего конца" IIО стратегиях внешней оптимизации