Як прискорити сайт: 12 способів покращити швидкість завантаження

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

Проблема в тому, що слово «швидкість» об’єднує різні речі: відповідь сервера, появу головного контенту, готовність сторінки реагувати та візуальну стабільність. Щоб прискорення дало результат, потрібно спочатку визначити слабкий етап, а вже потім змінювати код, медіа чи інфраструктуру.

Цей гайд допоможе власнику бізнесу провести базову діагностику, зрозуміти звіт PageSpeed Insights і поставити розробнику конкретне завдання замість абстрактного «зробіть сайт швидшим».

Що саме означає «швидкий сайт»

Google використовує три основні показники реального досвіду — Core Web Vitals:

Метрика	Що вимірює	Хороший орієнтир
LCP	Коли з’явився головний великий елемент першого екрана	до 2,5 секунди
INP	Як швидко сторінка відповідає на натискання й введення	до 200 мс
CLS	Наскільки сильно блоки несподівано зміщуються	до 0,1

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

LCP відповідає на питання «коли людина побачила головне?». INP — «чи відреагував сайт після дії?». CLS — «чи не втекла кнопка з-під пальця?». Високий бал Lighthouse не замінює жодну з цих відповідей.

Чому PageSpeed щоразу показує інший результат

PageSpeed Insights має два типи даних:

• Field data — анонімізовані дані реальних користувачів Chrome за рухомий період. Саме вони найкраще показують фактичний досвід, але доступні лише за достатнього обсягу відвідувань.

• Lab data — один змодельований тест Lighthouse. Він потрібний для діагностики, але залежить від тестового середовища й може трохи змінюватися між запусками.

Якщо лабораторний бал 95, а реальні Core Web Vitals не проходять, не оголошуйте перемогу. Якщо польових даних ще немає, тестуйте кілька типових сторінок, повторюйте запуск і додавайте власний Real User Monitoring, коли проєкт має достатній масштаб.

Перевіряйте не лише головну. Сторінка послуги, стаття, категорія, картка товару й checkout мають різні шаблони та ресурси. Одна зелена URL не означає, що весь сайт швидкий.

12 способів прискорити сайт

1. Почніть із водоспаду завантаження, а не з випадкових плагінів

PageSpeed дає список можливостей, але не знає вашої архітектури й бізнес-пріоритетів. Відкрийте Chrome DevTools Performance і Network або WebPageTest та знайдіть:

• час отримання HTML;

• елемент LCP;

• коли браузер почав його завантажувати;

• найбільші файли;

• блокувальні CSS і JavaScript;

• довгі задачі головного потоку;

• сторонні домени;

• помилки й повторні запити.

Спочатку сформулюйте діагноз: «LCP-фото починає завантажуватися пізно через слайдер» або «меню не реагує, бо чат і аналітичні скрипти блокують головний потік». Це значно точніше, ніж «PageSpeed червоний».

2. Оптимізуйте головний елемент першого екрана

LCP-елементом часто стає hero-зображення, банер або великий заголовок. Він має бути доступний браузеру якомога раніше. Не ховайте важливе фото всередині CSS-фону чи JavaScript-слайдера, якщо це затримує виявлення ресурсу.

Що перевірити:

• URL головного зображення присутній у початковому HTML;

• воно не має loading="lazy";

• за потреби використовується fetchpriority="high" або preload;

• розмір відповідає реальному контейнеру;

• сервер швидко віддає HTML;

• поверх фото не чекає довга анімація появи.

Не прелоадьте все поспіль. Якщо десяток файлів отримує найвищий пріоритет, пріоритет перестає допомагати.

3. Перетворіть зображення на керований ресурс

Фотографія з камери може важити кілька мегабайт, хоча на картці показується шириною 480 пікселів. Виріжте зайве, створіть адаптивні розміри через srcset і sizes, оберіть WebP або AVIF там, де це доречно, та задайте розумну якість.

Правила:

• не віддавайте мобільному екрану десктопне 4K-зображення;

