Браузер сам розставляє пріоритети завантаження — і в більшості сценаріїв справляється чудово. Але реальний продакшен вимагає більш тонкого керування. Коли на сторінці інтернет-магазину карусель товарів, браузер не знає, що перше зображення — 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 робочих днів. Вартість розраховується індивідуально після аналізу вашого проєкту. Отримайте консультацію — ми підкажемо, які покращення дадуть максимальний ефект.