Як прискорити сайт на WordPress і не зламати ні дизайн, ні функції

Ти відкриваєш свій сайт на телефоні, поки чекаєш каву, і бачиш білий екран, логотип і крутилку. Секунда, друга, третя. Потім нарешті вилазить банер, і вся сторінка підскакує на пів екрана вниз. Ти знаєш, що сайт «нормальний», бо вдома на ноутбуці він відкривається швидко. Клієнт, який стоїть у тій самій черзі за кавою, цього не знає. Він просто закрив вкладку.

Довгий час дизайн і швидкість сайту тягнули ковдру кожен на себе. Спершу «гарно» означало намальовані рамки, тіні, текстури, нестандартні кнопки, і все це важило. Потім прийшли смартфони з повільним мобільним інтернетом, і маятник хитнувся в інший бік: мінімалізм, білі площі, стандартні шрифти, однакові прямокутні блоки. Сайти стали легшими, але й схожими один на одного, як новобудови в одному ЖК.

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

Коли більшість людей сиділа на модемі, сайти були простими HTML-сторінками з кількома картинками. Сьогодні в нас швидкий інтернет, потужні телефони й сервери, а WordPress-сайт може бути інтернет-магазином з фільтрами, особистим кабінетом, бронюванням, картами, калькуляторами, CRM-віджетами, чатом і десятком рекламних пікселів.

Що змінилося за двадцять років

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

Коли ти замовляєш сайт, ти купуєш не набір сторінок, плагінів і макетів у Figma. Ти купуєш інструмент, який має приносити заявки й продажі. Тому «сайт відкривається» ще не означає «сайт готовий».

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

Готовий сайт швидко показує головне, не розвалюється на телефоні, коректно передає заявки й аналітику. Якщо відвідувач пішов, не дочекавшись першого екрана, сайт не зробив своєї єдиної роботи. Тому швидкість має бути частиною якості розробки з першого дня, а не платною «оптимізацією» після запуску.

На ринку це типова історія. Компанія замовляє новий сайт у відомій студії, чекає «преміум», а отримує гарні макети, які на реальному телефоні відкриваються десять секунд. Спершу їх намагаються «підтюнити» плагінами, потім ще раз, а в кінці сайт переробляють з нуля. Гроші за першу версію, місяці роботи й нерви, все в мінус.

Щоб не потрапити в цю історію, перевіряй сайт до приймання в реальних умовах:

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

Саме в цій комплектації сайт і житиме. Якщо швидкість перевіряли без пікселів і чату, ти перевірив зовсім інший сайт. Що ще варто забрати в розробника перед прийманням, щоб потім не залежати від нього, ми розібрали в статті «Підрядник зник. Що залишилося від твого сайту?».

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

1. Хостинг. Провайдер і тариф під реальне навантаження, а не «найдешевший на рік».
2. Тема. Легка основа без сотні шаблонів, які ніхто не використає.
3. Функції. Тільки ті плагіни й інтеграції, в кожного з яких є зрозуміла роль.
4. Контент. Правила для фото, шрифтів і відео ще до того, як сайт почнуть наповнювати.

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

Хостинг входить у головні чинники швидкості WordPress. Але це не означає, що треба одразу купувати найдорожчий сервер. Спершу шукай провайдера зі стабільним часом відповіді сервера, а вже в нього обирай тариф під свій сайт. Як показує практика, власники частіше міняють провайдера через нестабільність і «провали» в певні години, ніж через нестачу функцій у тарифі.

Це орієнтир, а не закон. Погано зібраний сайт на п’ять сторінок може їсти більше ресурсів, ніж акуратний магазин на сотні товарів. Почни з тарифу, якого вистачає з запасом, і нарощуй разом із трафіком.

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

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

Що CDN дає: швидшу доставку картинок, стилів і скриптів, менше навантаження на основний сервер, стабільнішу роботу для віддалених відвідувачів.

Чого CDN не виправить: повільних запитів до бази, важкої теми, конфлікту плагінів, зайвого JavaScript і кривої архітектури. Якщо сторінка важить 10 МБ, CDN просто швидше привезе ці 10 МБ.

Найкращий результат дає зв’язка: нормальний хостинг, правильний тариф, налаштований кеш WordPress, CDN там, де від нього є користь, і акуратно зібраний сам сайт.

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

Що контролює добре зроблена тема

• Структуру: HTML, шаблони сторінок, адаптивність, логіку виведення контенту.
• Ресурси: CSS, JavaScript, шрифти, зображення і порядок їх завантаження.
• Функції: інтерактивні елементи, запити до бази, сумісність із потрібними плагінами.
• Розвиток: можливість додати нову функцію без війни з архітектурою.

Років десять тому WordPress остаточно перетворився з блогового рушія на платформу для бізнес-сайтів і магазинів. Тоді ж вибухнули маркетплейси готових тем: під будь-яку нішу, з демо-контентом, сотнею шаблонів і вбудованим конструктором.

Типова пастка виглядає так. Тема ідеально лягає на дизайн, у ній уже є всі потрібні сторінки, доробити треба небагато. А після наповнення реальним контентом і підключення потрібних плагінів з’ясовується, що вона дуже важка. Плагіни оптимізації піднімають бали, але архітектуру не змінюють. Рано чи пізно підтримка такого сайту коштує стільки, що тему простіше замінити.

Добра тема дає чисту основу, куди легко додати лише потрібне.

Деякі студії, втомившись від ваги WordPress, роблять власну спрощену CMS. Перший результат вражає: сайти легкі й швидкі. Проблеми починаються, коли клієнту потрібна нова функція, інтеграція, магазин чи складніша структура. Розширювати таку систему важко, а залежність від однієї студії стає майже повною.

Перша версія власної CMS лише старт. Далі її треба постійно оновлювати, тестувати, захищати, документувати й підтримувати адмінку та інтеграції. Для цього потрібна окрема постійна команда. Практичніший шлях - не відмовлятися від WordPress, а користуватися ним вибірково: брати те, що потрібно, і не тягнути в проєкт решту.

Ігнорувати швидкість не можна, але й молитися на цифру в PageSpeed Insights теж не варто. Заради кількох балів іноді прибирають корисні блоки, вимикають функції, спрощують дизайн до стерильності й продовжують «оптимізувати» там, де людина вже не відчує різниці.

Швидкий checkout, який не приймає оплату, нікому не потрібен. Як і легка форма, з якої не доходять заявки.

Бал і реальна швидкість ще й не завжди рухаються разом. Коли ми ганяли тестовий WordPress-магазин, на одному з кроків вага головної впала з 2,1 МБ до 576 КБ, кількість запитів - з 64 до 31, а бал Lighthouse як був 85, так і лишився. Людина на повільному мобільному інтернеті цю різницю відчує. Цифра в звіті - ні.

Мета: найшвидша версія саме того сайту, який потрібен бізнесу, з усіма його функціями.

PageSpeed Insights розфарбовує результат у три кольори: 0-49 червоний, 50-89 помаранчевий, 90-100 зелений. Часто трапляється, що власник роками «доганяє» зелену зону на сайті, зібраному на важкому фреймворку: кешування, стиснення, налаштування сервера дають по кілька балів, а сторінки так і застрягають у середині жовтої зони. Новий сайт, спроєктований зі швидкістю в голові, виходить у зелену зону набагато легше.

• Червона зона. Проблему відчувають люди. Можуть страждати заявки й видимість у пошуку.
• Жовта зона. Сайтом цілком можна користуватися, але є запас для покращення.
• Зелена зона. Хороший орієнтир, але не гарантія продажів, дизайну чи позицій.
• 100 балів. Приємний технічний результат, але не мета сама по собі.

І головне: перехід із жовтої зони в зелену рідко помітно змінює позиції сам по собі. Google прямо пише, що хороші результати у звіті Core Web Vitals не гарантують верхніх позицій, а пошук завжди намагається показати найрелевантніший вміст, навіть якщо досвід на сторінці слабший (Google Search Central). Швидкість - лише частина роботи. Для органічного трафіку потрібна системна SEO-оптимізація: структура, контент, технічний стан і зовнішні сигнали.

Що з Core Web Vitals можна полагодити без розробника, ми розписали окремо: Core Web Vitals: що полагодити без розробника.

Сайт здали, все зелене. Через три місяці менеджер завантажує в блог фото з телефона «як є», і головна знову повзе. Тому, якщо ти плануєш сам наповнювати сайт, перше питання до себе чи команди: хто вміє готувати фото для вебу?

Сучасний телефон знімає фото завширшки 4000 пікселів і більше. Для друку чудово, для сайту забагато. На нашому тестовому стенді шість таких фото, вставлених на головну в «повному розмірі», важили 8,3 МБ, тобто 82% усієї ваги сторінки. Сама сторінка з ними важила майже 10 МБ, а найбільший елемент (LCP) на мобільному з’являвся за 44,7 секунди. Коли в тих самих блоках обрали розмір «Великий» (1024 пікселі), вага головної впала до 2,3 МБ, а LCP - до 5,1 секунди. Без жодного плагіна.

Що варто знати:

• WordPress з версії 5.3 сам зменшує завеликі фото до 2560 пікселів по довшому боці й зберігає версію з приставкою -scaled (WordPress Developer Blog). Але це все одно забагато для блоку в тексті.
• У блоці «Зображення» в редакторі є налаштування «Резолюція». Для фото в тексті майже завжди вистачає «Великий». «Повний розмір» - для рідкісних випадків.
• WordPress сам додає loading="lazy" фото нижче першого екрана і fetchpriority="high" головному банеру, якщо ти вставляєш їх стандартними блоками, а не кодом вручну.
• Конвертація в WebP допомагає, але не завжди. На стенді плагін-конвертер частину фото просто пропустив, бо WebP-версія вийшла важчою за і так добре стиснутий JPEG. Головний виграш дає правильний розмір, а не формат.

Що пояснити людям, які наповнюють сайт: рекомендовану ширину фото, орієнтовну максимальну вагу файлу (для фото в тексті розумна межа - до 200-300 КБ), формат і короткий порядок підготовки.

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

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

Для WordPress є десятки плагінів кешування, мінімізації CSS і JavaScript, стиснення зображень, очищення бази й інтеграцій з CDN. Звідси спокуса поставити кілька одразу: кожен же щось прискорює.

На практиці часто виходить навпаки. Хостинг уже має власний серверний кеш. Сайт іде через Cloudflare. Один плагін мінімізує CSS, другий об’єднує файли, сервер кешує результат, а CDN ще раз його обробляє. Підсумок - дубльована робота, застарілі сторінки й баги, які важко відтворити.

Сліди старих рішень теж заважають. На тестовому стенді, щойно ми замінили один кеш-плагін іншим, новий відмовився вмикатися: попередній залишив свій службовий файл advanced-cache.php, і WP Super Cache прямо попередив, що не може працювати, поки цей файл на місці. На робочому сайті такі «привиди» живуть роками.

Ще одна знахідка зі стенда стосується самих плагінів. Вісім плагінів типового набору (конструктор сторінок, його доповнення, слайдер, дві форми, кнопки «поділитися», WooCommerce) разом додали на головну близько 130 КБ, приблизно в шістдесят разів менше, ніж фото. Але стилі конструктора і його доповнень блокували показ сторінки, на якій не було жодного блоку цього конструктора. Після вимкнення п’яти плагінів, яким на сайті не було роботи, бал головної виріс з 60 до 85, а «стрибання» верстки (CLS) зникло. Тобто питання не в кількості плагінів, а в тому, що кожен вантажить і де.

Добрий набір для оптимізації короткий: у кожного інструмента одна зрозуміла роль.

WP Rocket. Платний плагін, який працює на звичайних серверах Apache і Nginx. Його часто обирають, коли хостинг не дає власного комплексу оптимізації: кеш сторінок, відкладення скриптів, ліниве завантаження в одному місці.

LiteSpeed Cache. Безкоштовний. Мінімізацію CSS і JavaScript та оптимізацію зображень у ньому можна використовувати на будь-якому сервері, але головна функція, кеш сторінок, працює тільки на сервері LiteSpeed або через CDN QUIC.cloud (сторінка плагіна). Ми перевірили це на Apache: перемикач «Enable Cache» стоїть у положенні ON, а над ним попередження, що кешування недоступне без LiteSpeed-сервера. Тобто «увімкнено» в налаштуваннях ще не означає «працює». Дізнайся в хостера, на якому сервері твій сайт, перш ніж розраховувати на цей плагін як на кеш.

Обирати треба за серверним середовищем і загальною архітектурою, а не за кількістю галочок у налаштуваннях чи популярністю. Якщо хостинг безкоштовних плагінів не дає, для Apache є прості безкоштовні варіанти на кшталт WP Super Cache. На стенді він скоротив час відповіді сервера на головній з 150-250 мілісекунд до 10-30.

Кілька систем кешування одночасно ставлять лише тоді, коли точно знають, хто з них що кешує.

Експерименти нормальні, на них вчаться. Порівнювати плагіни, міняти теми, вмикати й вимикати відкладення скриптів корисно. Але робити це варто на локальній копії, тестовому сервері або staging-версії сайту. Робочий сайт, з якого йдуть заявки, - не полігон.

Чому це важливо: неправильний кеш може показати старі ціни. Агресивне відкладення JavaScript ламає форми й checkout. Невдале «очищення» бази видаляє потрібні дані. І все це може тиждень лишатися непоміченим, бо адміністратор, залогінений у WordPress, часто бачить некешовану версію, а клієнти - кешовану.

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

Не роби висновків з одного тесту головної. Проблеми часто живуть в окремих шаблонах: головна літає, а сторінка товару повзе.

Що тестувати

• Інформаційні сторінки: головна, сторінка послуги, стаття блогу.
• Каталог: категорія, пошук, фільтри, сортування.
• Комерційні сторінки: товар, кошик, оформлення замовлення, форма заявки.
• Реальну взаємодію: меню, кнопки, форми, стабільність верстки, роботу на телефоні.

І запускай кожен тест кілька разів. На нашому стенді та сама сторінка статті в трьох прогонах поспіль дала 74, 48 і 74 бали. Головна в різних серіях коливалася від 33 до 58. Один прогін - це шум, медіана з трьох уже щось каже.

Відрізняй лабораторні дані від реальних. Lighthouse і діагностика в PageSpeed Insights симулюють одне завантаження. Блок даних реальних користувачів у верхній частині PageSpeed Insights і звіт Core Web Vitals у Search Console показують досвід справжніх відвідувачів за останні 28 днів, якщо трафіку достатньо (PageSpeed Insights). Дивись не лише на бал, а й на те, коли з’являється головний вміст, чи можна одразу натиснути кнопку, чи не стрибає сторінка і чи працюють форми.

Окремо подивись на аналітику, рекламні пікселі, онлайн-чати, відео, карти, CRM-віджети і сервіси відгуків. Прибрати їх зазвичай не можна, бо вони потрібні бізнесу. Задача - вантажити їх так, щоб вони не блокували головне. На стенді вбудовані YouTube і Google Maps разом тягнули близько 1,5 МБ ще до того, як людина до них догорнула. Звичайне loading="lazy" не допомогло: сторінка коротка, і браузер підвантажував їх заздалегідь. Допомогла проста заміна: обкладинка відео з посиланням на YouTube і кнопка «Відкрити на карті» замість вбудованої карти.

1. Переконайся, що проблема є. Протестуй кілька типів сторінок на телефоні й комп’ютері, по три прогони.
2. Знайди головне обмеження. Сервер, тема, фото, база, JavaScript чи сторонній сервіс. У звіті Lighthouse дивись, що саме важить найбільше.
3. Прибери найбільшу проблему. Одне велике виправлення дає більше, ніж двадцять дрібних налаштувань.
4. Перевір, що все працює. Форми, меню, фільтри, кошик, оплата, особистий кабінет. І лише потім міряй знову.

Ось як цей алгоритм спрацював на тестовому WordPress-магазині з темою Astra, WooCommerce і типовим набором плагінів. Медіана трьох прогонів Lighthouse, мобільний профіль:

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

Після технічної частини сайт ще треба просувати. Почати варто з SEO-аудиту: що перевірити самому, а що замовити. А якщо сайт переїжджає на нову тему чи платформу заради швидкості, не загуби трафік по дорозі: Новий сайт запустили. А Google досі шукає старий.

Швидкий WordPress-сайт майже ніколи не є заслугою одного плагіна. Швидкість складається з рішень на кожному етапі: хостинг, тема, спосіб реалізації дизайну, набір функцій і те, як потім працюють з контентом.

І швидкість не може бути єдиною мірою хорошого сайту. Примітивний дизайн, урізані функції чи зламані форми не стануть кращими від 100 балів у PageSpeed.

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

Тому питай себе, яка найшвидша версія сайту зберігає дизайн, потрібні функції й користь для бізнесу.

Якщо твій сайт повільний і незрозуміло, з чого почати, напиши нам. Ми подивимося, що його гальмує, і скажемо, що реально виправити налаштуваннями, а що вже потребує розробки. Як це виглядає на практиці, видно в кейсі LMakeup: прискорення сайту на конструкторі, де доступу до коду не було взагалі.