Повільний сайт на WordPress — часта проблема, яку вирішує якісне кешування. У своїй практиці ми використовуємо WP Rocket як основний інструмент для прискорення проєктів — це платний плагін, який дає повний контроль над кешем, мініфікацією та попереднім завантаженням. При правильному налаштуванні він дозволяє досягти зелених показників Core Web Vitals навіть на недорогому хостингу.
Як працює кешування WP Rocket?
WP Rocket створює статичні HTML-копії сторінок і віддає їх користувачам, минаючи обробку PHP та SQL-запити. В результаті TTFB скорочується в 3-5 разів порівняно з безкоштовними плагінами. Плагін також підтримує попереднє завантаження кешу — після очищення він автоматично прогріває всі сторінки, щоб перший відвідувач не чекав генерації. Докладніше про принципи кешування можна прочитати на Wikipedia.
Наскільки WP Rocket перевершує безкоштовні аналоги?
Безкоштовні плагіни, такі як W3 Total Cache або LiteSpeed Cache, потребують ручного тонкого налаштування і часто призводять до конфліктів. WP Rocket надає готові оптимізації, які працюють з коробки. Наприклад, у тестовому проєкті LCP покращився на 45% завдяки вбудованому лінивому завантаженню та мініфікації, тоді як на W3 Total Cache з такими ж налаштуваннями покращення склало лише 30%. Крім того, WP Rocket не вимагає редагування .htaccess або nginx-конфігів — всі зміни вносяться через інтерфейс.
Чому важливо правильно налаштувати винятки?
Без винятків з кешу можуть постраждати сторінки з динамічним контентом: кошик, оформлення замовлення, особистий кабінет. WP Rocket автоматично додає ці сторінки до списку Never Cache, але для складних WooCommerce-проєктів ми рекомендуємо додатково виключати:
# Не кешувати
/cart/
/checkout/
/my-account/
/wc-api-core
/*/feed/
# Не кешувати для авторизованих
wordpress_logged_in_
Покрокове налаштування WP Rocket
- Аналіз поточного стану. Вимірюємо Core Web Vitals (LCP, FID/INP, CLS) через PageSpeed Insights або Lighthouse. Для отримання стабільних результатів проводимо 3 виміри на різних пристроях.
- Активація кешу. Вмикаємо кешування для мобільних (тільки якщо використовується окрема мобільна тема). TTL виставляємо 10 годин для контентних сайтів, 1 годину — для e-commerce. Для інтернет-магазинів додатково налаштовуємо фрагментоване кешування віджетів кошика.
- Мініфікація CSS/JS. Вмикаємо мініфікацію, тестуємо візуально. Об'єднання CSS — тільки за відсутності HTTP/2. Об'єднання JS — майже завжди вимкнено, щоб уникнути блокування рендерінгу. Для критичного CSS використовуємо вбудовану опцію WP Rocket.
- Ліниве завантаження зображень. Вмикаємо для всіх зображень та iframe. Заміна YouTube-прев'ю знижує кількість зовнішніх запитів на 30-50%, а використання WebP зменшує вагу сторінки до 60%.
- Попереднє завантаження. Preload Cache — увімкнути. Preload Links — увімкнути (попередньо завантажує сторінки при наведенні миші). Опція Preload Heartbeat додає фонове попереднє завантаження для оновлених сторінок.
- Інтеграція з CDN. Вказуємо URL CDN (наприклад, Cloudflare). WP Rocket автоматично підміняє шляхи до статики. Для автоматичного скидання кешу Cloudflare використовуємо доповнення WP Rocket + Cloudflare Add-On. При використанні BunnyCDN додатково налаштовуємо Pull Zone.
- Тестування. Перевіряємо всі сторінки, кошик, форми. Вимірюємо підсумкові показники швидкості. Важно перевірити авторизованих користувачів — їх кеш має бути вимкнено.
Від чого залежить термін кешування?
Невиправдано високий TTL призводить до показу застарілого контенту, а низький — до надмірного навантаження. Для блогів з рідкісними публікаціями оптимально 10 годин, для новинних сайтів — 2-3 години. Інтернет-магазинам потрібен TTL не більше 1 години, особливо в періоди акцій. Для точного налаштування використовуйте вимірювання часу між оновленнями сторінок.
Що входить у послугу?
- Аудит поточної продуктивності — вимір Core Web Vitals, TTFB, Time to Interactive, кількість HTTP-запитів.
- Налаштування всіх модулів WP Rocket — кеш, мініфікація, медіа, попереднє завантаження, фрагментоване кешування.
- Інтеграція з CDN — Cloudflare, BunnyCDN, KeyCDN. Допомагаємо обрати провайдера, якщо його немає.
- Налаштування винятків — WooCommerce, форми, авторизовані користувачі, API-ендпоінти.
- Тестування та налагодження — перевірка на сторінках з динамікою, виправлення конфліктів з іншими плагінами.
- Документація — опис усіх налаштувань та рекомендацій з обслуговування, включаючи план регулярного очищення кешу.
Наш досвід та гарантії
Наша команда спеціалізується на оптимізації WordPress понад 5 років. Ми реалізували понад 50 проєктів з WP Rocket, досягнувши покращення LCP на 40-60% та проходження Core Web Vitals на всіх пристроях. Прискорений сайт знижує середню вартість кліка в рекламі та зменшує кількість відмов на 20-30%. Ми гарантуємо працездатність усіх налаштувань — якщо щось ламається, виправляємо безкоштовно.
Терміни та вартість
Налаштування WP Rocket з тестуванням займає від 3 до 8 годин залежно від складності проєкту. Вартість розраховується індивідуально після аналізу поточного стану сайту. Отримайте консультацію інженера — зв'яжіться з нами для попередньої оцінки.
| Тип сайту |
TTL кешу |
Рекомендовані модулі |
| Блог / контентний |
10 годин |
Preload Cache, Lazy Load, Minify CSS |
| Інтернет-магазин |
1 година |
+ Fragment Caching, винятки WooCommerce |
| Сайт з частими оновленнями |
2-3 години |
+ автоматичне очищення при публікації |
| Виключені URL |
Причина |
| /cart/, /checkout/ |
Динамічний контент, кошик |
| /my-account/ |
Персональні дані, замовлення |
| /wc-api/* |
API-запити, не кешуються |
| /.*/feed/ |
RSS-стрічки, оновлюються часто |
Після налаштування ви отримаєте стабільно високу швидкість завантаження та зниження навантаження на сервер. Замовте послугу — пишіть, і ми підберемо оптимальний план.
Чому Core Web Vitals критичні для технічного SEO
PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.
Як досягти хороших показників Core Web Vitals?
Core Web Vitals: що реально впливає на позиції
Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).
LCP: чому 8 секунд — це не проблема зображення
LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.
Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.
Рішення по кроках:
- Переносимо hero з CSS background в
<img> з fetchpriority="high" та loading="eager"
- Конвертуємо в WebP, додаємо
srcset: 800w для мобільних, 1400w для десктопа
-
<link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
- Прибираємо всі render-blocking скрипти вище hero через
defer
Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.
Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.
CLS: зсуви, які дратують користувача і Google
CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.
Джерела CLS:
- Зображення без заданих розмірів.
<img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
- Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через
min-height або завантажувати до рендеру основного контенту.
- Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування.
font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
- Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.
| Типовий сценарій |
CLS до |
CLS після |
Основний фікс |
Банер знижок без min-height |
0.42 |
0.02 |
min-height: 300px |
| Картинки в статтях без атрибутів |
0.18 |
0.01 |
width/height + aspect-ratio |
| Віджет чату, що завантажується через 3с |
0.35 |
0.05 |
position: fixed із зарезервованим відступом |
INP: чому інтерфейс «зависає» на 500ms
INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.
Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.
Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:
- Безперервна обробка великого списку без
requestIdleCallback або requestAnimationFrame
- Важкі event listeners без
debounce/throttle
- Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
- Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread
Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.
Schema.org: розмітка, яку читають роботи
Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.
Типи розмітки за сценаріями:
-
E-commerce:
Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
-
Статті та блог:
Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
-
Локальний бізнес:
LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
-
FAQ:
FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.
Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.
Як проводити технічний SEO-аудит
Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.
Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.
JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.
Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.
Типові помилки при впровадженні Schema.org
- Вказано
price без priceCurrency — розмітка ігнорується.
-
ratingValue без reviewCount — у видачі не показується.
- Кілька
Product на одній сторінці без @type: ItemList — Google бере тільки перший.
- JSON-LD в GTM — Google не завжди бачить динамічну розмітку, краще серверний рендеринг.
| Етап роботи |
Що входить |
Термін |
| Аудит |
Сканування, аналіз Core Web Vitals, аудит Schema, звіт з пріоритетами |
1–2 тижні |
| Оптимізація одного шаблону |
LCP, CLS, INP, впровадження SSR/SSG, налаштування preload |
2–4 тижні |
| Повна технічна оптимізація |
Всі шаблони, code splitting, Web Workers, моніторинг в CI |
4–10 тижнів |
| Впровадження Schema.org |
JSON-LD генерація, валідація, тестування rich snippets |
1–3 тижні |
Що входить в роботу
- Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
- Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
- Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
- Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.
Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.
