Speculation Rules API у 2026: миттєві переходи між сторінками з prerender і prefetch

Уявіть: користувач клікає на посилання — і нова сторінка з'являється миттєво. Без білого екрана, без спінера, без жодного очікування TTFB. Це не магія сервісних воркерів і не SPA-фреймворк (ні React Router, ні Next.js тут не до чого). Це Speculation Rules API — нативна функція браузера, яка у 2026 році нарешті стала зрілим інструментом оптимізації перцептивної продуктивності для багатосторінкових сайтів.

Чесно кажучи, я довго ставився до цього API скептично — у 2023-му воно мало забагато гострих кутів. Але після Chrome 144 ситуація змінилася кардинально, і саме час дати йому другий шанс.

У цьому посібнику розберемо API від базового синтаксису до тонких налаштувань eagerness, нової опції prerender until script із Chrome 144, інтеграції через HTTP-заголовок та (найголовніше) вимірювання реального впливу на Core Web Vitals.

Що таке Speculation Rules API і навіщо він у 2026

Якщо коротко, Speculation Rules API — це декларативний інтерфейс, через який ви повідомляєте браузеру: «Ось список URL-адрес, які користувач, скоріш за все, відкриє наступними. Завантаж їх (або повністю відрендер) у фоновому режимі, поки людина читає поточну сторінку».

API замінює застарілі <link rel="prerender"> і доповнює <link rel="prefetch">, пропонуючи значно гнучкішу конфігурацію: рівні «впевненості» (eagerness), правила за CSS-селекторами і централізоване керування через HTTP-заголовки.

Чому це важливо саме зараз:

• Стабільна підтримка у Chrome 109+, Edge 109+ та інших Chromium-браузерах — це приблизно 79% світового трафіку.
• Safari 26.2 отримав робочу імплементацію за прапорцем, а Firefox оголосив позитивну позицію стосовно prefetch-частини.
• Google Search уже використовує speculation rules для попереднього рендерингу результатів, на яких користувач затримується курсором.
• Chrome 144 (січень 2026) представив prerender until script — нову опцію, що мінімізує побічні ефекти від аналітики під час спекулятивного рендерингу.

Prefetch vs Prerender: у чому різниця

Speculation Rules API підтримує два рівні «спекуляції». Вибір між ними визначає компроміс «швидкість vs ресурси» — і це, мабуть, найважливіше архітектурне рішення, яке вам доведеться прийняти.

Prefetch

Браузер завантажує HTML-документ і, опціонально, ключові підресурси — але не виконує JavaScript і не рендерить сторінку. Коли користувач клікає, браузеру лишається тільки розпарсити, виконати скрипти і відмалювати — без мережевого запиту. Економно за пам'яттю та CPU, дає виграш у TTFB і ранніх метриках завантаження.

Prerender

А ось тут уже серйозніше. Браузер виконує повний цикл завантаження сторінки у прихованій вкладці: парсинг HTML, виконання JS, побудова DOM, лейаут, рендеринг. Коли користувач клікає — відбувається миттєва «активація» цієї заздалегідь готової сторінки. З точки зору користувача LCP та INP перетворюються майже на нуль, а перший кадр з'являється за <100 мс.

Ціна prerender — додаткові пам'ять, CPU, мережевий трафік і навантаження на бекенд. Тому загальна рекомендація:

Prefetch — широко. Prerender — точково, лише там, де ймовірність переходу справді висока.

Базова імплементація: ваш перший speculation rule

Найпростіший спосіб додати правила — інлайн-скрипт із типом speculationrules. Ось мінімальний приклад:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["/products", "/about", "/pricing"]
    }
  ]
}
</script>

Цей блок повідомляє Chromium, що при завантаженні поточної сторінки слід одразу почати prerender для трьох вказаних URL. Браузери без підтримки API просто проігнорують <script> з невідомим type, отже прогресивне покращення працює «з коробки» — і це чудово.

Ще зручніше — використати where-селектор, щоб правило автоматично застосувалося до всіх відповідних посилань на сторінці:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "selector_matches": "a[data-no-prerender]" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Тут ми кажемо: «Робіть prerender для будь-якого внутрішнього посилання, крім /logout і будь-якого посилання з атрибутом data-no-prerender. І починай не одразу, а коли користувач затримається курсором над посиланням». Просто, читабельно, без магії.

Eagerness: як контролювати агресивність спекуляції

