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

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

Для этого используются механизмы предварительной загрузки, включая prefetch и dns-prefetch. Они помогают сократить ожидание, но решают разные задачи.

Здесь важно не путать предварительную загрузку с показателями скорости. Prefetch — не метрика, которую оценивают в миллисекундах или по шкале от 0 до 100. Это технический механизм. Его эффективность определяют по результатам сетевых запросов, повторному использованию ресурсов и скорости последующей навигации.

Prefetch, DNS-prefetch, preconnect и preload: в чём разница

Названия похожи, но браузер выполняет принципиально разные операции.

Механизм	Что делает браузер	Когда полезен
dns-prefetch	Заранее определяет IP-адрес домена	Предстоящие обращения к сторонним доменам
preconnect	Заранее устанавливает соединение, включая DNS и необходимые сетевые согласования	Критичные сторонние ресурсы
prefetch	Предварительно загружает ресурс для вероятного будущего использования	Ресурсы следующих страниц
preload	Рано загружает необходимый ресурс текущей страницы	Главный шрифт, изображение или критичный файл
prerender	Предварительно загружает и отрисовывает документ	Очень вероятная следующая навигация

Различие особенно важно для оптимизации первого экрана.

Если главное изображение требуется сейчас, обычно нужно рассматривать preload или правильный приоритет его обычной загрузки. Использовать prefetch для ускорения этого же изображения неправильно: он ориентирован на будущие потребности и обычно имеет низкий приоритет.

Если ресурс находится на другом домене, а браузер ещё не знает его IP-адрес, dns-prefetch может сократить задержку будущего обращения.

Как работает DNS-prefetch

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

dns-prefetch предлагает выполнить этот этап заранее. При последующем обращении браузер сможет использовать уже полученный результат, если он доступен в DNS-кэше.

Однако это не гарантирует, что файл начнёт загружаться мгновенно. После DNS всё ещё могут потребоваться установка соединения, TLS-согласование, отправка HTTP-запроса и получение ответа.

Для критичных сторонних соединений более подходящим механизмом иногда оказывается preconnect.

Как настроить DNS-prefetch через HTML

Для предварительного разрешения домена используется элемент <link> с атрибутом rel="dns-prefetch".

Пример:

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

cdn.example.com — условный домен для демонстрации синтаксиса.

После обработки подсказки браузер может заранее выполнить DNS-разрешение этого хоста.

Для записи также допустим абсолютный HTTPS-адрес.

Если браузеру нужно подключить критичный ресурс с внешнего источника, вместо DNS-prefetch или в дополнение к нему при необходимости можно использовать:

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

Атрибут crossorigin особенно важен для соединений, используемых ресурсами с соответствующим режимом CORS, например некоторыми веб-шрифтами.

Не нужно автоматически добавлять обе подсказки для каждого домена. Современные браузеры поддерживают preconnect; дублирование стоит оценивать с точки зрения совместимости и реального эффекта.

Какие домены стоит добавлять

Типичные кандидаты — внешние источники ресурсов, которые используются на странице или с высокой вероятностью понадобятся вскоре:

• серверы шрифтов;
• CDN со статическими файлами;
• отдельные сервисы изображений;
• необходимые сторонние API;
• внешние виджеты, загружаемые после первоначальной отрисовки.

Но само присутствие внешнего домена в HTML ещё не делает его подходящим кандидатом.

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

Также не имеет смысла заранее разрешать десятки доменов, к которым браузер никогда не обратится.

Как работает предварительная загрузка будущих страниц

Для загрузки ресурса, который понадобится при следующем переходе, существует более старый механизм rel="prefetch".

Условный пример:

<link
  rel="prefetch"
  href="/assets/next-page.css"
  as="style"
>

Так браузеру сообщается, что файл стилей может понадобиться позднее.

Если браузер поддерживает механизм и разрешает предварительную загрузку, ресурс может попасть в HTTP-кэш для последующего использования.

При этом нужно учитывать заголовки кэширования, ограничения браузера и вероятность будущего обращения.

