ПаветтаPreload — атрибут <link rel="preload">, который запускает скачивание ресурса как можно раньше. Используют для критичных шрифтов, главной картинки hero-блока (LCP), важного JS.
Преимущество — ресурс уже в кеше браузера к моменту, когда HTML-парсер до него доходит. Опасность — злоупотреблять им: каждый preload отжирает полосу у других ресурсов, может ухудшить общую загрузку.
<!-- LCP-картинка — загружаем приоритетно --> <link rel="preload" as="image" href="/hero-1200.webp"> <!-- Шрифт — без preload UI «дёрнется» --> <link rel="preload" as="font" href="/font.woff2" crossorigin>
<link rel="preload" href="hero.webp" as="image"> — главная картинка hero готова к моменту рендера.
Самая частая ошибка — preload шрифта без атрибута crossorigin. Шрифты всегда грузятся в CORS-режиме, поэтому браузер делает два запроса: один по preload без crossorigin, второй уже из CSS — и предзагрузка превращается в двойную трату трафика вместо ускорения. Правильно: . Проверяется в DevTools → Network: если файл скачался дважды, в консоли висит предупреждение "resource was preloaded but not used".
Для LCP-картинки preload часто избыточен — современнее повесить на атрибут fetchpriority="high", он поднимает приоритет без отдельного тега и работает с responsive-источниками srcset. Preload же незаменим, когда критичный ресурс зашит вглубь: шрифт внутри @font-face в подключённом CSS или фоновая картинка в background-image, до которых парсер дойдёт поздно. И Яндекс, и Google в PageSpeed/Lighthouse явно советуют preload именно для таких ресурсов в блоке "Предзагрузка ключевых запросов" — лишний preload, наоборот, помечается как "не использован в течение нескольких секунд".
Браузер качает ресурс сразу при разборе head, не дожидаясь, пока до него дойдёт CSS или JS.
Каждый preload конкурирует за канал: лишние теги тормозят реально нужные ресурсы и LCP.
Шрифт первого экрана, hero-картинка, ключевой скрипт — и обязательно crossorigin для шрифтов.
На лендинге заголовок прыгал при загрузке из-за позднего шрифта. Добавили — CLS упал с 0.18 до 0.02, а LCP в Lighthouse улучшился на 0.4 с.
Приём помогает ровно там, где ресурс нужен немедленно и браузер узнаёт о нём поздно: главная картинка первого экрана, шрифт заголовка, критичный скрипт. Каждый лишний приоритетный ресурс отбирает канал у остальных, поэтому список держат коротким: два-три элемента на страницу.
Для изображений сегодня чаще используют атрибут приоритета загрузки прямо у картинки: он проще и не требует дублирования адреса в шапке страницы. Ошибка, которая встречается постоянно, — предзагрузка шрифта, который на странице не используется, или картинки, скрытой на мобильных: канал тратится впустую, а показатели скорости ухудшаются.
Частые вопросы
Что имеет смысл загружать заранее?
Главную картинку первого экрана, шрифт заголовка и критичный скрипт, без которого страница не отрисуется. Список держат коротким: два-три ресурса, иначе они начинают мешать друг другу.
Чем отличается атрибут приоритета у картинки?
Он проставляется прямо у изображения и говорит браузеру грузить его первым, без дублирования адреса в шапке страницы. Для главной картинки это самый простой способ ускорить отрисовку крупного элемента.
Может ли предзагрузка навредить?
Да, если грузить лишнее: неиспользуемый шрифт, картинку, скрытую на мобильных, или десяток файлов сразу. Канал отдаётся приоритетным ресурсам, и всё остальное начинает ждать.
Как проверить, что приём сработал?
По вкладке сети в инструментах разработчика: нужный файл должен начинать загружаться в первых строках. Итоговый эффект смотрят по времени отрисовки крупного элемента на реальных пользователях.