Оптимизация производительности сайта при деградации
Деградация производительности — постепенное или резкое ухудшение метрик на работающем сайте. В отличие от оптимизации нового проекта, здесь задача — найти регрессию: что именно изменилось и когда. Это диагностическая работа, которая начинается с корреляции метрик с событиями.
Определение момента деградации
Первый шаг — установить временну́ю точку начала проблемы. Источники данных:
- Google Search Console → Core Web Vitals → поле 28 дней vs предыдущий период
- Grafana/Datadog — если есть RUM, смотрим граф LCP/INP/TTFB по времени
- Lighthouse CI в CI/CD — какой деплой сломал метрики
- Git log — что деплоилось в день деградации
# Быстрый просмотр деплоев за неделю
git log --oneline --since="2 weeks ago" --until="today"
# Что изменилось в конкретный день
git log --oneline --after="2025-03-10" --before="2025-03-12"
Если метрика LCP выросла с 1.8s до 4.2s — проверяем деплои за 2 дня до начала роста.
Типичные причины деградации
JavaScript-регрессия:
Добавление тяжёлого скрипта в <head> без defer/async блокирует рендер:
<!-- Так блокирует LCP -->
<script src="https://somecdn.com/heavy-widget.js"></script>
<!-- Правильно -->
<script src="https://somecdn.com/heavy-widget.js" defer></script>
Диагностика: Chrome DevTools → Performance → снять трейс → найти задачи длиннее 50ms в main thread.
Новый шрифт без font-display:
/* Без font-display — FOIT блокирует текст, LCP растёт */
@font-face {
font-family: 'MyFont';
src: url('/fonts/myfont.woff2') format('woff2');
font-display: swap; /* добавить */
}
Несжатые изображения после смены CMS/хостинга:
# Проверить отдаёт ли сервер WebP/gzip
curl -I -H "Accept: image/webp" https://mysite.ru/images/hero.jpg | grep content-type
# content-type: image/webp — хорошо
# content-type: image/jpeg — нет WebP
CLS от элементов без размеров:
<!-- Изображение без размеров вызывает layout shift -->
<img src="banner.jpg" alt="Banner">
<!-- Правильно: резервируем место -->
<img src="banner.jpg" alt="Banner" width="1200" height="400"
style="aspect-ratio: 1200/400">
Инструменты диагностики
WebPageTest с трассировкой: webpagetest.org → Advanced → Capture video + Chrome DevTools trace. Видно точный элемент LCP и что его задерживает.
Chrome DevTools Coverage — показывает неиспользуемый JS/CSS:
DevTools → Coverage (Ctrl+Shift+P → "Coverage") → Record →
Reload page → Stop → смотрим % unused bytes
Если JS-файл используется на 15% — кандидат на code splitting.
Lighthouse в режиме сравнения:
# Lighthouse CLI — сравнение двух URL или одного URL до/после
npx lighthouse https://mysite.ru --output json --output-path before.json
# (внести изменения)
npx lighthouse https://mysite.ru --output json --output-path after.json
# Diff по ключевым метрикам
node -e "
const b = require('./before.json').audits;
const a = require('./after.json').audits;
['largest-contentful-paint','total-blocking-time','cumulative-layout-shift'].forEach(k => {
console.log(k, 'before:', b[k].displayValue, '-> after:', a[k].displayValue);
});
"
Оптимизация LCP
LCP обычно — крупное изображение hero или H1. Для изображения:
<!-- Приоритетная загрузка LCP-изображения -->
<img src="/hero.webp"
alt="Hero"
width="1440" height="600"
fetchpriority="high"
loading="eager"
decoding="sync">
<!-- Preload в <head> -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
Если LCP — текстовый блок, его тормозит загрузка шрифта. Решение:
<link rel="preload" href="/fonts/hero-font.woff2"
as="font" type="font/woff2" crossorigin>
INP — медленные обработчики событий
INP > 200ms означает, что кликая на кнопку пользователь ждёт визуального ответа. Диагностика в DevTools:
Performance → Interactions → выбрать долгую задачу → Bottom-up →
найти функцию с наибольшим Self Time
Типичная причина: синхронная операция в click-обработчике:
// Блокирует main thread
button.addEventListener('click', () => {
const result = heavyComputation(data); // 300ms
updateUI(result);
});
// Правильно: разбить на микрозадачи
button.addEventListener('click', async () => {
updateUI({ loading: true });
await scheduler.yield(); // освобождаем поток
const result = heavyComputation(data);
updateUI(result);
});
Деградация TTFB — серверная сторона
TTFB вырос → проблема на сервере. Проверяем:
# Время ответа сервера без сети (localhost)
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" http://127.0.0.1/page
# Сравниваем с продакшн
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://mysite.ru/page
Если на localhost 150ms, а на продакшн 2s — проблема в сети/CDN/SSL. Если на localhost уже 1.5s — проблема в приложении: slow query, заблокированный кэш, внешний API-вызов в синхронном коде.
Сроки работ
Диагностика источника деградации (Git bisect, трейсы, slow log): 0.5–1 день. Устранение типовых проблем (шрифты, изображения, JS defer): 1 день. Сложные случаи (N+1 запросы, кастомный JS с долгими задачами): 2–3 дня.