Для полноценного HTML-документа современный Chrome предлагает более специализированный механизм — Speculation Rules API.

Speculation Rules для следующей страницы

Пример предварительной загрузки конкретного HTML-документа:

<script type="speculationrules">
{
  "prefetch": [
    {
      "source": "list",
      "urls": ["/articles/next-article/"]
    }
  ]
}
</script>

Здесь браузер получает правило, разрешающее заранее загрузить документ по указанному пути.

Особенность такого prefetch: загружается HTML-документ, но не все его дополнительные ресурсы. Изображения, стили и скрипты следующей страницы могут загружаться уже после реального перехода.

Это отличает prefetch от prerender, при котором браузер может подготовить страницу значительно полнее.

Не следует путать эти механизмы с обычной внутренней перелинковкой. Speculation Rules не создаёт HTML-ссылку и не заменяет навигацию, доступную пользователям и поисковым роботам.

Prefetch в WordPress: что уже работает автоматически

Для WordPress важно сначала проверить существующую конфигурацию. Добавление ещё одного плагина предварительной загрузки может оказаться лишним.

Начиная с WordPress 6.8, ядро поддерживает спекулятивную загрузку через Speculation Rules API. В стандартной конфигурации используются режим prefetch и осторожная стратегия conservative.

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

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

Поэтому при тестировании WordPress откройте страницу как обычный посетитель, не вошедший в админку. Иначе можно ошибочно заключить, что предварительная загрузка не работает.

Как добавить DNS-prefetch через WordPress

У ядра WordPress есть фильтр wp_resource_hints, позволяющий управлять подсказками для браузера.

Пример для подключения одного проверенного стороннего домена:

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

        if ( 'dns-prefetch' !== $relation_type ) {
            return $urls;
        }

        $urls[] = 'https://cdn.example.com';

        return $urls;
    },
    10,
    2
);

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

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

Перед внедрением проверьте, не добавляет ли такую подсказку WordPress самостоятельно. Фильтр не нужен для доменов, которые уже присутствуют в итоговой разметке.

Не стоит отключать всю функцию wp_resource_hints() ради удаления одной ненужной записи: вместе с ней можно потерять другие полезные подсказки.

Также проверьте, не создают ли дубли CDN, плагины производительности и собственный код темы.

Как проверить работу prefetch в Chrome DevTools

Главная задача диагностики — выяснить, выполнил ли браузер предварительную операцию и пригодился ли её результат.

Проверка DNS-prefetch

Откройте Chrome DevTools, перейдите на вкладку Network и изучите запросы к нужному стороннему домену.

Для конкретного запроса полезно смотреть раздел Timing, включая стадию DNS Lookup.

Нужно учитывать, что DNS-prefetch сам по себе не обязательно отображается как обычная строка HTTP-запроса в Network.

Поэтому наличие тега в исходном HTML и отсутствие отдельного запроса в таблице Network — не доказательство ошибки.

Сравнивайте поведение при холодном и повторном открытии страницы, исключая влияние прогретых соединений и кэша. Если DNS Lookup равен нулю, это также не доказывает, что результат обеспечила именно добавленная подсказка.

Проверка Speculation Rules

В современных версиях Chrome DevTools диагностика доступна в панели Application, в разделе Speculative loads.

В ней можно исследовать обнаруженные правила и сведения о предварительных загрузках.

На вкладке Network запросы, инициированные Speculation Rules, можно дополнительно определить по HTTP-заголовку:

Sec-Purpose: prefetch

Для prerender используется другой вариант:

Sec-Purpose: prefetch;prerender

Важно: раздел Speculative loads относится к Speculation Rules и не предназначен для диагностики всех обычных подсказок rel="prefetch" или rel="dns-prefetch".

Может ли prefetch замедлить сайт

Да. Предварительная загрузка потребляет ресурсы, даже если пользователь никогда не откроет подготовленную страницу.

Потенциальные проблемы:

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

Дополнительная нагрузка на сервер. Каждый предварительный запрос может запускать обработку PHP, обращения к базе данных или другие операции. Это особенно чувствительно для некешируемых страниц.

