Як оптимізація швидкості може зламати сайт: реальний кейс із Delay JS і мобільним меню

Оптимізація WordPress зазвичай виглядає цілком логічно: прибираємо зайві ресурси, відкладаємо JavaScript, налаштовуємо кешування, оптимізуємо CSS — і поступово підтягуємо показники PageSpeed.

Але іноді чергове «покращення» створює проблему, якої в тестах майже не видно.

Нещодавно я натрапив саме на такий випадок на власному сайті PBB Design. На десктопі все працювало нормально. В емуляторі мобільної версії в Chrome DevTools — теж. PageSpeed залишався у високих 90-х.

А на реальному телефоні мобільне меню перестало нормально реагувати на клік.

Цей випадок добре показав мені одну просту річ: оптимізацію швидкості не можна зводити до зеленого кола в PageSpeed Insights.

Коли все виглядає справним — крім самого сайту

Проблема проявилася дуже просто. На телефоні натискаю hamburger menu — нічого не відбувається.

При цьому сама кнопка відображалася нормально, верстка не ламалася, desktop-версія працювала, а в мобільному емуляторі меню відкривалося.

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

І саме такі баги неприємні тим, що їх дуже легко пропустити під час звичайної перевірки. Після зміни CSS або JavaScript відкриваєш DevTools, переходиш у mobile viewport, натискаєш кілька кнопок — усе працює. Є велика спокуса вважати задачу закритою.

У моєму випадку вона закритою не була.

Перший підозрюваний — оптимізація JavaScript

На сайті використовується Kadence і LiteSpeed Cache. Оскільки проблема стосувалася саме взаємодії з елементом інтерфейсу, першим підозрюваним став JavaScript.

У LiteSpeed був увімкнений Delay JS — відкладене виконання частини скриптів до першої взаємодії користувача.

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

У моєму випадку такою взаємодією було відкриття мобільного меню.

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

Як я перевірив, що проблема саме в оптимізації

У LiteSpeed Cache є можливість відкрити сторінку без Page Optimization для конкретного перегляду. Я перевірив сайт на телефоні без оптимізацій — і меню запрацювало.

Це вже суттєво звузило коло пошуку.

Проблема була не в самій мобільній верстці, не в кнопці hamburger і не в структурі меню. Вона з’являлася саме після оптимізації frontend.

Далі я додав скрипти навігації Kadence до виключень:

navigation.min.js

navigation-lite.min.js

Підписуйтеся на наші соцмережі

Також додав їх до виключень для Guest Mode.

Після тесту я виключив navigation.min.js і navigation-lite.min.js із Delay/Deferred JS та Guest Mode — саме ці скрипти відповідають за мобільну навігацію Kadence.

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

Це теж характерний момент. Після зміни налаштувань оптимізації не варто робити висновок лише з одного відкриття сторінки. Одночасно можуть працювати page cache, browser cache, Guest Optimization, окремі кешовані варіанти сторінки та старі JS-ресурси в самому браузері.

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

Чому емулятор не показав проблему

Для мене це була найцікавіша частина цього випадку.

У DevTools mobile mode сайт поводився нормально. Фізичний телефон — ні.

Responsive emulator дуже корисний, але він не є повною заміною реального пристрою. Він чудово показує viewport, breakpoints, адаптивність layout і частину поведінки інтерфейсу. Але реальний мобільний браузер має інше навантаження на CPU, інший кеш, іншу швидкість виконання JavaScript і дещо іншу поведінку під час першої взаємодії.

Особливо добре це видно при агресивному Delay JS.

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

Тому після цього випадку я ще раз переконався: хоча б ключові frontend-сценарії треба перевіряти на реальному пристрої.

PageSpeed 99 не означає, що сайт працює правильно

Мій сайт останнім часом регулярно показує 97–99 балів Performance на мобільному, і я, звичайно, задоволений таким результатом. Але цей кейс добре нагадує просту річ:

PageSpeed не перевіряє, чи може користувач нормально користуватися сайтом.

Він вимірює інше.

Сторінка може швидко відобразити основний контент, мати хороший LCP, майже не мати CLS і отримати зелений Performance — і при цьому мати кнопку, яка не працює.

Це не недолік самого PageSpeed. Просто ми іноді очікуємо від нього більше, ніж він насправді вимірює.

Lighthouse не знає, яка саме взаємодія критична для конкретного бізнесу. Для одного сайту це меню, для іншого — форма заявки, для магазину — «Додати в кошик», для сервісу — бронювання чи оплата.

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

Особливо небезпечна оптимізація «увімкнути все»

Найчастіше проблеми виникають не через один конкретний механізм, а коли одночасно вмикають minify, combine, defer, delay, critical CSS, remove unused CSS, lazy load і guest optimization.

Кожна з цих функцій окремо може бути корисною. Але разом вони змінюють порядок завантаження та виконання великої кількості ресурсів.

Особливо це ризиковано на WordPress-сайті, де тема, плагіни й сторонні сервіси можуть мати різні припущення щодо того, коли саме їхній JavaScript буде доступний.

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

Проблема не в тому, що у вас «багато плагінів». І не в тому, що у вас увімкнений Delay JS.

Проблема з’являється тоді, коли конкретна комбінація компонентів починає працювати не так, як ми очікуємо.

Що я перевіряю після оптимізації frontend

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

На конкретному сайті це можуть бути меню, CTA, форми, popup, фільтри, пошук, кошик, checkout, телефонні посилання або інші інтерактивні елементи.

І хоча б один раз я роблю це на реальному телефоні.

Для невеликого корпоративного сайту така перевірка займає кілька хвилин. Але саме ці кілька хвилин можуть знайти проблему, яку Lighthouse, GTmetrix і desktop DevTools не покажуть.

Тут важливо перевіряти не тільки те, чи відкрилася сторінка, а й чи працюють дії, для яких ця сторінка взагалі створена.

Не кожен бал PageSpeed вартий боротьби

Є ще одна практична межа, яку з часом починаєш відчувати.

Підняти Performance із 50 до 80 часто можна за рахунок очевидних речей: нормальних зображень, кешування, серверної частини, шрифтів або зайвих скриптів.

Перехід від 80 до 95 уже потребує більше уваги.

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

Якщо сайт має 97 замість 100, але всі його ключові функції стабільно працюють, я не вважаю це проблемою.

Якщо він має 100, але користувач не може відкрити мобільне меню — це вже проблема.

Delay JS тут не винен сам по собі

З цього випадку я не зробив висновку «не використовуйте Delay JS».

Я використовую його й далі.

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

Після будь-якого defer або delay варто перевіряти все, що залежить від JavaScript: меню, форми, popup, sliders, filters, search, checkout та інші interactive elements.

І бажано не лише в емуляторі.

Бо кінцева мета оптимізації — не отримати красиве число.

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