Швидкість сайту як B2B маркетинговий інструмент: Core Web Vitals та оптимізація продуктивності

Швидкість сайту як B2B маркетинговий інструмент: Core Web Vitals та оптимізація продуктивності

Повільний сайт у B2B коштує грошей — навіть якщо ви не бачите прямої лінії між «сторінка завантажується 6 секунд» і «угода зірвалась». Але вона є.

За даними Google, кожна секунда затримки завантаження мобільної сторінки підвищує ймовірність відмови (bounce rate) на 32%. Для B2B-сайту, де потенційний клієнт — зайнятий менеджер, який відкриває вкладки на смартфоні між зустрічами, сторінка, що завантажується 5+ секунд, практично не існує.

Крім того, з 2021 року Google офіційно використовує Core Web Vitals як сигнал ранжування. Сайт із поганими показниками LCP, INP і CLS ранжується нижче за конкурентів із кращою технічною продуктивністю — за інших рівних умов.

У цій статті: що таке Core Web Vitals, як їх покращити, і які практичні оптимізації найбільш важливі для B2B-сайтів.

Що таке Core Web Vitals

Core Web Vitals — три метрики, які Google визначив як ключові показники якості досвіду користувача на веб-сторінці:

LCP — Largest Contentful Paint

Що вимірює: час до того, як найбільший видимий елемент сторінки (зазвичай головне зображення, велика текстова секція або відеообкладинка) повністю завантажився.

Цільовий показник: ≤ 2,5 секунди (хороший); 2,5–4 с (потребує покращення); > 4 с (погано).

Типові причини поганого LCP на B2B-сайтах:

• Великі неоптимізовані hero-зображення;
• Шрифти, що блокують відображення;
• Повільний TTFB (Time to First Byte) через повільний сервер;
• Відкладений рендеринг через JavaScript, що блокує парсинг.

INP — Interaction to Next Paint

Що вимірює: час від взаємодії користувача (клік, тап, натискання клавіші) до візуального відгуку сторінки. INP замінив FID (First Input Delay) у березні 2024 року і є суворішою метрикою.

Цільовий показник: ≤ 200 мс (хороший); 200–500 мс (потребує покращення); > 500 мс (погано).

Типові причини поганого INP на B2B-сайтах:

• Важкий JavaScript: великі аналітичні скрипти, chat widgets, маркетингові тулзи (Intercom, HubSpot), що завантажуються синхронно;
• Довгі задачі в main thread браузера;
• React/Next.js з надмірно важкою гідратацією.

CLS — Cumulative Layout Shift

Що вимірює: сумарне «стрибання» елементів сторінки під час завантаження (коли кнопка зсувається вниз після появи банера або зображення, і ви випадково натискаєте не туди).

Цільовий показник: ≤ 0,1 (хороший); 0,1–0,25 (потребує покращення); > 0,25 (погано).

Типові причини поганого CLS:

• Зображення без заданих атрибутів width і height;
• Динамічно вставлені банери або cookie-consent попапи, що зміщують контент;
• Шрифти, що підмінюють системний шрифт після завантаження (FOUT).

Чому Core Web Vitals важливі саме для B2B

Вплив на SEO

З серпня 2021 Google використовує Page Experience signals (включаючи Core Web Vitals) як фактор ранжування. Для B2B-запитів із середньою або низькою конкурентністю різниця у CWV між вами і конкурентом може бути вирішальною для позиції.

Крім того, поганий Page Experience Score знижує CTR у пошукових результатах, оскільки Google може демонструвати попередження про «некомфортний досвід» для окремих сайтів.

Вплив на конверсії

B2B-сайт — зазвичай не e-commerce із тисячами транзакцій, де кожна мілісекунда легко рахується. Але навіть у B2B дослідження показують: поліпшення LCP на 1 секунду підвищує конверсії форм і звернень на 5–15%.

Сигнал довіри

Менеджер, який відкриває сайт потенційного IT-партнера і бачить повільне завантаження, «стрибаючий» лейаут і лаги при кліках, — несвідомо формує враження про якість роботи компанії. Сайт є цифровим офісом: перше враження про вашу операційну культуру.

Практичні оптимізації

Оптимізація зображень

Зображення — найчастіша причина поганого LCP на B2B-сайтах.

Дії:

• Конвертуйте всі зображення у WebP або AVIF (30–50% менший розмір при тій самій якості порівняно з JPEG/PNG);
• Додайте атрибути width і height до всіх <img> для попередження CLS;
• Використовуйте loading="lazy" для зображень нижче viewport;
• Для hero-зображення (LCP-елемент): додавайте <link rel="preload"> у <head> і використовуйте fetchpriority="high";
• Встановіть responsive images (srcset + sizes) для подачі зображень правильного розміру на різних пристроях.

У Next.js компонент <Image> автоматично обробляє більшість цих оптимізацій.

Оптимізація шрифтів

Google Fonts і кастомні шрифти можуть блокувати рендеринг, спричиняти FOUT/FOIT і погіршувати CLS.

Дії:

