Уявіть: користувач відкриває інтернет-магазин, але 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 мс.