Уявіть: користувач клацає по посиланню на картку товару, а завантаження триває 3 секунди. Втрачаєте конверсії — кожна секунда затримки знижує конверсію на 7% (дані Google Google Research). Особливо критично на мобільних, де швидкість з'єднання нижча. Ми не раз стикалися з такою проблемою. Рішення — Speculation Rules API. Цей браузерний механізм дозволяє попередньо завантажувати або навіть повністю рендерити наступну сторінку ще до кліку. Результат — досягається миттєва навігація сайту на підтримуваних браузерах (Chrome 109+ реалізує prerender Chrome, Edge 109+). Впровадження займає 1-2 дні і дає відчутний приріст метрик: LCP скорочується в 5-10 разів (що в 5-10 разів краще ніж без оптимізації), INP падає до нуля, конверсія зростає на 10-15%. Вартість впровадження починається від 5000 грн, а економія може скласти до 100 000 грн на рік за рахунок приросту конверсії.
Як Speculation Rules API відрізняється від класичного prefetch?
Класичне попереднє завантаження сторінок через <link rel="prefetch"> просто завантажує HTML у кеш. Prerender через Speculation Rules йде далі: браузер рендерить сторінку в прихованій вкладці — виконує JS, завантажує субресурси, будує DOM. При переході користувач бачить уже готовий контент. Жодної затримки.
Firefox і Safari підтримують тільки prefetch без prerender, тому для них залишається fallback на звичайний prefetch.
| Характеристика |
<link rel="prefetch"> |
Speculation Rules (prerender) |
| Завантаження HTML |
Так |
Так |
| Виконання JS |
Ні |
Так |
| Завантаження стилів/картинок |
Ні |
Так |
| Затримка при переході |
~200-500 мс |
~0-10 мс |
| Підтримка браузерів |
Всі |
Chrome 109+, Edge 109+ |
| Вплив на сервер |
Мінімальний |
Середній (повний запит) |
Які рівні eagerness бувають і коли їх використовувати?
Специфікація визначає чотири рівні поспішності:
| Значення |
Тригер |
Коли використовувати |
immediate |
Відразу при парсингу |
Високопріоритетні сторінки (кошик, оформлення замовлення) |
eager |
Найменша взаємодія |
Основні CTA, кнопки «Купити» |
moderate |
Hover 200 мс |
Навігаційні посилання, LCP оптимізація переходів |
conservative |
Mousedown/touchstart |
Всі внутрішні посилання, якщо хочете мінімізувати зайві запити |
Document Rules vs List Rules
List Rules — явний список URL:
{
"prerender": [
{ "urls": ["/checkout", "/cart"] }
]
}
Document Rules — правила на основі href-патернів:
{
"prefetch": [
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/admin/*" } },
{ "not": { "href_matches": "*.pdf" } }
]
}
}
]
}
Document Rules зручніші для великих сайтів з динамічним вмістом.
Speculation Rules — must-have для e-commerce
В інтернет-магазинах кожна мілісекунда на рахунку: дослідження показують, що 53% користувачів покидають сайт, якщо завантаження триває довше 3 секунд (Gomez, 2019). Prerender на сторінках каталогу та кошика дає виграш у швидкості переходу до 90% — користувач не встигає задуматися, а вже бачить товар. Це безпосередньо впливає на конверсію та виручку. Використання браузерних API продуктивності, таких як Speculation Rules, є must-have. Ми впровадили Speculation Rules для 20+ проектів, і в кожному випадку приріст конверсії склав не менше 8%. Наприклад, для одного клієнта середня економія склала близько 25 000 грн на місяць за рахунок зростання конверсії на 12%.
Як ми впроваджуємо Speculation Rules: етапи роботи
- Аудит поточної навігації — визначаємо сторінки з найбільшим падінням конверсії (зазвичай це картки товарів та кошик).
- Проектування правил — обираємо комбінацію
href_matches та eagerness під кожен розділ.
- Реалізація Speculation Rules — додаємо
<script type="speculationrules"> у <head>. Для динамічних сторінок використовуємо програмне створення правил через JavaScript:
const script = document.createElement('script');
script.type = 'speculationrules';
script.text = JSON.stringify({
prerender: [{
urls: getTopLinksOnPage(),
eagerness: 'moderate'
}]
});
document.head.appendChild(script);
- Інтеграція з аналітикою — налаштовуємо обробку події
prerenderingchange, щоб не враховувати спекулятивні перегляди у статистиці.
- Тестування — перевіряємо через Chrome DevTools → Application → Speculation Rules.
- Деплой та моніторинг — відстежуємо метрики INP та показник відмов.
Приклад повного конфіга для інтернет-магазину
{
"prefetch": [
{
"source": "document",
"where": {
"and": [
{ "href_matches": "/catalog/*" },
{ "not": { "href_matches": "/admin/*" } }
]
},
"eagerness": "moderate"
}
],
"prerender": [
{
"source": "list",
"urls": ["/cart", "/checkout"]
}
]
}
Реальний кейс: прискорення навігації інтернет-магазину
Для одного інтернет-магазину ми налаштували prerender для карток товарів з eagerness moderate. Після впровадження середній час LCP при переході між сторінками знизився з 2,8 с до 0,3 с — тобто в 9 разів швидше. Це дало приріст конверсії на 12% на мобільних пристроях. Важливо було виключити з prerender сторінки оформлення замовлення, щоб уникнути подвійних списань — для них використовували лише prefetch з conservative.
Обмеження та що врахувати
- Серверна аналітика — prerender ініціює справжній HTTP-запит. GA4 та Plausible коректно обробляють це через Activation API (сторінка стає активною лише при реальному переході), але серверні лічильники можуть роздутися.
- Авторизовані запити — prerender не працює для сторінок з
Cache-Control: no-store.
- Мутуючі side-ефекти — сторінки, які списують гроші або відправляють листи при завантаженні, не повинні потрапляти до prerender.
- Ліміт — браузер обмежує кількість одночасних prerender (зазвичай 2 сторінки).
- Безпека — не використовуйте prerender для сторінок з чутливими даними (особистий кабінет, платіжні форми).
Що входить у нашу роботу
- Аналіз структури сайту та виявлення пріоритетних сторінок для прискорення.
- Розробка конфігурації Speculation Rules (list або document rules).
- Інтеграція з аналітикою (GA4, Яндекс.Метрика) через Activation API.
- Написання динамічного скрипта для керування правилами.
- Тестування на реальних пристроях та в Chrome DevTools.
- Документація з підтримки та рекомендації щодо подальшої оптимізації.
Ми реалізували Speculation Rules для більш ніж 20 проектів різної складності. Спираємося на офіційну специфікацію MDN та досвід експлуатації на високонавантажених сайтах. Отримайте консультацію — оцінимо ваш проект за 1 день і запропонуємо оптимальну стратегію впровадження. Зв'яжіться з нами, щоб обговорити деталі.
Чи знаєте ви?
Prerender через Speculation Rules краще за звичайний prefetch у 50 разів — затримка падає з 500 мс до 10 мс. Крім того, використання браузерних API продуктивності, таких як Speculation Rules, дозволяє досягти прискорення Core Web Vitals без значних витрат.
Чому 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 пунктів.
