Швидкість завантаження сайту: як прискорити і що вимірювати

Один зайвий секунд завантаження — мінус 7% конверсії. Це не теорія, а дані Google/Deloitte по e-commerce. Швидкість сайту впливає на ранжування через Core Web Vitals і напряму — через відмови: якщо сторінка не завантажилась за 3 секунди, 53% мобільних користувачів її покидають. Для більшості українських бізнесів прискорення сайту — одне з небагатьох SEO-покращень, яке одночасно позитивно впливає і на трафік, і на продажі.

У цій статті — конкретні кроки прискорення: від зображень і кешування до шрифтів, Critical Rendering Path, WordPress-плагінів, серверної оптимізації та моніторингу. Якщо потрібен аудит продуктивності в рамках повного SEO-просування — звертайтесь до команди SEO-Factory.

Де вимірювати швидкість сайту

Перш ніж оптимізувати — потрібна точка відліку. Різні інструменти дають різну інформацію, і розуміти різницю між ними важливо.

PageSpeed Insights

Безкоштовний інструмент від Google (pagespeed.web.dev). Показує оцінку від 0 до 100 для мобільних і десктопних версій, метрики Core Web Vitals (LCP, INP, CLS), і конкретні рекомендації — що прибрати, що відкласти, що стиснути. Використовує реальні дані CrUX і лабораторні дані Lighthouse.

Google Search Console → Core Web Vitals

Показує реальний стан сторінок сайту за даними реальних користувачів Chrome. Поділяє сторінки на «добрі», «потребують покращення», «погані». Це найточніший індикатор того, як Google бачить швидкість вашого сайту — і саме ці дані впливають на ранжування. Повний гайд по роботі з інструментом — у статті Google Search Console для SEO.

GTmetrix і WebPageTest

Детальніший waterfall-аналіз: бачите кожен запит, його розмір і час завантаження. Корисно для пошуку конкретних «важких» ресурсів — JavaScript бандлів, CSS файлів, зображень без lazy loading.

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

Зображення — найчастіша причина повільного завантаження. На більшості сайтів вони займають 60–80% від загального обсягу сторінки. Три ключові кроки:

Формат

Переводьте зображення в WebP. Порівняно з JPEG — менший розмір при тій самій якості (на 25–35%). Порівняно з PNG — ще більша економія. Підтримується всіма сучасними браузерами. Для ілюстрацій із прозорим фоном — WebP замість PNG. Для фотографій — WebP замість JPEG.

Розмір

Не завантажуйте зображення 2400px ширини туди, де відображається 600px. Використовуйте атрибут srcset для адаптивної подачі різних версій під різні екрани.

Lazy loading

Додайте атрибут loading="lazy" до зображень нижче першого екрану. Браузер завантажить їх лише коли користувач доскролює до них — сторінка відкривається швидше.

Кешування та стиснення

Gzip / Brotli стиснення

На рівні сервера увімкніть стиснення текстових ресурсів: HTML, CSS, JavaScript. Brotli (підтримується на Nginx, Apache) дає кращий результат ніж Gzip. Типовий ефект — зменшення обсягу JS/CSS-файлів на 60–70%.

Кешування браузера

Встановіть заголовки Cache-Control і Expires для статичних ресурсів. Для CSS/JS-файлів, що змінюються рідко — кеш на 1 рік. Логіка проста: якщо браузер вже завантажував ресурс — він бере його з кешу, а не з сервера.

Мінімізація файлів (minification)

Видаліть пробіли, коментарі та зайві символи з CSS, JS і HTML. Кожен сучасний плагін (Autoptimize для WordPress, Webpack для JS-проєктів) робить це автоматично. Зменшення розміру файлів — 10–30%.

Завантаження JavaScript і CSS

JavaScript — найчастіша причина блокування рендерингу. Поки браузер завантажує і виконує JS-файли, відображення сторінки гальмується.

CDN і хостинг

CDN (Content Delivery Network) — мережа серверів по всьому світу. Коли користувач відкриває ваш сайт, він отримує файли з найближчого вузла мережі, а не з сервера у дата-центрі в іншому місті чи країні. Для сайтів із аудиторією в різних регіонах України або за кордоном — CDN скорочує TTFB (час до першого байту) на 40–60%.

