Як працює браузер: що варто знати кожному frontend-розробнику
Практичний огляд того, що насправді робить браузер між URL і відрендереною сторінкою — парсинг, конвеєр рендерингу та event loop JavaScript — і чому це пояснює більшість поведінки в продуктивності й багах.
Більшість роботи над frontend-продуктивністю й дивовижна частка важкопояснюваних багів зводяться до жменьки механік браузера, яких рідко навчають явно. Не потрібно будувати браузер, щоб писати хороший frontend-код, але знання того, що насправді відбувається між URL і відрендереною сторінкою, перетворює «це чомусь повільно» на конкретну, виправну причину.
Від URL до першого байта
Навігація починається з DNS-резолвінгу, TCP-зʼєднання (часто через TLS) і запиту/відповіді для HTML-документа — кожен крок додає затримку до того, як відрендериться хоч один піксель. Тому DNS-префетчинг, перевикористання зʼєднання й CDN близько до користувача важливі ще до того, як задіяно хоч якийсь frontend-код.
Парсинг: HTML, CSS і DOM/CSSOM
Браузер парсить HTML у DOM інкрементально, але тег `<script>` без `async` чи `defer` повністю блокує цей парсинг, доки скрипт не завантажиться й не виконається — саме це механізм за «блокуючим рендер JavaScript». CSS парситься в CSSOM паралельно, і обидва обʼєднуються в render tree лише коли готові обидва.
Конвеєр рендерингу: style, layout, paint, composite
| Стадія | Що відбувається | Тригериться |
|---|---|---|
| Style | Обчислення, які CSS-правила застосовуються до кожного вузла | Зміни DOM чи класів |
| Layout | Розрахунок розміру й позиції кожного елемента | Зміна розмірів, контенту чи структури DOM |
| Paint | Заповнення пікселів — колір, текст, тіні, зображення | Будь-яка візуальна зміна, навіть без зміни layout |
| Composite | Обʼєднання намальованих шарів у фінальний кадр | Transform, opacity — найдешевша стадія |
Саме тому `transform` і `opacity` анімуються набагато плавніше, ніж анімація `width`, `top` чи `margin` — перші торкаються лише дешевої стадії composite, тоді як другі змушують до повного layout і paint на кожному кадрі — звідси й береться більшість тремтливих анімацій.
Event loop JavaScript і основний потік
JavaScript, layout і paint конкурують за той самий єдиний основний потік — довга JavaScript-задача блокує рендеринг і ввід користувача, що є прямою механічною причиною сторінки, яка «зависає», хоча нічого не крашнулось. Саме тому й існує INP (Interaction to Next Paint) як Core Web Vital: він вимірює точно цю конкуренцію за основний потік.
Чому це пояснює типові баги й проблеми продуктивності
- Layout thrashing — читання властивості layout (як `offsetHeight`) одразу після запису змушує до синхронного, небатчованого перерахунку layout, повторюваного для кожної пари читання/запис.
- Тремтливий скрол чи анімація — зазвичай анімується властивість, що тригерить layout, замість transform/opacity.
- Заморожений UI під час великого обчислення — синхронна задача основного потоку без «уступання», що блокує і paint, і ввід.
- Спалах нестильованого контенту — CSS приходить після того, як браузер уже почав малювати нестильований DOM.
- Cumulative Layout Shift — контент (часто зображення чи реклама), вставлений без зарезервованого місця, змушує до пізнього перерахунку layout, що видимо зсуває все нижче.
Як це знання окупається на практиці
Це ментальна модель за більшістю конкретних порад із нашого гайду про оптимізацію продуктивності вебсайту — розбиття коду, критичний CSS і зарезервований простір для розмітки не довільні правила; це прямі відповіді на цей конвеєр.
Підсумок
Браузер — не чорна скринька, а доволі невелика, засвоювана множина механік (парсинг, конвеєр рендерингу, event loop), і більшість «дивних» frontend-багів і проблем продуктивності зводяться до однієї з них. Розуміння цього перетворює роботу над продуктивністю з здогадок на діагностику.
Поширені запитання
Чому анімація «width» гірша за анімацію «transform»?
Зміна width змушує браузер перерахувати layout для цього елемента й усього, на що він впливає, а потім перемалювати — на кожному окремому кадрі. Transform (і opacity) повністю пропускають layout і paint і торкаються лише стадії composite, що драматично дешевше — саме тому анімації на transform плавні навіть на слабших пристроях.
Що таке layout thrashing і як цього уникнути?
Layout thrashing трапляється, коли код чергує читання властивості layout (як offsetHeight) і запис зміни стилю в циклі, змушуючи браузер синхронно перераховувати layout на кожній ітерації замість батчування. Виправлення — спершу батчувати всі читання, потім усі записи, щоб браузер обчислив layout один раз замість багатьох.
Чи важливо знати внутрішній устрій браузера, якщо я використовую сучасний фреймворк?
Так — фреймворки абстрагують DOM API, але зрештою все одно продукують той самий HTML/CSS/JS, який браузер має спарсити, розкласти й намалювати. Проблеми продуктивності на рівні фреймворку (зайві ре-рендери, великі бандли, що блокують парсинг) — зазвичай ті самі базові механіки браузера в синтаксисі іншого фреймворку.