Поле eagerness керує тим, наскільки рано браузер починає завантажувати або рендерити цільову сторінку. Це найважливіший важіль для балансу між швидкістю та витратами ресурсів — і саме тут найчастіше припускаються помилок.

Значення	Коли спрацьовує	Ліміт у Chrome	Типовий сценарій
immediate	Одразу при парсингу правила	50 prefetch / 10 prerender	Ключові сторінки воронки
eager	За найменшим натяком — наведення курсору, скрол посилання у в'юпорт	50 prefetch / 10 prerender	Магазини з вузьким каталогом
moderate	Hover ≥ 200 мс або touchstart	2 prefetch / 2 prerender (FIFO)	Універсальний дефолт
conservative	Натискання кнопки миші (mousedown/touchstart)	2 prefetch / 2 prerender (FIFO)	Ризикові або «дорогі» сторінки

І ось цікавий нюанс conservative, який багатьох здивує: навіть якщо користувач і так зараз клікне, виграш є. Подія click у браузері спрацьовує на mouseup, а спекуляція стартує на mousedown. Ця затримка у 80–120 мс уже встигає завантажити документ. На мобільних аналогічно ловиться touchstart, що дає до 300 мс форою. Маленька деталь, а ефект — реальний.

Стратегія «починай дешевим, апгрейдь дорогим»

Кращий патерн 2026 року — комбінувати prefetch і prerender у різні правила:

<script type="speculationrules">
{
  "prefetch": [
    {
      "where": { "href_matches": "/blog/*" },
      "eagerness": "moderate"
    }
  ],
  "prerender": [
    {
      "where": { "href_matches": "/blog/*" },
      "eagerness": "conservative"
    }
  ]
}
</script>

Тут на hover ми робимо дешевий prefetch (вже маємо HTML і CSS), а коли користувач справді натиснув на посилання — Chrome апгрейдить його до повного prerender і встигає підготувати інтерактивну сторінку до моменту відпускання кнопки. Простий, дешевий патерн, який працює.

Document Rules: правила за селекторами замість списку URL

Перераховувати конкретні URL у "urls" зручно для лендингу або статичної навігації. Але для динамічного сайту з сотнями посилань це нереалістично — пам'ятаю, як на одному e-commerce проєкті ми спершу намагалися генерувати такі списки на бекенді, і це швидко перетворилося на пекло. Тут і допомагають document rules — правила, які працюють із посиланнями просто на основі їхніх атрибутів:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/product/*" },
          { "selector_matches": ".product-card a" }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Це правило застосується до будь-якого посилання типу /product/123, що знаходиться всередині блока з класом .product-card. Ви можете комбінувати and, or, not для побудови складної логіки — наприклад, виключити посилання з оплатою або форми.

HTTP-заголовок Speculation-Rules: централізоване керування

Замість того, щоб додавати <script> у кожен шаблон, можна винести правила у зовнішній JSON-файл і підключити через заголовок відповіді:

HTTP/1.1 200 OK
Content-Type: text/html
Speculation-Rules: "/rules/speculation.json"

А сам файл /rules/speculation.json відповідає з MIME-типом application/speculationrules+json:

{
  "prefetch": [
    { "where": { "href_matches": "/*" }, "eagerness": "moderate" }
  ],
  "prerender": [
    { "urls": ["/checkout"], "eagerness": "conservative" }
  ]
}

Цей підхід зручний для CDN і реверс-проксі (Cloudflare Workers, Akamai Ion, Fastly Compute), де ви можете оновлювати спекулятивну стратегію без редеплою фронтенду. Для команд із розділеними фронт- і дев-опс зонами відповідальності — справжня знахідка.

Prerender Until Script: новинка Chrome 144

Найбільший головний біль prerender'у — це побічні ефекти JavaScript. Аналітика рахує перегляд сторінки, яку користувач не відкрив. Реклама фіксує impression. A/B-тестинг розподіляє варіант. Скільки PR-ів я переробляв саме через цю проблему — і не злічити. У січні 2026 Chrome 144 нарешті розв'язав цю проблему опцією prerender until script.

Працює так: браузер починає завантажувати HTML і всі статичні підресурси (CSS, шрифти, зображення), будує DOM — але зупиняє виконання JavaScript на першому блокуючому скрипті. Коли користувач справді активує сторінку, JS продовжує виконання так, ніби нічого не було.