• не стискайте логотип і просту графіку як велике JPEG;

• використовуйте SVG для доречної векторної графіки;

• перевіряйте візуальну якість, а не лише вагу;

• задавайте width і height, щоб браузер резервував місце;

• вмикайте lazy loading лише для зображень нижче першого екрана.

Для каталогів потрібна автоматична генерація варіантів під час завантаження товару. Ручне стискання кожної фотографії не масштабується.

4. Завантажуйте шрифти без блокування тексту

П’ять гарнітур, сім накреслень і великі набори символів легко створюють сотні кілобайт. Залиште лише реально використані файли, перейдіть на WOFF2, створіть subset потрібних мов і перевірте, чи потрібні всі ваги.

Використовуйте font-display, щоб текст не залишався невидимим. Preload потрібний лише критичним шрифтам першого екрана. Системний fallback має бути близьким за пропорціями, інакше після завантаження вебшрифту текст змінить ширину й погіршить CLS.

5. Приберіть CSS, що блокує перший рендер

Великий глобальний файл стилів змушує браузер чекати навіть правила для сторінок, яких зараз немає. Виділіть критичний CSS першого екрана, приберіть невикористані правила й завантажуйте стилі компонентів там, де вони потрібні.

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

6. Скоротіть і відкладіть JavaScript

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

Пріоритети:

• видалити код і бібліотеки, які не використовуються;

• розділити bundle за сторінками й функціями;

• завантажувати важкі компоненти після наміру користувача;

• використовувати defer або async відповідно до залежностей;

• розбивати довгі задачі й віддавати браузеру можливість відрендерити кадр;

• не створювати весь HTML сторінки на клієнті без потреби;

• контролювати розмір DOM.

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

7. Контролюйте сторонні скрипти

Аналітика, реклама, call tracking, чат, heatmap, A/B-тестування й віджети соцмереж часто додаються різними командами й залишаються назавжди. Створіть реєстр: власник, мета, сторінки, умова запуску, вага й дата перегляду.

Завантажуйте скрипт лише там, де він потрібний. Карта може відкриватися після кліку, чат — після основного контенту, відео — через легкий placeholder. Видаляйте дублікати GTM і старі теги кампаній.

Consent Mode не є інструментом прискорення. Не можна блокувати або запускати теги неправильно лише заради балів — поведінка має відповідати вибору користувача й реальній політиці сайту.

8. Налаштуйте кеш і сучасне стиснення

Браузерний кеш дозволяє не завантажувати незмінні файли повторно. Довгі строки доречні для версіонованих CSS, JS, шрифтів і зображень. HTML зазвичай потребує обережнішої політики, щоб користувач бачив актуальний контент.

На сервері використовуйте Brotli або gzip для текстових ресурсів, сторінковий кеш для публічного контенту й object cache для повторних запитів до даних, якщо архітектура це підтримує. Після кожного оновлення перевірте invalidation: старий кеш не повинен показувати попередню ціну або зламаний CSS.

Не кешуйте бездумно персональний кабінет, кошик чи сторінки з індивідуальними даними.

9. Зменште TTFB і роботу сервера

Якщо HTML починає надходити пізно, оптимізація картинок не прибере кореневу затримку. Причини високого TTFB:

• слабкі або перевантажені ресурси;

• повільна база даних;

• некешовані сторінки;

• довгі зовнішні API-запити;

• зайві редиректи;

• складні плагіни й middleware;

• велика географічна відстань.

Профілюйте сервер і запити до бази. Не переходьте одразу на дорожчий тариф: поганий SQL або зовнішній API може залишитися повільним на потужнішому сервері. Але якщо CPU, RAM або I/O регулярно впираються в ліміт, кодова оптимізація теж не замінить потрібні ресурси.

10. Використовуйте CDN там, де він вирішує реальну проблему

