SEO-продуктивність: Core Web Vitals, Schema.org та технічний аудит
PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент з сайтом на 3 роки старше стоїть вище у виданні, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій.
Core Web Vitals: що справді впливає на позиції
Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з березня 2024).
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 з потрібними розмірами.
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) — сигнал якості.
Стек інструментів
- Діагностика: Chrome DevTools Performance, Lighthouse CLI, WebPageTest з трасуванням
- Моніторинг: Sentry Performance, Google Search Console, SpeedCurve для історичних трендів
- Розмітка: JSON-LD генерація на бекенді (не через GTM — Google надійніше бачить server-rendered)
- Сканування: Screaming Frog SEO Spider, Sitebulb для візуалізації структури сайту
Процес та строки
Технічний аудит → пріоритизація проблем по впливу → оптимізація критичного шляху рендера → робота з CLS та INP → внедрення Schema.org → налаштування моніторингу Core Web Vitals у CI.
| Тип робіт | Строк |
|---|---|
| Технічний SEO-аудит + roadmap | 1–2 тижні |
| Оптимізація Core Web Vitals (один шаблон) | 2–4 тижні |
| Повна технічна оптимізація сайту | 4–10 тижнів |
| Внедрення Schema.org для e-commerce | 1–3 тижні |
Вартість розраховується індивідуально після аудиту.