Швидкість — єдина технічна характеристика сайту, яку одразу відчуває кожен відвідувач. Він не бачить вашого коду й не знає про плагіни, але точно знає, скільки секунд дивиться на білий екран. І якщо їх забагато — просто закриває вкладку.
Розберемо, з чого складається оптимізація швидкості сайту: що вимірює Google, що насправді гальмує сторінку, у якому порядку це лікувати і чого не варто чекати від «плагіна кешування».
Чому швидкість важлива не лише для SEO
Core Web Vitals входять у сигнали ранжування — про це ми говорили в статті про SEO-оптимізацію сайту. Але вплив швидкості значно ширший:
- Конверсія. Частина відвідувачів іде ще до того, як побачить вашу пропозицію. Особливо болісно на платному трафіку: за цей візит ви вже заплатили.
- Поведінкові показники. Швидка сторінка отримує більше переглядів і менше відмов.
- Бюджет сканування. Робот обходить швидкий сайт глибше й частіше.
- Мобільні користувачі. 4G у дорозі — не оптоволокно в офісі, де ви тестуєте сайт.
Core Web Vitals простими словами
Google звів досвід користувача до трьох метрик. Кожна відповідає на просте питання.
LCP — коли з’явився головний контент
Largest Contentful Paint фіксує момент, коли відмалювався найбільший видимий елемент — зазвичай банер або заголовок першого екрана. Ціль — до 2,5 секунди. Найчастіші винуватці: важке зображення в hero-блоці, повільна відповідь сервера, шрифти, що блокують рендер.
INP — наскільки швидко сторінка реагує
Interaction to Next Paint замінив старий FID. Він вимірює затримку між кліком користувача й видимою реакцією інтерфейсу. Ціль — до 200 мс. Псує показник надлишковий JavaScript: поки головний потік зайнятий, кнопка «не натискається».
CLS — чи не стрибає верстка
Cumulative Layout Shift — сумарний зсув контенту під час завантаження. Класика: ви цілитеся в кнопку, зверху дозавантажується банер, і ви натискаєте зовсім не те. Ціль — до 0,1. Лікується заданими розмірами зображень і зарезервованим місцем під рекламу й віджети.
Лабораторні дані проти польових
Важливо розрізняти два типи вимірювань, інакше ви оптимізуєте не те.
- Lab data (Lighthouse, PageSpeed Insights) — синтетичний тест в емульованих умовах. Показує причини й дає перелік проблем.
- Field data (CrUX, Search Console) — реальні відвідувачі, їхні пристрої й мережі. Саме ці цифри враховує ранжування.
Не ганяйтеся за «100 балів у Lighthouse». Бал — похідна, а не мета. Сайт із 78 балами й зеленими польовими метриками кращий за сайт зі 100 балами, який реальні користувачі бачать повільним.
Що насправді гальмує сайт
Зображення
Найчастіша й найдешевша у виправленні причина. Типова помилка — фотографія 4000 px, стиснута до 400 px засобами CSS: браузер усе одно завантажує оригінал. Що робити: віддавати WebP (або AVIF), генерувати кілька розмірів і підключати через srcset, задавати width і height в атрибутах, вмикати loading="lazy" для всього нижче першого екрана — але не для головного зображення hero-блоку, інакше LCP погіршиться.
Сторонні скрипти
Чат-віджет, дві системи аналітики, піксель, карта, віджет відгуків, шрифти з чужого CDN — кожен тягне свій код і свої запити. Часто саме вони, а не ваш сайт, з’їдають секунди й псують INP. Правило: кожен сторонній скрипт має довести свою потрібність. Те, що лишилося, — вантажити відкладено, після взаємодії.
Роздутий CSS і JS
Універсальні теми та візуальні конструктори підключають стилі й скрипти на всі випадки життя — навіть якщо сторінка складається з заголовка й двох абзаців. Звідси мегабайти невикористаного CSS. Власна тема з критичним CSS у head і рештою — асинхронно, дає приріст, який не витягне жоден плагін кешування.
Шрифти
Три накреслення замість двох — плюс сотні кілобайт і затримка тексту. Тримайте шрифти локально (а не з чужого CDN), обмежтеся 2–3 накресленнями, використовуйте font-display: swap і preload для основного шрифту.
Сервер і хостинг
Якщо сервер думає 800 мс, перш ніж віддати перший байт, фронтенд-оптимізація рятує мало. Дивіться на TTFB: адекватний орієнтир — до 200 мс. Дешевий shared-хостинг, стара версія PHP, база без індексів і сотня плагінів — типовий набір, що дає повільний бекенд.
Кешування: що і на якому рівні
«Поставити плагін кешування» — не стратегія. Кеш буває на кількох рівнях, і кожен вирішує своє завдання:
- Кеш сторінок — готовий HTML замість повторної генерації. Найбільший ефект для анонімних відвідувачів.
- Object cache (Redis, Memcached) — кеш запитів до бази. Критичний для магазинів і сайтів з авторизацією.
- OPcache — скомпільований PHP-байткод. Вмикається на сервері, майже завжди виправдано.
- Кеш браузера — статика (зображення, шрифти, CSS) не перезавантажується на кожному візиті.
- CDN — файли віддаються з вузла, ближчого до користувача.
Мінімальні заголовки кешу для статики на Apache виглядають так:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css application/javascript image/svg+xml
</IfModule>Довгий строк життя безпечний, якщо у назвах файлів є хеш версії — тоді після оновлення браузер завантажує новий файл, а не тримає старий із кешу.
Як прискорити WordPress: порядок дій
- Виміряти й зафіксувати старт. PageSpeed Insights + Search Console, обов’язково мобільна версія.
- Актуальний PHP і нормальний хостинг. Дивимося TTFB — це база, без неї далі немає сенсу.
- Ревізія плагінів. Видалити невикористані; кожен, що лишився, перевірити на вплив.
- Зображення. WebP, правильні розміри,
srcset, lazy-load (крім hero). - Скрипти й стилі. Прибрати невикористане, відкласти несуттєве, критичний CSS — у head.
- Кешування. Сторінки, object cache, заголовки для статики, за потреби CDN.
- База даних. Ревізії, спам, транзієнти, autoload-опції.
- Повторний замір і контроль польових даних протягом місяця.
Якщо після цього метрики все одно червоні — проблема, найімовірніше, в архітектурі теми. Іноді дешевше зробити чисту тему під ключ, ніж нескінченно лікувати наслідки конструктора.
Типові помилки
- Ганятися за балами. 100 у Lighthouse при червоних польових даних нічого не варті.
- Ставити три плагіни оптимізації одночасно. Вони конфліктують і ламають верстку.
- Lazy-load на hero-зображення. Прямий шлях зіпсувати LCP.
- Мінімізувати все підряд без перевірки. Об’єднання JS може зламати залежності.
- Тестувати з увімкненим кешем браузера. Перевіряйте в інкогніто.
- Оптимізувати лише головну. Трафік приходить на внутрішні сторінки.
Часті питання
Чому сайт повільно завантажується?
Найчастіше через важкі зображення, надлишок плагінів і сторонніх скриптів, роздутий CSS універсальної теми та повільний сервер. Точну причину показує звіт PageSpeed Insights разом із вкладкою Network у браузері: там видно, який саме файл затримує рендер.
Чи достатньо плагіна кешування?
Ні. Кеш прискорює віддачу вже згенерованої сторінки, але не зменшує вагу зображень, не прибирає невикористаний CSS і не рятує від десятка сторонніх скриптів. Це важливий інструмент, а не заміна оптимізації.
Скільки має важити сторінка?
Універсального нормативу немає, але орієнтир для контентної сторінки — кілька сотень кілобайт, а не мегабайти. Практичніше дивитися не на вагу, а на метрики: LCP до 2,5 с, INP до 200 мс, CLS до 0,1 на мобільному пристрої з реальною мережею.
Чи впливає хостинг на швидкість?
Так, і суттєво. Хостинг визначає TTFB — час до першого байта. Якщо сервер відповідає повільно, жодна фронтенд-оптимізація не компенсує цю затримку, бо браузер просто чекає. Орієнтир — TTFB до 200 мс, актуальна версія PHP і можливість увімкнути object cache.
Скільки часу займає оптимізація швидкості?
Базовий пакет — зображення, кешування, ревізія плагінів і скриптів — зазвичай кілька днів роботи. Якщо проблема в архітектурі теми або конструкторі, потрібна глибша переробка, і терміни залежать від обсягу сайту. Точну оцінку дає аудит.
Підсумок
Швидкість — не разова акція, а властивість архітектури. Її неможливо «доклеїти» плагіном до сайту, зібраного з важкої теми й двадцяти розширень. Працює послідовність: швидкий сервер → легка тема → оптимізовані зображення → мінімум скриптів → кеш. І контроль польових метрик, а не балів у тесті.
Надішліть посилання на сайт — подивлюся метрики й скажу, що дасть найбільший приріст швидкості з найменшими зусиллями.
