Core Web Vitals для маркетингового сайту

Щоб пройти Core Web Vitals для сайту, маркетинговій сторінці треба показати основний вміст за 2,5 секунди, відповідати на кожен дотик чи клік за 200 мілісекунд і майже не зсувати макет. Це «добрі» пороги для LCP, INP і CLS. На більшості маркетингових сайтів проблеми виникають в одних і тих самих місцях: важке медіа в першому екрані, сторонні теги, cookie-банери та шрифти, що пізно вантажаться.

Нижче пояснюємо кожну метрику простими словами, показуємо, де маркетингові сайти зазвичай втрачають бали, і перелічуємо виправлення, які застосовуємо на Next.js.

Що таке Core Web Vitals і чому маркетингові сайти їх не проходять?

Core Web Vitals - це три метрики, якими Google описує реальний досвід користувача на сторінці. Їх збирають із реальних візитів у Chrome і оцінюють за 75-м процентилем, тобто три візити з чотирьох мають вкладатися в поріг.

• Largest Contentful Paint (LCP) вимірює завантаження: момент, коли найбільший видимий елемент, зазвичай зображення чи заголовок першого екрана, повністю відмальовано. Добре - 2,5 секунди або менше.
• Interaction to Next Paint (INP) вимірює чуйність: скільки часу сторінці потрібно, щоб помітно відреагувати на кліки, дотики й натискання клавіш протягом усього візиту. Добре - 200 мілісекунд або менше. У березні 2024 року INP замінила First Input Delay серед Core Web Vitals.
• Cumulative Layout Shift (CLS) вимірює візуальну стабільність: сумує неочікувані зсуви вмісту, поки сторінка відкрита. Добре - 0,1 або менше.

Детальні визначення є в огляді Web Vitals на web.dev від Google.

Маркетингові сайти провалюють ці метрики з конкретної причини. Їх часто створює дизайн-команда, а потім розширює маркетинг. Кожна кампанія додає тег, віджет або більше відео на першому екрані. Окремо кожне доповнення здається дрібним. Разом вони виводять сторінку за межу.

Чи впливають Core Web Vitals на позиції? Вони входять до сигналів досвіду сторінки, які враховують системи Google, але релевантність і якість контенту важать значно більше. Вагоміша причина інша: повільні сторінки, що «стрибають», втрачають відвідувачів ще до того, як ті прочитають вашу пропозицію.

Польові та лабораторні дані: вимірюйте правильне

Є два види вимірювань, і вони часто не збігаються.

• Польові дані надходять від реальних користувачів через Chrome User Experience Report. Саме їх показує звіт Core Web Vitals у Search Console. Вони відображають реальні пристрої й мережі та оновлюються в ковзному 28-денному вікні.
• Лабораторні дані дає тестовий запуск у контрольованих умовах, наприклад Lighthouse або лабораторний розділ PageSpeed Insights. Вони зручні для налагодження, бо тест можна повторити після кожної зміни.

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

Для сторінок із невеликим трафіком власних польових даних може бракувати. Тоді Search Console групує їх зі схожими сторінками, а ви можете додати власний моніторинг реальних користувачів.

Як виправити LCP: зазвичай винен перший екран

На більшості маркетингових сторінок елемент LCP - це зображення першого екрана, постер відео або головний заголовок. Виправлення добре відомі:

1. Віддавайте зображення правильного розміру й формату. У Next.js next/image генерує адаптивні розміри й сучасні формати. Задайте атрибут sizes, щоб телефон не завантажував десктопну картинку.
2. Дайте йому пріоритет. Позначте зображення першого екрана як priority, щоб воно попередньо завантажувалося, і ніколи не вмикайте ліниве завантаження для того, що видно одразу.
3. Відмовтеся від слайдерів і автовідтворення відео. Карусель відкладає справжній елемент LCP і додає JavaScript. Статичне зображення або сильний заголовок зазвичай і так працюють краще. Робочі патерни першого екрана без них ми розібрали в статті про дизайн головної сторінки SaaS.
4. Рендерте на сервері. З React Server Components HTML першого екрана приходить готовим. Браузер не чекає на JavaScript, щоб зібрати сторінку.
5. Скоротіть блокувальні запити. Вбудовуйте критичний CSS, хостіть шрифти самостійно і прибирайте зайві стилі сторонніх віджетів.

