Автоматичний контроль розміру бандла в 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 робочих днів. Вартість розраховується індивідуально після оцінки вашого проекту. Отримайте консультацію — ми розповімо, який варіант оптимальний. Замовте аудит бандла, і ми запропонуємо конкретні рішення.