Налаштування 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 і захистити ваш сайт від просадок продуктивності.