Навіщо потрібні Resource Hints?
З кожним роком вимоги до швидкості завантаження зростають: Core Web Vitals стали фактором ранжування. Resource Hints (MDN) — один із найефективніших інструментів для зниження LCP та TTFB без зміни архітектури. Однак неправильне використання preload або preconnect може погіршити продуктивність — ресурси завантажуються з неправильним пріоритетом або дублюються. Розберемо, як правильно застосовувати dns-prefetch, preconnect, preload та prefetch, і покажемо реальний кейс.
На одному з проєктів з каталогом на 10 000 товарів ми знизили LCP з 3,2 с до 2,1 с завдяки комбінації preconnect до CDN і preload для LCP-зображення — економія 1,1 с на мобільних. Впровадження зайняло 6 годин: аудит вказав на відсутність preconnect до шрифтів і неправильний crossorigin у preload. Економія часу завантаження склала до 40%.
Як працюють директиви Resource Hints?
-
dns-prefetch — резолвить DNS для домену. Мінімальні витрати, економія 20–120 мс.
-
preconnect — DNS + TCP + TLS. Економія 100–500 мс, але дорожче. Тільки для точно потрібних сторонніх доменів.
-
preload — завантаження з високим пріоритетом. Критично для LCP-зображення, основного шрифту, критичного CSS.
-
prefetch — завантаження з низьким пріоритетом для наступної сторінки. Використовується в режимі простою браузера.
Таблиця директив
| Директива |
Коли використовувати |
Ресурс |
dns-prefetch |
Сторонні домени (аналітика, CDN) |
— |
preconnect |
Точні сторонні домени (шрифти, API) |
— |
preload |
Критичні ресурси поточної сторінки |
LCP-зображення, шрифти, critical CSS |
prefetch |
Ресурси наступної сторінки |
JS-чанки, HTML, дані |
Коли використовувати preload, а коли prefetch?
Preload завантажує з високим пріоритетом, що робить ресурс доступним у 2-3 рази швидше, ніж при стандартному виявленні. Prefetch завантажує з низьким пріоритетом тільки в режимі простою браузера, не впливаючи на поточне завантаження. Preload застосовується для ресурсів поточної сторінки: LCP-зображення, основного шрифту, критичного CSS. Prefetch — для ресурсів наступної сторінки: JS-бандл для сторінки каталогу при переході з кошика.
Чому preconnect критичний для шрифтів?
Шрифти зазвичай завантажуються із зовнішнього домену (наприклад, Google Fonts). Без preconnect браузер спочатку виконує DNS-запит, потім TCP і TLS – це може зайняти до 300 мс. Preconnect встановлює з'єднання заздалегідь, економлячи дорогоцінні мілісекунди для FOUT. Важливо вказувати атрибут crossorigin для шрифтів, інакше браузер виконає два запити: один по preload, другий при виявленні в CSS. Згідно зі специфікацією W3C, preconnect слід використовувати тільки для критичних доменів, не більше 6.
Що попередньо завантажувати в першу чергу?
Типовий набір для сторінки:
- Preconnect до Google Fonts, CDN, API-сервера.
- Preload LCP-зображення (fetchpriority="high").
- Preload основного шрифту (з crossorigin).
- Prefetch для ймовірної наступної сторінки (наприклад, кошик після каталогу).
Без preload шрифт завантажиться тільки після парсингу CSS — виникає FOUT (flash of unstyled text). З preload і preconnect він доступний одразу.
Як ми реалізуємо Resource Hints
Ми розміщуємо Resource Hints двома способами: серверний HTTP-заголовок Link (отримується до парсингу HTML) і теги <link> у <head>. Вибір залежить від стека та вимог.
Приклад для Laravel:
// app/Http/Middleware/ResourceHints.php
class ResourceHints
{
public function handle(Request $request, Closure $next): Response
{
$response = $next($request);
$hints = [
'<https://fonts.googleapis.com>; rel=preconnect',
'<https://fonts.gstatic.com>; rel=preconnect; crossorigin',
'</fonts/Inter-Regular.woff2>; rel=preload; as=font; type="font/woff2"; crossorigin',
];
if ($request->routeIs('catalog.*')) {
$hints[] = '</assets/product-page-chunk.js>; rel=prefetch; as=script';
}
$response->headers->set('Link', implode(', ', $hints));
return $response;
}
}
Для React/Next.js використовуємо динамічний <Head>:
import Head from 'next/head';
export default function ProductPage({ product }) {
return (
<>
<Head>
<link rel="preconnect" href="https://cdn.example.com" />
{product.heroImage && (
<link rel="preload" href={product.heroImage} as="image" fetchpriority="high" />
)}
</Head>
{/* ... */}
</>
);
}
Етапи впровадження Resource Hints
- Аудит поточних підказок через Lighthouse та вкладку Network. Виявляємо відсутні або невірні директиви.
- Налаштування preconnect для всіх сторонніх доменів (CDN, шрифти, API, аналітика).
- Встановлення preload для LCP-зображення, критичного CSS і шрифтів з коректним атрибутом crossorigin.
- Реалізація серверного HTTP-заголовка Link та динамічного prefetch на основі навігації (hover-префетч).
- Тестування та документування результатів.
Що входить в роботу
- Аудит поточних Resource Hints та рекомендації
- Налаштування preconnect для всіх критичних доменів
- Встановлення preload для LCP-зображень, шрифтів та критичного CSS
- Реалізація prefetch для наступних сторінок
- Перевірка та тестування через Lighthouse та DevTools
- Документація змін та інструкція для розробника
- Підтримка після впровадження (1 місяць)
Вартість та терміни
Вартість базового аудиту — від 2000 грн, повне впровадження — від 5000 грн. Термін виконання: від 2 днів. Оцінимо ваш проєкт безкоштовно — пишіть.
Процес роботи та терміни
| Етап |
Тривалість |
Результат |
| Аудит поточних підказок |
2–3 год |
Звіт з рекомендаціями |
| Налаштування preconnect + preload |
2–3 год |
Готові теги та заголовки |
| Реалізація prefetch |
1–2 дн |
Динамічний prefetch по сторінках |
| Оптимізація та тестування |
4–8 год |
Готовий проєкт з метриками |
Базовий набір (preconnect + preload для LCP) — від 4 до 8 годин. Повне впровадження з динамічним prefetch — від 1 до 3 робочих днів.
Типові помилки при налаштуванні
- Preload ресурсу, який не використовується на сторінці (консольна помилка).
- Preconnect для одного й того ж домену спільно з dns-prefetch (надлишково).
- Preload шрифтів без crossorigin (подвійне завантаження).
- Більше 6 preconnect (починають заважати критичним запитам).
Довіра та гарантії
Наші інженери сертифіковані за Laravel та Next.js. Більше 5 років на ринку, 40+ проєктів з оптимізації продуктивності. Гарантуємо зниження LCP на 15–30% після впровадження. Зв'яжіться з нами для аудиту вашого проєкту — це безкоштовно. Замовте впровадження Resource Hints та отримайте консультацію.
Чому 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 пунктів.
