Автоматичний контроль розміру бандла в CI/CD: налаштування

Бандл росте непомітно — ми допомагаємо це контролювати

Ви додали одну залежність, колега імпортував утиліту цілком — і через місяць JS-бандл потяжчав на 200 КБ. LCP просіло на 30%, а винуватець не знайдений. У 80% проектів розробники помічають проблему лише після деплою в прод. Автоматична перевірка розміру бандла в CI/CD зупиняє деградацію до потрапляння в реліз. Наші інженери з досвідом 5+ років (понад 50 реалізованих проектів) гарантують якісне налаштування. Первинна консультація — за запитом. Зв'яжіться для аудиту бандла.

Які проблеми вирішуємо

• Невидиме зростання бандла — кожна нова залежність збільшує розмір, але в PR цього не видно, поки LCP не виросте на 30%. Наприклад, імпорт lodash цілком замість lodash.get додає 20 КБ в gzip.
• Дублювання коду — одна й та сама бібліотека в різних чанках після code splitting, що збільшує загальний розмір на 10-15%. Контроль чанків дозволяє це уникнути.
• Роздуття initial bundle — lazy-завантаження не налаштоване, і користувач завантажує все одразу, збільшуючи TTI на 2 секунди.
• Відсутність baseline — без історії змін важко відстежити, яка версія внесла регресію.

Підвищення продуктивності фронтенду напряму впливає на конверсію: зменшення часу завантаження на 1 секунду може збільшити продажі на 7%. Економія бюджету за рахунок запобігання деградації сягає 500$ на місяць.

Як це працює: огляд підходів

На кожен PR або деплой збираємо бандл, порівнюємо його розмір та розмір окремих чанків з baseline — значеннями з попереднього деплою або фіксованими лімітами. Якщо поріг перевищено — CI падає або залишає попередження в PR. Інтеграція CI займає від 4 годин.

Налаштування інструментів

Як bundlewatch допомагає контролювати розмір бандла?

Встановлюємо:

npm install --save-dev bundlewatch 

Конфігурація в package.json:

{
  "bundlewatch": {
    "files": [
      {
        "path": "dist/assets/index-*.js",
        "maxSize": "150kB"
      },
      {
        "path": "dist/assets/vendor-*.js",
        "maxSize": "400kB"
      },
      {
        "path": "dist/assets/*.css",
        "maxSize": "50kB"
      }
    ],
    "ci": {
      "trackBranches": ["main", "master"],
      "repoBranchBase": "main"
    }
  }
}

В GitHub Actions:

---
name: Bundle Size Check
on: [pull_request]
jobs:
  bundlewatch:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run build
      - run: npx bundlewatch
        env:
          BUNDLEWATCH_GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          CI_REPO_OWNER: ${{ github.repository_owner }}
          CI_REPO_NAME: ${{ github.event.repository.name }}
          CI_COMMIT_SHA: ${{ github.event.pull_request.head.sha }}
          CI_BRANCH: ${{ github.head_ref }}
          CI_BRANCH_BASE: ${{ github.base_ref }}

bundlewatch залишає коментар в PR з таблицею: поточний розмір, delta, статус. Детальніше в bundlewatch.

Налаштування size-limit: глибше, ніж просто ліміти

size-limit аналізує дерево імпортів: показує вагу модуля з урахуванням tree-shaking і gzip. Аналіз size-limit допомагає виявити приховані дублі.

npm install --save-dev size-limit @size-limit/preset-app 

.size-limit.json:

[
  {
    "path": "dist/assets/index-*.js",
    "limit": "150 kB",
    "gzip": true
  },
  {
    "name": "Vendor chunk",
    "path": "dist/assets/vendor-*.js",
    "limit": "380 kB",
    "gzip": true
  }
]

В package.json:

{
  "scripts": {
    "size": "size-limit",
    "analyze": "size-limit --why"
  }
}

--why запускає webpack-bundle-analyzer і показує, що саме тягне розмір.

Чому відносні ліміти зручніші за абсолютні?

Абсолютні ліміти застарівають — проект росте, і постійно піднімати цифри набридає. Альтернатива: перевіряти delta відносно base branch. Ми використовуємо скрипт, який порівнює розмір поточної гілки з базовою. Скрипт виконує збірку, зберігає поточний розмір, завантажує розмір базової гілки з артефактів CI і обчислює дельту. Якщо дельта перевищує 10%, CI падає. Такий підхід економить час на налаштування і не вимагає ручного оновлення лімітів. Відносні ліміти бандла особливо корисні для швидкозростаючих проектів.

Практичні поради

Що перевіряти окрім загального розміру

• Кількість чанків — зростання при code splitting може збільшити кількість HTTP-запитів. Контроль чанків допомагає уникнути цього.
• Розмір initial bundle окремо від lazy-loaded чанків — саме він впливає на LCP і TTI.
• Дублі залежностей — коли одна бібліотека затягується в кілька чанків у різних версіях. Для аналізу: npm ls <package> або npx duplicate-package-checker-webpack-plugin.

Типові помилки та як їх уникнути

Деякі команди забувають налаштувати кешування, і перевірка займає 5+ хвилин. Ми використовуємо кешування node_modules і .vite, скорочуючи час до 40–60 секунд. Інша помилка — встановлюють ліміти «на око». Правильно: заміряти поточні розміри і задати з запасом 10–15%.

Як ми допомагаємо

Що входить в роботу

• Аудит поточного бандла та виявлення проблемних місць.
• Налаштування обраного інструменту (bundlewatch або size-limit) з індивідуальними лімітами.
• Інтеграція в CI/CD (GitHub Actions, GitLab CI, Bitbucket Pipelines).
• Документування конфігурації та процесу підтримки.
• Навчання команди роботі зі сповіщеннями та аналізом.
• Пост-релізна підтримка протягом 1 місяця.

Терміни орієнтовно

Базова налаштування bundlewatch в існуючий CI-пайплайн — від 4 до 8 годин. Налаштування size-limit з аналізом та сповіщеннями в PR — від 1 до 2 робочих днів. Вартість розраховується індивідуально після оцінки вашого проекту. Отримайте консультацію — ми розповімо, який варіант оптимальний. Замовте аудит бандла, і ми запропонуємо конкретні рішення.