Что происходит, когда пользователь вводит URL в браузере

Хороший ответ не обязан быть лекцией по сетям. Вам достаточно показать последовательность и объяснить, почему она важна для frontend-разработчика.

Самый безопасный порядок такой: URL, кэши и DNS, соединение, HTTP, ответ, парсинг HTML, загрузка ресурсов, построение страницы, выполнение JavaScript и дальнейшие запросы приложения.

Если вы начинаете с фразы "браузер отправляет запрос на сервер", добавьте перед этим хотя бы разбор URL и DNS. Иначе пропадает часть, где часто теряется время до первого байта.

Браузер сначала разбирает введенную строку. Если схема не указана, он может попробовать выбрать https или обработать ввод как поисковый запрос. Для нормального URL важны схема, host, порт, путь, query и fragment.

Пример:

https://shop.example.com:443/products?id=10#reviews

https задает протокол. shop.example.com это host. 443 это порт. /products это путь. ?id=10 отправляется на сервер. #reviews остается в браузере и может использоваться для прокрутки или клиентского роутинга.

Практический риск: не передавайте токены, email и одноразовые секреты через URL. Query может попасть в логи сервера, аналитику, историю и referrer. Fragment не уходит на сервер, но виден в адресной строке, истории и клиентском коде. Безопаснее использовать код обмена с коротким сроком жизни, защищенные cookies или серверную сессию, если это подходит вашему сценарию.

После разбора адреса браузеру нужен IP-адрес. Он проверяет кэши браузера, ОС, иногда настройки сети, и только потом идет к DNS-резолверу. Если домен уже был недавно открыт, этот шаг может быть почти незаметным.

Практический вывод: каждый новый origin может добавить задержку. Поэтому набор сторонних доменов для аналитики, шрифтов, виджетов и рекламы влияет не только на размер ресурсов, но и на DNS, соединения и TLS.

Когда IP найден, браузер устанавливает соединение. Для классического HTTPS это TCP, затем TLS. На TLS-этапе проверяется сертификат, домен, срок действия и цепочка доверия. Если проверка не проходит, пользователь может увидеть предупреждение, а запросы из приложения могут падать.

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

Браузер не ждет, пока скачает абсолютно все. Он начинает парсить HTML потоково, строит DOM и по мере встреченных тегов запрашивает дополнительные ресурсы: CSS, JavaScript, картинки, шрифты, favicon и другие файлы.

CSS участвует в построении CSSOM. Затем DOM и CSSOM используются для render tree, после чего идут layout и paint. Если CSS большой или приходит поздно, пользователь дольше ждет видимый контент.

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

Плохой пример:

<script src="/heavy-analytics.js"></script>
<h1>Catalog</h1>

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

При повторном посещении сценарий может быть короче. DNS может быть в кэше, соединение может переиспользоваться, ресурсы могут прийти из HTTP cache, memory cache или Service Worker. При переходе назад браузер может восстановить страницу из back-forward cache почти мгновенно.

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

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

Хорошая короткая формулировка для интервью:

При холодной навигации браузер разбирает URL, находит IP через DNS, устанавливает соединение и для HTTPS делает TLS. Потом отправляет HTTP-запрос, получает HTML и начинает потоково строить страницу: DOM, CSSOM, render tree, layout и paint. CSS и синхронные скрипты могут блокировать отображение, а кэш, Service Worker и повторное соединение могут сильно сократить часть шагов.

Практический вывод: при отладке медленной страницы смотрите не только на React-компоненты. Проверьте redirects, DNS и TLS, размер критичного CSS, синхронные скрипты, кэширование, лишние origins и повторные API-запросы после гидрации.