Какие существуют способы управления настройками браузера html

Обзор инструментов разработки в браузерах

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

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

Как открыть инструменты веб-разработчика в вашем браузере?

Панель разработчика находится в нижней части вашего браузера :

Как её отобразить? Есть три варианта:

• Клавиатура.Ctrl + Shift + I, кроме
  • Internet Explorer.(клавиша — F12)
  • Mac OS X.(сочетание клавиш — ⌘ + ⌥ + I )
• Панель Меню.
  • Firefox. Открыть меню *➤ *➤ Инструменты разработки, или_ Инструменты ➤Веб-разработка ➤ Инструменты разработки
  • Chrome.Дополнительные инструменты ➤ Инструменты разработчика
  • Safari.Разработка ➤ Показать Web Inspector . Если вы не видите меню «Разработка», зайдите в Safari ➤ Настройки ➤ Дополнительно, и проверьте стоит ли галочка напротив «Показать меню разработки».
  • Opera. Меню➤Разработка ➤ Инструменты разработчика. Если вы не видите меню «Разработка», включите его отображение, перейдя в Меню ➤ Другие инструменты ➤ Показать меню разработчика.
• Контекстное меню. Нажмите правой кнопкой мыши на любом участке веб-страницы (Ctrl-клик для Mac), появится контекстное меню, в котором вам нужно выбрать пункт Исследовать Элемент. (дополнение: этот способ отобразит вам код того элемента, на котором вы щёлкнули правой кнопкой.)

Inspector: DOM обозреватель и CSS редактор

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

Если вы не видите Inspector,

• Нажмите на вкладку Inspector .
• В Internet Explorer, нажмите на DOM Обозреватель, или нажмите Ctrl + 1.
• В Safari, элементы управления представлены не так чётко, но вы должны увидеть HTML код, если вы не выбрали что-то другое в окне разработки. Нажмите на кнопку Стиль, чтобы увидеть CSS.

Обзор DOM inspector

Для начала, попробуйте нажать правой кнопкой мыши (Ctrl+клик) по элементу HTML в DOM inspector и посмотрите на контекстное меню. Пункты меню могут различаться в разных браузерах, но важными из них являются одни и те же:

• Удалить узел (иногда Удалить элемент). Удаляет текущий элемент.
• Править как HTML (иногда Добавить атрибут/Править текст). Позволяет редактировать HTML и видеть результат «вживую». Очень полезно для отладки и тестирования.
• :hover/:active/:focus. Заставляет элементы переключить своё состояние на то, к которому применён ваш стиль.
• Копировать/Копировать как HTML. Копирует текущий выделенный HTML.

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

Обзор CSS редактора

По умолчанию, CSS редактор отображает CSS-свойства применённые к текущему выбранному элементу:

Эти функции особенно удобны:

• Свойства, применённые к текущему элементу, отображаются в порядке убывания приоритета.
• Можно убирать галочки напротив свойств для того чтобы видеть, что получится, если их удалить.
• Нажмите на маленькую стрелочку рядом со свойством, чтобы увидеть все его эквиваленты.
• Нажмите на имя свойства или его значение, чтобы открыть текстовое окошко, в котором вы можете задать новые значения и увидеть, как изменится ваш элемент с новыми значениями.
• Рядом с каждым свойством указаны имя файла и номер строки. где располагается это свойство. Щелчок по этому пути перенесёт вас в окно, где можно редактировать этот CSS и сохранить.
• Вы можете также нажать на закрывающуюся фигурную скобку любого свойства, чтобы вывести текстовое поле на новую строку, где вы сможете написать совершенно новую декларацию для вашей страницы.

Вы должно быть уже заметили другие вкладки в CSS редакторе:

