Загружаем публикацию…
Мы используем cookies для работы сайта и аналитики посещаемости. Подробнее в Политике обработки данных и Правилах.
О Вебе | ex. Frontender’s notes
IT и технологии · 16 июня 2026 г.
Fetch Priority в production: как управлять LCP-ресурсами без starvation и регрессий загрузки fetchpriority — это не «ускоритель сайта», а hint для браузера: какой ресурс стоит поднять или опустить в очереди загрузки. В production он полезен прежде всего для LCP-ресурсов: hero image, poster, иногда preload шрифта/критичного ассета. Главная ошибка — ставить fetchpriority="high" на всё важное. Если всё high, то high не значит ничего. Более того, можно получить starvation: hero начнёт конкурировать с preload’ами, скриптами, шрифтами, картинками карусели и ухудшит загрузку остального критичного пути. Практическое правило: 1. Поднимать только реальный LCP-кандидат Один viewport, один главный ресурс. <img src="/hero.avif" srcset="/hero-768.avif 768w, /hero-1440.avif 1440w" sizes="100vw" width="1440" height="720" fetchpriority="high" decoding="async" alt="" > 2. Если LCP-ресурс поздно обнаруживается — используйте preload + fetchpriority Например, hero приходит из CSS background или рендерится поздно после JS. Лучше сделать ресурс discoverable раньше: <link rel="preload" as="image" href="/hero.avif" fetchpriority="high" /> Но не дублируйте бездумно: href, imagesrcset, imagesizes, type должны совпадать с реальным ресурсом, иначе можно скачать не то или скачать дважды. 3. Не повышайте приоритет всем картинкам above the fold Типичный анти-паттерн: <img src="/slide-1.avif" fetchpriority="high"> <img src="/slide-2.avif" fetchpriority="high"> <img src="/slide-3.avif" fetchpriority="high"> Если виден только первый слайд — high должен быть только у него. Остальные: loading="lazy" или обычный auto. 4. Опускайте второстепенное, но аккуратно fetchpriority="low" может быть полезен для изображений, которые браузер обнаруживает рано, но которые не нужны для первого экрана: декоративные картинки, hidden-состояния, неактивные слайды. <img src="/promo-secondary.avif" fetchpriority="low" loading="lazy" alt=""> Но не ставьте low на ресурсы, которые могут стать LCP на других брейкпоинтах. Иначе на mobile можно случайно замедлить именно главный ресурс. 5. Не лечите fetchpriority то, что сломано архитектурно Если LCP плохой из-за: — огромного JS до первого рендера; — CSS, блокирующего отображение; — неверного sizes; — слишком тяжёлого hero; — позднего SSR/streaming; — client-only рендера над hero; то fetchpriority="high" даст ограниченный эффект. Он управляет очередью загрузки, но не чинит сам критический путь. Production-чеклист: — Найдите реальный LCP через field data, а не только Lighthouse. — Проверьте разные viewport’ы: mobile/desktop могут иметь разные LCP. — Ставьте high максимум на 1–2 ресурса первого экрана. — Не повышайте приоритет preload’ов «на всякий случай». — Проверяйте waterfall: не вытеснили ли вы CSS, font или critical JS. — Сравнивайте p75 LCP до/после, а не один локальный прогон. — Раскатывайте по маршрутам: главная, листинг, карточка могут требовать разных hints. Хороший fetchpriority в production — это не «сделать быстрее всё». Это явно сказать браузеру: «вот этот ресурс сейчас определяет LCP, остальные пусть не мешают».
