Що відбувається за 100 мілісекунд після натискання Enter у браузері

Уявіть: ви вводите URL у адресний рядок і натискаєте Enter. Проходить лише 100 мілісекунд — менше часу, ніж потрібно для моргання — а сайт вже починає з'являтися. Ці 100 мс є критичними для успіху будь-якого веб-досвіду. Спойлер: за цей час відбувається складний танець між браузером, сервером і мережею, який визначає, чи буде ваш сайт швидким чи повільним.

📋 Зміст статті:

• 🎯 Обробка введення користувача
• 🔗 Розпізнавання URL
• 🌐 DNS-резолвінг
• 🤝 Встановлення з'єднання (TCP + TLS)
• 📤 Відправка HTTP-запиту
• 🖥️ Обробка запиту сервером
• 📥 Формування HTTP-відповіді
• ⚙️ Завантаження й парсинг ресурсу
• 🎨 Візуалізація та перший рендер
• 👆 Реакція на взаємодії користувача
• ❓ Часті питання (FAQ)
• ✅ Висновки

⸻

🎯 Обробка введення користувача

Все починається з простого натискання клавіші, але за цим стоять складні процеси браузера.

📝 Подія keydown та перевірка фокусу

Коли ви натискаєте клавішу Enter у адресному рядку, відбувається низка подій:

• ✅ keydown → keypress → keyup: стандартна послідовність подій клавіатури
• ✅ Перевірка фокусу: браузер переконується, що фокус дійсно в адресному рядку
• ✅ Валідація введення: перевірка, чи не є введений текст потенційно небезпечним

👉 Приклад: Якщо ви вводите "example.com", браузер спочатку перевіряє, чи це дійсно URL, а не команда для пошуку.

⚡ Важливо: Браузерний процес (Browser Process) негайно отримує введений текст і починає аналіз — це перший крок до завантаження сторінки.

✅ Швидкий висновок: Натискання Enter запускає низку подій, які передають введений текст до браузерного процесу для подальшої обробки.

⸻

🔗 Розпізнавання URL

Браузер повинен зрозуміти, що саме ви хочете — перейти на сайт чи виконати пошук.

🔍 Парсинг схеми URL

Браузер аналізує введений текст, щоб визначити тип запиту:

• ✅ https://, http://: звичайні веб-адреси
• ✅ file://: локальні файли
• ✅ about:config, chrome://: внутрішні сторінки браузера
• ✅ Відсутня схема: браузер автоматично додає "https://"

🎯 Визначення типу запиту

Браузер вирішує, чи це:

✅ Швидкий висновок: Браузер аналізує введений текст, визначає тип запиту і активує відповідний обробник навігації.

⸻

🌐 DNS-резолвінг

Перш ніж з'єднатися з сервером, браузер повинен знайти його IP-адресу — це як пошук адреси будинку за його назвою.

🔍 Багаторівневий пошук DNS

Браузер шукає IP-адресу в чотирьох місцях по черзі:

• ✅ Кеш браузера: локальне сховище останніх запитів
• ✅ Кеш ОС: системний кеш DNS запитів
• ✅ DNS сервер провайдера: зовнішній DNS-резолвер
• ✅ DoH (DNS over HTTPS): зашифрований DNS для підвищення конфіденційності

👉 Приклад: При запиті "google.com" браузер спочатку перевіряє свій кеш, потім кеш Windows/Mac, і лише потім звертається до зовнішніх серверів.

⏱️ Час резолвінгу

✅ Швидкий висновок: DNS-резолвінг — це пошук IP-адреси за доменним ім'ям, який може займати від 0 до 300 мс залежно від кешування.

⸻

🤝 Встановлення з'єднання (TCP + TLS)

Тепер, коли браузер знає IP-адресу, він повинен встановити безпечне з'єднання — це як підійти до дверей і постукати.

🔄 TCP Handshake

Триетапний процес встановлення з'єднання:

• ✅ SYN: Клієнт відправляє пакет "Давай поговоримо?"
• ✅ SYN-ACK: Сервер відповідає "Так, давай!"
• ✅ ACK: Клієнт підтверджує "Добре, починаємо!"

👉 Приклад: Це як телефонний дзвінок: ви дзвоните (SYN), вам відповідають (SYN-ACK), ви говорите "Привіт" (ACK).

🔒 TLS Handshake (для HTTPS)

Для безпечного з'єднання додається ще кілька кроків:

• ✅ Client Hello: Браузер представляється і показує підтримувані шифри
• ✅ Server Hello: Сервер відповідає і надсилає сертифікат
• ✅ Перевірка сертифіката: Браузер перевіряє чи сертифікат дійсний
• ✅ Ключі шифрування: Сторони обмінюються ключами для симетричного шифрування