• Вычислено: Здесь указаны все вычисления свойств выделенного элемента (окончательные, нормализованные значения применённые браузером).
• Блоковая модель: Отображает блочную модель выделенного элемента, здесь вы можете увидеть внешние и внутренние отступы, а также границы применённые к элементу, здесь также указан их размер.
• Анимации: В Firefox, на вкладке Анимации вы можете увидеть анимации применённые к выделенному элементу.

Узнать больше

Узнать больше об Inspector в различных браузерах:

• Firefox Page inspector
• IE DOM Explorer
• Chrome DOM inspector (Inspector в Opera схож с Inspector в Chrome)
• Safari DOM inspector and style explorer

Консоль JavaScript

Консоль JavaScript невероятно полезный инструмент для отладки JavaScript, если он не работает, как ожидалось. Она позволяет вам загружать JavaScript вопреки порядку загрузки скрипта в браузере, и докладывает об ошибках как только браузер пытается выполнить ваш код. Для доступа к консоли из любого браузера просто нажмите на кнопку Console. (В Internet Explorer, нажмите Ctrl + 2.) Откроется окно, как показано ниже:

Чтобы понять, что происходит, попробуйте ввести фрагменты кода в консоль один за другим (и затем нажмите Enter):

alert("hello!"); 

.querySelector("html").style.backgroundColor = "purple"; 

var myImage = document.createElement("img"); myImage.setAttribute( "src", "https://farm4.staticflickr.com/3455/3372925208_e1f2aae4e3_b.jpg", ); document.querySelector("h1").appendChild(myImage); 

Теперь попробуйте ввести следующую, неправильную версию кода и посмотрите, что из этого получится.

