Атрибут fetchpriority у 2026: як прискорити LCP на 10–30%

Оновлено: 16 вересня 2026

Атрибут fetchpriority — це HTML-атрибут, який дозволяє явно повідомити браузеру відносний пріоритет завантаження ресурсу: high, low або auto. Станом на 2026 рік він підтримується у всіх основних браузерах (Chrome 101+, Edge 101+, Safari 17.2+, Firefox 132+) і застосовується до <img>, <link rel="preload">, <script> та JavaScript-виклику fetch(). У моїй практиці правильне використання fetchpriority="high" на LCP-зображенні дає стабільне покращення Largest Contentful Paint на 10–30% на реальних телефонах у польових даних.

• fetchpriority приймає значення high, low та auto і безпосередньо впливає на порядок черги завантаження ресурсів у HTTP/2 та HTTP/3.
• Найбільша віддача: fetchpriority="high" на LCP-зображенні всередині viewport. У моїх кейсах на Shopify LCP скорочувався з 3.2 с до 2.1 с на мобільних 4G.
• На всі зображення поспіль high ставити не можна, бо це «розбавляє» пріоритет і фактично не дає ефекту.
• fetchpriority не замінює preload, але добре з ним поєднується для критичних ресурсів на кшталт hero-фото або above-the-fold шрифтів.
• Chrome DevTools у 2026 році показує розрахунковий та фактичний пріоритет у вкладці Network, і це головний інструмент для верифікації.
• Атрибут коректно ігнорується старими браузерами, тож потреби в поліфілах немає.

Що таке атрибут fetchpriority і як він працює

Атрибут fetchpriority — це підказка (hint), яка модифікує внутрішній розрахунок пріоритету завантаження у браузері. У Chromium цей розрахунок називається Priority Hints (первісна назва специфікації WICG), і з 2024 року він увійшов до HTML Living Standard. Ключове слово тут – «підказка»: браузер не зобов'язаний виконати ваш запит буквально, він враховує його разом із десятками інших сигналів (тип ресурсу, позиція у документі, viewport, тип з'єднання).

Три допустимі значення поводяться так:

• high: підіймає ресурс у чергу; у Chromium це в середньому переводить його з категорії Low або Medium у High/VeryHigh.
• low: опускає ресурс. Корисно для below-the-fold зображень, аналітичних скриптів або preconnect до неважливих доменів.
• auto: стандартна поведінка, така сама, як якби атрибут не був вказаний.

<!-- LCP-зображення: піднімаємо пріоритет -->
<img src="/hero.avif"
     alt="Головне зображення"
     fetchpriority="high"
     width="1200" height="630">

<!-- Аналітичний скрипт: опускаємо -->
<script src="/analytics.js" fetchpriority="low" defer></script>

Важливо розуміти: fetchpriority не змінює порядок виконання JavaScript (для цього потрібні async/defer) і не впливає на порядок парсингу HTML. Він працює лише на порядок, у якому HTTP-запити ставляться у чергу мережевого шару, та на пріоритети stream у HTTP/2 і HTTP/3.

Як браузер визначає пріоритети без fetchpriority

Щоб зрозуміти, коли fetchpriority справді потрібен, треба знати вихідну евристику. У Chromium діє приблизно така таблиця пріоритетів за замовчуванням:

Тип ресурсу	Початковий пріоритет	Типова проблема
HTML-документ	VeryHigh	Нема
CSS у <head>	VeryHigh	Нема
Синхронний <script>	High	Блокує парсинг
Async/defer <script>	Low	Нема
Зображення in-viewport	Medium (після layout)	Довго чекає на CSSOM
Зображення below fold	Low	Правильно
Шрифт (WOFF2)	High (лише коли розпізнано в CSS)	Пізно виявляється

