Шаблон брифу покращення Core Web Vitals

Бриф впровадження (для заповнення)

Коли використовувати: Один бриф на кожну групу URL, що не проходить перевірку: польова базова лінія, лабораторне відтворення, шаблон, якого це стосується, виправлення, відповідальний і вікно повторної перевірки.

Бриф впровадження Core Web Vitals

Пишіть один бриф на кожну групу URL, яка не проходить перевірку в Search Console, а не на кожен URL. Групи мають спільний шаблон, тож одне виправлення зазвичай покращує всю групу.

1. Польова базова лінія

2. Лабораторне відтворення

• Приклад URL із групи: [URL]
• Інструмент і налаштування: [Lighthouse / DevTools, пристрій, обмеження мережі]
• Що відтворюється: [напр. елемент LCP - головне зображення, 3,9 с, затримка завантаження 1,6 с]
• Не вдалося відтворити? [зафіксуйте це; проблеми INP, які видно лише в польових даних, часто потребують даних реальних користувачів]

3. Шаблон, якого це стосується, та причина

• Шаблон / компонент: [сторінка товару, компонент головного банера]
• Розмір групи URL: [кількість URL у групі Search Console]
• Першопричина: [одне речення]

4. Виправлення та критерії приймання

• Запропоноване виправлення: [попереднє завантаження головного зображення, задати fetchpriority, прибрати lazy-load]
• Лабораторне приймання: [LCP менше 2,5 с на тестовому URL з тими самими налаштуваннями]
• Польове приймання: [група має статус «добре» в Search Console після перевірки]
• Ризик: [що може зламатися, напр. верстка на малих екранах]

5. Відповідальний і вікно повторної перевірки

• Відповідальний: [ім'я, команда] · Рецензент: [ім'я]
• Дата релізу: [дата] · Перевірку розпочато: [дата] · Перевірити результат: [дата + 28 днів]

Перевірка завершення: лабораторне приймання пройдено, перевірку в Search Console розпочато, результат записано через 28 днів, а бриф закрито або відкрито знову з новою причиною.

Базова лінія та польові дані проти лабораторних

Коли використовувати: Зафіксуйте базову лінію для кожної метрики Core Web Vitals, перш ніж щось змінювати, і з'ясуйте, якому джерелу даних довіряти для оцінки, а якому для налагодження.

Зафіксуйте базову лінію

Перш ніж щось оптимізувати, зафіксуйте, де сьогодні перебуває кожна метрика для [URL сторінки]. Search Console показує польові дані (реальні користувачі Chrome з набору даних CrUX, ковзне вікно 28 днів), тож саме це число треба звітувати і саме його потрібно пройти. Лабораторні дані (Lighthouse, одне змодельоване завантаження) потрібні для налагодження, бо вони відтворювані й дають корисні трасування.

• Польове джерело: беріть дані CrUX з PageSpeed Insights або зі звіту «Основні веб-показники» (Core Web Vitals) у Search Console для [ресурс].
• Лабораторне джерело: запускайте Lighthouse (Chrome DevTools або PageSpeed Insights), щоб відтворити й відстежити проблеми.
• Запишіть порогові значення: LCP добре <=2,5 с, потребує покращення <=4 с; INP добре <=200 мс, потребує покращення <=500 мс; CLS добре <=0,1, потребує покращення <=0,25. Для кожної метрики вкажіть значення 75-го процентиля і статус.

Польові й лабораторні дані розходитимуться, і це нормально. Лабораторія тестує один пристрій і одну мережу, а польові дані зводять багато. Використовуйте лабораторію, щоб знайти причину, а польові дані, щоб підтвердити результат лікування.

Результат: таблиця базової лінії з кожною метрикою, її поточним польовим значенням, лабораторним значенням і статусом «пройдено / не пройдено» на [дата].

Виправлення Largest Contentful Paint (LCP)

Коли використовувати: Діагностуйте й виправте повільний LCP, щоб основний елемент контенту відмальовувався за 2,5 секунди для більшості відвідувачів.

Нехай основний контент з'являється швидко

LCP вимірює, коли найбільший видимий елемент (зазвичай головне зображення, постер відео або блок заголовка) завершує відмальовування. Ціль: <=2,5 с на 75-му процентилі. Знайдіть елемент LCP у Lighthouse або на панелі Performance у DevTools, потім розбийте його час на чотири частини. Посібник Google на web.dev дає орієнтовні цілі для кожної.