Якщо елемент LCP текстовий, усе залежить від шрифтів. Коли заголовок чекає на вебшрифт, LCP теж чекає. Про це нижче.

Як виправити INP: сторонні скрипти й важкий JavaScript

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

• Менеджери тегів, які вантажать кілька пікселів аналітики й реклами.
• Чат-віджети, що на кожній сторінці завантажують цілий застосунок.
• Інструменти A/B-тестування, які ховають сторінку, поки їхній скрипт не вирішить, що показати.
• Важкі бібліотеки анімації з ефектами прокручування на кожному кадрі.
• Вбудовані сторонні форми, що тягнуть власні фреймворки.

Що працює:

• Перевірте кожен тег. Для кожного скрипта запитайте, хто користується його даними і коли востаннє туди дивився. Приберіть усе, для чого немає відповідальної особи.
• Вантажте пізніше. У Next.js next/script зі стратегією lazyOnload або afterInteractive виводить необов’язкові скрипти з критичного шляху.
• Вантажте за наміром. Покажіть легку кнопку чату і завантажуйте повний віджет лише після кліку.
• Відправляйте менше клієнтського JavaScript. Залиште більшість компонентів серверними, а клієнтськими робіть лише інтерактивні частини.
• Розбивайте довгі задачі. Обробник події має зробити мінімум до наступного відмальовування, а решту відкласти.

Менше сторонніх скриптів - це ще й простіша безпека. Кожен скрипт додає джерело у вашу Content Security Policy, про що ми писали в чеклісті безпеки сайту.

Як виправити CLS: банери, шрифти й вбудовані елементи

Зсув макета стається, коли щось з’являється або змінює розмір уже після того, як вміст навколо відмальовано.

• Cookie-банери. Показуйте їх як оверлей, закріплений унизу екрана, а не як блок, що штовхає сторінку вниз.
• Зображення й відео без розмірів. Завжди задавайте ширину й висоту або співвідношення сторін, щоб браузер зарезервував місце.
• Вебшрифти. Запасний шрифт з іншими метриками змушує текст перешиковуватися, коли приходить вебшрифт. next/font хостить шрифти самостійно і підганяє метрики запасного шрифту, що прибирає більшу частину цього зсуву.
• Вбудовані елементи й реклама. Резервуйте контейнер фіксованого розміру для карт, відео та сторонніх форм.
• Пізні банери та оголошення. Промосмуги, які вставляються вгорі сторінки вже після завантаження, - часта причина. Рендерте їх на сервері або резервуйте для них місце.

Чекліст Core Web Vitals для сайту

Проходьте його перед запуском і після кожної великої кампанії:

• Зображення першого екрана віддається через next/image з правильними sizes і priority.
• Над лінією згину немає каруселі чи відео з автовідтворенням.
• Шрифти підключені через next/font, не більше двох гарнітур.
• Для кожного зображення, відео й вбудованого елемента зарезервовано розміри.
• Cookie-банер - фіксований оверлей.
• Список тегів переглянуто, у кожного скрипта є відповідальний.
• Необов’язкові скрипти вантажаться через lazyOnload або за дією користувача.
• Більшість компонентів рендериться на сервері.
• Лабораторні перевірки проходять на профілі мобільного пристрою середнього класу з обмеженою мережею.
• Польові дані в Search Console переглянуто через 28 днів після запуску.

Швидкість легше втримати, ніж повернути. Короткий бюджет, погоджений із маркетингом, на кшталт «жодного нового стороннього скрипта без перевірки», захищає результат після запуску.

Наступний крок: маркетинговий сайт, який лишається швидким

Наша розробка лендингу коштує від 5 000 $ за односторінковий сайт на 8 блоків, з 2 раундами правок і типовим терміном 1-2 тижні. Для багатосторінкового маркетингового сайту є корпоративний сайт від 8 500 $. Ми будуємо на Next.js, бюджети швидкодії входять у розробку, і перед запуском ми перевіряємо Core Web Vitals на кожному ключовому шаблоні.

Якщо обираєте між конструктором і власною розробкою, наше порівняння Webflow і кастомного сайту показує, де кожен варіант полегшує або ускладнює роботу зі швидкістю.