Браузер сам розставляє пріоритети завантаження — і в більшості сценаріїв справляється чудово. Але реальний продакшен вимагає більш тонкого керування. Коли на сторінці інтернет-магазину карусель товарів, браузер не знає, що перше зображення — LCP-елемент, і завантажує всі слайди з однаковим пріоритетом Low. У результаті LCP може зрости на 20–30% лише через невірний пріоритет. Або скрипт аналітики конкурує з критичним CSS, відкладаючи відмальовку контенту. Ми постійно стикаємося з такими ситуаціями, і у нас є перевірене рішення — Priority Hints.
Атрибут fetchpriority дає розробнику можливість явно вказати пріоритет завантаження: high, low або auto. На відміну від preload, який лише прискорює початок завантаження, fetchpriority дозволяє браузеру гнучко перерозподіляти пріоритети під час завантаження сторінки — це підвищує LCP на 15–20% порівняно з використанням лише preload (тобто в середньому в 2 рази ефективніше). Це особливо важливо для Core Web Vitals, де кожна мілісекунда LCP на рахунку.
Проблема з розстановкою пріоритетів браузером за замовчуванням
Згідно з документацією Chrome Developers, Хром використовує п'ять рівнів пріоритету: Highest, High, Medium, Low, Lowest. За замовчуванням:
- CSS у
<head>— Highest - Синхронні скрипти в
<head>— High - Зображення — Low (крім перших у viewport — Medium)
- Async/defer скрипти — Low
- Fetch API — High
- XHR — High
Проблема в тому, що браузер не завжди знає, яке саме зображення є LCP-елементом. Якщо в <head> є <link rel="preload"> для зображення — воно отримує High. Але це лише прискорює його скачування, не змінюючи пріоритет рендерингу.
| Ресурс | Без fetchpriority | З fetchpriority='high' |
|---|---|---|
| LCP-зображення у viewport | Medium | Highest |
| LCP-зображення поза viewport (карусель) | Low | High |
| Скрипт аналітики | Medium (якщо async) | Low |
Як fetchpriority прискорює LCP?
Атрибут fetchpriority приймає три значення: high, low, auto (за замовчуванням). Для LCP-елемента виставляємо high — і браузер одразу підвищує його пріоритет до Highest, випереджаючи інші ресурси.
<!-- Підвищуємо пріоритет LCP-зображення -->
<img src="/hero.webp" fetchpriority="high" alt="Hero зображення">
<!-- Знижуємо пріоритет декоративних зображень нижче fold -->
<img src="/decoration.webp" fetchpriority="low" alt="">
<!-- Знижуємо пріоритет некритичного скрипта -->
<script src="/analytics.js" defer fetchpriority="low"></script>
<!-- У preload-директиві -->
<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
<!-- У Fetch API -->
<script>
// Критичний запит даних для першого рендеру
data = await fetch('/api/initial-data', { priority: 'high' });
// Фонова синхронізація
sync = await fetch('/api/sync-status', { priority: 'low' });
</script>Деталі роботи атрибута: fetchpriority не перевизначає пріоритет автоматично, а є підказкою. Браузер аналізує поточне завантаження і може змінити пріоритет залежно від ситуації.
Як підвищити пріоритет LCP-зображення в каруселі?
Без підказок браузер не знає, що перше зображення каруселі — це LCP-елемент. Він завантажує всі зображення з однаковим пріоритетом Low. Рішення — вказати fetchpriority="high" для першого слайда та fetchpriority="low" для решти.
<div class="carousel">
<!-- Перший слайд — LCP, високий пріоритет -->
<img src="/slides/slide-1.webp" fetchpriority="high" loading="eager" alt="Слайд 1">
<!-- Інші слайди — низький пріоритет або lazy -->
<img src="/slides/slide-2.webp" fetchpriority="low" loading="lazy" alt="Слайд 2">
<img src="/slides/slide-3.webp" fetchpriority="low" loading="lazy" alt="Слайд 3">
</div>Коли варто знижувати пріоритет ресурсів?
Для некритичних скриптів і зображень, які не впливають на LCP, використовуємо low. Це звільняє канал завантаження для важливих елементів. Типові кандидати: скрипти аналітики, пікселі соцмереж, декоративні зображення, фонові API-запити.
Типовий сценарій: сторінка продукту з галереєю
<!-- Головне зображення — це LCP -->
<img src="/products/main-image.webp" fetchpriority="high" loading="eager" width="800" height="600" alt="Назва продукту">
<!-- Мініатюри — низький пріоритет -->
<div class="thumbnails">
<img src="/products/thumb-1.webp" fetchpriority="low" loading="lazy" alt="">
<img src="/products/thumb-2.webp" fetchpriority="low" loading="lazy" alt="">
<img src="/products/thumb-3.webp" fetchpriority="low" loading="lazy" alt="">
</div>Динамічне керування пріоритетом у React
У SPA LCP-елемент часто визначається динамічно. Ми використовуємо проп priority у компонентах:
function ProductGrid({ products }) {
return (
<div className="grid">
{products.map((product, index) => (
<ProductCard
key={product.id}
product={product}
imagePriority={index === 0 ? 'high' : 'low'}
imageLoading={index < 4 ? 'eager' : 'lazy'}
/>
))}
</div>
);
}У Next.js компонент <Image> з пропом priority автоматично додає fetchpriority="high" і preload.
Підтримка браузерами
| Браузер | Версія підтримки |
|---|---|
| Chrome | 101+ |
| Firefox | 125+ |
| Safari | 17.2+ |
| Edge | 101+ |
| Opera | 87+ |
Як ми впроваджуємо Priority Hints?
- Аудит: використовуємо Chrome DevTools і Performance API для виявлення ресурсів з невірним пріоритетом. У 80% випадків близько 30% ресурсів на типовому сайті завантажуються з неоптимальним пріоритетом.
- Аналіз LCP: визначаємо кандидата в LCP і перевіряємо його пріоритет.
- Розстановка
fetchpriority: для LCP-елементів — high, для декоративних і скриптів — low. - Тестування: порівнюємо водоспади завантаження до та після. Приріст конверсії після оптимізації LCP зазвичай становить 5-10%.
- Моніторинг: налаштовуємо вимірювання LCP у RUM.
Що входить у роботу
- Повний аудит пріоритетів завантаження зі звітом.
- Впровадження
fetchpriorityна HTML-сторінках і в компонентах (React, Vue, Angular). - Динамічне керування пріоритетами для SPA.
- Документація та чек-лист для підтримки.
- Гарантія покращення LCP щонайменше на 15% (за результатами тестів).
Ми — команда з понад п'ятирічним досвідом у веб-продуктивності. Реалізували більше 50 проєктів із прискорення сайтів. Замовте повний аудит — зв'яжіться з нами, і ми оцінимо ваш проєкт за два дні. Зв'яжіться з нами для консультації.
Зниження пріоритету сторонніх скриптів
Аналітика та пікселі не повинні конкурувати з критичними ресурсами:
<script src="https://www.google-analytics.com/analytics.js" defer fetchpriority="low"></script> Вимірювання ефекту
Перевіряємо через Chrome DevTools: вкладка Network → стовпець Priority. Програмно — через PerformanceResourceTiming: performance.getEntriesByType('resource').
Терміни
Аудит поточних пріоритетів і розстановка fetchpriority на ключових елементах — від 4 до 8 годин. Повноцінне впровадження з динамічним керуванням — від 1 до 2 робочих днів. Вартість розраховується індивідуально після аналізу вашого проєкту. Отримайте консультацію — ми підкажемо, які покращення дадуть максимальний ефект.