• Хостуйте шрифти власноруч (self-hosted) — це прибирає DNS-запит до Google та дає контроль над кешуванням;
• Додайте font-display: swap у @font-face — це запобігає невидимому тексту під час завантаження;
• Preload критичні шрифти: <link rel="preload" as="font" crossorigin="anonymous">;
• Використовуйте мінімальний набір символів (subset), якщо підтримуєте латиницю і кирилицю — окремий subset для кожного алфавіту;
• Обмежте кількість шрифтових накреслень: замість 8 варіантів ваги завантажуйте 2–3 необхідні.

Оптимізація JavaScript

JavaScript — основна причина поганого INP і повільного LCP.

Дії:

• Аудит скриптів: use Chrome DevTools → Performance panel → Main thread. Ідентифікуйте найважчі завдання;
• Відкладайте некритичні скрипти: Google Tag Manager, HubSpot, Intercom, live chat — завантажуйте через async або defer, або через динамічне вставлення після завантаження сторінки;
• Tree shaking і code splitting: у сучасних JS-фреймворках (Next.js, Nuxt.js) переконайтесь, що бандл не містить невикористаного коду;
• Зменшіть розмір третіх сторін: замініть важкий повнофункціональний аналітичний SDK на lightweight варіант (наприклад, Plausible замість повного Google Analytics).

CDN (Content Delivery Network)

CDN знижує TTFB (Time to First Byte) — час до першого байту відповіді сервера — для користувачів, далеких від вашого сервера.

Для B2B-сайту CDN рекомендований, якщо:

• Ваша аудиторія географічно розподілена (різні регіони або країни);
• Сайт хоститься на одному дата-центрі.

Варіанти: Cloudflare (безкоштовний базовий план), Vercel Edge Network (вбудований при деплої на Vercel), AWS CloudFront. Cloudflare — найпростіший старт: достатньо змінити NS-записи і увімкнути проксування.

Server-Side Rendering (SSR) vs Static Site Generation (SSG)

Вибір між SSR і SSG впливає на TTFB і LCP.

SSG (Static Site Generation):

• HTML генерується при білді;
• Файли віддаються з CDN: TTFB зазвичай < 100 мс;
• Ідеально для маркетингових сторінок, блогу, лендингів;
• Обмеження: контент оновлюється тільки при ребілді.

SSR (Server-Side Rendering):

• HTML генерується при кожному запиті;
• TTFB вищий (150–500 мс залежно від сервера), але контент завжди актуальний;
• Підходить для персоналізованих сторінок, кабінетів, динамічного контенту.

Рекомендація для B2B-сайту: використовуйте SSG для всього маркетингового контенту (головна, послуги, блог, кейси) і SSR тільки там, де дійсно потрібна динаміка (кабінет, форми з персоналізацією). У Next.js це вирішується на рівні окремих маршрутів.

Incremental Static Regeneration (ISR) — золота середина: статичні файли з автоматичним ребілдом через задані інтервали. Для B2B-блогу з щотижневими публікаціями ISR з revalidate: 3600 (1 година) — оптимальне рішення.

Як читати PageSpeed Insights

PageSpeed Insights (pagespeed.web.dev) — основний інструмент для перевірки CWV. Кілька важливих моментів при інтерпретації:

• Lab data vs Field data: Lab data (Lighthouse) — синтетичний тест на симульованому пристрої; Field data (Chrome User Experience Report, CrUX) — реальні дані з браузерів Chrome. Field data важливіший для SEO.
• Мобільна vs. десктопна: Google оцінює мобільну версію в першу чергу (mobile-first indexing). Якщо у вас хороша десктопна оцінка і погана мобільна — пріоритизуйте мобільну оптимізацію.
• Opportunities vs. Diagnostics: Opportunities = конкретні можливості з оціненою економією (наприклад, «Serve images in next-gen formats: -1.2s»). Починайте з них.

Вимірювання та моніторинг

• Google Search Console → Core Web Vitals report: показує реальні CWV-дані для вашого сайту за полевими даними Chrome UX, з розбивкою по мобільних/десктопних пристроях і списком URL, що потребують покращення;
• PageSpeed Insights: one-off перевірка окремих URL;
• Web Vitals Chrome Extension: реальний моніторинг при перегляді сторінок;
• Lighthouse CI: автоматичний запуск Lighthouse у CI/CD-пайплайні при кожному деплої — фіксує регресії у продуктивності.

Чекліст B2B-оптимізації продуктивності

• Усі зображення у WebP/AVIF з атрибутами width/height
• Hero-зображення preload з fetchpriority="high"
• Шрифти: self-hosted, font-display: swap, preload критичних шрифтів
• GTM/аналітика/чат: завантаження після першої взаємодії (defer/async)
• SSG для маркетингових сторінок, SSR тільки де необхідно
• CDN увімкнено (Cloudflare або платформенний CDN)
• Core Web Vitals у «зеленій зоні» за PSI mobile: LCP ≤ 2,5s, INP ≤ 200ms, CLS ≤ 0,1
• Lighthouse CI налаштований у CI/CD

Висновок

Швидкість сайту — не технічна деталь для розробників; це маркетинговий актив. Для B2B-компанії, де кожен лід може принести значний контракт, інвестиції у технічну продуктивність сайту мають один із найвищих ROI серед цифрових маркетингових активностей.

MMIX проводить технічний аудит продуктивності B2B-сайтів і впроваджує оптимізації, що покращують Core Web Vitals і конверсії. Зв'яжіться з нами для аудиту вашого сайту.