Оптимізація продуктивності веб-сайту при деградації
Деградація продуктивності — поступове або різке погіршення метрик на роботуючому сайті. На відміну від оптимізації нового проекту, тут завдання — знайти регресію: що саме змінилось і коли. Це діагностична робота, яка починається з кореляції метрик з подіями.
Визначення часу початку деградації
Перший крок — встановити часову точку початку проблеми. Джерела даних:
- 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 → записати trace → знайти завдання > 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 — стабільніше за DevTools (немає інших вкладок)
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
# Порівнюємо з production
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://mysite.ru/page
Якщо на localhost 150ms, а на production 2s — проблема в мережі/CDN/SSL. Якщо на localhost вже 1.5s — проблема в додатку: slow query, заблокований кеш, зовнішній API-виклик у синхронному коді.
Терміни робіт
Діагностика джерела деградації (Git bisect, трейси, slow log): 0.5–1 день. Усунення типових проблем (шрифти, зображення, JS defer): 1 день. Складні випадки (N+1 запити, кастомний JS з довгими завданнями): 2–3 дні.