alert('hello!); 

.cheeseSelector("html").style.backgroundColor = "purple"; 

var myImage = document.createElement("img"); myBanana.setAttribute( "src", "https://farm4.staticflickr.com/3455/3372925208_e1f2aae4e3_b.jpg", ); document.querySelector("h1").appendChild(myImage); 

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

Узнать больше

Узнать больше о JavaScript консоли в различных браузерах:

• Firefox Web Console
• IE JavaScript console
• Chrome JavaScript Console (Inpector в Opera схож с Inspector в Chrome)
• Safari Console

Found a content problem with this page?

• Edit the page on GitHub.
• Report the content issue.
• View the source on GitHub.

This page was last modified on 3 авг. 2023 г. by MDN contributors.

Your blueprint for a better internet.

Введение в Chrome DevTools. Панель Elements

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

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

Как открыть инструменты разработчика

Настройки DevTools

Тема интерфейса

Можно настроить инструменты разработчика и изменить их внешний вид — например, выбрать тёмное оформление интерфейса.

Горячие клавиши

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

Расположение панелей

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

Вкладка Elements

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

Как получить информацию об элементе

Есть три способа получить информацию о любом элементе на странице — выбирайте самый удобный для себя.

Через инспектор. Способ удобен, если вы точно видите элемент и можете кликнуть по нему правой кнопкой мыши. Выберите Inspect или «Посмотреть код». Заодно сразу откроется панель разработчика.

Поиск по элементам. При показанном отладчике нажимаем Ctrl+F, и внизу появится окно поиска по тегу, атрибуту, классу или текстовому содержимому элемента.

Введём, например, класс header , и увидим все подходящие элементы:

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

Как внести изменения в элемент на странице

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

Чтобы переместиться вперёд, нажмите Tab, назад — Shift+Tab, а чтобы скрыть элемент, нажмите H.

Как изменить разметку страницы

Любители мыши кликают правой кнопкой на элемент и выбирают Edit as HTML, а фанаты клавиатуры нажимают F2. Результат сразу отображается на экране.

Проверка вёрстки на переполнение

Мы верстали, редактировали, а как проверить, что вёрстка не развалится, если количество элементов изменится? Сделаем тесты на переполнение.

Проверка на переполнение текстом. Есть два способа:

1. Находим элемент, делаем двойной клик и добавляем текст. Проще всего скопировать содержимое и вставить его несколько раз.
2. Открываем вкладку Console, вставляем команду document.body.contentEditable = true , нажимаем Enter. Теперь можно редактировать любой текстовый элемент на странице напрямую. Естественно, исправленный текст останется до перезагрузки страницы и никак не повлияет на сайт.

На что обращать внимание? При добавлении текста элементы должны растягиваться по вертикали, текст не должен вылезать за поля элемента, выпадать или обрезаться.

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

Сетка при переполнении не должна ломаться, а логика потока должна сохраняться.

Просмотр и тестовое редактирование стилей

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

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

Блок с метриками (на скриншоте) на самом деле находится в самом низу — нужно проскроллить список до конца.

Меняем стили прямо в браузере

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

Напишем правило с ошибкой. Правило не применится, потому что его не существует. Оно зачёркнуто, а слева появляется иконка с предупреждением.

А ещё мы можем разворачивать сокращённое правило, кликнув на стрелку. Например, так можно развернуть правило для border-style .

Слева у всех элементов есть чекбокс для включения и выключения стилей.

Данные о цвете

У элементов со свойством color легко меняется цвет — для этого нужно воспользоваться пипеткой. Можно выбрать любой цвет из интерфейса или указать цвет в RGBA или HSL.

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

Как работают браузеры

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

Чтобы понять, как улучшить производительность и ощущаемую пользователем производительность (User Perceived Performance, UPP), вам необходимо понимать, как работают браузеры.

Обзор

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

Две главных проблемы в производительности — это проблема скорости сети и проблема однопоточности браузеров.

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

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

Навигация

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

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

DNS запрос

Первый шаг навигации к странице — это поиск места, откуда нужно запрашивать данные. Если вы переходите на https://example.com , браузер грузит HTML-код страницы с IP-адреса 93.184.216.34 . Если вы никогда ранее не были на этом сайте, произойдёт поиск DNS записи.

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

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

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

TCP Рукопожатие (Handshake)

В тот момент, когда IP адрес становится известен, браузер начинает установку соединения к серверу с помощью рукопожатия TCP three-way handshake (en-US). Этот механизм спроектирован так, чтобы два устройства, пытающиеся установить связь, могли обменяться параметрами соединения, прежде чем приступать к передаче данных. Чаще всего — через защищённое соединение HTTPS.

Трёхэтапное рукопожатие TCP — это техника, очень часто упоминаемая как «SYN-SYN-ACK» ( SYN, SYN-ACK, ACK , если быть точнее), т.к. при установке соединения передаются 3 сообщения. Это означает, что прежде чем установится соединение, браузер должен обменяться ещё тремя сообщениями с сервером.

TLS Переговоры (Negotiation)

Для установки безопасных соединений с использованием HTTPS требуется ещё одно рукопожатие. На этот раз — TLS переговоры. На этом шаге определяется, какой шифр будет использоваться для шифрования соединения, удостоверяется надёжность сервера и устанавливается безопасное соединение. Этот шаг также требует несколько дополнительных сообщений, которыми должны обменяться сервер и браузер, прежде чем данные будут посланы.

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

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

Ответ на запрос

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

doctype html> html> head> meta charset="UTF-8" /> title>My simple pagetitle> link rel="stylesheet" src="styles.css" /> script src="myscript.js"> script> head> body> h1 class="heading">My Pageh1> p>A paragraph with a a href="https://example.com/about">linka>p> div> img src="myimage.jpg" alt="image description" /> div> script src="anotherscript.js"> script> body> html> 

Этот ответ содержит в себе первый байт полученных данных. Время до первого байта (Time to First Byte, TTFB) — это время между моментом когда пользователь отправил запрос, скажем, нажав на ссылку, и моментом получения первого пакета данных HTML. Первый пакет обычно содержит 14КБ данных.

В примере выше ответ значительно меньше, чем 14КБ; скрипты и стили, перечисленные в ответе, не будут запрошены, пока браузер не обработает ответ. Процесс обработки ответа — парсинг — мы обсудим отдельно.

TCP медленный старт / правило 14kb

Объём первого пакета данных — всегда 14KB. Это часть спецификации TCP slow start (en-US) — алгоритма, который балансирует скорость соединения. Такое правило позволяет постепенно, по мере необходимости, увеличивать размеры передаваемых данных, пока не будет определена максимальная ширина канала.

В алгоритме TCP slow start (en-US) каждый следующий отправленный сервером пакет увеличивается в размере в два раза. Например, размер второго пакета будет около 28КБ. Размер пакетов будет увеличиваться до тех пор, пока не достигнет какого-то порогового значения или не упрётся в проблему переполнения.

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

Контроль переполнения

Любое соединение имеет ограничения, связанные с аппаратной и сетевой системами. Если сервер отправит слишком много пакетов за раз — они могут быть отброшены. Для того, чтобы избежать таких проблем, браузер должен реагировать на получение пакетов и подтверждать, что он получает их. Такой ответ-подтверждение называется Aknowledgements (ACK). Если из-за ограничений соединения браузер не получит данных, то он не пошлёт подтверждений ACK. В этом случае, сервер зарегистрирует, что какие-то пакеты не дошли и пошлёт их заново, что приведёт к лишней работе сервера и дополнительной нагрузке сети.

Парсинг

Как только браузер получает первый кусочек данных, он сразу начинает обрабатывать получаемую информацию. Эта обработка называется «Парсинг» (Parsing). Во время парсинга получаемые данные преобразуются в DOM и CSSOM (en-US), которые напрямую участвуют в отрисовке.

DOM (Объектная модель документа) — это внутреннее представление разметки HTML. Браузер предоставляет доступ к манипуляции объектами этой модели через разные JavaScript API.

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

Построение дерева объектной модели документа

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

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

Когда парсер находит неблокирующие ресурсы (например, изображения), браузер отправляет запрос на загрузку ресурсов, но сам продолжает обработку. Обработка может продолжаться когда обнаружена ссылка на CSS файл, но если обнаружен , особенно если он без параметров async или defer — такой скрипт считается блокирующим и приостанавливает обработку HTML до завершения загрузки скрипта. Несмотря на то, что сканер предзагрузки (о нём ниже) браузера может находить и запрашивать такие скрипты заранее, сложные и объёмные скрипты всё ещё могут стать причиной заметных задержек загрузки страницы.

Сканер предзагрузки

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

link rel="stylesheet" src="styles.css" /> script src="myscript.js" async> script> img src="myimage.jpg" alt="image description" /> script src="anotherscript.js" async> script> 

В примере выше основной поток обрабатывает HTML и CSS. В то же время, сканер предзагрузки находит скрипты и изображение и начинает их загрузку. Чтобы сделать скрипт неблокирующим, добавьте атрибут async или, в случае, если порядок загрузки скриптов важен, атрибут defer .

Примечание: Ожидание получения CSS не блокирует парсинг HTML, но он блокирует JavaScript, потому что JavaScript часто используется для выборки узлов документа по CSS-селекторам.

Построение модели стилей CSSOM

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

Как и в HTML, браузер должен преобразовать полученные правила CSS во что-то, с чем он может работать. Таким образом, весь этот процесс — это повторение формирования DOM, только для CSS.

CSSOM дерево включает в себя стили пользовательского агента — это стили, которые браузер вставляет по умолчанию. Браузер начинает построение модели с наиболее общих правил для каждого узла, постепенно применяя более специфичные правила. Другими словами, он применяет правила каскадно. Отсюда и название CSS — Cascading Style Sheets.

Построение CSSOM происходит очень быстро и не отображается отдельным цветом в средствах разработчика. Оно настолько быстрое, что чаще всего включается в показатель «Повторное вычисление стилей (Recalculate Styles)» в средствах разработчика. Этот показатель показывает общее время обработки стилей — обработку CSS, построение CSSOM и рекурсивное вычисление стилей. С точки зрения оптимизации производительности здесь нечего делать, так как построение CSSOM, в целом, занимает даже меньше времени, чем DNS запрос.

Остальные процессы

Компиляция JavaScript

Как CSS обработан и CSSOM создан, другие ресурсы, например, JavaScript-файлы, продолжают загружаться (спасибо сканеру предзагрузки). JavaScript по окончании загрузки должен быть интерпретирован, скомпилирован, обработан и исполнен. Скрипты преобразовываются в абстрактное синтаксическое дерево (AST). Некоторые браузеры берут Abstract Syntax Tree и передают его в интерпретатор, который преобразует дерево в байт-код. Байт-код исполняется в основном потоке. Весь этот процесс называется компиляцией.

Построение дерева доступности

Браузер также строит дерево доступности, которое используется устройствами-помощниками для понимания и интерпретирования контента. Объектная модель доступности (accessibility object model, AOM) — это семантическая версия DOM. Браузер обновляет AOM в тот же момент, когда обновляется DOM. В то же время, дерево доступности не может быть изменено вспомогательными технологиями.

Пока модель AOM не построена, содержимое страницы недоступно для голосовых помощников и считывателей экрана (en-US) .

Рендеринг

Этапы рендеринга включают в себя стилизацию, компоновку (layout), отрисовку (paint) и, в некоторых случаях, композицию (composition). CSSOM и DOM деревья, созданные на предыдущем этапе комбинируются в дерево рендера, которое затем используется для расчёта положения каждого видимого элемента. После этого элементы будут отрисованы на экране. В некоторых случаях содержимое может быть вынесено на отдельные слои и совмещено (composition) — такой подход увеличивает производительность, позволяя отрисовывать содержимое экрана на графическом процессоре вместо ЦПУ. Это освобождает основной поток.

Стилизация

Третий шаг в критическом пути рендеринга — это комбинирование DOM и CSSOM в дерево рендеринга. Конструирование этого дерева начинается с прохода всего DOM-дерева от корня, с выявлением каждого видимого узла.

Элементы, которые не должны быть показаны, например, , а так же их дети или любые элементы с display:none , такие как script < display: none; >, не будут включены в дерево рендера, так как они не должны быть отрисованы. Узлы с правилом visibility: hidden включены в дерево рендера, так как они всё равно занимают своё место. Так как мы не указали никаких специальных правил для перезаписи стилей агента по умолчанию, узел script в примере выше также не будет включён в дерево рендера.

Каждый видимый узел имеет свои правила из CSSOM. Дерево рендера содержит все видимые узлы с их содержимым и вычисленными стилями. Стили определяются путём применения всех подходящих правил с использованием CSS каскада.

Компоновка (Layout)

Четвёртый шаг на критическом пути рендеринга — это запуск компоновки (layout) элементов дерева рендера. На этом шаге вычисляется геометрия каждого узла, то есть ширина, высота, положение элементов. Reflow (перекомпоновка) — это любой последующий процесс определения размеров и позиции для любой из частей целого документа.

Как только дерево рендера построено — начинается layout. Дерево несёт в себе информацию о том, какие узлы должны быть отрисованы (даже если они невидимы), и какие стили должны быть применены, но в дереве нет никакой информации о размерах и позиции элементов. Чтобы определить эти значения, браузер начинает обход дерева.

На веб-странице практически все элементы прямоугольны (box). Разные устройства и настройки подразумевают бесчисленное количество разных размеров видимой области. На начальной фазе браузер, учитывая размер видимой области, определяет какие размеры разных элементов должны быть на экране. Использует размер видимой области как базис, процесс начинает вычисление с элемента body , затем переходит к его потомкам, вычисляет размеры каждого элемента и резервирует место для тех элементов, размеры которых он ещё не знает (например, изображения).

Момент, когда позиция и размеры узлов вычислены, называется layout. Последующие вычисления позиций и размеров называются reflow. В нашем примере предполагаемый начальный layout происходит перед тем, как изображение получено. Так как мы не задавали размер изображения, в момент получения изображения произойдёт reflow.

Отрисовка (Paint)

Последний шаг критического пути рендеринга — это отрисовка каждого отдельного узла на экране. Момент, когда это происходит впервые, называется first meaningful paint (первая значащая отрисовка). Во время фазы отрисовки или растеризации, браузер конвертирует каждый контейнер box в настоящие пиксели на экране (напомним, что данные контейнеров формируются на этапе layout). Отрисовка подразумевает рисование каждой визуальной частицы элемента на экране (текст, цвета, границы, тени) и рисование заменяемых элементов (картинки, кнопки). Браузер должен выполнять это быстро.

Чтобы обеспечить плавную прокрутку и анимацию, отрисовка каждого элемента занимает весь основной поток. Сюда включается вычисление стилей, повторное вычисление стилей и отрисовка. Все эти этапы должны выполняться не дольше 16.67 мс. (1000мс. / 60 кадров в секунду). При разрешении 2048х1536 экран iPad содержит 3.145.000 пикселей, которые должны быть отрисованы. Это много! Для того, чтобы сделать инициирующую и повторную отрисовки быстрее, можно разбить весь процесс на несколько слоёв. Когда это случается — становится необходима композиция.

Отрисовка может разбить элементы в дереве рендера на слои. Для того, чтобы ускорить их рендер, браузер может перенести отрисовку разных слоёв на GPU (вместо основного потока CPU). Для переноса вычислений отрисовки на GPU вы можете использовать некоторые специальные HTML теги, например и ; а также CSS-свойства opacity , transform и will-change . Узлы, созданные таким образом, будут отрисованы на их собственном слое, вместе с их потомками, если только потомки сами по себе не будут вынесены в отдельные слои.

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

Композиция (Compositing)

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

При догрузке ранее запрошенных ресурсов (например, изображений) может потребоваться перерассчитать размеры и положение элементов относительно друг друга. Этот перерасчёт — reflow — запускает перерисовку (repaint) и перекомпозицию (re-composite). Если мы заранее определили размер изображения, перерасчёт не будет необходим и в этом случае только тот слой, который должен быть перерисован — будет перерисован. Но если мы не определили размер изображения заранее, то браузер, после получения ответа от сервера, будет вынужден отмотать процесс рендеринга обратно к шагу компоновки (layout) и начать процесс отрисовки ещё раз.

Интерактивность

Можно было бы подумать, что как только основной поток завершает отрисовку страницы — «всё готово». Это не всегда так. Если среди загружаемых ресурсов есть JavaScript, загрузка которого была корректно отложена, а запуск которого происходит только после события onload , основной поток начинает обработку скриптов. Во время этой обработки браузер не может обрабатывать события прокрутки, нажатий и др.

Time to Interactive (TTI, время до интерактивности) — это показатель того, как много времени проходит между самым первым сетевым запросом и моментом, когда страница становится интерактивной. В хронологии этот этап следует сразу за First Contentful Paint. Интерактивностью называется показатель того, что страница отреагировала на действие пользователя за время в 50мс. Если процессор занят обработкой, компиляцией и выполнением JavaScript, то браузер не может отреагировать достаточно быстро, а значит страница считается не интерактивной.

В нашем примере, даже несмотря на то, что изображение загрузилось быстро, скрипт anotherscript.js , размер которого достигает 2МБ, загружается долго. В этом случае пользователь увидит страницу очень быстро, но не будет способен взаимодействовать с ней, пока скрипт не будет загружен, обработан и исполнен. Это плохая практика. Старайтесь избегать полной загрузки процесса.

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

Смотрите также

Found a content problem with this page?

• Edit the page on GitHub.
• Report the content issue.
• View the source on GitHub.

Как работают браузеры. Часть 1: навигация и получение данных

Примечания переводчиков:

1. Статья предназначена для начинающих разработчиков и интересующихся разработкой. Здесь нет глубоких технических деталей.

2. В оригинальной статьей используются два сокращения: SYN и SYNC. Пониманию это особенно не помогает, поэтому, чтобы не запутывать читателя, мы оставили только SYN.

Браузеры — это программное обеспечение, установленное у нас на устройствах и позволяющее получать доступ к Интернету. Одним из них вы пользуетесь, когда читаете этот текст. Браузеров много, и по состоянию на 2021 год наиболее часто применяются следующие: Google Chrome, Safari, Microsoft Edge и Firefox.

Но как они работают, и что происходит от момента ввода адреса до тех пор, пока нужная страница не отобразится на экране?

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

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

НАВИГАЦИЯ

Навигация — первый шаг к загрузке страницы. Это процесс, когда пользователь запрашивает страницу: нажимает на ссылку, пишет адрес в адресной строке браузера, отправляет форму и т. д.

Поиск DNS (разрешение адреса)

Первый шаг при переходе на страницу – поиск того, где находятся ресурсы этой страницы (HTML, CSS, JavaScript и другие типы файлов). Если перейти на https://example.com, то HTML-страница расположена на сервере с IP-адресом 93.184.216.34. Для нас сайты — это имена доменов, а для компьютеров — IP-адреса. Если мы не посещали этот сайт раньше, происходит поиск системы доменных имен (DNS).

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

Поэтому, когда мы запрашиваем поиск DNS, на самом деле мы взаимодействуем с одним из этих серверов и просим выяснить, какой IP-адрес соответствует имени https://example.com. Если найден соответствующий IP-адрес, он предоставляется. Если поиск почему-то не удался, в браузере появляется сообщение об ошибке.

После этого первоначального поиска IP-адрес, вероятно, на некоторое время будет сохранён в кэше. Поэтому следующие посещения того же сайта будут происходить быстрее, так как не нужно искать DNS. Помните, поиск DNS происходит только при первом посещении сайта.

Подтверждение TCP (протокол управления передачей)

Как только браузер узнает IP-адрес сайта, он попытается установить соединение с сервером, на котором хранятся ресурсы, с помощью трехэтапного подтверждения TCP (также называемого SYN — SYN — ACK , или, точнее, SYN , SYN — ACK , ACK , потому что согласно TCP передаются три сообщения для согласования и начала сеанса TCP между двумя компьютерами).

TCP означает «протокол управления передачей», стандарт связи, который позволяет прикладным программам и вычислительным устройствам обмениваться сообщениями по сети. Он предназначен для отправки пакетов данных через Интернет и обеспечения успешной доставки данных и сообщений по сети.

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

Таким образом, если представить, что браузер и сервер – два человека, разговор между ними будет выглядеть примерно так:

Браузер отправляет серверу сообщение SYN и запрашивает синхронизацию (синхронизация означает подключение).

Затем сервер отвечает сообщением SYN — ACK (синхронизация и подтверждение):

На последнем этапе браузер отвечает сообщением ACK .

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

Переговоры в TLS

Для безопасных соединений, установленных по протоколу HTTPS, требуется еще одно подтверждение.

Это подтверждение (переговоры в TLS) определяет, какой шифр будет использоваться для шифрования связи, проверяет сервер и подтверждает, что безопасное соединение установлено до начала фактической передачи данных.

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

На этом шаге происходит обмен сообщениями между браузером и сервером.

1. Клиент приветствует. Браузер отправляет серверу сообщение, в котором указывается, какую версию TLS и набор шифров он поддерживает, а также строка случайных байтов, известная как случайное число клиента.
2. Приветственное сообщение сервера и сертификат. Сервер отправляет обратно сообщение, содержащее сертификат SSL сервера, выбранный сервером набор шифров и случайное число сервера – строку случайных байтов, которую генерирует сервер.
3. Аутентификация. Браузер проверяет сертификат SSL сервера в центре сертификации, который его выдал. Таким образом, браузер убеждается, что сервер тот, за кого себя выдает.
4. Предварительный секретный ключ. Браузер отправляет еще одну строку случайных байтов – предварительный секретный ключ, зашифрованный открытым ключом, который браузер взял из сертификата SSL с сервера. Сервер может расшифровать предварительный секретный ключ только с помощью закрытого ключа.
5. Используется закрытый ключ. Сервер расшифровывает предварительный секретный ключ.
6. Ключи сеанса созданы. Браузер и сервер генерируют ключи сеанса из случайного числа клиента, случайного числа сервера и секретного ключа.
7. Клиент завершает работу. Браузер отправляет на сервер сообщение о том, что он завершил работу.
8. Сервер завершает работу. Сервер отправляет браузеру сообщение о том, что он также завершил работу.
9. Достигнуто надежное симметричное шифрование. Подтверждение завершено, и связь можно продолжать с помощью ключей сеанса.

Теперь можно запрашивать и получать данные с сервера.

ПОЛУЧЕНИЕ ДАННЫХ

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

HTTP Request (запрос)

После установления безопасного соединения с сервером браузер отправит первоначальный HTTP-запрос методом GET. Сначала браузер запросит HTML-документ с разметкой страницы. Для этого используется протокол HTTP.

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

Метод – например: POST (отправить), GET (получить), DELETE (удалить) и т. д.

URI – это унифицированный (единообразный) идентификатор ресурса. URI используется для идентификации абстрактных или физических ресурсов в Интернете, например сайтов или адресов электронной почты. У URI насчитывается до 5 частей:

• Схема: используется для обозначения используемого протокола.
• Иерархическая часть: используется для идентификации домена.
• Путь: используется для отображения точного пути к ресурсу.
• Запрос: используется для представления запроса.
• Фрагмент: используется для ссылки на часть ресурса.

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

HTTP Response (ответ)

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

Код состояния – например: 200, 400, 401, 504 Gateway Timeout (Время ожидания шлюза сервера истекло) и т. д. Мы стремимся к коду состояния 200, так как он означает, что всё прошло хорошо, и запрос выполнен успешно.

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

Пример HTML-документа выглядит примерно так:

Если посмотреть на HTML-документ, видно, что он ссылается на различные файлы CSS и JavaScript. Запроса на данные файлы не будет до тех пор, пока браузер не столкнется с этими ссылками, но это произойдёт не на данном этапе, а во время парсинга — синтаксического анализа, о котором пойдёт речь в следующей статье. На данный момент запрашивается и принимается от сервера только HTML.

В ответе на такой первоначальный запрос содержится первый байт полученных данных. Время до получения первого байта (TTFB, Time to First Byte) – время между моментом, когда пользователь сделал запрос (введя имя сайта в адресную строку), и моментом получения первого пакета HTML (обычно 14 кб).

Алгоритмы медленного запуска и предотвращения перегрузки TCP

Медленный старт TCP – это алгоритм, который уравновешивает скорость сетевого соединения. Первый пакет данных составляет 14 кб (или меньше), и его роль заключается в том, что объем передаваемых данных постепенно увеличивается, пока не достигнет заранее определённого порога.

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

Ещё одна статья про frontend для начинающих:

• Как сделать свой текстовый редактор на React.js
• Как работают браузеры: навигация и получение данных, парсинг и выполнение JS, деревья спец возможностей и рендеринга

Другие статьи про frontend для продвинутых:

• Как мы выбирали архитектуру микрофронтендов в ЛК для 260 000 сотрудников Пятёрочки
• Как мы сетапили монорепозиторий с SSR и SPA для Otus.ru
• Как собрать свою библиотеку для SSR на React