CDN наближає статичні ресурси до відвідувачів, може кешувати відповіді, стискати контент і захищати від частини навантаження. Він особливо корисний для аудиторії з різних регіонів, медіанасичених сайтів і піків трафіку.

Але CDN не виправить повільну базу, великий JavaScript або hero-зображення, яке браузер знаходить занадто пізно. Після підключення перевірте заголовки кешу, purge, HTTPS, редиректи, персоналізований контент і реальний TTFB із потрібних регіонів.

11. Приберіть стрибки макета

CLS погіршують зображення без розмірів, банери cookie, реклама, iframe, вебшрифти й блоки, які вставляються над уже показаним контентом. Зарезервуйте місце через розміри або aspect-ratio.

Не додавайте промосмугу над заголовком після завантаження. Банер cookie має з’являтися передбачувано. Для динамічних блоків використовуйте стабільний контейнер або skeleton відповідного розміру. Анімуйте transform і opacity, коли це можливо, замість властивостей, які запускають перерахунок layout.

12. Введіть бюджет продуктивності й постійний контроль

Оптимізований сайт знову стане повільним, якщо після кожної кампанії додавати новий чат, піксель, шрифт і відео. Визначте бюджет для типових шаблонів:

• максимальна вага першого завантаження;

• бюджет JavaScript;

• кількість сторонніх доменів;

• пороги LCP, INP і CLS;

• обмеження для hero-медіа;

• допустиме падіння перед релізом.

Додайте Lighthouse або інший performance-тест у процес приймання, а реальні Core Web Vitals — у регулярний моніторинг. Тестуйте після зміни теми, плагіна, рекламного тегу, checkout, галереї або хостингу.

Окремий чекліст для WordPress

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

1. Чи не дублюють плагіни одну функцію.

2. Які модулі створюють повільні запити й cron-задачі.

3. Чи має тема важкий builder, глобальний CSS і JS на кожній сторінці.

4. Чи генеруються адаптивні зображення.

5. Чи налаштований page cache та object cache.

6. Чи очищена база від непотрібних revisions, transients і таблиць видалених плагінів — після резервної копії та перевірки.

7. Чи актуальні PHP, WordPress, тема й плагіни.

8. Чи не запускаються WooCommerce-ресурси на сторінках, де вони не потрібні.

9. Чи немає двох плагінів кешування або двох механізмів оптимізації, що конфліктують.

Не встановлюйте п’ять «speed optimizer» одночасно. Кожен може переписувати порядок CSS/JS, створювати окремий кеш і ускладнювати діагностику. Після кожної зміни очищуйте потрібні рівні кешу й тестуйте форми, меню, оплату та адмінку.

Діагностика за симптомом

Симптом	Імовірні причини	Що перевірити першим
Довго білий екран	TTFB, блокувальний CSS/JS, клієнтський рендеринг	HTML response, FCP, waterfall
Головний банер з’являється пізно	великий файл, slider, lazy load, пізнє виявлення	LCP element і request start
Кнопка натискається із затримкою	довгі JS-задачі, великий DOM, сторонні віджети	INP, Long Tasks, Performance trace
Сторінка стрибає	немає розмірів, шрифти, динамічні банери	CLS і Layout Shift track
Повторний візит такий самий повільний	відсутній browser cache	Cache-Control і повторний Network
Повільна лише адмінка	база, cron, плагіни, API	server profiler і slow queries
Повільний лише checkout	API доставки/оплати, JS, сесії	timing кожного запиту й помилки
Десктоп зелений, мобільний червоний	великі ресурси, CPU, непотрібний JS	mobile PSI та реальні пристрої

Перевірка сайту за 30 хвилин

1. Запустіть PageSpeed для головної, послуги, статті та ключової конверсійної сторінки.

2. Спочатку прочитайте field data, потім lab diagnostics.

3. Запишіть LCP-елемент і найбільший ресурс.

4. Перевірте сайт на реальному телефоні через мобільний інтернет.

5. Натисніть меню, форму, фільтр, кошик і модальні вікна під час завантаження.