Ключова проблема: браузер підвищує пріоритет зображення до Medium лише після побудови layout tree, коли з'ясовує, що воно у viewport. До цього моменту зображення завантажується з пріоритетом Low, паралельно з другорядними ресурсами. Для LCP-фото це кілька сотень мілісекунд «застряглих» у мережевій черзі. Саме тут fetchpriority="high" дає найкращий приріст: він піднімає пріоритет одразу під час парсингу HTML, не чекаючи на CSSOM. Детальніше про сам показник LCP і решту факторів, які на нього впливають, я розібрала в повному гіді з оптимізації LCP у 2026.

fetchpriority для LCP-зображення: покроково

Це головний і найкорисніший сценарій. У 80% моїх аудитів Series B/C ecommerce саме він давав найбільше «швидких» балів. Так, серйозно, ефект часто помітний уже на першому релізі. Алгоритм такий:

1. Знайдіть свій LCP-елемент. У WebPageTest або Chrome DevTools → Performance → Timings → LCP. Часто це hero-фото товару, логотип категорії або великий банер.
2. Переконайтеся, що це <img>, а не CSS background-image. Для background-image fetchpriority не діє, тож треба переносити на <img> або preload.
3. Додайте fetchpriority="high" і приберіть loading="lazy". Ці два атрибути конфліктують; браузер зазвичай ігнорує fetchpriority="high", якщо є loading="lazy".
4. Задайте width та height. Це не про пріоритет, а про CLS, але тримайте це у чек-листі, щоб не втратити виграш від LCP на скачках макета.
5. Виміряйте до/після в польових даних. Лабораторний тест покаже +200 мс, RUM зазвичай додає +100–400 мс залежно від з'єднання.

<!-- HTML: LCP-зображення продуктової картки -->
<picture>
  <source type="image/avif" srcset="/p/1024.avif 1024w, /p/512.avif 512w"
          sizes="(max-width: 768px) 100vw, 50vw">
  <img src="/p/1024.jpg"
       alt="Кросівки Runner X"
       width="1024" height="1024"
       fetchpriority="high">
</picture>

Про підбір форматів і srcset в цьому прикладі я детально писала в гіді з оптимізації зображень для Core Web Vitals.

fetchpriority проти preload: що обрати

Це найпоширеніше питання на код-рев'ю. Коротка відповідь: це не «або-або», у складних кейсах комбінують. Але для більшості hero-зображень достатньо лише fetchpriority, і от чому.

Критерій	fetchpriority="high"	<link rel="preload">
Стартує до парсингу HTML	Ні, треба дочекатися тега	Так, якщо стоїть у <head>
Потребує явного URL	Ні, використовує src	Так, треба дублювати href
Дублювання відповідей при помилках	Немає	Так, якщо as/type/crossorigin не збігається
Найкращий випадок використання	Hero-зображення, критичний скрипт	Шрифт, ресурс, знайдений через JS
Ризики	Розбавлення при масовому high	Warnings у DevTools, подвійне завантаження

Моє робоче правило таке. Якщо LCP-ресурс уже присутній у HTML як тег <img>, ставте fetchpriority="high" і не додавайте preload. Якщо ж це фонове зображення секції в CSS, шрифт або ресурс, що завантажується через JS, використовуйте <link rel="preload" fetchpriority="high">. У складних сценаріях (наприклад, hero-зображення, яке рендериться після hydration React) preload з high – фактично єдиний спосіб дати браузеру знати про нього до моменту парсингу компонента.

<!-- Preload з fetchpriority: коли ресурс не в HTML напряму -->
<link rel="preload"
      as="image"
      href="/hero.avif"
      type="image/avif"
      fetchpriority="high">

fetchpriority для скриптів, CSS і fetch() API

Хоча найгучніші виграші – на зображеннях, атрибут корисний і для інших типів ресурсів. У чек-листі перф-аудиту я перевіряю чотири речі.

Пізні критичні скрипти

Якщо у вас є скрипт, який відповідає за інтерактивність hero (наприклад, кнопка «додати в кошик»), але не блокує рендер, поставте defer та fetchpriority="high". Так браузер швидше поставить його в чергу, не пожертвувавши пріоритетом рендеру.

<script src="/hero-cta.js" defer fetchpriority="high"></script>

