T1, T2, T3 звучит как официальная классификация, но никакого стандарта за этим нет. Каждая рекламная сеть рисует свою табличку, поэтому Польша у одних T1, у других T2, а Аргентина плавает вообще везде. Настоящие стандарты это ISO 3166-1 (249 кодов, из них 193 страны ООН, остальное территории) и классификация Всемирного банка по доходу.
Отдельная история это выдача. С 2017 года Google определяет регион не по домену, а по вашему местоположению, так что google.co.uk из Москвы покажет российскую выдачу. Помогают параметры gl, hl и uule, но собирать их руками каждый раз неудобно.
Я веду бесплатное расширение Geo Tier Builder: 249 стран с флагами, тиры, регионы, мета-группы, экспорт в Cloudflare WAF, nginx, JSON и CSV. В новой версии добавил вывод выдачи из под любой страны или языка.
Сайт кажется простым: ввёл адрес, нажал Enter — и через мгновение видишь страницу. Но до этого момента браузер успевает проделать целую цепочку работы: найти сервер, установить соединение, получить HTML, загрузить дополнительные файлы и собрать из них изображение на экране.
Обычно мы не замечаем эти этапы. Они становятся заметны, когда сайт начинает тормозить. Задержка может появиться ещё до обращения к серверу — например, во время DNS-резолвинга, — или уже после получения ответа, когда браузер разбирает JavaScript и строит интерфейс.
Я выбрал эту тему, потому что хотел разобраться, что именно происходит между вводом адреса и появлением страницы. Разберём этот путь от адресной строки до первого отрисованного пикселя и посмотрим, на каком этапе может возникнуть задержка.
Прежде чем разбирать каждый этап подробно, полезно увидеть картину целиком.
Разбор URL — браузер понимает, что вы имеете в виду.
DNS-резолвинг — имя сайта превращается в IP-адрес.
Установка соединения — рукопожатия TCP и, для HTTPS, TLS.
HTTP-запрос и ответ — браузер спрашивает, сервер отвечает.
Разбор HTML, CSS и JavaScript — превращение кода в структуру.
Рендеринг — структура превращается в пиксели на экране.
Дозагрузка ресурсов — картинки, шрифты, кеш и CDN.
Дальше — подробно о каждом шаге.
Основные этапы загрузки страницы в браузере
❯ Сначала — вся цепочка загрузки страницы
Когда вы вводите что-то в адресную строку, браузер сначала решает: это адрес сайта или поисковый запрос. Если похоже на адрес — начинается разбор.
Полный URL состоит из нескольких частей.
Протокол (http или https) — по какому «языку» будет вестись общение.
Домен (например, timeweb.cloud) — имя сервера, к которому нужно обратиться.
Порт (обычно скрыт: по умолчанию 80 для http и 443 для https) — «дверь», через которую сервер принимает соединения.
Путь (/blog/article) — какой именно документ или раздел нужен.
Параметры запроса (?id=123) — дополнительные данные для сервера.
Якорь (#section) — часть страницы, к которой нужно прокрутить; сервер его даже не увидит, это забота браузера.
Прежде чем куда-то обращаться, браузер проверяет несколько вещей на месте: не сохранена ли страница в собственном кеше и не входит ли домен в список принудительного HTTPS. Это список сайтов, которые нельзя открывать по незащищенному http, даже если так написано в адресе, — он называется HSTS.
Из каких частей состоит URL
❯ Шаг 2. DNS: превращаем имя сайта в IP-адрес
Компьютеры и маршрутизаторы в интернете работают с числами — IP-адресами вида 192.0.2.1. Люди же запоминают имена: timeweb.cloud куда удобнее, чем набор цифр. Служба, которая связывает одно с другим, называется DNS — Domain Name System, или система доменных имен.
Чтобы найти IP-адрес нужного домена, браузер проходит цепочку проверок, и любая из них может дать готовый ответ и остановить поиск.
Кеш браузера — может, этот адрес уже искали недавно.
Кеш операционной системы — то же самое, но на уровне всей системы.
Файл hosts — локальный список «имя → адрес», который можно отредактировать вручную.
Рекурсивный DNS-резолвер — обычно сервер провайдера или публичный сервис вроде 1.1.1.1 или 8.8.8.8.
Если ни один из уровней не помог, в дело вступает сам резолвер. Он опрашивает корневые серверы (их адреса зашиты в каждый резолвер) и получает ссылку на серверы зоны — например, .cloud или .ru. Затем обращается к ним и получает ссылку уже на авторитетный сервер конкретного домена, который и отдает финальный ответ — IP-адрес. Результат резолвер запоминает на время, указанное в настройках домена (TTL), чтобы не повторять всю цепочку при следующем запросе.
Обычно DNS-запросы летают по протоколу UDP на порт 53 — он быстрее TCP, потому что не требует установки соединения. Часть современных браузеров и резолверов также умеет шифровать DNS-запросы через DNS-over-HTTPS или DNS-over-TLS, чтобы провайдер не видел, какие сайты вы посещаете.
Упрощённая схема поиска IP-адреса через DNS
Проверить, какой IP-адрес сейчас связан с доменом, можно самостоятельно. В терминале Linux и macOS для этого используют:
Команда покажет полученный IP-адрес и сведения об ответе DNS. Время полной загрузки страницы лучше смотреть отдельно — во вкладке Network в инструментах разработчика браузера.
❯ Шаг 3. Устанавливаем соединение: TCP и TLS
IP-адрес найден. Теперь браузеру нужно установить соединение с сервером. Для обычного HTTPS здесь участвуют два протокола: TCP отвечает за транспорт, а TLS — за шифрование.
Сначала — рукопожатие TCP, протокола, который отвечает за надежную доставку данных. Оно состоит из трех сообщений: клиент отправляет SYN («хочу соединиться»), сервер отвечает SYN-ACK («принято, я тоже готов»), клиент подтверждает ACK («отлично, начинаем»). После этого обмена соединение считается установленным.
Если сайт работает по HTTPS — а сегодня это подавляющее большинство сайтов — поверх TCP сразу начинается второе рукопожатие, уже TLS, протокола шифрования. Браузер отправляет Client Hello: какие версии TLS и шифры он поддерживает, и имя сайта, к которому обращается. Это нужно, чтобы сервер с несколькими доменами на одном IP понял, какой сертификат показать. Сервер отвечает Server Hello: выбранный шифр и сертификат, который браузер проверяет на подлинность — совпадает ли имя, не истек ли срок действия, подписан ли он доверенным центром сертификации. Если все сходится, стороны договариваются об общем ключе шифрования, и дальнейшее общение становится зашифрованным.
TLS 1.3 обычно требует меньше сетевых обменов, чем TLS 1.2, поэтому соединение может установиться быстрее. При повторном подключении браузер также способен возобновить ранее созданную сессию. Режим 0-RTT возможен только при определённых условиях и не является обязательной частью каждого соединения.
HTTP/3 работает поверх QUIC — транспорта на основе UDP. В QUIC транспортные механизмы и TLS тесно связаны, поэтому при установлении соединения можно сократить число сетевых обменов. Кроме того, потеря одного пакета не обязательно блокирует передачу независимых потоков, как это может происходить при использовании TCP.
Установка TCP-соединения и TLS-рукопожатие
❯ Шаг 4. Отправляем HTTP-запрос и получаем ответ
Соединение готово — можно отправлять сам запрос. Выглядит он примерно так: метод (чаще всего GET — «дай мне документ»), путь к нужной странице и набор заголовков. Заголовки — это служебная информация: какой браузер отправляет запрос, какой формат ответа он ожидает и какие cookies уже сохранены для этого сайта.
На стороне сервера запрос обычно проходит через несколько узлов. Балансировщик нагрузки распределяет его между несколькими машинами. Обратный прокси, например nginx, может сразу отдать закешированную копию страницы или передать запрос дальше — серверному приложению, которое обращается к базе данных за нужными данными. Ответ собирается в обратном порядке и уходит к браузеру.
Ответ сервера тоже состоит из нескольких частей. Код состояния показывает, как все прошло: 200 значит все хорошо, 301 — ресурс переехал, 404 — не найдено, 500 — ошибка на сервере. Дальше идут заголовки — например, тип содержимого или правила кеширования, — и тело ответа, обычно HTML-код страницы.
Важная деталь: то, как физически передаются запрос и ответ, зависит от версии HTTP. В HTTP/1.1 на одно соединение приходится один запрос за раз. Поэтому браузеры исторически открывали сразу несколько параллельных соединений к одному серверу — как правило, около шести, — чтобы грузить ресурсы одновременно. HTTP/2 решил эту проблему иначе: он умеет вести сразу много запросов и ответов в рамках одного соединения — это называется мультиплексированием. А еще он сжимает заголовки, чтобы не гонять одни и те же данные повторно. HTTP/3 пошел еще дальше и убрал саму причину проблемы, отказавшись от TCP в пользу QUIC.
Условный пример HTTP-запроса и ответа сервера
❯ Шаг 5. Браузер разбирает HTML, CSS и JavaScript
Получив HTML, браузер не ждет, пока загрузится весь документ, — он начинает разбирать его сразу, по мере поступления данных. Из тегов строится DOM — дерево, отражающее структуру документа: какие элементы вложены друг в друга, какой у них текст и атрибуты.
Стоит браузеру встретить ссылку на таблицу стилей, он запускает параллельную загрузку CSS-файла. Разобранные стили складываются в похожее дерево — CSSOM, которое описывает, как должен выглядеть каждый элемент.
JavaScript может вмешаться в этот процесс. Обычный тег <script> способен приостановить разбор HTML до загрузки и выполнения файла. Атрибуты async и defer изменяют это поведение, но работают по-разному: async запускает скрипт сразу после его загрузки, а defer сохраняет порядок выполнения скриптов и запускает их после завершения разбора документа.
Когда DOM и CSSOM готовы, браузер объединяет их в дерево рендеринга — тоже похожее на DOM. Но без скрытых элементов вроде тех, что помечены display: none, и без служебных тегов вроде head.
Как браузер превращает код в структуру страницы
❯ Шаг 6. Рендеринг: как дерево превращается в картинку
Дерево рендеринга описывает, что нужно показать, но изображением ещё не является. Сначала браузер рассчитывает размеры и координаты элементов, затем рисует их и собирает отдельные слои в итоговый кадр.
Сначала — layout, раскладка: для каждого элемента вычисляются точные размеры и координаты на странице. Затем — покраска (paint): элементы закрашиваются цветом, получают текст, границы, тени и фон, обычно на нескольких отдельных слоях. Последний этап — компоновка (compositing): все слои собираются в итоговое изображение, и часто эта работа перекладывается на видеокарту, что особенно заметно на анимациях и прокрутке.
Практическое следствие: если JavaScript потом меняет структуру или стили страницы, браузеру может понадобиться заново пройти часть этих этапов. Это стоит времени и может ощущаться как подтормаживание интерфейса. Именно поэтому в вопросах производительности веб-страниц часто советуют менять как можно меньше элементов на странице за один раз.
Три этапа формирования изображения страницы
❯ Шаг 7. Дозагрузка ресурсов, кеширование и ускорение
Первый ответ сервера — обычно только HTML. Внутри него браузер находит ссылки на картинки, шрифты, дополнительные стили и скрипты и запрашивает их тоже, по возможности параллельно.
Чтобы не гонять одни и те же файлы по сети заново, существует несколько уровней кеширования. Браузер хранит уже загруженные файлы локально и, ориентируясь на заголовки вроде Cache-Control, решает, можно ли использовать сохраненную копию вместо нового запроса. Если сайт использует CDN — сеть серверов, распределенных географически, — статичные файлы отдаются с ближайшего к пользователю сервера, а не с одного центрального. Некоторые сайты дополнительно используют service worker — скрипт, который может перехватывать запросы браузера и обслуживать их из локального хранилища даже без подключения к интернету.
Небольшие, но полезные приемы ускорения — это подсказки браузеру вроде preconnect (заранее установить соединение с нужным сервером) или preload (заранее загрузить конкретный файл, который точно понадобится).
Условный пример вкладки Network и waterfall загрузки
❯ Зачем это знать на практике
При диагностике медленной загрузки обычно начинают со вкладки Network в инструментах разработчика. Она показывает, сколько времени заняли DNS, установка соединения, ожидание ответа, загрузка и обработка ресурсов. Так можно понять, на каком именно участке появляется задержка. Если долго выполняется DNS-запрос, стоит проверить резолвер. Если сервер долго отвечает, причину нужно искать в приложении, базе данных или настройках кеша. Если задержка появляется уже при рендеринге, внимание стоит обратить на JavaScript и стили.
Для тех, кто выбирает хостинг или настраивает сервер, из всей этой цепочки видно: на скорость влияет буквально каждый шаг. Играют роль близость сервера к пользователю, поддержка современных версий HTTP и TLS, настройка кеширования. Эти решения измеряются в миллисекундах и складываются в разницу, которую замечает пользователь.
❯ Итоги
Между нажатием Enter и готовой страницей происходит гораздо больше, чем кажется. Браузер может сначала обратиться к кешу, затем найти IP-адрес через DNS, установить соединение, получить HTML и только после этого начать строить изображение страницы.
Поэтому медленная загрузка — это не одна универсальная проблема. Задержка может появиться на этапе DNS, при соединении с сервером, во время ожидания ответа или уже в браузере, когда выполняется JavaScript и перерисовывается интерфейс. Вкладка Network помогает отделить один случай от другого.
❯ Что почитать дальше
MDN Web Docs, «How the web works» — подробный разбор всего пути запроса от адресной строки до отрисованной страницы (на английском языке).
RFC 9110 (HTTP Semantics) и RFC 9114 (HTTP/3) — официальные спецификации для тех, кто хочет разобраться в деталях протоколов.
Cloudflare Learning Center, статья «What is DNS» — доступное объяснение DNS-резолвинга с наглядной схемой.
Может будет кому-нибудь полезно. Расширение для браузера, которое позволяет смотреть видео и фильмы в отдельном окне с субтитрами. Отлично подойдёт для тех, кто хочет изучать иностранный язык и одновременно заниматься другими делами на компьютере.
Недавно понадобилось вытащить данные из QR-кода на кассовом чеке. Чек уже успел пожить: слегка затёрт, плюс классические полоски от грязной головки при термопечати. Сканеры и приложения дружно говорили «не удалось распознать».
Первая мысль была классическая: открыть фото в редакторе и просто перерисовать все эти чёрные и белые квадратики руками. Через минут пятнадцать я понял, что это путь в никуда. Модулей там несколько сотен. Глаза уже начинали плыть, а я ещё даже до середины не добрался.
Тогда началось самое интересное — думалка.
Сначала хотелось полностью автоматизировать. Натравить какую-нибудь нейросеть, чтобы она «восстановила» картинку. Но чем больше я об этом думал, тем сильнее понимал: нейросеть на таких грязных данных легко начнёт фантазировать. А мне нужна не красивая картинка, а точный код, который реально прочитается.
В итоге пришло решение, которое оказалось самым правильным: самый мощный, бесплатный и пока не превзойдённый ИИ на планете — человеческий мозг. Но использовать его нужно умно, а не заставлять человека тупо тыкать в каждую точку с нуля.
Вот как это выглядит в деле.
Сначала просто загружаешь фото:
Дальше можно нормально подготовить снимок: обрезать, повернуть, подкрутить экспозицию, яркость, контраст, гамму, насыщенность, шумоподавление и резкость. После каждого изменения программа сразу пытается прочитать QR.
Часто уже на этом этапе хватает. Если код прочитался — программа сразу выдаёт чистый QR и сами данные. Их можно скопировать, а код сохранить картинкой. И всё, дальше идти не нужно.
Если же даже после всех правок фото код всё равно молчит — тогда включается более тяжёлая артиллерия. Программа сама находит область, считает размер модуля и строит сетку.
1/2
Если чек снят криво или бумага изогнута — можно выровнять автоматически по finder-паттернам или потянуть контрольные точки руками:
И только если совсем ничего не помогает — начинается самый крайний режим: построчная проверка каждого модуля. Программа предлагает цвет, а ты только подтверждаешь или инвертируешь (пробел / X).
1/2
Всё это работает полностью локально в браузере. Фото никуда не уезжает.
Получился такой гибрид: компьютер делает всю тяжёлую и нудную работу по геометрии, измерению яркости и попыткам прочитать код, а финальное решение в сложных случаях оставляет человеку. Потому что на грязном чеке с полосками именно глаз пока ещё лучше любого алгоритма понимает «это чёрный или уже почти белый».
Если у кого-то валяется такой же «полумёртвый» QR с чека, наклейки или старой распечатки — можете попробовать. Интересно, насколько далеко можно зайти с сильно повреждёнными кодами.
А вы когда-нибудь пытались вручную восстанавливать QR? Какие ощущения остались?
