Preconnect: как измерить и улучшить производительность сайта

Представьте интернет-магазин, у которого название товара и кнопка «Купить» появляются сразу, а фирменный шрифт и большая фотография первого экрана приезжают с внешнего сервера. Браузер узнаёт об этом сервере не мгновенно: сначала ему приходится найти его адрес, установить соединение и, для HTTPS, подготовить защищённый канал. И только потом начинается получение файла.

preconnect позволяет часть этой подготовки сделать заранее.

Для бизнеса это похоже не на «ускоритель сайта», а на пропуск для курьера. Без него машина с важным товаром приезжает к закрытому шлагбауму и только тогда начинает оформлять въезд. С preconnect пропуск подготовлен заранее — когда груз приехал, можно ехать дальше почти сразу.

Именно поэтому смотреть нужно не на наличие красивой строки в HTML, а на вопрос: какой важный внешний ресурс пользователь действительно ждёт на этой странице?

Что именно делает Preconnect — и чего он не делает

Самая частая ошибка начинается уже с определения. preconnect не скачивает шрифт, изображение или JavaScript заранее. Он лишь сообщает браузеру: «С этим внешним источником мы, скорее всего, скоро будем работать — имеет смысл подготовить соединение».

Для HTTPS это может включать несколько этапов:

1. определение IP-адреса домена;
2. установку сетевого соединения;
3. подготовку защищённого TLS-соединения.

После этого конкретный файл всё равно придётся запросить отдельно.

<link rel="preconnect" href="https://cdn.example.com">

Допустим, главная фотография интернет-магазина хранится на отдельном image-CDN. HTML страницы уже пришёл, но точный вариант изображения браузер узнаёт чуть позже. Если origin CDN известен заранее и картинка действительно важна для первого экрана, раннее соединение может убрать часть ожидания перед её загрузкой.

А теперь противоположный пример. На странице есть карта филиала в самом низу — пользователь увидит её после нескольких экранов текста. Открывать соединение с сервисом карты в первые миллисекунды только потому, что «он есть на странице», — примерно как вызвать такси утром к ресторану, хотя ехать домой вы собираетесь после полуночи. Машина готова, но пользы бизнесу от этого нет.

Когда владелец сайта действительно может увидеть пользу

Полезность preconnect определяется не количеством сторонних сервисов, а их местом в загрузке страницы.

Сценарий 1. Шрифт нужен для первого экрана

Компания подключила внешний шрифт. Заголовок, цена и кнопка первого экрана зависят от файла, находящегося на другом origin.

Здесь раннее соединение может иметь смысл, потому что ресурс участвует в том, что посетитель должен увидеть сразу. Для внешних шрифтов важно также корректно учитывать режим cross-origin:

<link rel="preconnect" href="https://fonts.example.com" crossorigin>

Но есть и более фундаментальный вопрос: нужен ли бизнесу вообще внешний шрифтовый сервис. Если те же файлы разумно разместить локально, иногда лучший способ оптимизировать внешнее соединение — перестать его создавать.

Сценарий 2. Главная картинка приходит с CDN

Представьте сайт застройщика: первый экран почти целиком занимает фотография жилого комплекса, а изображения доставляет отдельный CDN.

Если именно этот внешний origin задерживает получение LCP-изображения, preconnect становится кандидатом на тестирование. Но если браузеру уже известен точный URL картинки, могут оказаться важнее раннее обнаружение самого изображения, preload или правильный приоритет загрузки.

То есть задача звучит не «добавить preconnect», а «убрать конкретную паузу из критической цепочки».

Сценарий 3. Аналитика, чат и карта

На корпоративном сайте одновременно работают аналитика, call-tracking, онлайн-чат и карта офиса.

Очень хочется добавить четыре preconnect и считать задачу закрытой. Но посетитель пришёл читать предложение и нажимать кнопку, а не любоваться тем, насколько быстро сервер аналитики познакомился с его браузером.

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

Внешний источник	Стоит рассматривать preconnect?	Почему
CDN с главным изображением	Часто да	Ресурс может быть частью первого экрана
Внешний критичный шрифт	Часто да	Соединение требуется до загрузки шрифта
Аналитика	Обычно не первый кандидат	Не должна задерживать основное содержимое
Чат, появляющийся после взаимодействия	Скорее нет	Соединение можно отложить
Карта внизу длинной страницы	Скорее нет	Пользователь увидит её значительно позже

Именно такой подход полезен и в разборе TTFB и серверной задержки: сначала определяется место, где теряется время, а уже потом выбирается инструмент. Preconnect не исправит медленный PHP, тяжёлый запрос к базе или сервер, который долго формирует HTML.

Preconnect, DNS Prefetch и Preload — это не три названия одного ускорения

Эти механизмы легко перепутать, хотя решают они разные задачи.

dns-prefetch — самый лёгкий вариант. Он заранее выясняет, куда в сети ведёт доменное имя, но не готовит полноценное защищённое соединение.

<link rel="dns-prefetch" href="//example.com">

preconnect идёт дальше и заранее готовит соединение с origin.

<link rel="preconnect" href="https://example.com">