Якщо CDN ще не підключено — мінімальний крок: перейти на хостинг із SSD-дисками та Nginx замість Apache. Різниця у відповіді сервера відчутна.

Пріоритети: що прискорює найбільше

Мобільна версія повільніша за десктопну майже завжди. Але Google оцінює саме мобільний досвід — через Mobile-First індексацію. Оптимізуйте під мобільний у першу чергу.

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

Шрифти — часто недооцінений фактор швидкості. Google Fonts зручні для підключення, але у стандартному варіанті вони самостійно завантажуються і можуть блокувати рендеринг сторінки — особливо на мобільних пристроях з повільним з'єднанням.

Проблема Google Fonts і рендер-блокування

Стандартне підключення Google Fonts через тег <link> в head виконує два зовнішніх запити: спочатку до fonts.googleapis.com для CSS, потім до fonts.gstatic.com для файлів шрифтів. На повільному з'єднанні або при холодному кеші браузера — це реально затримує відображення тексту. Ефект: FOIT (Flash of Invisible Text) — текст невидимий до завантаження шрифту, що погіршує LCP і сприйняття швидкості.

Self-hosting шрифтів

Розміщення шрифтів на власному сервері прибирає залежність від зовнішнього CDN. Разом із <link rel="preload"> це дозволяє браузеру завантажити шрифт якнайраніше:

<link rel="preload" href="/fonts/inter-v13-regular.woff2" as="font" type="font/woff2" crossorigin>

У CSS-правилі @font-face вкажіть локальний шлях до файлу формату woff2 (найменший і найшвидший).

font-display: swap vs optional vs block

Для SEO рекомендується font-display: swap або optional. Swap гарантує видимість тексту, optional — мінімальний CLS і найкращий LCP при повторних відвідинах.

Мінімізація накреслень (weight/style)

Кожне накреслення — окремий файл. Regular 400 + Bold 700 — мінімальний набір для більшості сайтів. Italic додає ще два файли. Кожен шрифтовий файл woff2 важить 15–50 KB. На сайті з 6 накресленнями — це 90–300 KB тільки шрифтів. Перевірте, які накреслення реально використовуються: PageSpeed Insights покаже «Ensure text remains visible» якщо є render-blocking шрифти.

Variable fonts (змінні шрифти)

Variable fonts — один файл замість кількох накреслень. Наприклад, Inter Variable (.woff2) охоплює всі ваги від 100 до 900 в одному файлі розміром ~60–80 KB. Порівняно зі стандартними файлами для 4–6 накреслень (100–200 KB сумарно) — це значна економія і менша кількість HTTP-запитів. Підтримка: всі сучасні браузери. Як підключити:

@font-face { font-family: 'Inter'; src: url('/fonts/inter-variable.woff2') format('woff2'); font-weight: 100 900; font-display: swap; }

Критичний шлях рендерингу (Critical Rendering Path)

Critical Rendering Path (CRP) — послідовність кроків, яку браузер виконує від отримання HTML до відображення пікселів на екрані. Розуміння цієї послідовності дозволяє цілеспрямовано оптимізувати перші секунди завантаження.

Послідовність: DOM → CSSOM → Render Tree → Layout → Paint

1. DOM (Document Object Model) — браузер парсить HTML і будує дерево елементів. Блокується, якщо зустрічає <script> без async/defer.
2. CSSOM (CSS Object Model) — будується з CSS файлів. Рендеринг сторінки заблокований до повного завантаження і парсингу всіх CSS.
3. Render Tree — об'єднання DOM і CSSOM. Містить тільки видимі елементи.
4. Layout — браузер обчислює розміри і позиції всіх елементів.
5. Paint — відмальовування пікселів на екрані. Після цього — First Contentful Paint (FCP).

Render-blocking resources

Render-blocking ресурси — CSS і JS файли, які затримують крок Paint. Будь-який <link rel="stylesheet"> в <head> є render-blocking за замовчуванням. Будь-який <script> без async або defer — також. Lighthouse показує ці ресурси у розділі «Eliminate render-blocking resources» з оцінкою економії часу.

Critical CSS: вбудовування стилів для Above The Fold

Щоб браузер міг виконати перший Paint без очікування завантаження зовнішнього CSS файлу — вбудуйте мінімальний набір стилів для Above The Fold прямо в <style> в <head>. Решту стилів завантажуйте асинхронно:

