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

Чому Core Web Vitals критичні для технічного SEO

PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.

Як досягти хороших показників Core Web Vitals?

Core Web Vitals: що реально впливає на позиції

Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).

LCP: чому 8 секунд — це не проблема зображення

LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.

Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Прибираємо всі render-blocking скрипти вище hero через defer

Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.

Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.

CLS: зсуви, які дратують користувача і Google

CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.

Джерела CLS:

• Зображення без заданих розмірів. <img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
• Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через min-height або завантажувати до рендеру основного контенту.
• Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування. font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
• Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.

INP: чому інтерфейс «зависає» на 500ms

INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.

Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.

Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:

• Безперервна обробка великого списку без requestIdleCallback або requestAnimationFrame
• Важкі event listeners без debounce/throttle
• Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
• Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread

Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.

Schema.org: розмітка, яку читають роботи

Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.

Типи розмітки за сценаріями:

• E-commerce: Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
• Статті та блог: Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
• Локальний бізнес: LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
• FAQ: FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.

Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.

Як проводити технічний SEO-аудит

Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.

Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.

JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.

Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.

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

• Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
• Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
• Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
• Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.