preload и prefetch — две подсказки браузеру, из-за путаницы между которыми страница на быстром сервере всё равно дорисовывается рывками. Заголовок первого экрана секунду висит системным шрифтом, потом дёргается и перерисовывается уже нормальным. Картинка героя появляется последней, когда скрипты аналитики уже отработали. Сервер отдал первый байт за 200 мс, канал широкий, а страница собирается медленно — потому что браузер сам решает, что качать первым, и его решение не совпадает с тем, что нужно посетителю.
Разница между «сайт быстрый» и «сайт кажется быстрым» — это чаще всего порядок загрузки, а не общий вес страницы. Я вижу это на большинстве проектов, которые ко мне приходят на SEO-продвижение бизнеса: файлы оптимизированы, кэш стоит, а LCP держится на четырёх секундах, потому что главный элемент экрана стоит в очереди за третьестепенными ресурсами.
Почему браузер грузит не то и не в том порядке
Браузер не знает вашего дизайна. Он получает HTML и начинает разбирать его сверху вниз. Всё, что он умеет на старте, — видеть теги. Дальше работает предзагрузчик (preload scanner): он бегло просматривает HTML вперёд, выхватывает ссылки на картинки, скрипты и стили и ставит их в очередь ещё до того, как основной парсер до них дойдёт. Это хорошая механика, но у неё есть слепые зоны.
Первая слепая зона — шрифты. Ссылки на файл шрифта в HTML нет. Она спрятана внутри CSS, в правиле @font-face. Чтобы её найти, браузер должен сначала скачать CSS, разобрать его, построить дерево стилей, понять, что на странице есть текст, которому нужен именно этот шрифт, — и только тогда запросить .woff2. Получается цепочка из трёх последовательных шагов: HTML → CSS → шрифт. Пока она отрабатывает, заголовок либо не виден вообще, либо показан запасным шрифтом и потом прыгает.
Вторая слепая зона — картинки, которых нет в HTML напрямую. Фон в CSS через background-image, слайдер, который собирает разметку скриптом, ленивая загрузка через JS с подстановкой src. Предзагрузчик их не видит: для него это не картинки, а строки внутри других файлов.
Третья проблема — конкуренция. У браузера ограниченное число одновременных соединений с одним доменом и конечный канал. Он раздаёт ресурсам приоритеты сам: блокирующий CSS в <head> получает Highest, синхронный скрипт — High, картинки внутри видимой области — High после вёрстки, картинки ниже сгиба — Low. Проблема в том, что «внутри видимой области» браузер узнаёт только после того, как посчитает раскладку. До этого момента картинка героя для него — обычная картинка с низким приоритетом, и она честно ждёт, пока догрузится счётчик и виджет обратного звонка.
Итог: страница технически быстрая, но метрика LCP считается по моменту отрисовки самого крупного элемента экрана — и он приходит последним. Как это влияет на позиции, я подробно разбирал в материале про Core Web Vitals и рост позиций. Здесь важно другое: браузеру можно подсказать. Именно для этого существуют директивы ресурсных подсказок.
Пять директив и чем они отличаются друг от друга
Все они — обычные теги <link> в <head> (или одноимённые заголовки ответа сервера). Разница в том, что именно они говорят браузеру.
preload — «этот файл точно нужен на текущей странице, скачай его сейчас с высоким приоритетом, не жди, пока найдёшь его сам». Файл скачивается и кладётся в кэш, но не применяется — применит его тот код, который до него доберётся.
<link rel="preload" href="/fonts/inter-600.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/img/hero.webp" as="image" fetchpriority="high">prefetch — «этот файл, скорее всего, понадобится на следующей странице, скачай его, когда будешь свободен». Приоритет самый низкий, загрузка идёт в простое, после того как текущая страница дособралась. На текущую страницу prefetch не влияет никак — он про переход дальше.
<link rel="prefetch" href="/uslugi/" as="document">preconnect — «мы точно пойдём на этот чужой домен, установи соединение заранее». Браузер делает DNS-резолв, TCP-рукопожатие и TLS-рукопожатие, не запрашивая ни одного файла. На мобильной сети это экономит реально ощутимые сотни миллисекунд, потому что три оборота до сервера при высокой задержке стоят дорого.
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>dns-prefetch — то же самое, но только резолв имени в IP. Дешевле preconnect, эффект меньше. Смысл имеет для доменов, к которым обращение вероятно, но не гарантировано, — и как запасной вариант для очень старых браузеров.
fetchpriority — не отдельный тег, а атрибут на уже существующем элементе: <img>, <script>, <link>. Он не заставляет браузер найти ресурс раньше, он меняет место найденного ресурса в очереди: high поднимает, low опускает. Это ручка громкости, а не новый источник звука.
| Директива | Когда срабатывает | Приоритет | Типичное применение | Вред при неправильном использовании |
|---|---|---|---|---|
| preload | Сразу при разборе <head>, до CSS и JS | Высокий (для шрифтов и стилей — вплоть до Highest) | Шрифт первого экрана, LCP-картинка, критический CSS | Отбирает канал у по-настоящему важных файлов; при ошибке в as файл качается дважды |
| prefetch | В простое, после отрисовки текущей страницы | Самый низкий (Lowest) | Следующий шаг воронки: карточка из каталога, страница услуги, вторая страница пагинации | Съеденный мобильный трафик, лишняя нагрузка на сервер, мусор в логах и статистике |
| preconnect | Сразу, параллельно разбору HTML | Не файл, а соединение | Домен шрифтов, CDN картинок, домен счётчика | Каждое лишнее соединение держит ресурсы; при десятке доменов браузер часть подсказок просто игнорирует |
| dns-prefetch | Сразу | Только DNS-резолв | Домены, к которым обращение вероятно, но не гарантировано | Практически безвреден, но и пользы даёт немного — легко создаёт иллюзию работы |
| fetchpriority | В момент, когда браузер нашёл ресурс | Поднимает или опускает существующий | high на LCP-картинку, low на карусель ниже сгиба |
Если high навешан на всё подряд, приоритеты выравниваются и перестают работать |
Ключевое, что стоит запомнить владельцу сайта: preload — про эту страницу, prefetch — про следующую. Их путают чаще всего, и путаница дорогая: prefetch на шрифт первого экрана не ускорит ничего, потому что файл начнёт качаться уже после того, как страница отрисовалась.
fetchpriority и lazy loading: одна ручка в обе стороны
Разгон первого экрана — это не только «ускорить нужное». Это ещё и «притормозить ненужное». Канал у посетителя один, и если по нему одновременно летят восемь картинок из карусели внизу страницы, картинке героя достаётся меньше.
Обратная задача решается двумя атрибутами. loading="lazy" откладывает загрузку картинки до момента, когда она приближается к области видимости. fetchpriority="low" оставляет загрузку сразу, но задвигает её в конец очереди.
Правило, которое я применяю на всех проектах: картинки первого экрана — никогда не lazy, всё остальное — всегда lazy. Самая частая поломка LCP на WordPress выглядит именно так: плагин оптимизации вешает loading="lazy" на все картинки без исключения, включая главную. Браузер честно откладывает её, ждёт вычисления раскладки, потом спохватывается и запрашивает — и LCP уезжает на секунду вперёд. У ленивой загрузки есть и второй побочный эффект, про который забывают: она мешает попаданию картинок в поиск по изображениям, я писал об этом отдельно в разборе, как ленивая загрузка съедает трафик из поиска по картинкам.
Ещё один нюанс: fetchpriority="high" на теге <img> в большинстве случаев работает лучше, чем <link rel="preload" as="image">, если картинка уже присутствует в исходном HTML. Предзагрузчик всё равно найдёт её за миллисекунды, ей нужен не поиск, а приоритет. Preload для картинки имеет смысл тогда, когда её адреса в HTML нет: фон из CSS, слайдер, собираемый скриптом, картинка внутри отложенного компонента. Такие ситуации типичны для сайтов, где вёрстка целиком строится на JavaScript — про это есть подробный разбор, почему красивый сайт на JavaScript робот видит пустой страницей.
Как найти ресурсы первого экрана, которые грузятся поздно
Подсказки нельзя расставлять наугад — иначе получится ровно тот случай, когда оптимизация делает хуже. Порядок работы простой и занимает минут двадцать.
Шаг 1. Определите LCP-элемент. Откройте страницу в Chrome, вкладка Performance, включите запись с перезагрузкой (throttling — Slow 4G, чтобы увидеть картину как на телефоне). На готовой временной шкале найдите отметку LCP. Браузер подсветит конкретный элемент: чаще всего это картинка героя, крупный заголовок или фоновое изображение блока.
Шаг 2. Посмотрите водопад. Вкладка Network, обязательно включите колонку Priority — правый клик по шапке таблицы, отметить Priority. Отсортируйте по времени старта. Вы увидите ровно то, ради чего всё затевалось: во сколько браузер запросил ваш LCP-ресурс и что он качал до него.
Шаг 3. Найдите цепочки. Наведите курсор на полосу ресурса — всплывёт разбивка: сколько времени ушло на ожидание в очереди (Queueing), на соединение, на ожидание ответа, на скачивание. Длинный Queueing означает, что ресурс не «медленный», а «поздний»: сервер тут ни при чём, файл просто ждал очереди. Если же большая часть времени уходит на ожидание ответа сервера, проблема в другом месте — там нужен разбор про то, куда исчезает секунда до первого байта, а не подсказки браузеру.
Шаг 4. Проверьте шрифты отдельно. Отфильтруйте Network по типу Font. Если запрос шрифта стартует позже, чем закончилась загрузка CSS, — это классическая цепочка, и она чинится preload’ом. Если шрифтов в списке четыре штуки и три из них — начертания, которых на первом экране нет, чинится это не preload’ом, а удалением лишних начертаний.
Шаг 5. Соберите список сторонних доменов. В колонке Domain видно всё чужое: счётчики, чаты, шрифты Google, CDN. Для двух-трёх самых ранних имеет смысл preconnect. Для остальных — не имеет.
| Что видите в Network | Что это значит | Что делать |
|---|---|---|
| Шрифт стартует после загрузки CSS | Цепочка HTML → CSS → шрифт | preload as="font" с crossorigin |
| Один и тот же шрифт в списке дважды | Забыт crossorigin у preload |
Добавить атрибут, вес страницы упадёт сразу |
| LCP-картинка с приоритетом Low | Браузер считает её незначимой до вёрстки | fetchpriority="high", снять loading="lazy" |
| Длинный Queueing у важного файла | Конкуренция за канал и соединения | Понизить приоритет второстепенных, убрать лишние preload |
| Долгий Waiting (TTFB) у HTML | Тормозит сервер или бэкенд | Подсказки не помогут, чинить кэш и хостинг |
| Скрипт счётчика раньше картинки героя | Синхронный сторонний скрипт | Перевести в defer/async, добавить preconnect к его домену |
Что стоит preload’ить почти всегда, а что почти никогда
Список короткий — и в этом весь смысл. Preload работает как право прохода без очереди: пока таких пропусков два-три, они дают преимущество; когда их пятнадцать, очередь просто восстанавливается в прежнем виде.
| Ресурс | Preload | Почему |
|---|---|---|
| Шрифт заголовка первого экрана (одно начертание, woff2) | Да, почти всегда | Прячется в CSS, находится поздно, вызывает скачок текста |
| LCP-картинка, заданная фоном в CSS | Да | Предзагрузчик её вообще не видит |
| LCP-картинка обычным тегом <img> в HTML | Нет, достаточно fetchpriority="high" |
Браузер и так найдёт её мгновенно, нужен приоритет |
| Критический CSS, подключённый файлом | Иногда | Обычно уже Highest; смысл есть, если он подключается из другого CSS через @import |
| Второе и третье начертание шрифта | Нет | На первом экране не участвуют, только отбирают канал |
| Все картинки каталога | Нет | Обесценивает приоритеты и раздувает трафик |
| Скрипты аналитики и чатов | Нет | Их место — в конце очереди, а не в начале |
| Иконочный шрифт | Почти никогда | Иконки редко формируют первый экран; лучше заменить на SVG |
| Видео-фон | Нет | Тяжёлый файл забьёт канал целиком |
Практический ориентир, от которого я отталкиваюсь: не больше трёх preload на страницу. Если хочется четвёртый — сначала докажите водопадом, что предыдущие три реально нужны. Обычно на этом этапе один из них отваливается.
Пять ошибок, которые превращают preload во вред
Ошибка первая: preload шрифта без crossorigin. Самая частая и самая обидная. Шрифты запрашиваются в анонимном CORS-режиме независимо от того, лежат они на вашем домене или на чужом. Если у тега preload нет атрибута crossorigin, режим запроса не совпадёт с тем, который потом использует CSS, и браузер посчитает это разными ресурсами. Файл скачается дважды: один раз впустую, второй — по делу. В Network это видно невооружённым глазом. Атрибут пишется без значения — просто crossorigin, этого достаточно.
Ошибка вторая: preload всего подряд. Обычно появляется после того, как кто-то прочитал, что preload ускоряет. Пятнадцать высокоприоритетных запросов конкурируют между собой и с HTML, канал делится, и в результате LCP становится хуже, чем был до оптимизации. Это тот случай, когда правка «по совету из интернета» измеряемо ухудшает метрику.
Ошибка третья: неверный или отсутствующий атрибут as. Он говорит браузеру, что за файл качается, — от этого зависят приоритет, заголовки запроса и CORS-режим. Без as браузер выдаёт предупреждение в консоли и качает файл с непонятным приоритетом; с неверным as — качает дважды. Значения простые: font, image, style, script, fetch, document.
Ошибка четвёртая: prefetch страниц, куда никто не переходит. Идея «предзагрузим все пункты меню» выглядит красиво и на десктопе почти незаметна. На мобильном интернете это чужой оплаченный трафик: посетитель качает пять страниц, открывает одну. Плюс мусор в логах сервера и, если prefetch задевает страницы со счётчиком, — искажённая статистика. Prefetch оправдан там, где следующий шаг предсказуем: карточка товара из каталога, вторая страница пагинации, страница оформления заказа из корзины. В остальных случаях — вред.
Ошибка пятая: preconnect к десяти доменам. Каждое соединение — это память, сокет и работа TLS. Браузеры ограничивают число подсказок, которые готовы отработать, и лишние тихо игнорируют, иногда вместе с нужными. Разумный предел — два-три домена, и только те, к которым обращение происходит в первые секунды. Отдельно: preconnect к домену шрифтов требует crossorigin, иначе соединение установится не то, которое потом понадобится, и всё придётся делать заново.
Бонусная ошибка. Preload ресурса, которого на странице нет. Если preload’нутый файл не использован в течение нескольких секунд, браузер пишет в консоль предупреждение «was preloaded but not used». Обычно это остаток от старого шаблона: шрифт заменили, а строчка в <head> осталась. Чистый убыток — трафик потрачен, пользы ноль. Проверяется за пять секунд: откройте консоль на главной и посмотрите на предупреждения.
Как это делается на WordPress
Руками — через хук wp_head в файле functions.php дочерней темы. Это самый предсказуемый способ: вы точно знаете, какие теги выводятся и на каких страницах.
add_action( 'wp_head', function () {
// шрифт первого экрана — только одно начертание
echo '<link rel="preload" href="' . get_stylesheet_directory_uri()
. '/fonts/inter-600.woff2" as="font" type="font/woff2" crossorigin>' . "\n";
// соединение с доменом счётчика
echo '<link rel="preconnect" href="https://mc.yandex.ru">' . "\n";
// LCP-картинка только на главной
if ( is_front_page() ) {
echo '<link rel="preload" href="/wp-content/uploads/hero.webp" as="image" fetchpriority="high">' . "\n";
}
}, 1 );Приоритет 1 в конце важен: подсказки должны попасть в начало <head>, а не под десяток мета-тегов и стилей плагинов. Обратите внимание на условие is_front_page(): preload картинки главной на всех страницах сайта — это тот самый вред, о котором шла речь выше.
Что делают плагины оптимизации. Практически все крупные кэш-плагины умеют автоматически расставлять preload шрифтов, preconnect к внешним доменам и «умный» prefetch ссылок при наведении курсора. Часть этих функций полезна, часть — вредна по умолчанию, и включаются они одним переключателем.
| Функция плагина | Что делает на самом деле | Мой вердикт |
|---|---|---|
| Автоматический preload шрифтов | Находит все @font-face и preload’ит каждый файл |
Ограничить вручную одним-двумя начертаниями |
| Preload ссылок при наведении (link prefetch) | Качает страницу, когда курсор над ссылкой | На десктопе допустимо, на мобильных отключать |
| Lazy load для всех картинок | Вешает loading="lazy" глобально |
Обязательно исключить первый экран, иначе LCP ломается |
| Автоматический preconnect | Добавляет соединение ко всем встреченным доменам | Оставить два-три, остальное убрать |
| Отложенная загрузка всего JS | Переводит все скрипты в отложенный режим | Проверять формы и корзину — часто ломается именно там |
Второй капкан — кэш. Правки в functions.php не появятся в HTML, пока не сброшен кэш страниц: вы правите, смотрите исходник и видите старую версию. Это классика, разобранная в материале про то, почему после правок вы видите старую страницу. Проверяйте результат обязательно на чистом URL, без служебных параметров в адресе, — параметры часто обходят кэш и показывают картину, которой у реальных посетителей нет.
Отдельная история — сайты на визуальных конструкторах. Там HTML генерируется билдером, шрифты подключаются его собственным механизмом, и вставить preload в нужное место головы бывает физически некуда. Механику этого я разбирал в статье про то, почему сайт на конструкторе грузится шесть секунд. Формат картинок тоже никуда не девается: preload тяжёлого JPEG на 900 КБ ускорит его появление, но общий вес останется — сначала переводите картинки в WebP и режьте размеры, об этом есть разбор про то, как картинки съедают скорость WordPress.
Когда это не нужно и не сработает
Ресурсные подсказки — инструмент точечный. Есть ситуации, где их внедрение не даст ничего, а времени и рисков добавит.
Лёгкая страница на системных шрифтах. Если сайт использует стек system-ui или -apple-system, шрифт вообще не скачивается — он уже в операционной системе. Preload’ить нечего. Если при этом на первом экране нет крупной картинки, а внешних доменов не подключено, вся тема preload/preconnect для такого сайта закрыта: браузеру просто нечего подсказывать.
Сайт с медленным сервером. Если TTFB держится на полутора секундах, спорить о приоритетах внутри страницы бессмысленно: браузер ещё не получил HTML, ему нечего расставлять по очереди. Сначала кэш и хостинг, потом подсказки. Порядок именно такой, и я на нём настаиваю — иначе получается оптимизация второго знака после запятой при проблеме в первом. Что вообще решает в скорости, я разбирал в материале о том, где прячется настоящая метрика скорости.
Страница, у которой LCP — обычный текст. Лендинг с крупным заголовком без картинки: LCP-элементом будет блок текста, и он зависит только от того, когда приедут CSS и шрифт. Preload картинок ничего не изменит, единственная осмысленная подсказка — шрифт.
Сайт целиком на одном домене без внешних ресурсов. Preconnect и dns-prefetch не нужны: соединение с вашим доменом уже установлено, оно использовалось для загрузки самого HTML.
Когда правки некуда вносить. Часть конструкторов не даёт доступа к <head>, часть тем перезаписывает шаблон при обновлении. Если правку негде закрепить, она проживёт до ближайшего апдейта. В таких случаях честнее заняться доработкой сайта на нормальной технической базе, чем чинить симптом на месяц.
Чего подсказки не делают вообще. Они не уменьшают вес файлов, не включают сжатие, не чинят рендер-блокирующий CSS, не ускоряют базу данных и не влияют на индексацию. Робот Яндекса не ранжирует сайт выше за наличие preload в коде — он оценивает результат, то есть скорость, которую видит живой посетитель. Связь между скоростью и позициями подробно разобрана в статье про то, как медленный сайт роняет позиции в Яндексе.
Коротко
Браузер расставляет приоритеты сам и в двух случаях ошибается предсказуемо: не видит шрифт, спрятанный в CSS, и не знает, какая картинка окажется на первом экране, пока не посчитает вёрстку.
preload — про текущую страницу, высокий приоритет, максимум два-три на страницу. prefetch — про следующую страницу, самый низкий приоритет, только для предсказуемого следующего шага. preconnect — соединение с чужим доменом заранее, два-три штуки. dns-prefetch — только резолв имени, эффект скромный. fetchpriority — регулятор для уже найденного ресурса в обе стороны.
Практический минимум для типового сайта: preload одного начертания шрифта первого экрана с crossorigin, fetchpriority="high" и снятый loading="lazy" на LCP-картинке, loading="lazy" на всё остальное, preconnect к домену счётчика. Этого достаточно в подавляющем большинстве случаев.
Главная ошибка — считать preload бесплатным. Он не бесплатный: канал один, и каждый пропуск без очереди отобран у кого-то другого. Проверять результат нужно только замером до и после, на дросселированном соединении, а не по ощущению «вроде быстрее стало».
Чеклист перед выкладкой
- Определён LCP-элемент через вкладку Performance с дросселированием Slow 4G, а не на глаз.
- В Network включена колонка Priority, зафиксировано время старта LCP-ресурса до правок.
- На странице не больше трёх тегов
rel="preload". - У каждого preload прописан корректный атрибут
as. - У preload шрифта стоит
crossorigin, в Network файл качается один раз, а не два. - Preload’ится одно начертание шрифта, а не весь набор.
- LCP-картинка без
loading="lazy"и сfetchpriority="high". - Все картинки ниже первого экрана — с
loading="lazy". - Preconnect стоит максимум к трём доменам, к домену шрифтов — с
crossorigin. - Prefetch либо отсутствует, либо ведёт на реально предсказуемый следующий шаг, и на мобильных отключён.
- В консоли браузера нет предупреждений «preloaded but not used».
- Кэш сброшен, проверка сделана на чистом URL без параметров.
- Проверены не только главная, но и страница услуги, карточка и статья блога — preload картинки главной не должен уезжать на весь сайт.
- Сделан повторный замер: LCP улучшился измеримо, а не «кажется, быстрее».
- Проверены формы и корзина — отложенная загрузка скриптов чаще всего ломает именно их.
Если после всех правок LCP всё равно держится выше двух с половиной секунд, дело не в подсказках браузеру, а в фундаменте: сервере, теме или количестве стороннего кода. Такое имеет смысл разбирать целиком — я смотрю это в рамках бесплатного аудита сайта, где видно и водопад загрузки, и то, что за ним стоит.
Увеличьте позиции и продажи вашего сайта
Профессиональное SEO-продвижение с гарантией результата. Выберите подходящую услугу:
Остались вопросы по продвижению?
Меня зовут Анатолий Кузнецов, я SEO-оптимизатор с 20-летним стажем. Разберу ваш сайт, отвечу на вопросы и подскажу, что улучшить для роста позиций в Яндексе и Google.
Связаться со мной →
Старт 
Стандарт 
Премиум 
Комментарии
Игорь
Поставил preload на шрифт, а в Network он всё равно грузится дважды. Вес страницы вырос. Что не так?
Анатолий Кузнецов автор
Почти наверняка забыт атрибут crossorigin. Шрифты всегда запрашиваются в анонимном CORS-режиме, и без этого атрибута браузер считает preload и запрос из CSS разными ресурсами. Пишется просто crossorigin, без значения. Добавьте — второй запрос исчезнет сразу.
Мария
Не поняла разницу между preload и prefetch. Оба же предзагрузка?
Анатолий Кузнецов автор
Разница в том, для какой страницы. preload — «нужно здесь и сейчас, качай в первую очередь». prefetch — «пригодится, если человек перейдёт дальше, качай, когда будет свободно». Если поставить prefetch на шрифт текущей страницы, он начнёт качаться уже после отрисовки, то есть не поможет вообще.
Дмитрий
Спорно про «не больше трёх preload». У меня их девять, и PageSpeed показывает 92. Никакой деградации не вижу.
Анатолий Кузнецов автор
Возможный вариант — у вас широкий канал в лаборатории и лёгкие файлы, тогда конкуренции просто не возникает. Проверьте на дросселировании Slow 4G и уберите четыре preload из девяти: если LCP не изменится, значит эти четыре не работали и раньше. Три — не догма, а ориентир, чтобы каждый preload приходилось обосновывать.
Сергей
Кэш-плагин сам расставил preload на шесть файлов шрифтов. Оставлять или лезть руками?
Ольга
Спасибо, наконец-то стало понятно, зачем нужна колонка Priority. Уточню: у меня LCP-картинка идёт фоном в CSS. Ей нужен preload или хватит fetchpriority?
Анатолий Кузнецов автор
Фону нужен именно preload. fetchpriority — атрибут элемента, а у фона из CSS элемента с адресом картинки нет, вешать атрибут не на что. Ставьте link rel=»preload» as=»image» — это как раз тот случай, ради которого preload картинок и придуман.
Антон
А dns-prefetch вообще нужен, если есть preconnect? Или ставить оба на всякий случай?
Наталья
Включила prefetch по наведению на ссылки. По статистике хостинга запросов стало сильно больше, а конверсия та же.
Павел
Интернет-магазин, 40 товаров в категории. Есть смысл prefetch’ить карточки?
Анатолий Кузнецов автор
Сорок карточек — нет, это гарантированный слив мобильного трафика. Осмысленно предзагружать один-два самых кликаемых товара или следующую страницу пагинации, если люди реально листают. Смотрите в Метрике карту кликов: если у категории нет явных лидеров, prefetch здесь не нужен.
Роман
Убрал lazy load с картинки героя — LCP улучшился на глазах. Год работал с этой настройкой и не знал.
Виктория
В консоли висит предупреждение «preloaded but not used», но страница работает нормально. Можно игнорировать?
Максим
Тема на системных шрифтах, картинок на первом экране нет. Получается, вся эта история мимо меня?
Елена
Не соглашусь, что preconnect лучше ограничивать тремя доменами. У нас подключено семь внешних сервисов, и все нужны.