<link rel="stylesheet" href="/css/main.css" media="print" onload="this.media='all'">

Для WordPress — плагіни WP Rocket і LiteSpeed Cache мають вбудовану генерацію Critical CSS. Для інших платформ — npm-пакет critical або penthouse.

First Contentful Paint (FCP) і чому він важливий

FCP — час від початку навігації до відображення першого текстового або графічного контенту. Хороший FCP: менше 1.8s. Це не рейтинговий сигнал Google напряму (LCP є рейтинговим), але FCP впливає на сприйняття швидкості користувачем і поведінкові метрики — особливо на мобільних з повільним з'єднанням.

Above The Fold оптимізація

Above The Fold — частина сторінки, видима без скролу. Це пріоритетна зона: браузер повинен відобразити її якнайшвидше. Практичні заходи:

• LCP-зображення (зазвичай hero) — завантажуйте з <link rel="preload"> в head, не loading="lazy"
• Critical CSS для цієї зони — вбудований, не в зовнішньому файлі
• Шрифти для заголовка і основного тексту — preload
• Не ставте сторонні скрипти (аналітика, чати) перед рендерингом — defer або завантаження після взаємодії

Оптимізація для WordPress

WordPress — найпопулярніша CMS у світі, і більшість сайтів на ньому мають значний потенціал для прискорення. Сам по собі WordPress не є повільним — повільним його роблять погано налаштовані плагіни, завеликі теми і відсутність кешування.

Топ плагіни для швидкості: порівняння

Database optimization

WordPress накопичує сміття в базі даних, яке уповільнює запити:

• wp-cron — псевдо-cron WordPress виконується при кожному запиті. При великому трафіку це створює паразитне навантаження. Вимкніть через wp-config.php (define('DISABLE_WP_CRON', true);) і налаштуйте реальний cron на сервері.
• Transients — тимчасові дані, які WordPress зберігає в wp_options. З часом накопичуються старі transients. Очищення — плагін Transients Manager або WP-Optimize.
• Revision cleanup — WordPress зберігає необмежену кількість ревізій записів. Обмежте через wp-config.php: define('WP_POST_REVISIONS', 3);. Старі ревізії очистіть через WP-Optimize.
• Spam comments — видаляйте спам-коментарі через Akismet + регулярна очистка. Таблиця wp_comments з тисячами спам-записів уповільнює запити.

Відключення непотрібних функцій WordPress

WordPress за замовчуванням завантажує ряд ресурсів, які більшість сайтів не потребує:

• Emoji скрипт — WordPress автоматично завантажує wp-emoji-release.min.js. Якщо не використовуєте emoji в контенті — відключіть через functions.php або плагін Disable Emojis.
• Dashicons на фронтенді — іконки адмін-панелі завантажуються навіть для неавторизованих користувачів якщо плагін посилається на них. Перевірте через DevTools → Network і відключіть якщо не потрібні.
• jQuery Migrate — бібліотека для сумісності старих плагінів. Якщо всі плагіни сучасні — jQuery Migrate зайва. Відключіть через WP Rocket або вручну в functions.php.
• Embed і oEmbed — якщо не вставляєте відео або твіти через URL — ці скрипти зайві.

Додаткові налаштування WP Rocket і LiteSpeed Cache

Базова активація плагіну — це половина роботи. Є конкретні налаштування, які дають помітний ефект:

• WP Rocket → Preload: увімкніть прогрів кешу (Preload Cache) — плагін сам обійде сайт і закешує сторінки до першого відвідувача. Без цього перший після очищення кешу відвідувач отримує некешовану сторінку з повільним TTFB.
• WP Rocket → Delay JS Execution: відкладає виконання JavaScript до першої взаємодії користувача (кліку, скролу). Особливо ефективно для зниження TBT і поліпшення INP на сторінках з багатьма сторонніми скриптами.
• LiteSpeed Cache → Object Cache: підключіть Redis або Memcached через налаштування плагіну. TTFB для динамічних сторінок WordPress падає до 30–80ms замість типових 200–500ms. Вимагає підтримки на рівні хостингу — уточніть у провайдера.
• Imagify / ShortPixel → Bulk Optimization: запустіть масове перетворення всіх наявних зображень у WebP у фоновому режимі. Для великих медіатек (1000+ зображень) — розбивайте на партії по 200–300, щоб не навантажувати сервер.