preload — уже про конкретный ресурс. Вы сообщаете браузеру не просто «скоро понадобится этот сервер», а «вот этот файл нужен рано».

Поэтому хороший выбор можно свести к трём вопросам:

• знаете только важный внешний origin — рассматривайте preconnect;
• внешний домен может пригодиться, но он не критичен — возможно, достаточно dns-prefetch;
• знаете конкретный критичный файл — проверьте, не правильнее ли работать с ранней загрузкой самого ресурса.

Вместо коллекционирования оптимизационных тегов полезнее выстроить единый подход к тому, как измерить и улучшить производительность сайта: сначала критическая цепочка, затем изменение, потом повторное измерение.

Как проверить Preconnect, не превращаясь в сетевого инженера

Владельцу бизнеса не нужно вручную измерять TLS-пакеты. Достаточно ответить на четыре практических вопроса.

1. Есть ли вообще критичный внешний origin?
Откройте сетевую картину загрузки страницы и найдите внешние домены, от которых зависит первый экран. Если все ключевые стили, шрифты и изображения идут с вашего же origin, preconnect может просто не понадобиться.

2. Когда браузер впервые подключается к этому origin?
Если соединение начинается только после позднего обнаружения важного ресурса, появляется потенциальное место для оптимизации.

3. Что изменилось после добавления preconnect?
Сравнивайте одну и ту же страницу в одинаковых условиях. Нужное соединение должно начинаться раньше. Если визуально изменился только HTML, а критичный ресурс всё равно приходит в тот же момент, оптимизация не решила проблему.

4. Улучшился ли показатель, который действительно был ограничением?
Если проблема была связана с поздно загружаемым LCP-ресурсом, смотрите в первую очередь на его цепочку загрузки и LCP. Если LCP ограничивает медленный сервер, тяжёлое изображение или блокирующий CSS, попытка лечить всё preconnect напоминает замену дверной ручки у автомобиля с пустым баком.

В актуальном Lighthouse отдельная старая рекомендация Preconnect to required origins уже объединена с анализом дерева сетевых зависимостей. Поэтому искать обязательно именно прежний пункт отчёта не стоит — интерфейс инструмента меняется, логика диагностики остаётся той же.

Как правильно внедрять Preconnect на WordPress

На WordPress можно просто вывести <link> в <head>, но для постоянной поддержки сайта логичнее использовать штатный механизм resource hints. В WordPress для этого существует фильтр wp_resource_hints.

Пример для разработчика:

add_filter( 'wp_resource_hints', function ( $urls, $relation_type ) {

	if ( 'preconnect' === $relation_type ) {
		$urls[] = [
			'href'        => 'https://cdn.example.com',
			'crossorigin' => 'anonymous',
		];
	}

	return $urls;

}, 10, 2 );

Но бизнес-решение принимается до написания этого кода: какой origin добавляем и какой пользовательский сценарий этим ускоряем?

Если ответа нет, разработчику фактически поставлена задача «добавить тег ради тега».

Что чаще всего делают неправильно

Первая ошибка — предварительно подключаться ко всему подряд. На странице нашли восемь внешних доменов — добавили восемь строк. Но браузеру приходится тратить ресурсы на каждое подготовленное соединение.

Вторая — использовать preconnect для собственного origin. Для обычных запросов к тому же источнику это не даёт того смысла, ради которого механизм существует: соединение с сервером страницы уже используется.

Третья — пытаться заменить им оптимизацию ресурса. Если hero-изображение весит несколько мегабайт, раннее знакомство с CDN не сделает сам файл легче.

Четвёртая — оптимизировать некритичный маркетинговый сервис раньше основного контента. Быстро загруженный счётчик не компенсирует медленно появившуюся карточку товара.

Пятая — оценивать результат только по лабораторному баллу. Google прямо рекомендует смотреть на Core Web Vitals как на часть общего пользовательского опыта, а не стремиться к идеальной оценке ради самой оценки.

В рамках SEO-продвижения сайта с техническим аудитом такие изменения имеют смысл тогда, когда диагностика показывает конкретное узкое место: например, критичный внешний ресурс поздно обнаруживается и соединение с его сервером действительно находится на пути к первому экрану. Добавлять preconnect как формальный пункт SEO-чеклиста смысла нет.

Как понять, стоит ли вообще тратить время на эту настройку

У preconnect есть довольно простой бизнес-фильтр.

Если внешний ресурс важен для того, что посетитель видит сразу, соединение с его сервером начинается поздно, а источник нельзя или неразумно перенести к себе — настройку стоит протестировать.

Если речь идёт о карте в футере, отложенном чате, аналитическом пикселе или сервисе, который пользователь может вообще не задействовать, сначала ищите более крупные причины медленной загрузки.

Preconnect — хороший инструмент именно потому, что решает узкую задачу. Он не «ускоряет интернет-магазин», не «поднимает SEO» и не исправляет медленный сервер. Он убирает одну конкретную паузу между браузером и важным внешним origin.

И когда такой паузы на критическом пути действительно нет, лучший preconnect — тот, который вы не добавили.