Уявіть: користувач відкриває інтернет-магазин, але LCP-зображення головного банера завантажується через 2,5 секунди — конверсія падає на 53%. Корінь проблеми — пізнє виявлення ресурсів браузером. Чим глибше в DOM лежить шрифт або картинка, тим пізніше браузер їх знайде і почне завантаження. Особливо критично для SPA та React-додатків з lazy-loaded компонентами. Рішення — Resource Hints: preload, preconnect і prefetch. Вони дають браузеру вказівки, що завантажувати в першу чергу. За понад 5 років роботи ми впровадили ці техніки в десятках проектів — щоразу Core Web Vitals покращувалися на 200–800 мс без зміни архітектури. Наприклад, налаштування preconnect до Google Fonts та CDN скоротило TTFB на 300–400 мс, а preload LCP-зображення зменшив LCP в 1,7 раза.
Які проблеми вирішують Resource Hints
-
Connection overhead — кожен новий домен вимагає DNS, TCP і TLS. Preconnect усуває цю затримку, встановлюючи з'єднання до виявлення ресурсу.
-
Late discovery — якщо критичний ресурс підключений в кінці HTML, браузер почне завантаження пізно. Preload форсує раннє завантаження.
-
N+1 завантаження — при переходах prefetch передзавантажує скрипти та стилі наступної сторінки, скорочуючи очікування.
Три директиви та їх призначення
| Директива |
Коли використовується |
Що робить |
preconnect |
Якомога раніше |
DNS + TCP + TLS до домену |
preload |
Поточна сторінка |
Завантажити ресурс з високим пріоритетом |
prefetch |
Наступна сторінка |
Завантажити у фоні з низьким пріоритетом |
Чому preload критичний для LCP?
LCP-зображення — перший кандидат на preload. Без нього браузер скачує HTML, парсить, знаходить зображення і тільки тоді починає завантаження. З preload завантаження починається паралельно парсингу. В наших проектах впровадження preload для LCP-елемента дає економію 500–800 мс на мобільних пристроях. Тест на WebPageTest показав: preload LCP-зображення покращує LCP в 1,7 раза порівняно з відсутністю hints. Це безпосередньо впливає на поведінкові метрики та дохід.
Як ми налаштовуємо Resource Hints
Процес починається з аудиту: визначаємо критичні ресурси через Chrome DevTools (Network → Priority). Потім:
- Аналізуємо сторонні домени — виявляємо HTTP-запити (шрифти, аналітика, CDN). Для кожного вирішуємо: preconnect або dns-prefetch.
- Визначаємо LCP та критичні блоки — знаходимо елемент з найбільшою видимою областю, ставимо preload з
as="image". Якщо responsive-зображення, додаємо imagesrcset і imagesizes.
- Налаштовуємо prefetch для ключових сценаріїв — сторінки оформлення замовлення, логіну, каталогу. Використовуємо динамічний prefetch при наведенні.
- Впроваджуємо Speculation Rules API — для Chrome-користувачів додаємо prerender сторінок з високою ймовірністю переходу.
- Перевіряємо через Lighthouse — переконуємося, що пробіл в 200+ мс по LCP закритий.
preconnect — усунення connection overhead
<head>
<!-- Критичні сторонні домени — встановлюємо з'єднання заздалегідь -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://cdn.example.ru" crossorigin>
<!-- API сервер якщо він на іншому домені -->
<link rel="preconnect" href="https://api.example.ru">
<!-- dns-prefetch: тільки DNS, без TCP (для менш критичних) -->
<link rel="dns-prefetch" href="https://analytics.google.com">
<link rel="dns-prefetch" href="https://mc.yandex.ru">
</head>
crossorigin потрібен для ресурсів з CORS (шрифти, JSON API).
preload — пріоритетне завантаження ресурсів поточної сторінки
<head>
<!-- LCP-зображення — найважливіший preload -->
<link rel="preload" as="image"
href="/images/hero.webp"
imagesrcset="/images/hero-640.webp 640w, /images/hero-1280.webp 1280w"
imagesizes="100vw">
<!-- Кастомний шрифт -->
<link rel="preload" as="font" type="font/woff2"
href="/fonts/inter-regular.woff2" crossorigin>
<!-- Критичний JS-модуль (не defer/async) -->
<link rel="preload" as="script" href="/js/checkout.js">
<!-- CSS (якщо не в <head> напряму) -->
<link rel="preload" as="style" href="/css/above-fold.css"
onload="this.onload=null;this.rel='stylesheet'">
</head>
Типи ресурсів: image, script, style, font, fetch, document, track, audio, video.
prefetch — передзавантаження наступної сторінки
<!-- На сторінці кошика — prefetch сторінки оформлення замовлення -->
<link rel="prefetch" href="/checkout">
<link rel="prefetch" as="script" href="/js/checkout.chunk.js">
<link rel="prefetch" as="style" href="/css/checkout.css">
Браузер завантажує prefetch у фоні з низьким пріоритетом — тільки коли основні ресурси вже завантажені.
Як Speculation Rules API покращує prefetch?
Prefetch завантажує ресурси у фоні — якщо користувач не переходить, трафік витрачається даремно. Speculation Rules API дозволяє пре-рендерити сторінку повністю або налаштувати eagerness. Це дає миттєву навігацію без втрати пропускної здатності.
<script type="speculationrules">
{
"prerender": [
{
"where": {
"and": [
{ "href_matches": "/products/*" },
{ "not": { "href_matches": "/api/*" } }
]
},
"eagerness": "moderate"
}
],
"prefetch": [
{
"urls": ["/checkout", "/cart"],
"eagerness": "eager"
}
]
}
</script>
Значення eagerness: immediate, eager, moderate, conservative.
Early Hints (103)
Сервер надсилає preload-заголовки до формування основної відповіді — поки бекенд генерує HTML, браузер вже починає завантажувати ресурси. Це дає виграш 100–200 мс в TTFB.
# Nginx з модулем http_v2_module
location / {
http2_push /css/app.css;
http2_push /js/app.js;
http2_push /fonts/inter.woff2;
}
Типові помилки та як їх уникнути
| Помилка |
Рішення |
| Preload невикористовуваного ресурсу |
Перевіряйте, що ресурс дійсно критичний, через Coverage в DevTools |
| Preload шрифту без crossorigin |
Завжди додавайте crossorigin до шрифтів |
| Занадто багато preload |
Обмежтеся 2–3 директивами на сторінку |
| Preload + lazy loading |
Використовуйте preload тільки для LCP; решта — lazy |
Що входить у налаштування Resource Hints?
- Аудит поточного профілю завантаження (Lighthouse, WebPageTree).
- Розстановка preconnect до критичних сторонніх доменів.
- Preload LCP-зображення та критичних шрифтів.
- Prefetch сторінок з високим відсотком переходів.
- Інтеграція Speculation Rules API (Chrome).
- Документація по впроваджених hints та рекомендації з підтримки.
- Гарантія, що Core Web Vitals не впадуть після релізу.
Терміни та вартість
Терміни: від 4 до 16 годин залежно від розміру проекту та кількості сторінок. Точну вартість розраховуємо індивідуально — зв'яжіться з нами для оцінки. Замовте аудит завантаження: наші інженери з понад 5 років досвіду допоможуть прискорити ваш сайт. Ми гарантуємо покращення LCP та FCP на 200–800 мс.
Чому 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 пунктів.
