Bcorrections

dns-prefetch, preconnect, preload: пайплайн префетчинга в 2026

Четыре способа подсказать браузеру что грузить заранее. Когда использовать каждый, как не перегрузить сеть и как выжать максимум из LCP.

21 мая 2025 г.·8 мин чтения·Команда Bcorrections

В современном вебе сайт грузит десятки сторонних ресурсов: шрифты, аналитика, видео, чаты, картинки с CDN. Каждый — это DNS-резолв, TCP-handshake, TLS-handshake, HTTP-запрос. Несколько сотен миллисекунд на каждое новое соединение. Если эти соединения сделать заранее — основной контент рендерится быстрее.

В этой статье разбираем четыре rel-подсказки браузеру для префетчинга и когда какую использовать.

Четыре уровня подсказок

От самого лёгкого к самому тяжёлому:

  1. dns-prefetch — резолв DNS
  2. preconnect — DNS + TCP + TLS handshake
  3. prefetch — скачать ресурс с низким приоритетом (для будущего использования)
  4. preload — скачать ресурс с высоким приоритетом (для текущей страницы)

Каждый «сильнее» предыдущего и решает свою задачу.

dns-prefetch

Самая лёгкая подсказка. Браузер начинает DNS-резолв указанного домена, не открывая соединения.

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

DNS-резолв занимает обычно 20-50 мс на холодном кеше. Если ресурс с этого домена понадобится позже, время резолва уже потрачено заранее — ресурс начнёт загружаться быстрее на эти 20-50 мс.

Когда использовать:

  • На сторонние домены, которые понадобятся точно (аналитика, шрифты, чаты)
  • Когда вы НЕ уверены, что соединение точно понадобится — dns-prefetch дешёвый, не больно если не пригодится
  • Для нескольких доменов сразу — браузер сделает резолв всех параллельно

Чего не делать:

  • Не делайте dns-prefetch на 30 доменов «на всякий случай». Каждый отъедает crawl рейтинг приоритета.
  • Не делайте на доменах, к которым обращаетесь по <link rel="preconnect"> — preconnect уже включает DNS-резолв.

preconnect

Браузер делает DNS-резолв И открывает TCP-соединение И инициирует TLS-handshake. Когда придёт реальный запрос — соединение уже готово, можно сразу слать запрос.

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

Сэкономленное время: 100-300 мс (DNS + handshake). На холодном соединении — больше.

Когда использовать:

  • Для домена, который точно понадобится (CDN с критичными ресурсами, шрифт-провайдер)
  • Когда ресурс будет нужен через 100+ мс от загрузки HTML
  • Только 3-5 доменов максимум — больше нагрузит сеть

Важный нюанс — crossorigin:

Если запрашиваете шрифты или другие ресурсы с CORS-запросом, нужен атрибут crossorigin без значения (для credentials="omit") или с crossorigin="use-credentials". Без этого preconnect и реальный запрос откроют разные соединения, и preconnect зря потрачен.

Пример с Google Fonts:

<!-- Правильно -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

<!-- Неправильно -->
<link rel="preconnect" href="https://fonts.gstatic.com">

Без crossorigin шрифт будет качаться через новое соединение, preconnect сработает впустую.

preload

Самая сильная подсказка. Браузер не только открывает соединение, но и скачивает ресурс с высоким приоритетом.

<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/hero-image.webp" as="image">
<link rel="preload" href="/critical.js" as="script">

Используется для критических ресурсов, которые точно нужны для рендера above-the-fold.

Когда использовать:

  • Главный шрифт, который применяется в above-the-fold
  • Hero-картинка (LCP-кандидат)
  • Критический JS-чанк

Атрибут as:

Обязателен для preload. Говорит браузеру какой тип ресурса. Возможные:

  • font — шрифт (требует crossorigin)
  • image — картинка
  • script — JS
  • style — CSS
  • fetch — XHR/Fetch запрос
  • video — видео

Без as браузер не знает приоритет и часто игнорирует preload.

Чего не делать:

  • Не preload-ить десятки ресурсов. Если всё имеет высокий приоритет — ничто не имеет высокого приоритета. 3-5 preload на страницу — оптимум.
  • Не preload-ить ресурсы, которые могут не понадобиться. Если pre-loaded ресурс не используется на странице, браузер ругается в DevTools «preload was not used».