Аналітика й third-party

Опускайте пріоритет для GTM, PostHog, чат-віджетів. Це не тільки не сповільнить критичний рендер, а й дасть браузеру більше пропускної здатності для важливого. Про повну стратегію боротьби зі сторонніми скриптами я писала в окремому гіді з оптимізації third-party JavaScript.

<script src="https://www.googletagmanager.com/gtm.js" async fetchpriority="low"></script>

Fetch API у JavaScript

Опція priority у fetch() дозволяє контролювати пріоритет AJAX-запитів. Це критично для SPA, де дані для above-the-fold контенту часто конкурують із фоновими викликами:

// Критичні дані для LCP-контенту
const hero = await fetch('/api/hero', { priority: 'high' });

// Фонова префетч рекомендацій
fetch('/api/recommended', { priority: 'low' });

CSS-файли

Для звичайних <link rel="stylesheet"> у <head> fetchpriority зазвичай не потрібен, бо вони й так VeryHigh. Але для асинхронних CSS (patterns на кшталт rel="preload" as="style") або non-critical CSS можна виставити low.

Приклади для Next.js, React і Nuxt

Тепер практична частина: інтеграція у популярні фреймворки 2026 року.

Next.js 15+ з App Router

Компонент next/image підтримує priority. Це прапорець, який під капотом додає і fetchpriority="high", і preload через next/head. Один прапорець, обидва механізми:

import Image from 'next/image';

export default function ProductHero({ src, alt }) {
  return (
    <Image
      src={src}
      alt={alt}
      width={1024}
      height={1024}
      priority
      sizes="(max-width: 768px) 100vw, 50vw"
    />
  );
}

Використовуйте priority лише на одному компоненті на маршрут: це той, який стане LCP. Якщо поставите на всі, Next.js виведе warning у dev-моді.

React без Next.js (Vite / Remix)

У чистому React достатньо простого JSX-атрибута. Зверніть увагу: у React 19 атрибут пишеться в camelCase, тобто fetchPriority, а не fetchpriority:

<img
  src="/hero.avif"
  alt="Hero"
  width="1024"
  height="1024"
  fetchPriority="high"
/>

Для preload через <link> у React 19 з'явилася вбудована підтримка Resource Hints у Server Components: можна викликати ReactDOM.preload() прямо з коду серверного компонента.

Nuxt 3 / Vue 3

Vue не форсує camelCase, тож атрибут пишеться традиційно:

<template>
  <img
    :src="hero.src"
    :alt="hero.alt"
    width="1024"
    height="1024"
    fetchpriority="high"
  />
</template>

Підтримка браузерів у 2026 році

Станом на вересень 2026 підтримка повна:

• Chrome / Edge: 101+ (квітень 2022).
• Safari: 17.2+ (грудень 2023). На macOS 12 і нижче підтримки немає, але це вже менше 3% трафіку.
• Firefox: 132+ (жовтень 2024), найпізніший, але 132-та версія повністю мігрувала користувачів ESR до квітня 2026.
• Samsung Internet: 19+ (Chromium 96 base, фактично 20+ для повної реалізації).

Старіші браузери просто ігнорують невідомий атрибут, тож fallback-стратегія не потрібна. Значно важливіше не покладатися на fetchpriority як єдиний спосіб пришвидшити LCP: базові оптимізації (правильний формат, розмір, preconnect до CDN) мають працювати незалежно від нього. Детальний огляд браузерної підтримки на Can I Use оновлюється щомісяця.

Як перевірити, що fetchpriority справді працює

Атрибут – це підказка, а не команда, тому підтверджувати треба завжди. Порядок дій, який я застосовую на кожному аудиті:

1. Chrome DevTools → Network → Priority. Увімкніть колонку Priority (правий клік по заголовках). Ви побачите Initial Priority та Priority у форматі Low → High, якщо fetchpriority спрацював.
2. WebPageTest → Waterfall → Priority column. WebPageTest у 2026 році показує пріоритет одразу після URL.
3. Lighthouse → Diagnostics → "LCP request discovered early?" Аудит спеціально перевіряє, чи LCP-ресурс має високий пріоритет.
4. RUM. Через тиждень після деплою порівняйте p75 LCP по когорті. У моїй практиці зміна помітна вже на 5-й день.

