Оптимизация производительности сайта при деградации

Сайт на 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 успешных проектов гарантируют результат. Свяжитесь с нами для консультации — и мы вернём вашему сайту скорость.