prefetch

Скачивание ресурса с низким приоритетом, для использования на следующих страницах.

<link rel="prefetch" href="/next-page.html">
<link rel="prefetch" href="/large-bundle.js">

Браузер скачает указанный ресурс в idle-времени, когда основная страница уже отрендерилась и сеть свободна. Если пользователь перейдёт по соответствующей ссылке — ресурс уже в кеше, переход почти мгновенный.

Когда использовать:

  • Следующая логичная страница (например, на главной можно prefetch-ить «о компании» если 50% пользователей туда переходят)
  • Чанки SPA-приложения, к которым пользователь скорее всего перейдёт
  • Большие ресурсы, которые понадобятся «потом, но точно»

Когда не использовать:

  • На медленных соединениях (mobile через 3G). Prefetch может «съесть» трафик пользователя и ничего не дать.
  • На страницах, где переходы редкие и непредсказуемые.
  • Когда вы не уверены, что пользователь пойдёт именно туда.

Современная альтернатива: Speculation Rules API

С 2024 года в Chrome (а с 2026 — в большинстве браузеров) появился Speculation Rules API. Это более продвинутая система предзагрузки страниц:

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/article/*" },
    "eagerness": "moderate"
  }]
}
</script>

Браузер начинает prerender (не просто prefetch, а полную загрузку и рендер) указанных страниц в фоне, когда пользователь наводит мышь на ссылку или есть другие признаки намерения кликнуть. Переход — мгновенный.

Это будущее. На современных Chrome и Edge работает уже в 2026, на остальных — постепенно подтягивается.

Стратегия: что и когда использовать

Под типовой коммерческий сайт:

<head>
  <!-- Шрифты с CDN -->
  <link rel="preconnect" href="https://api.fontshare.com" crossorigin>
  <link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>

  <!-- LCP-картинка -->
  <link rel="preload" href="/hero-bg.webp" as="image">

  <!-- Аналитика и чат — не критичны, dns-prefetch достаточно -->
  <link rel="dns-prefetch" href="//mc.yandex.ru">
  <link rel="dns-prefetch" href="//www.googletagmanager.com">

  <!-- Внутри body можно prefetch для следующих страниц -->
  <link rel="prefetch" href="/uslugi/">
  <link rel="prefetch" href="/cases/">
</head>

Это даёт оптимальный баланс — критичные ресурсы preload-ятся с высоким приоритетом, второстепенные домены резолвятся заранее, следующие страницы скачиваются в фоне.

Реальные цифры

На типовом сайте без префетча:

  • LCP: 2400 мс
  • TTI: 3200 мс

После добавления preload для шрифта и hero-картинки + preconnect для шрифтового CDN:

  • LCP: 1800 мс
  • TTI: 2700 мс

Прирост — 600 мс к LCP. Большой эффект от минимальных правок в <head>.

Чего избегать

  1. Слишком много preload — каждый preload забирает приоритет у других ресурсов. Если у вас 20 preload, ни один реально не приоритетный.
  2. dns-prefetch там, где уже есть preconnect — preconnect уже делает DNS-резолв. Дублирование.
  3. prefetch на медленных соединениях — респектируйте prefers-reduced-data через JS-чек.
  4. preload без as — игнорируется браузером.
  5. preload шрифта без crossorigin — браузер качает два раза.

Резюме

Префетчинг — мощный и недорогой способ ускорить сайт. dns-prefetch для «возможно нужно», preconnect для «точно нужно скоро», preload для «нужно прямо сейчас», prefetch для «нужно на следующей странице». Применяйте осознанно — не больше 5 preload + 3 preconnect + 5 dns-prefetch на страницу.

Хотите аудит префетчинга вашего сайта? Напишите нам. Бесплатно за 2 рабочих дня.

Веб-разработка

Это часть нашей услуги Разработка сайтов

Сайты под ключ, сразу готовые к SEO и AI-поиску

Перейти к услуге →
Идём дальше?

Нужна пара экспертных глаз на ваш проект?

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

Обсудить проект