Серверна оптимізація

TTFB (Time to First Byte)

TTFB — час від запиту браузера до отримання першого байту відповіді від сервера. Норма за рекомендацією Google: менше 200ms. TTFB > 600ms є сигналом в Lighthouse і безпосередньо погіршує LCP. Причини поганого TTFB:

• Повільний хостинг (shared hosting з перевантаженим сервером)
• Відсутнє серверне кешування (кожен запит генерується заново)
• Важкі SQL-запити (WordPress без оптимізації БД)
• Фізична відстань до сервера

HTTP/2 і HTTP/3 — переваги мультиплексування

HTTP/1.1 дозволяє лише 6 паралельних з'єднань на домен. HTTP/2 додає мультиплексування — кілька запитів і відповідей в одному з'єднанні без черги. Ефект: суттєво менша затримка при завантаженні сторінок з багатьма ресурсами (CSS, JS, шрифти, зображення).

HTTP/3 (QUIC) іде далі — використовує UDP замість TCP, що дає швидший старт з'єднання і краще відновлення при packet loss. Особливо помітно на мобільних мережах. Перевірте підтримку: більшість сучасних хостингів з Nginx 1.25+ і LiteSpeed підтримують HTTP/3.

Keep-Alive з'єднання

Keep-Alive дозволяє повторно використовувати TCP-з'єднання для кількох запитів замість встановлення нового на кожен ресурс. На Nginx: параметр keepalive_timeout 65;. Ефект мінімальний при HTTP/2, але важливий для HTTP/1.1-клієнтів.

Серверне кешування: Redis і Memcached

Redis і Memcached зберігають часто використовувані дані в оперативній пам'яті, щоб уникнути повторних звернень до бази даних. Для WordPress: Redis Object Cache — найпопулярніший варіант. При правильному налаштуванні TTFB падає з 200–400ms до 20–50ms для кешованих запитів.

Shared vs VPS vs Cloud хостинг і вплив на швидкість

Регіон сервера для UA-аудиторії

Для сайтів з переважно українською аудиторією найближчий регіон — Варшава (AWS eu-central-1, Azure Poland Central) або Франкфурт. Різниця між сервером у Варшаві і сервером в Сінгапурі для UA-користувача — 200–400ms TTFB тільки за рахунок RTT (Round Trip Time). При виборі хостинга завжди перевіряйте через WebPageTest.org з тестовим вузлом у Варшаві або Амстердамі.

Найчастіша помилка при виборі хостингу — орієнтація на ціну, а не на географію. Хостинг за 3$/міс у США для сайту з UA-аудиторією дасть TTFB 400–600ms — і ніякі інші оптимізації не компенсують цей базовий lag.

Вимірювання і моніторинг швидкості

Як відстежувати деградацію після оновлень

Швидкість сайту деградує непомітно: новий плагін, оновлення теми, додавання сторонніх скриптів — кожна зміна може погіршити PageSpeed на 5–15 балів. Без систематичного моніторингу це помічають тільки коли позиції вже впали.

Мінімальний підхід: після кожного значимого оновлення — перевірка PageSpeed Insights для 3–5 ключових сторінок (головна, категорія, картка товару). Фіксуйте результати в таблиці — це дає розуміння тренду.

Lighthouse CI в CI/CD

Lighthouse CI — інтеграція автоматичного Lighthouse-тесту в pipeline розгортання. При кожному deploy або PR автоматично запускається Lighthouse і результати порівнюються з baseline. Якщо Performance Score падає нижче порогу — build можна заблокувати.

Налаштування для GitHub Actions: npm-пакет @lhci/cli + конфіг lighthouserc.js з порогами. Безкоштовно для публічних репозиторіїв.

SpeedCurve і DataDog RUM

SpeedCurve — платформа моніторингу швидкості в реальному часі. Відстежує Core Web Vitals, LCP, CLS для реальних користувачів, будує графіки динаміки і алертить при деградації. Порівнює вас із конкурентами. Оптимально для e-commerce і великих контентних сайтів де швидкість напряму конвертується в гроші.

DataDog RUM (Real User Monitoring) — більш широкий інструмент моніторингу, але включає Web Performance метрики. Дозволяє сегментувати дані за пристроями, браузерами, географією.

WebVitals.js для польового збору