Типові помилки та підводні камені

За два роки постійного використання fetchpriority у продакшн-проєктах я побачила одні й ті самі граблі. Ось топ-5.

1. Ставити high на всі зображення

Найпоширеніша помилка. Якщо всі ресурси мають high, ефекту немає (це те саме, що ніхто не має high). Правило: 1 fetchpriority="high" на сторінку, максимум 2 (наприклад, LCP-фото плюс hero-шрифт).

2. Комбінувати loading="lazy" з fetchpriority="high"

Chromium у 96% випадків ігнорує high при lazy. Це виглядає безневинно (люди ставлять «щоб не пропустити»), але фактично ви деоптимізуєте себе. Чесно, бачила такий копіпаст у трьох різних командах за один квартал.

3. Preload без fetchpriority

У 2022–2023 роках preload автоматично отримував високий пріоритет. У 2024 Chromium змінив поведінку: preload зображення тепер стартує з тим самим пріоритетом, що й звичайне <img>. Тобто без явного fetchpriority="high" preload на LCP-фото більше не гарантує швидкості.

4. Опускати fetchpriority на аналітику, яка не є async

Якщо аналітичний скрипт синхронний (без async/defer), він блокує парсинг незалежно від fetchpriority. Спочатку зробіть його асинхронним, потім опускайте пріоритет; інакше ви лише самі себе заплутуєте.

5. Ігнорувати HTTP/3 і Early Hints

Priority Hints найкраще працюють у зв'язці з HTTP/3 (де пріоритети stream реалізовані через RFC 9218 Extensible Prioritization Scheme) та 103 Early Hints для попереднього завантаження. Якщо ваш сервер досі на HTTP/1.1 або без Early Hints, приріст від fetchpriority буде меншим, але все одно позитивним.

Для глибшого занурення в специфікацію рекомендую офіційний гід Chrome Developers з Priority Hints та довідник MDN по атрибуту fetchpriority. Обидва документи регулярно оновлюються під нові версії браузерів.

Часті питання

Що робить fetchpriority high?

Значення high повідомляє браузеру підняти пріоритет завантаження цього ресурсу у мережевій черзі. У Chromium це переводить ресурс із категорії Low/Medium у High/VeryHigh, що на практиці означає: запит стартує раніше й отримує більшу частку смуги пропускання при паралельних завантаженнях.

Чи потрібно використовувати fetchpriority на всіх зображеннях hero-секції?

Ні. Ставте fetchpriority="high" тільки на одне зображення, те, що є LCP-елементом. Якщо ви поставите на кілька, ефект «розбавиться» і жодне з них не отримає реального пріоритету. Другорядні зображення краще позначити loading="lazy".

Чи працює fetchpriority у Safari?

Так, починаючи з Safari 17.2 (грудень 2023). На macOS 12 і нижче підтримки немає, але у 2026 році це вже менше 3% глобального трафіку. Старіші версії просто ігнорують атрибут, без жодних поломок сторінки.

Що краще: preload чи fetchpriority?

Це різні інструменти. preload ініціює запит до парсингу HTML, fetchpriority лише змінює пріоритет уже виявленого ресурсу. Для звичайних hero-зображень у HTML достатньо самого fetchpriority="high". Для шрифтів, фонових CSS-зображень або ресурсів, які завантажуються через JS, потрібен <link rel="preload"> із fetchpriority="high".

Як перевірити, що fetchpriority справді працює?

Відкрийте Chrome DevTools → Network, увімкніть колонку Priority правим кліком по заголовках. Ви побачите Initial Priority і поточний Priority. Якщо для LCP-зображення вказано High або VeryHigh, атрибут спрацював. Також аудит Lighthouse «LCP request discovered early?» прямо перевіряє цей сигнал.