1. Час до першого байта (близько 40%): скоротіть відповідь сервера для [джерело (origin)] за допомогою кешування, швидшого хостингу або рендерингу на edge.
2. Затримка завантаження ресурсу (менше 10%): зробіть зображення LCP помітним у HTML, попередньо завантажте його та задайте fetchpriority="high", щоб браузер почав рано.
3. Тривалість завантаження ресурсу (близько 40%): віддавайте зображення у відображуваному розмірі, у сучасному форматі, з CDN.
4. Затримка відмальовування елемента (менше 10%): скоротіть CSS і JavaScript, що блокують рендеринг, і ніколи не застосовуйте lazy-load до зображення LCP.

Не завантажуйте головне зображення через CSS-фон або клієнтський JavaScript: браузер виявляє його надто пізно. Перевірте сирий HTML за допомогою Get Source Code of Webpage, щоб переконатися, що тег зображення і preload справді є у відповіді сервера.

Перевірка: повторно запустіть лабораторний тест і переконайтеся, що елемент LCP для [URL сторінки] тепер завантажується менш ніж за 2,5 с, а також з'ясуйте, яка з чотирьох частин скоротилася.

Виправлення Interaction to Next Paint (INP)

Коли використовувати: Покращте чутливість, щоб сторінка швидко реагувала на кліки, дотики та натискання клавіш. INP замінив старішу метрику FID.

Нехай взаємодії здаються миттєвими

INP замінив FID як метрику Core Web Vitals у березні 2024 року. Він вимірює затримку взаємодій протягом усього візиту на сторінку і показує приблизно найгіршу з них. Ціль: <=200 мс. Поганий INP майже завжди пов'язаний з JavaScript, який займає головний потік саме тоді, коли користувач діє.

• Знайдіть довгі завдання: на панелі Performance у DevTools шукайте завдання головного потоку понад 50 мс під час взаємодії на [URL сторінки].
• Розбийте JavaScript: діліть довгі завдання на менші частини й поступайтеся головним потоком, щоб браузер міг обробити введення.
• Зменште роботу головного потоку: приберіть або відкладіть невикористовувані скрипти, особливо важкі сторонні теги на кшталт [назва тегу].
• Оптимізуйте обробники подій: застосовуйте debounce до важкої роботи й відкладайте нетермінові оновлення до наступного відмальовування.
• Зменште розмір DOM і вартість компонування: великий або глибоко вкладений DOM робить кожну взаємодію дорожчою.

Мета в тому, щоб головний потік був вільним, коли користувачі клікають і торкаються екрана, і браузер встигав відмалювати відповідь у межах 200 мс.

Перевірка: протестуйте реальні взаємодії й переконайтеся, що польовий INP для [ресурс] рухається до статусу «добре».

Виправлення Cumulative Layout Shift (CLS)

Коли використовувати: Не дайте контенту стрибати під час завантаження, щоб макет залишався візуально стабільним із CLS нижче 0,1.

Зупиніть стрибки макета

CLS вимірює неочікувані зсуви видимого контенту протягом усього життя сторінки. Ціль: <=0,1. Зсуви дратують користувачів і призводять до хибних кліків, і майже завжди їх спричиняють елементи, що завантажуються без зарезервованого місця.

• Задавайте розміри медіа: завжди вказуйте атрибути width і height (або CSS aspect-ratio) для зображень, відео та iframe, щоб браузер резервував місце ще до їх завантаження.
• Резервуйте місце для вставок і реклами: дайте слотам для [реклама або вставка] контейнер із фіксованою min-height, щоб вони не зсували контент униз.
• Ніколи не вставляйте контент над наявним: уникайте банерів, сповіщень або cookie-панелей, які зсувають сторінку вниз після рендерингу.
• Запобігайте зсувам через заміну шрифтів: попередньо завантажуйте ключові шрифти й розумно використовуйте [font-display], щоб обмежити перекомпонування.
• Резервуйте місце для динамічного інтерфейсу: залишайте простір для елементів, які додає JavaScript, щоб вони розгорталися в заздалегідь виділеному місці.

Вважайте будь-який видимий під час завантаження "стрибок" дефектом, який треба усунути.

Перевірка: перегляньте покадрову стрічку завантаження і переконайтеся, що на [URL сторінки] немає видимих зсувів.

