Оптимізація продуктивності сайту при деградації

Сайт на Laravel 11 з Next.js 14 працював стабільно, поки після деплою нової фічі LCP не виріс з 1.8 до 4.2 секунди, а INP перевищив 300ms. Причина — важкий скрипт аналітики, підключений без defer. Така ситуація знайома багатьом: деградація продуктивності часто виникає через непомітні регресії. Наші інженери з 10+ річним досвідом діагностували сотні таких випадків і повертали метрики в норму.

Як визначити момент деградації?

Перший крок — встановити часову точку початку проблеми. Використовуємо Google Search Console (Core Web Vitals за 28 днів), Grafana з RUM-метриками, Lighthouse CI в CI/CD та git-лог. Команда git log --oneline --since="2 weeks ago" --until="today" показує всі деплої. Якщо LCP виріс, звіряємо дату росту з комітами. Одного разу деградація збіглася з оновленням бібліотеки swiper — відкат версії вирішив проблему за 15 хвилин.

Типові причини деградації

• JavaScript-регресія. Додавання скрипту без defer/async блокує рендер. Діагностика: Chrome DevTools → Performance → зняти трейс → знайти задачі довші за 50ms в main thread.
• Новий шрифт без font-display: swap. Без цього браузер приховує текст до завантаження шрифту, збільшуючи LCP. Google рекомендує завжди використовувати swap.
• Нестиснуті зображення після зміни CMS. Перевіряємо віддачу WebP через curl:

curl -I -H "Accept: image/webp" https://site.ru/img.jpg | grep content-type 

• CLS від елементів без розмірів. Зображення без width/height викликають layout shift. Резервуємо місце через атрибути або aspect-ratio.

Порівняння інструментів діагностики

WebPageTest кращий для візуального аналізу, а DevTools — для глибинної налагодження. Ми комбінуємо обидва, щоб точно визначити причину.

Як швидко діагностувати деградацію?

Беремо останній звіт Lighthouse CI і порівнюємо з попереднім. Якщо метрики впали більше ніж на 10% — шукаємо регресію. Використовуємо git bisect для автоматичного пошуку проблемного коміту. Це скорочує діагностику до кількох годин навіть у великому проекті.

Чому метрики погіршуються після оновлень?

Часта причина — додавання сторонніх скриптів без урахування продуктивності. Наприклад, новий чат-віджет може завантажувати 500+ КБ JS і блокувати main thread. Ми аналізуємо кожну зміну через performance budget в CI. Якщо бюджет перевищено — збірка падає, і деградація не доходить до продакшену.

Як ми усуваємо деградацію: покроковий процес

1. Діагностика. Збираємо метрики: LCP, INP, TTFB через WebPageTest і DevTools. Аналізуємо git-лог для пошуку регресії. Записуємо slow log бази даних.
2. Виправлення типових проблем. Шрифти, зображення, відкладене завантаження JS. Економія на CDN-доставці — до 30% часу завантаження.
3. Складні випадки. N+1 запити, довгі задачі в main thread. Розбиваємо на мікрозадачі через scheduler.yield().
4. Тестування. Прогоняємо Lighthouse CI в паралелі з production-навантаженням.
5. Гарантія. Надаємо звіт зі змінами та 2-тижневу гарантію на відновлення метрик. Якщо деградація повторюється, проводимо повторну діагностику безкоштовно.

Що входить в роботу

• Діагностичний звіт з графіками метрик
• Визначення точної причини регресії
• Оптимізація коду, шрифтів, зображень
• Повторний аудит після виправлень
• Гарантія 2 тижні на відновлені метрики

Оптимізація LCP та INP

LCP найчастіше — велике зображення або текстовий блок. Для зображення використовуємо fetchpriority="high" та прелоад:

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high"> 

Якщо LCP — текст, його гальмує завантаження шрифту. Рішення — прелоад шрифту з crossorigin та font-display: swap.

INP > 200ms означає, що користувач чекає відгуку. Типова причина — синхронна операція в обробнику. Виправляємо розбиттям на мікрозадачі через scheduler.yield() або setTimeout(0). Детальніше про yield.

Деградація TTFB

TTFB виріс — проблема на сервері. Порівнюємо localhost і продакшн через curl. Якщо на localhost 150ms, а на продакшн 2s — проблема в мережі або CDN. Якщо на localhost теж високий — повільний запит до БД або зовнішнього API.

В одному проекті TTFB виріс з 200ms до 1.2s після додавання кешування Redis. Виявилося, що інвалідація кешу скидалася на кожен запит. Налаштування TTL вирішило проблему.

Типові результати оптимізації

Терміни та вартість

Діагностика — від 0.5 дня, типове виправлення — від 1 дня, складні випадки — до 3 днів. Вартість розраховується індивідуально після первинного аналізу. Наші інженери з 10+ річним досвідом та понад 500 успішних проектів гарантують результат. Зв'яжіться з нами для консультації — і ми повернемо вашому сайту швидкість.