Браузер сам розставляє пріоритети завантаження — і в більшості сценаріїв справляється чудово. Але реальний продакшен вимагає більш тонкого керування. Коли на сторінці інтернет-магазину карусель товарів, браузер не знає, що перше зображення — 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 робочих днів. Вартість розраховується індивідуально після аналізу вашого проєкту. Отримайте консультацію — ми підкажемо, які покращення дадуть максимальний ефект.
Чому Core Web Vitals критичні для технічного SEO
PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.
Як досягти хороших показників Core Web Vitals?
Core Web Vitals: що реально впливає на позиції
Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).
LCP: чому 8 секунд — це не проблема зображення
LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.
Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.
Рішення по кроках:
- Переносимо hero з CSS background в
<img> з fetchpriority="high" та loading="eager"
- Конвертуємо в WebP, додаємо
srcset: 800w для мобільних, 1400w для десктопа
-
<link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
- Прибираємо всі render-blocking скрипти вище hero через
defer
Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.
Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.
CLS: зсуви, які дратують користувача і Google
CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.
Джерела CLS:
- Зображення без заданих розмірів.
<img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
- Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через
min-height або завантажувати до рендеру основного контенту.
- Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування.
font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
- Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.
| Типовий сценарій |
CLS до |
CLS після |
Основний фікс |
Банер знижок без min-height |
0.42 |
0.02 |
min-height: 300px |
| Картинки в статтях без атрибутів |
0.18 |
0.01 |
width/height + aspect-ratio |
| Віджет чату, що завантажується через 3с |
0.35 |
0.05 |
position: fixed із зарезервованим відступом |
INP: чому інтерфейс «зависає» на 500ms
INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.
Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.
Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:
- Безперервна обробка великого списку без
requestIdleCallback або requestAnimationFrame
- Важкі event listeners без
debounce/throttle
- Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
- Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread
Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.
Schema.org: розмітка, яку читають роботи
Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.
Типи розмітки за сценаріями:
-
E-commerce:
Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
-
Статті та блог:
Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
-
Локальний бізнес:
LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
-
FAQ:
FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.
Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.
Як проводити технічний SEO-аудит
Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.
Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.
JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.
Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.
Типові помилки при впровадженні Schema.org
- Вказано
price без priceCurrency — розмітка ігнорується.
-
ratingValue без reviewCount — у видачі не показується.
- Кілька
Product на одній сторінці без @type: ItemList — Google бере тільки перший.
- JSON-LD в GTM — Google не завжди бачить динамічну розмітку, краще серверний рендеринг.
| Етап роботи |
Що входить |
Термін |
| Аудит |
Сканування, аналіз Core Web Vitals, аудит Schema, звіт з пріоритетами |
1–2 тижні |
| Оптимізація одного шаблону |
LCP, CLS, INP, впровадження SSR/SSG, налаштування preload |
2–4 тижні |
| Повна технічна оптимізація |
Всі шаблони, code splitting, Web Workers, моніторинг в CI |
4–10 тижнів |
| Впровадження Schema.org |
JSON-LD генерація, валідація, тестування rich snippets |
1–3 тижні |
Що входить в роботу
- Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
- Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
- Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
- Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.
Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.