Оптимізація ресурсів та доставки

Коли використовувати: Зменште й пришвидшіть ресурси, які віддає сторінка: зображення, JavaScript, CSS, кешування та CDN, щоб покращити всі метрики одразу.

Віддавайте менше і швидше

Більшість проблем зі швидкістю сторінки зводиться до того, що ви віддаєте забагато байтів або надсилаєте їх надто повільно. Оптимізація доставки покращує LCP, INP та CLS одночасно, бо браузеру треба менше завантажувати, розбирати й виконувати.

• Зображення: віддавайте сучасні формати (наприклад, WebP або AVIF), підганяйте їх під відображувані розміри та стискайте; застосовуйте lazy-load лише до зображень нижче першого екрана, ніколи до зображення LCP.
• JavaScript: мініфікуйте, застосовуйте tree-shaking і розділення коду, щоб кожна сторінка завантажувала лише потрібне; відкладайте (defer) або завантажуйте асинхронно (async) некритичні скрипти.
• CSS: мініфікуйте, прибирайте невикористовувані правила й вбудовуйте критичний CSS для контенту першого екрана на [шаблон].
• Кешування: задавайте довгий термін кешування для статичних ресурсів і використовуйте імена файлів із хешем, щоб оновлення безпечно скидали кеш.
• CDN: віддавайте ресурси з edge-локацій поблизу користувачів і ввімкніть стиснення (Brotli або gzip) у [CDN-провайдер].

Безжально перевіряйте сторонні скрипти: це поширена прихована причина повільного завантаження і поганої чутливості.

Перевірка: порівняйте загальний обсяг переданих даних і кількість запитів до і після для [URL сторінки].

Повторна перевірка та моніторинг

Коли використовувати: Підтвердьте, що виправлення спрацювали в польових даних, і налаштуйте постійний моніторинг, щоб рано помічати регресії.

Підтвердьте перемогу та втримайте її

Виправлення не завершене, доки його не підтвердять польові дані. CrUX використовує ковзне вікно 28 днів, тож покращення для реальних користувачів проявляються поступово. Перевіряйте у два етапи: спочатку лабораторія для миттєвого зворотного зв'язку, потім польові дані протягом наступних тижнів.

1. Повторіть лабораторні тести: переконайтеся в Lighthouse або PageSpeed Insights, що проблема на рівні трасування на [URL сторінки] зникла.
2. Розпочніть перевірку в Search Console: у звіті «Основні веб-показники» (Core Web Vitals) відкрийте проблему й натисніть «Перевірити виправлення» (Validate fix). Search Console відстежує групу URL 28 днів, і навіть один URL, що досі не проходить, залишає проблему відкритою.
3. Тримайте цілі: LCP <=2,5 с, INP <=200 мс, CLS <=0,1 на 75-му процентилі. Статус групи URL визначає її найгірша метрика.
4. Моніторте постійно: додайте моніторинг реальних користувачів або планові перевірки для [ресурс], щоб регресії швидко ставали помітними.
5. Захищайтеся від дрейфу: перевіряйте знову після релізів, нових сторонніх тегів або змін шаблонів.

Результат: нотатка «до і після» для кожного брифу з датою початку перевірки [дата] та результатом.

Розібраний приклад (вигаданий меблевий магазин)

Коли використовувати: Заповнений бриф для вигаданого онлайн-магазину меблів, сторінки товарів якого не проходили LCP на мобільних.

Розібраний приклад: сторінки товарів Oak & Ember

Лише приклад. Компанія, люди, URL і цифри вигадані, щоб показати, як виглядає придатна до використання заповнена версія.

Чому цей бриф спрацював

Він назвав одну причину для 1 900 URL. Розробнику не довелося чіпати кожну сторінку, лише компонент галереї. А дата через 28 днів була в брифі, тож ніхто не оголосив перемогу після одного вдалого запуску Lighthouse.

Наступний крок

Запустіть безкоштовний аудит сайту, щоб побачити Core Web Vitals вашої головної сторінки і список виправлень зрозумілою мовою. Перевіряйте будь-який шаблон під час перегляду за допомогою seotools.pro SEO Extension, яке включає Core Web Vitals до своїх on-page перевірок. Якщо вашій команді потрібно, щоб виправлення хтось реалізував, наша команда з розробки сайтів може взяти бриф у роботу.