⚡ Важливо: TLS 1.3 значно прискорює цей процес, зменшуючи кількість кругових шляхів з 2 до 1.

🚀 HTTP/2 та HTTP/3

✅ Швидкий висновок: Встановлення TCP+TLS з'єднання зазвичай займає 200-500 мс, але нові технології як HTTP/3 значно прискорюють цей процес.

⸻

📤 Відправка HTTP-запиту

З'єднання встановлено — тепер браузер може попросити конкретну сторінку.

📝 Формування запиту

Браузер створює HTTP-запит з такими компонентами:

• ✅ Метод: GET, POST, HEAD, PUT, DELETE
• ✅ Заголовки: інформація про браузер, підтримувані формати, куки
• ✅ Тіло: для POST-запитів — дані форми

👉 Приклад GET-запиту:

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0...
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate, br
Cookie: session=abc123...

🎯 Критичні заголовки

✅ Швидкий висновок: Браузер формує детальний HTTP-запит з метою, заголовками та можливим тілом, який передається через встановлене з'єднання.

⸻

🖥️ Обробка запиту сервером

Запит дійшов до сервера — тепер він має зрозуміти, що саме потрібно повернути.

🔧 Веб-сервер (Nginx, Apache)

Веб-сервер отримує запит і визначає як його обробити:

• ✅ Віртуальні хости: визначення сайту за доменом
• ✅ Статичний контент: безпосередня віддача файлів
• ✅ Динамичний контент: передача запиту до бекенду

🚀 Бекенд-обробка

Для динамічних сторінок сервер виконує:

• ✅ Маршрутизація: визначення відповідного обробника
• ✅ База даних: запити для отримання даних
• ✅ Шаблонізація: генерація HTML з даних
• ✅ Кешування: використання готових відповідей

👉 Приклад: Запит до "/products/123" може викликати контролер продуктів, який звертається до бази даних, отримує інформацію про продукт і генерує HTML.

⏱️ Час обробки сервером

✅ Швидкий висновок: Сервер обробляє запит, визначаючи маршрут, отримуючи дані з бази даних та генеруючи відповідь, що займає від 1 до 500 мс.

⸻

📥 Формування HTTP-відповіді

Сервер підготував відповідь — тепер він має правильно її упакувати і відправити назад.

📊 Статус-коди та заголовки

Сервер починає відповідь зі статусу та заголовків:

• ✅ 200 OK: успішне виконання
• ✅ 301/302 Redirect: перенаправлення
• ✅ 404 Not Found: ресурс не знайдено
• ✅ 500 Server Error: помилка сервера

👉 Приклад успішної відповіді:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 15243
Cache-Control: public, max-age=3600
Last-Modified: Mon, 15 Jan 2024 10:30:00 GMT
<!DOCTYPE html>
<html>...</html>

🔧 Критичні заголовки для продуктивності

✅ Швидкий висновок: Сервер формує HTTP-відповідь зі статус-кодом, заголовками та тілом, яка потім передається назад до браузера.

⸻

⚙️ Завантаження й парсинг ресурсу

Браузер отримав HTML — тепер він має перетворити цей текст на повноцінну веб-сторінку.

🔍 Побудова DOM

Браузер аналізує HTML і будує Document Object Model:

• ✅ Токенізація: розбиття HTML на токени
• ✅ Побудова дерева: створення ієрархії елементів
• ✅ Стрімінговий парсинг: обробка HTML по мірі надходження

🎨 Побудова CSSOM

Одночасно з DOM браузер будує CSS Object Model:

• ✅ Парсинг CSS: аналіз стилів
• ✅ Каскадування: визначення фінальних стилів
• ✅ Специфічність: розрахунок ваги селекторів

⚡ Блокування JavaScript

JavaScript може блокувати парсинг HTML:

👉 Приклад: Якщо браузер зустрічає <script src="app.js"> без async/defer, він зупиняє парсинг HTML, завантажує і виконує скрипт, і лише потім продовжує.

✅ Швидкий висновок: Браузер парсить HTML і CSS, будує DOM і CSSOM, при цьому JavaScript може блокувати цей процес, якщо не використані async/defer.

⸻

🎨 Візуалізація та перший рендер

Дерева DOM і CSSOM готові — тепер браузер може відобразити сторінку на екрані.

🔨 Побудова Render Tree

Браузер поєднує DOM і CSSOM у Render Tree:

• ✅ Фільтрація: виключення прихованих елементів (display: none)
• ✅ Відповідність: поєднання елементів DOM з правилами CSS
• ✅ Обчислення стилів: визначення фінальних значень CSS властивостей