6. Вимкніть сторонні теги в тестовому середовищі та порівняйте.

7. Подивіться, чи є подвійні зображення, шрифти й JS.

8. Сформуйте три задачі за впливом: критична, середня, косметична.

Мета цього тесту — не виправити все за пів години, а перестати вгадувати.

У якому порядку впроваджувати зміни

Безпечна послідовність:

1. Зафіксувати базові показники й бізнес-конверсії.

2. Виправити помилки, дублікати та випадкові важкі ресурси.

3. Оптимізувати LCP першого екрана.

4. Зменшити JavaScript і сторонні теги.

5. Налаштувати кеш, стиснення й сервер.

6. Виправити CLS та повільні взаємодії.

7. Повторити лабораторні й реальні тести.

Не оптимізуйте production без резервної копії, staging і плану відкату. Комбінація CSS/JS, агресивний кеш або оновлення PHP може зламати форму чи оплату навіть тоді, коли PageSpeed став зеленим.

Чи допоможе швидкість вийти в ТОП Google

Core Web Vitals використовуються системами ранжування Google, але зелені показники не гарантують ТОП. Релевантність, корисність контенту, структура, авторитет і відповідність запиту залишаються важливими. Оптимізувати сайт лише заради ідеальних 100 балів — поганий пріоритет, якщо сторінка не відповідає користувачеві.

Правильна логіка: швидкість прибирає технічний бар’єр, покращує досвід і допомагає сильному контенту реалізувати потенціал. Повний SEO-процес описаний у матеріалі «Як вивести сайт у ТОП Google: покрокова інструкція».

Коли оптимізувати, а коли переробляти архітектуру

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

• кожна сторінка отримує величезний bundle незалежно від функцій;

• важливий контент з’являється лише після складного клієнтського рендерингу;

• builder генерує надмірний DOM і CSS, який неможливо нормально розділити;

• плагіни критично залежать один від одного;

• кешування неможливе через неправильну модель даних;

• кожне невелике покращення ламає іншу частину сайту.

Рішення приймають після профілювання й оцінки вартості. «Низький PageSpeed» сам по собі не є достатнім аргументом для повного редизайну.

Висновок

Щоб прискорити сайт, не починайте з випадкового плагіна або дорожчого хостингу. Визначте, що саме повільне: сервер, головний контент, реакція на дію чи стабільність. Потім оптимізуйте найбільший бар’єр — LCP-ресурс, зображення, JavaScript, сторонні теги, кеш, базу або інфраструктуру.

Хороший результат — це не скриншот зі 100 балами. Це сайт, на якому реальні користувачі швидко бачать потрібне, одразу можуть взаємодіяти й не натискають не туди через стрибок макета. А бізнес при цьому не втрачає форми, оплату, аналітику чи можливість оновлювати контент.

FAQ

Який PageSpeed вважається хорошим?

Для лабораторного Performance score зеленою вважається зона від 90. Але важливіше, чи проходять реальні LCP, INP і CLS. Ідеальні 100 балів не потрібні кожному сайту.

Чому мобільний PageSpeed нижчий за десктопний?

Мобільний тест моделює слабший пристрій і складнішу мережу. Великі зображення та JavaScript сильніше навантажують телефон, тому різниця природна, але її причини потрібно дослідити.

Чи допоможе плагін кешування?

Допоможе, якщо проблема пов’язана з повторною генерацією сторінок і відсутністю кешу. Він не виправить великий hero, зайвий JavaScript, повільний зовнішній API або поганий CLS.

Чи потрібно переносити сайт на інший хостинг?

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

Чи треба ставити lazy loading на всі зображення?

Ні. Зображення першого екрана, особливо LCP, не слід завантажувати ліниво. Lazy loading доречний для контенту нижче viewport.

Скільки часу займає оптимізація?

Критичні помилки інколи виправляються за кілька годин, а системна робота з архітектурою — за кілька спринтів. Термін визначають після вимірювання, а не за одним балом.