Бібліотека web-vitals від Google дозволяє збирати реальні Core Web Vitals від ваших користувачів і відправляти їх у вашу аналітику (Google Analytics 4, DataDog, власний endpoint):

import {onLCP, onINP, onCLS} from 'web-vitals'; onLCP(metric => sendToAnalytics(metric)); onINP(metric => sendToAnalytics(metric));

Це дає реальні дані по реальним пристроям і з'єднанням — на відміну від лабораторних даних Lighthouse.

GSC Core Web Vitals report — як читати

Звіт Core Web Vitals у GSC (Experience → Core Web Vitals) показує статус URL-груп: Good / Needs Improvement / Poor. Важливо розуміти:

• Дані агрегуються за 28-денний rolling window — зміни видно з лагом
• URL-групи — GSC кластеризує схожі сторінки. Проблема в одній URL-групі може стосуватись сотень сторінок
• Клацніть на URL-групу → «Open Report» → побачите конкретні URL і метрики
• Виправте проблему → GSC перевірить через 28 днів → статус зміниться на Good

На практиці

Київська мережа піцерій з онлайн-замовленням прямо зі сторінки меню виявила критичну проблему через GSC Core Web Vitals report: LCP сторінки меню на мобільних сягав 7,4 секунди, вся URL-група зі статусом «Poor». Waterfall-аналіз у GTmetrix розкрив джерело — 34 фотографії страв у форматі JPEG загальною вагою 9,2 MB без lazy loading, плюс скрипт кошика, що завантажувався синхронно в <head> і затримував появу кнопки «Замовити» на 3,1 секунди.

Дані Hotjar підтвердили: 67% користувачів залишали сторінку до того, як кнопка ставала активною.

За тиждень роботи конвертували всі 34 фотографії страв у WebP через ShortPixel — медіатека зменшилась з 9,2 MB до 2,6 MB, зображення нижче першого екрану отримали loading="lazy". Скрипт кошика перенесли в defer: кнопка «Замовити» стала доступною ще до повної ініціалізації скрипту.

LCP впав з 7,4 до 1,8 секунди, PageSpeed mobile виріс із 31 до 87 балів. Конверсія зі сторінки меню зросла на 28% за перші 4 тижні — відстежували через Google Analytics 4 за подією begin_checkout.

Коли LCP-елементом є фотографія страви чи товару — конвертація в WebP дає найбільший ефект серед усіх оптимізацій. Але перш ніж починати: відкрийте Lighthouse на мобільній версії і подивіться, який саме елемент є LCP. Якщо це зображення без loading="lazy", але й без rel="preload" — воно конкурує саме із собою за пропускну здатність.

Часті запитання

Яка швидкість завантаження вважається хорошою для SEO?

За стандартами Google Core Web Vitals: LCP (Largest Contentful Paint) має бути до 2,5 секунди, FID/INP — до 200 мс, CLS — до 0,1. PageSpeed Insights Score від 90+ вважається хорошим. Для мобільних пристроїв ці пороги важливіші, оскільки Google ранжує за мобільною версією.

Які основні причини повільного завантаження сайту?

Найчастіші причини: незжаті зображення у застарілих форматах (JPEG/PNG замість WebP/AVIF), відсутність кешування, блокуючий JavaScript і CSS у верхній частині сторінки, повільний хостинг з великим TTFB (понад 600 мс), відсутність CDN, завантаження сторонніх скриптів (чати, пікселі) без defer/async.

Як безкоштовно перевірити швидкість сайту?

Три основні безкоштовні інструменти: Google PageSpeed Insights (pagespeed.web.dev) — дані з реальних Chrome-користувачів і лабораторний аналіз; Google Search Console → розділ «Core Web Vitals» — агреговані дані по всьому сайту; GTmetrix — детальний водоспадний аналіз запитів. Перевіряйте мобільну і десктопну версію окремо.

Чи впливає хостинг на швидкість завантаження і ранжування?

Так, прямо. TTFB (Time To First Byte) — час відповіді сервера — повністю залежить від хостингу. Хороший TTFB: до 200 мс. Якщо хостинг дає TTFB 800+ мс, жодна фронтенд-оптимізація не компенсує це повністю. Переїзд з shared-хостингу на VPS або хмарний сервер (AWS, Google Cloud) дає зниження TTFB у 2–5 разів.