📐 Layout (Reflow)

Браузер розраховує позиції та розміри елементів:

• ✅ Геометрія: розрахунок ширини, висоти, позиції
• ✅ Вікно перегляду: врахування розмірів екрану
• ✅ Каскадні зміни: зміна одного елемента може викликати перерахунок інших

🎨 Paint та Composite

Фінальні етапи візуалізації:

📊 Метрики першого рендеру

• ✅ First Paint (FP): перше відображення будь-якого контенту
• ✅ First Contentful Paint (FCP): перше відображення корисного контенту
• ✅ Largest Contentful Paint (LCP): відображення найбільшого елементу

✅ Швидкий висновок: Браузер будує Render Tree, розраховує layout, малює елементи і композує фінальне зображення, досягаючи першого візуального відображення сторінки.

⸻

👆 Реакція на взаємодії користувача

Сторінка завантажилась — але чи буде вона реагувати миттєво на дії користувача?

⚡ First Input Delay (FID)

Метрика, що вимірює час від першої взаємодії до реакції браузера:

• ✅ Цільове значення: ≤ 100 мс
• ✅ Прийнятне значення: ≤ 300 мс
• ✅ Погане значення: > 300 мс

👉 Приклад: Користувач клікає на кнопку, але браузер не може негайно обробити клік, тому що головний потік зайнятий виконанням JavaScript.

🔧 Оптимізація головного потоку

Стратегії для покращення FID:

🚫 Поширені проблеми

• ❌ Довгі задачі JavaScript: виконання коду понад 50 мс
• ❌ Великі зображення: декодування займає час
• ❌ Складні CSS-анімації: можуть блокувати головний потік

✅ Швидкий висновок: Для забезпечення миттєвої реакції на взаємодії необхідно оптимізувати JavaScript, використовувати Web Workers і уникати блокування головного потоку довгими задачами.

⸻

❓ Часті питання (FAQ)

🔍 Чому саме 100 мс вважається критичним порогом?

Дослідження UX показують, що затримки менше 100 мс сприймаються як миттєві, тоді як більші затримки вже помітні для користувача. Це пов'язано з тим, як мозок обробляє зорову інформацію та очікує зворотного зв'язку.

🔍 Чи можна досягти завантаження сторінки за 100 мс?

Так, це можливо для добре оптимізованих сайтів з використанням сучасних технологій: серверного рендерингу, CDN, HTTP/2 або HTTP/3, ефективного кешування та мінімалістичного дизайну. Однак для складних веб-додатків типові часи завантаження становлять 1-3 секунди.

🔍 Які інструменти допоможуть виміряти час завантаження?

Найефективніші інструменти: Chrome DevTools (Performance та Network панелі), Lighthouse, WebPageTest, GTmetrix. Вони дозволяють аналізувати кожен етап завантаження сторінки та виявляти "вузькі місця".

🔍 Чи впливає тип браузера на швидкість завантаження?

Так, різні браузери мають різну продуктивність через відмінності в рушіях (Blink у Chrome, Gecko у Firefox, WebKit у Safari). Однак ці відмінності зазвичай не є критичними — набагато важливіша оптимізація самого сайту.

🔍 Як мобільні пристрої впливають на час завантаження?

Мобільні пристрої зазвичай мають меншу потужність CPU та більш повільні мережі, що може збільшити час завантаження в 2-5 разів порівняно з десктопом. Тому оптимізація для мобільних пристроїв є критично важливою.

⸻

✅ Висновки

Підведемо підсумки нашого подорожі від натискання Enter до повноцінної веб-сторінки:

• 🎯 Кожен мілісекунд має значення: Оптимізація на кожному з 10+ етапів завантаження може суттєво покращити користувацький досвід
• 🎯 100 мс — це психологічний поріг: Затримки менше 100 мс сприймаються як миттєві, що критично для утримання уваги користувача
• 🎯 Продуктивність — це система: Не існує єдиного "серебряної кулі" — потрібна комплексна оптимізація всіх компонентів
• 💡 Рекомендація: Регулярно вимірюйте та аналізуйте продуктивність вашого сайту за допомогою Lighthouse та реальних користувацьких метрик

💯 Підсумок: Швидкість завантаження веб-сторінки — це не випадковість, а результат ретельного проектування та оптимізації кожного етапу, від DNS-запиту до останнього байта JavaScript. Робота над скороченням кожного мілісекунди окупається покращеним користувацьким досвідом, вищими конверсіями та кращими позиціями в пошукових системах.

Цю статтю підготував засновник і лідер компанії з 8-річним досвідом у веброзробці — Вадім Харов'юк.