<script type="speculationrules">
{
  "prerender": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "moderate",
      "target_hint": "_self"
    }
  ]
}
</script>

<!-- Усе, що йде до цього блокуючого тега, виконається у prerender -->
<link rel="stylesheet" href="/critical.css">

<!-- А це призупиниться до активації -->
<script src="/analytics.js"></script>

Так ви отримуєте більшість виграшу від prerender (LCP, ранній лейаут, попередній парсинг CSS) майже без витрат на «фантомні» події в аналітиці. Win-win.

Що НЕ можна (або обережно) спекулювати

Деякі URL небезпечно завантажувати без явної дії користувача — це може зламати застосунок або змінити стан акаунта. Чек-лист, що варто виключити:

• GET-маршрути, що змінюють стан — /logout, /cart/remove?id=1, /admin/delete. Вони і за SEO-практиками не повинні бути GET, але реальність відрізняється від ідеалу (ми всі це знаємо).
• Пошукові запити з параметрами — prefetch може створити навантаження на пошуковий бекенд.
• Сторінки оплати — особливо ті, що генерують одноразові токени (PayPal, Stripe Checkout).
• Сторінки з персоналізацією на основі User-Agent Client Hints — спекуляція може закешувати неправильний варіант.
• Крос-доменні URL з кукі — Chrome автоматично їх пропустить заради приватності, тому покладатися не варто.

Найпростіший спосіб масово виключити такі URL — додати атрибут і CSS-селектор:

