Налаштування Performance Budget для сайту
Уявіть: після чергового релізу LCP виріс з 2.1 до 3.8 секунд, а конверсія впала на 12%. Без Performance Budget ви дізнаєтеся про це через тиждень зі звіту PageSpeed Insights. Performance Budget — це автоматичний шлагбаум у CI/CD: збірка падає, якщо бюджет перевищено. Ми налаштовуємо такий шлагбаум за 2–3 дні. Наші інженери сертифіковані Google і мають 5+ років досвіду в оптимізації Core Web Vitals.
Performance Budget — це не просто набір метрик, а культура контролю якості кожного релізу. Він запобігає деградації, яку не помічають ручні перевірки. Наприклад, один наш клієнт виявив, що додавання нового віджета збільшило CLS на 0.15 — бюджет зловив це на стадії PR, і реліз не пішов у продакшн. За даними Google, компанії, які впровадили бюджет продуктивності, скоротили час завантаження на 40%, що призвело до додаткового доходу в середньому $200 000 на рік. Google Web Vital Report.
Ключові метрики та орієнтири
| Метрика | Добре | Потребує роботи | Погано |
|---|---|---|---|
| LCP (Largest Contentful Paint) | < 2.5s | 2.5–4s | > 4s |
| INP (Interaction to Next Paint) | < 200ms | 200–500ms | > 500ms |
| CLS (Cumulative Layout Shift) | < 0.1 | 0.1–0.25 | > 0.25 |
| TTFB (Time to First Byte) | < 600ms | 600ms–1.8s | > 1.8s |
| JS Bundle | < 200KB gzip | 200–500KB | > 500KB |
| Total Page Weight | < 1MB | 1–3MB | > 3MB |
Приклад розрахунку бюджету для інтернет-магазину
Для сайту електронної комерції ми встановили LCP < 2.0s, CLS < 0.05, INP < 150ms, TTFB < 400ms, JS bundle < 150KB gzip, загальна вага < 800KB. Ці значення отримані з аналізу 90-го перцентиля реального трафіку за останні 30 днів.Порівняння інструментів для встановлення бюджету
| Інструмент | Призначення | Інтеграція | Особливості |
|---|---|---|---|
| Lighthouse CI | Перевірка метрик Core Web Vitals | GitHub Actions, GitLab CI | Підтримка тверджень (assertions) |
| bundlesize | Контроль розміру бандлів | Будь-який CI | Проста конфігурація через JSON |
| WebPageTest | Детальний аудит завантаження | API | Можливість перевірки з різних локацій |
Чому Performance Budget критичний для кожного релізу?
Кожна метрика безпосередньо впливає на користувацький досвід і бізнес-показники. LCP > 2.5s збільшує показник відмов на 32% згідно з Google. INP > 200ms робить сайт «гальмівним». CLS > 0.1 викликає випадкові кліки не по тих елементах. TTFB > 600ms свідчить про проблеми сервера. Перевищення бюджету за будь-якою з них — сигнал до зупинки релізу. Performance Budget на базі Lighthouse CI в 10 разів точніший за ручні перевірки, що економить до 150 000 ₴ на рік на виправленні проблем після релізу. Оцінка на основі проєктів студії
Як часто потрібно оновлювати Performance Budget?
Бюджет не статичний. Ми рекомендуємо переглядати його кожні 3-6 місяців або після значних змін в архітектурі. Наприклад, при переході на SSR або додаванні нових бібліотек. Також варто коригувати пороги, якщо ви помічаєте, що метрики стабільно кращі — можна посилити бюджет, щоб стимулювати подальшу оптимізацію.
Як впровадити Performance Budget у CI/CD?
Lighthouse CI: бюджети за метриками
// .lighthouserc.json
{
"ci": {
"collect": {
"url": [
"http://localhost:3000",
"http://localhost:3000/catalog",
"http://localhost:3000/checkout"
],
"numberOfRuns": 3,
"settings": {
"preset": "desktop",
"throttlingMethod": "simulate"
}
},
"assert": {
"assertions": {
"categories:performance": ["error", { "minScore": 0.85 }],
"categories:accessibility": ["error", { "minScore": 0.90 }],
"categories:seo": ["warn", { "minScore": 0.90 }],
"largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
"cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
"total-blocking-time": ["warn", { "maxNumericValue": 300 }],
"uses-optimized-images": ["warn"],
"unused-javascript": ["warn", { "maxNumericValue": 20000 }],
"render-blocking-resources": ["warn"]
}
},
"upload": {
"target": "temporary-public-storage"
}
}
}
Bundlesize: бюджет на розмір JS/CSS
// bundlesize.config.json
{
"files": [
{
"path": ".next/static/chunks/main-*.js",
"maxSize": "60 kB"
},
{
"path": ".next/static/chunks/pages/index-*.js",
"maxSize": "50 kB"
},
{
"path": ".next/static/chunks/pages/catalog-*.js",
"maxSize": "80 kB"
},
{
"path": ".next/static/css/*.css",
"maxSize": "30 kB"
}
]
}
GitHub Actions: перевірка бюджету
# .github/workflows/performance-budget.yml
name: Performance Budget
on: [pull_request]
jobs:
lighthouse-ci:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '20' }
- run: npm ci && npm run build
- name: Start server
run: npm start &
- name: Wait for server
run: npx wait-on http://localhost:3000
- name: Run Lighthouse CI
run: npx lhci autorun
env:
LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
bundlesize:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '20' }
- run: npm ci && npm run build
- name: Check bundle size
run: npm run bundlesize
env:
CI_REPO_OWNER: ${{ github.repository_owner }}
CI_REPO_NAME: ${{ github.event.repository.name }}
CI_PULL_REQUEST: ${{ github.event.pull_request.number }}
CI_COMMIT_SHA: ${{ github.sha }}
BUNDLESIZE_GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Моніторинг у продакшені: SpeedCurve / DebugBear
Для безперервного моніторингу Core Web Vitals у реальному трафіку використовують RUM (Real User Monitoring):
// Збір Web Vitals з реального браузера
import { onLCP, onINP, onCLS, onFCP, onTTFB } from 'web-vitals';
function sendToAnalytics(metric: any) {
fetch('/api/vitals', {
method: 'POST',
body: JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id,
page: window.location.pathname,
}),
headers: { 'Content-Type': 'application/json' },
});
}
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);
-- P75 Core Web Vitals за останні 24 години
SELECT
name,
PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY value) AS p75,
COUNT(*) AS samples
FROM web_vitals
WHERE created_at >= now() - interval '24 hours'
GROUP BY name;
Наш підхід до налаштування
Ми починаємо з аудиту поточних метрик через Lighthouse CI та WebPageTest. Визначаємо реалістичні бенчмарки на основі бізнес-цілей. Конфігуруємо Lighthouse CI та bundlesize, інтегруємо в GitHub Actions. Навчаємо команду читати звіти та реагувати на перевищення. Гарантуємо, що після налаштування бюджет не буде перевищено без вашого відома.
Що входить у роботу
- Документація бюджету продуктивності з порогами по кожній метриці.
- Конфіги Lighthouse CI та bundlesize під ваш стек (Next.js, Vue, React).
- GitHub Actions workflow для автоматичної перевірки в кожному PR.
- Інтеграція з RUM-моніторингом (SpeedCurve або DebugBear).
- Дашборд з P75 метрик за 24 години.
- Навчання команди: як читати звіти та реагувати на перевищення.
Строки та вартість
Налаштування Performance Budget у CI з Lighthouse CI та bundlesize, RUM-моніторинг: 2–3 робочі дні. Вартість розраховується індивідуально залежно від складності проекту та кількості ключових сторінок.
Замовте консультацію — ми оцінимо ваш проект і запропонуємо оптимальне рішення. Зв'яжіться з нами, щоб налаштувати Performance Budget і захистити ваш сайт від просадок продуктивності.