Конкуренция за соединения. Слишком активная предварительная загрузка может мешать обычным запросам, хотя браузеры стараются отдавать приоритет текущей странице.

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

Персонализированный контент. Предварительно полученная страница может содержать состояние, которое изменится к моменту перехода. Особенно осторожно нужно работать с корзиной, личным кабинетом и оформлением заказа.

В Chrome предварительная загрузка также зависит от настроек браузера, памяти, энергосбережения и сетевых ограничений. Наличие правила не гарантирует выполнения запроса.

Для динамических WordPress-сайтов рекомендуется исключать чувствительные маршруты из спекулятивной загрузки, а не пытаться ускорить абсолютно все URL.

Практический пример: предварительная загрузка страниц каталога

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

Разработчик рассматривает возможность заранее загружать HTML карточек.

Есть два варианта.

Вариант А: предварительно загружать все 20 товаров, видимых в категории.

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

Второй подход потенциально экономнее.

Для демонстрации рассмотрим условную ситуацию: браузер выполнил 100 предварительных запросов, но только 20 подготовленных URL пользователь действительно открыл, пока результат оставался пригодным для использования.

Это означает, что 80 запросов не привели к соответствующему переходу. Даже если 20 остальных помогли навигации, эффективность такой стратегии требует проверки.

Вместо оценки только общей скорости загрузки нужно исследовать:

Показатель	Что он помогает понять
Количество предварительных запросов	Дополнительную сетевую и серверную нагрузку
Доля использованных результатов	Насколько точно система предсказывает переходы
Время последующей навигации	Получает ли пользователь реальную выгоду
Объём переданных данных	Насколько дорого обходится предварительная загрузка
Ошибки и отменённые запросы	Где механизм не срабатывает или ограничивается браузером

Это учебный сценарий, а не данные конкретного сайта.

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

Влияет ли prefetch на SEO, индексацию и Core Web Vitals

Добавление prefetch не является прямым способом увеличения количества проиндексированных страниц.

Поисковым системам по-прежнему необходимы доступные URL, корректные ссылки, индексируемое содержимое и технически исправные ответы сервера.

Обычная HTML-навигация и предварительная загрузка выполняют разные функции:

• HTML-ссылки помогают пользователям и поисковым роботам обнаруживать страницы.
• Prefetch подготавливает данные для потенциальной будущей навигации.
• Sitemap сообщает поисковому роботу о доступных URL.
• Canonical и директивы индексирования решают другие задачи и не заменяются предварительной загрузкой.

Google не публикует правило, по которому наличие dns-prefetch или Speculation Rules автоматически повышает позиции сайта.

Связь с LCP и другими метриками

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

Однако влияние зависит от технологии.

Например, DNS-prefetch способен сократить ожидание DNS-разрешения, но не устранит задержку отрисовки, вызванную тяжёлым JavaScript.

Speculation Rules Prefetch может ускорить получение HTML при следующей навигации, но не гарантирует ускорения всех изображений и скриптов страницы.

Prerender способен дать более существенный эффект на последующей навигации, однако требует более осторожного обращения с ресурсами и состоянием приложения.

Поэтому показатели LCP, INP и CLS нужно оценивать отдельно. Успешный prefetch-запрос сам по себе не является доказательством улучшения Core Web Vitals.

Когда предварительная загрузка действительно оправдана

На практике prefetch стоит рассматривать, когда одновременно выполняются три условия:

1. Есть предсказуемая следующая навигация. Например, последовательное чтение статей, переход из категории в товар или движение по многошаговому сценарию.
2. Подготовленный результат пригодится. Он не устареет слишком быстро и сможет быть использован браузером.
3. Затраты оправданы. Дополнительный трафик и серверная нагрузка не превышают потенциальной пользы.

Для большинства обычных сайтов разумно сначала проверить уже существующие механизмы WordPress, критический путь загрузки текущей страницы и реальные задержки сторонних ресурсов.

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

Если же посетители регулярно переходят между страницами, корректно настроенная предварительная загрузка может сделать навигацию заметно комфортнее.

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