<a href="/logout" data-no-prerender>Вийти</a>

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "selector_matches": "[data-no-prerender]" } },
          { "not": { "href_matches": ["/logout", "/cart/*", "/checkout"] } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Як писати JS-код, дружній до prerender

Сторінка, яку Chrome рендерить у фоні, технічно завантажена, але прихована від користувача. Це створює нюанси, які треба врахувати з самого початку — інакше ловити баги по продакшну буде непросто.

1. Перевіряйте Document.prerendering

if (document.prerendering) {
  // Ми у prerender — відкласти аналітику, A/B-сплітинг, рекламу
  document.addEventListener('prerenderingchange', initAnalytics, { once: true });
} else {
  initAnalytics();
}

2. Використовуйте Page Lifecycle API

Подія prerenderingchange спрацьовує, коли сторінка переходить зі стану prerender до активної. Це ваша точка ініціалізації для всього, що змінює стан або викликає мережеві запити.

3. Захист від подвійного виконання таймерів

Якщо ви запускаєте setTimeout або setInterval на завантаженні, ці таймери стартують у prerender. Загорніть їх у перевірку document.prerendering === false або відкладіть до події активації. Інакше ваш «таймер показу попапа через 30 секунд» спрацює одразу після того, як користувач відкриє сторінку. Несподіванка — і не з приємних.

Як це використовує Google Search

Google Search застосовує speculation rules з 2024 року, і у 2026 розгортання охопило практично всі регіони. Стратегія Google показова:

• Для топ-1 органічного результату — prerender з eagerness: moderate, бо ймовірність кліку висока.
• Для решти результатів сторінки — prefetch з eagerness: moderate.
• Для рекламних посилань — prefetch з eagerness: conservative (бо clicktracking-редиректи небезпечно prerender'ити).

Внутрішні метрики Google показали зниження медіанного LCP на органічних переходах на понад 50%. Це, мабуть, найкращий аргумент на користь впровадження, який можна знайти.

Сумісність браузерів станом на травень 2026

Браузер	Підтримка	Деталі
Chrome 109+	✅ Повна	Стабільна з 2023; prerender until script у 144
Edge 109+	✅ Повна	Як і Chrome (Chromium-based)
Opera, Brave, Vivaldi	✅ Повна	Chromium-base
Chrome / Edge Android	✅ Повна	Включно з touchstart-евристикою
Safari 26.2+	🟡 За прапорцем	Не за замовчуванням
Firefox	🟡 Декларація	Підтримує prefetch-частину специфікації

Перевірити підтримку у рантаймі:

const supportsSpeculation =
  HTMLScriptElement.supports &&
  HTMLScriptElement.supports('speculationrules');

if (supportsSpeculation) {
  console.log('Speculation Rules доступні');
}

Як виміряти реальний ефект

Speculation rules можуть і нашкодити: якщо ви робите prerender 10 сторінок на кожну зміну в'юпорта, це з'їдає батарею мобільних і навантажує бекенд. Тому після впровадження обов'язково міряйте — без цього все як з гороху об стіну.

1. RUM-метрики через web-vitals.js

import { onLCP, onINP } from 'web-vitals/attribution';

onLCP((metric) => {
  const wasPrerendered = document.prerendering === false &&
                          performance.getEntriesByType('navigation')[0]?.activationStart > 0;
  navigator.sendBeacon('/rum', JSON.stringify({
    metric: 'LCP',
    value: metric.value,
    prerendered: wasPrerendered
  }));
});

Поле activationStart > 0 у Navigation Timing — надійна ознака того, що сторінка прийшла з prerender-кешу. Розділіть RUM-дашборд на дві когорти і порівняйте медіану LCP/INP. Цифри говоритимуть самі за себе.

2. Chrome DevTools → Application → Speculative Loads

У Chrome 124+ є окремий розділ DevTools, що показує, які URL були спекульовані, який статус (Ready, Failure, AlreadyClicked) і скільки байтів витрачено. Незамінний для дебагу — серйозно, не пропустіть.

3. Серверна аналітика

Запити, ініційовані Speculation Rules API, надходять із заголовком Sec-Purpose: prefetch або Sec-Purpose: prefetch;prerender. Ви можете окремо логувати ці запити, щоб не плутати їх із реальними переглядами в access-логах.

Чек-лист впровадження для production

1. Виключіть /logout, /cart/remove*, сторінки оплати з prerender і prefetch.
2. Почніть із "prefetch" з "eagerness": "moderate" для всіх внутрішніх посилань.
3. Додайте document.prerendering-гард у код аналітики, A/B і реклами.
4. Виміряйте baseline RUM на тиждень.
5. Увімкніть "prerender" для топ-3 найвідвідуваніших сторінок із eagerness: conservative.
6. Слідкуйте за серверним навантаженням — спекулятивні запити з Sec-Purpose мають окремо моніторитися.
7. Додайте Speculation-Rules-заголовок на CDN-рівні замість інлайну, щоб контролювати правила без редеплою.

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

Speculation Rules API працює у Safari у 2026?

Safari 26.2 має робочу імплементацію за прапорцем Speculation Rules API у Develop → Experimental Features, але вона не ввімкнена за замовчуванням для звичайних користувачів. Браузери без підтримки просто ігнорують <script type="speculationrules">, тому додавати правила безпечно — вони просто не дадуть ефекту в Safari.

Prefetch чи prerender — що обрати для блогу?

Для контентного сайту з довгим скролом і високою ймовірністю «next article» оптимальна схема — prefetch із moderate для всіх посилань блогу плюс prerender із conservative точково для рекомендованих статей у бічному блоці. Це дає миттєвий перехід без перевитрат пам'яті.

Чи впливає Speculation Rules API на SEO?

Прямо — ні. Googlebot ігнорує <script type="speculationrules">. Опосередковано — так: prerender суттєво покращує LCP реальних користувачів (RUM), а CrUX-дані LCP є складовою Page Experience сигналу Google. Тобто кращі Core Web Vitals → краще ранжування.

Як уникнути подвійного списання реклами через prerender?

Усі скрипти аналітики, реклами та A/B-тестингу обгортайте в перевірку document.prerendering і запускайте їх у обробнику події prerenderingchange. Альтернатива — нова опція Chrome 144 prerender until script, яка автоматично призупиняє виконання JS до активації сторінки.

Скільки сторінок Chrome може тримати у prerender одночасно?

За документацією Chrome — до 10 prerender-сторінок при eagerness: immediate або eager, і лише 2 при moderate або conservative (черга FIFO — нові спекуляції витісняють старі). Префетчі лімітовано 50 та 2 відповідно. Ці ліміти автоматично знижуються в режимі економії батареї або Save Data.

Висновок

У 2026 році Speculation Rules API — це найдешевший спосіб отримати «нуль-LCP» для багатосторінкових сайтів. Кілька рядків JSON у <head> або один HTTP-заголовок на CDN — і ваші користувачі переходять між сторінками так, ніби це SPA, без жодного фреймворку, бандлера чи роутера.

Ключ до успіху — обережність із prerender, ретельне виключення «небезпечних» URL і дисципліноване вимірювання через RUM. Почніть із prefetch, моніторте, апгрейдьте до prerender там, де ймовірність переходу очевидно висока. І ваш LCP стане предметом заздрості конкурентів — без перебільшень.