Після редизайну сайт може виглядати сучасніше, але працювати повільніше. Новий шаблон, великі зображення, додаткові скрипти, вебшрифти або зміни на сервері впливають на показники Core Web Vitals — LCP, INP і CLS. Червоні значення в PageSpeed Insights не завжди означають критичну несправність, але часто вказують на проблеми, які погіршують користувацький досвід і можуть знижувати ефективність сайту в пошуку.
Важливо не починати оптимізацію навмання. Перед змінами варто створити резервну копію файлів і бази даних, особливо якщо планується редагування теми, плагінів, конфігурації кешування або серверних налаштувань. Невдала оптимізація може порушити верстку, роботу форм чи окремих функцій.
Що змінилося після редизайну
Спочатку потрібно порівняти сайт до і після редизайну. Навіть якщо візуальні зміни здаються незначними, швидкість могли погіршити:
- новий конструктор сторінок або важча тема WordPress;
- додаткові блоки, слайдери, відео, анімації та спливаючі вікна;
- зображення у надто великій роздільній здатності;
- нові вебшрифти з кількома накресленнями та мовами;
- маркетингові, аналітичні або рекламні скрипти;
- зміни в системі кешування, CDN або налаштуваннях хостингу;
- помилки в CSS і JavaScript, через які браузер завантажує зайві ресурси.
Окремо перевірте, чи не змінилися URL-адреси зображень, правила кешу та формат графіки. Після перенесення на інший сервер можуть зникнути стиснення, кешування браузером або підтримка сучасних форматів WebP та AVIF.
Для коректного порівняння тестуйте ті самі сторінки, бажано в однакових умовах. Перевірка лише головної сторінки не покаже проблеми на картках товарів, у блозі, каталозі чи на сторінках із формами.
Як знайти причини поганих LCP INP і CLS
LCP показує, за який час стає видимим найбільший елемент основного вмісту сторінки. Ним може бути заголовок, банер, зображення або великий текстовий блок. Поганий LCP часто виникає через повільну відповідь сервера, блокувальні CSS і JavaScript, важке головне зображення або відсутність попереднього завантаження потрібного ресурсу.
INP характеризує швидкість реакції сторінки на дії користувача: натискання, введення тексту, відкриття меню. На цей показник негативно впливають довгі JavaScript-завдання, велика кількість сторонніх скриптів, складні анімації та перевантажений DOM.
CLS відображає несподівані зміщення елементів під час завантаження. Причиною можуть бути зображення без заданих розмірів, пізніше завантаження шрифтів, рекламні блоки без зарезервованого місця або вставка банерів після появи основного контенту.
Для первинної діагностики використовуйте PageSpeed Insights, Lighthouse і вкладку Performance у Chrome DevTools. Перевіряйте не тільки загальну оцінку, а й конкретні рекомендації:
- визначте елемент, який формує LCP;
- перегляньте найдовші JavaScript-завдання та обробники подій;
- знайдіть ресурси, що блокують відображення;
- перевірте зміщення елементів у процесі завантаження;
- порівняйте результати на мобільному та настільному пристроях;
- зіставте лабораторні показники з польовими даними Chrome User Experience Report.
Якщо після редизайну одночасно погіршилися всі показники, причина може бути комплексною: повільний сервер посилює LCP, надлишковий JavaScript погіршує INP, а динамічна верстка спричиняє CLS. У такій ситуації зміна одного плагіна не обов’язково вирішить проблему.
Оптимізація зображень шрифтів і скриптів
Зображення варто зберігати в розмірах, близьких до фактичного відображення на екрані. Великі оригінали не слід завантажувати на сторінку, якщо блок показує їх у значно меншому розмірі. Використовуйте WebP або AVIF після перевірки сумісності, задавайте атрибути ширини й висоти та застосовуйте відкладене завантаження для зображень, які розташовані нижче першого екрана.
Головне зображення, від якого залежить LCP, не варто бездумно відкладати. Для нього може знадобитися правильний пріоритет завантаження, оптимальний формат і попереднє завантаження. Водночас надмірне використання preload здатне створити конкуренцію між ресурсами, тому цей інструмент потрібно застосовувати лише для справді критичних файлів.
Під час роботи зі шрифтами:
- залиште лише потрібні сімейства, накреслення та мовні набори;
- використовуйте сучасні формати, зокрема WOFF2;
- перевірте політику
font-display; - за можливості розміщуйте критичні шрифти локально;
- не підключайте кілька незалежних бібліотек для однакової функції.
JavaScript потрібно проаналізувати за призначенням, а не просто мінімізувати. Непотрібні плагіни та інтеграції краще вимкнути після перевірки їхнього впливу на сайт. Некритичні скрипти можна завантажувати із затримкою або після взаємодії користувача, але це не повинно ламати аналітику, форми, кошик чи інші бізнес-функції.
Також перевірте CSS: видалення невикористаних стилів, критичний CSS і правильне кешування можуть скоротити час відображення. Перед очищенням або об’єднанням файлів обов’язково протестуйте адаптивність, меню, модальні вікна та інтерактивні елементи. Збережіть резервну копію, оскільки конфлікт оптимізаторів іноді призводить до помилок на всьому сайті.
Як перевірити мобільну версію
Мобільна перевірка має бути окремим етапом, а не зменшеною копією тесту для комп’ютера. У PageSpeed Insights оберіть мобільний режим і подивіться, як сайт працює за умов обмеженої швидкості мережі та менш потужного процесора.
Додатково відкрийте сайт на реальному смартфоні. Перевірте завантаження головної сторінки, меню, пошуку, форм, фільтрів, кошика та інших ключових дій. Зверніть увагу, чи не зміщуються кнопки під час появи банерів і чи не перекриває контент фіксована шапка або спливаюче повідомлення.
У Chrome DevTools можна перевірити різні ширини екрана, throttling мережі та CPU. Однак емуляція не повністю замінює реальні польові дані. На результат впливають модель телефона, якість мобільної мережі, географія користувача, кеш браузера та сторонні сервіси.
Якщо мобільна версія повільна лише на окремих сторінках, порівняйте їхню структуру та список ресурсів. Часто проблема пов’язана не з усім сайтом, а з конкретним шаблоном, галереєю, відеоблоком або плагіном.
Коли очікувати оновлення польових даних
Польові дані відображають досвід реальних користувачів за певний період, тому вони не змінюються одразу після внесення оптимізацій. Спочатку можна побачити покращення в лабораторному тесті Lighthouse або PageSpeed Insights, а польові показники оновляться пізніше, коли буде зібрано достатньо нових даних.
Оцінка може залишатися червоною навіть після технічного виправлення, якщо значна частина користувачів ще працює зі старою версією сторінки, повільними пристроями або нестабільним підключенням. Також варто враховувати, що польові дані зазвичай агрегуються за період, а не показують результат одного конкретного відвідування.
Після змін перевірте сайт повторно через кілька інструментів і порівняйте однакові URL. Контролюйте не лише оцінку, а й фактичні значення LCP, INP і CLS, а також помилки сервера, час відповіді та роботу кешу.
Спеціаліст потрібен, якщо після редизайну сайт має нестабільні результати, з’явилися помилки JavaScript, порушилася мобільна верстка, не працюють форми або незрозуміло, який компонент створює навантаження. Повноцінна діагностика допоможе відокремити проблеми фронтенду від несправностей WordPress, бази даних, сервера чи конфігурації кешування та зменшити ризик втрати даних під час ремонту.