Если человек хочет быть механиком или хотя бы диагностом автомобилей, странно, если он не понимает, как работает двигатель. То же самое с тестировщиком и браузером: чтобы отличать баг вёрстки от бага логики и понимать, почему страница тормозит, полезно знать, что происходит между запросом к серверу и картинкой на экране. Это один из самых частых вопросов на технических собеседованиях — и большинство кандидатов на него не могут ответить системно. Разберём весь путь по шагам.
Что происходит после того как браузер получил HTML
Клиент-серверная архитектура работает так: браузер (клиент) отправляет запрос, сервер отвечает. Первым делом браузер получает главный файл — HTML — и находит в нём ссылки на остальные ресурсы: CSS, JavaScript, картинки, шрифты, иконки. На каждый ресурс уходит отдельный запрос, и если ресурсы не блокирующие, эти запросы и последующий парсинг идут параллельно, ускоряя загрузку.
С этого момента браузер проходит несколько последовательных этапов, чтобы превратить текстовый файл в готовую к отображению страницу.
С этого момента браузер проходит несколько последовательных этапов, чтобы превратить текстовый файл в готовую к отображению страницу.
DOM и CSSOM — два дерева, из которых строится страница
Первый этап — парсинг HTML. Напрямую работать с текстовым HTML-документом браузеру неудобно, поэтому он строит DOM (Document Object Model) — абстрактное древовидное представление документа. Корень дерева — тег <html>, от него отходят <head> и <body>, а дальше структура повторяет вложенность тегов в исходном коде. Любое изменение страницы — через JavaScript или через DevTools — сначала меняет DOM, и только потом отображение на экране.
Параллельно браузер парсит CSS и строит CSSOM — аналогичное дерево, но с привязанными стилями для каждого элемента. Важная особенность CSSOM: CSS нельзя применять по частям. Из-за каскадной природы стилей (когда более поздние правила могут переопределять более ранние) браузер обязан дочитать все стили до конца, прежде чем понять итоговый набор свойств для каждого элемента.
Где-то между этими этапами браузер встречает и выполняет JavaScript — но об этом отдельно, потому что именно здесь чаще всего теряется скорость.
Параллельно браузер парсит CSS и строит CSSOM — аналогичное дерево, но с привязанными стилями для каждого элемента. Важная особенность CSSOM: CSS нельзя применять по частям. Из-за каскадной природы стилей (когда более поздние правила могут переопределять более ранние) браузер обязан дочитать все стили до конца, прежде чем понять итоговый набор свойств для каждого элемента.
Где-то между этими этапами браузер встречает и выполняет JavaScript — но об этом отдельно, потому что именно здесь чаще всего теряется скорость.
Почему JavaScript тормозит рендеринг
JavaScript выполняется браузером в том порядке, в котором встречается в HTML, и у этого есть критичное следствие: JS — блокирующий ресурс. Как только браузер встречает тег <script>, он останавливает парсинг HTML, выполняет скрипт, и только потом возвращается к разбору документа дальше.
Именно поэтому классическая практика — размещать скрипты в конце <body>: тогда весь видимый контент уже успевает отрисоваться, и пользователь видит готовую страницу, пока в фоне ещё грузится и выполняется JavaScript. Обойти блокировку можно и явно — атрибутом async (скрипт загружается параллельно и выполняется сразу после загрузки) или defer (загружается параллельно, но выполняется только после полного парсинга HTML).
Для тестировщика это прямая связь между техническим устройством страницы и наблюдаемым поведением: если сайт долго показывает пустой экран или элементы «прыгают» при загрузке — это повод посмотреть, где именно в разметке расположены скрипты.
Именно поэтому классическая практика — размещать скрипты в конце <body>: тогда весь видимый контент уже успевает отрисоваться, и пользователь видит готовую страницу, пока в фоне ещё грузится и выполняется JavaScript. Обойти блокировку можно и явно — атрибутом async (скрипт загружается параллельно и выполняется сразу после загрузки) или defer (загружается параллельно, но выполняется только после полного парсинга HTML).
Для тестировщика это прямая связь между техническим устройством страницы и наблюдаемым поведением: если сайт долго показывает пустой экран или элементы «прыгают» при загрузке — это повод посмотреть, где именно в разметке расположены скрипты.
Render Tree, Layout и Paint — от дерева к пикселям
Когда DOM и CSSOM готовы, браузер сливает их в единое дерево — Render Tree, чтобы понять, что именно и где будет отрисовано. На этом этапе из финального дерева исключаются все элементы со стилем display: none и служебные теги вроде <head>, <script>, <meta> — остаётся только то, что реально появится на экране.
Дальше следует Layout (генерация раскладки) — браузер рассчитывает точные позиции и размеры каждого элемента. Ключевую роль на этом этапе играет метатег viewport:
<meta name="viewport" content="width=device-width, initial-scale=1.0">
Без него адаптивная вёрстка попросту не работает: по умолчанию браузер считает ширину экрана равной 980px, тогда как у большинства мобильных устройств она составляет 320-425px. Итог такого пропуска — страница, которая выглядит корректно на десктопе, но превращается в нечитаемую мешанину на телефоне.
Последний этап — Paint, физическая отрисовка: именно здесь рисуются текст, картинки, тени, рамки, скругления и градиенты. Это самый дорогостоящий этап по вычислительным затратам, и любые перерисовки — при анимациях, скролле или манипуляциях через JavaScript — расходуют ресурсы устройства заново. На слабых компьютерах и телефонах это проявляется как подтормаживающая анимация.
Если собрать всю цепочку в один ответ для собеседования, звучит она так: браузер получает HTML, парсит его в DOM, параллельно подтягивает остальные ресурсы, парсит CSS в CSSOM, выполняет блокирующий JavaScript, сливает DOM и CSSOM в Render Tree, рассчитывает Layout и в конце выполняет Paint.
Дальше следует Layout (генерация раскладки) — браузер рассчитывает точные позиции и размеры каждого элемента. Ключевую роль на этом этапе играет метатег viewport:
<meta name="viewport" content="width=device-width, initial-scale=1.0">
Без него адаптивная вёрстка попросту не работает: по умолчанию браузер считает ширину экрана равной 980px, тогда как у большинства мобильных устройств она составляет 320-425px. Итог такого пропуска — страница, которая выглядит корректно на десктопе, но превращается в нечитаемую мешанину на телефоне.
Последний этап — Paint, физическая отрисовка: именно здесь рисуются текст, картинки, тени, рамки, скругления и градиенты. Это самый дорогостоящий этап по вычислительным затратам, и любые перерисовки — при анимациях, скролле или манипуляциях через JavaScript — расходуют ресурсы устройства заново. На слабых компьютерах и телефонах это проявляется как подтормаживающая анимация.
Если собрать всю цепочку в один ответ для собеседования, звучит она так: браузер получает HTML, парсит его в DOM, параллельно подтягивает остальные ресурсы, парсит CSS в CSSOM, выполняет блокирующий JavaScript, сливает DOM и CSSOM в Render Tree, рассчитывает Layout и в конце выполняет Paint.
Зачем тестировщику знать про рендеринг
Знание этой цепочки работает как рабочий инструмент в повседневных задачах тестировщика. Понимание каскадной природы CSS (стили применяются только целиком) объясняет, почему один неправильный селектор может визуально сломать элемент в другом конце страницы. Понимание блокирующей природы JavaScript помогает быстро локализовать причину долгой загрузки — достаточно посмотреть, где в разметке расположены скрипты и есть ли у них async или defer. А знание про Paint как самый дорогой этап подсказывает, откуда берутся тормозящие анимации и почему их стоит проверять отдельно от статичной вёрстки.
На собеседовании этот вопрос задают именно чтобы отличить тестировщика, который умеет только кликать по кнопкам, от того, кто понимает продукт на уровне устройства технологии. Разбор рендеринга — только первый шаг: следующий логичный вопрос — как всё это исследовать в DevTools, от Elements до Network и Lighthouse.
Понимание рендеринга и уверенная работа с DevTools — часть базового набора инструментов, который школа даёт на курсе «Инженер по ручному тестированию»: с разбором на конкретных сайтах и реальными примерами того, как это выглядит на практике.
-------
На собеседовании этот вопрос задают именно чтобы отличить тестировщика, который умеет только кликать по кнопкам, от того, кто понимает продукт на уровне устройства технологии. Разбор рендеринга — только первый шаг: следующий логичный вопрос — как всё это исследовать в DevTools, от Elements до Network и Lighthouse.
Понимание рендеринга и уверенная работа с DevTools — часть базового набора инструментов, который школа даёт на курсе «Инженер по ручному тестированию»: с разбором на конкретных сайтах и реальными примерами того, как это выглядит на практике.
-------
Полезные ссылки школы
Сайт Quality Academy:
https://quality-academy.ru/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena
https://quality-academy.ru/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena