בקרה אוטומטית על גודל ה-Bundle ב-CI/CD: הגדרה ואופטימיזציה

הצמיחה של ה-bundle לא מורגשת — אנחנו עוזרים לכם לשלוט בה

הוספתם תלות אחת, קולגה ייבא utility שלם — וחודש לאחר מכן ה-JS bundle גדל ב-200 KB. LCP ירד ב-30%, והאשם לא נמצא בשום מקום. ב-80% מהפרויקטים, מפתחים שמים לב לבעיה רק לאחר העלייה לייצור. בדיקות אוטומטיות של גודל ה-bundle ב-CI/CD עוצרות את ההידרדרות לפני שהיא מגיעה לשחרור. המהנדסים שלנו, עם ניסיון של 5+ שנים, מקימים בקרה כזו עבור ה-stack שלכם. ייעוץ ראשוני זמין. צרו קשר לבדיקת bundle.

אילו בעיות אנחנו פותרים

• צמיחה בלתי נראית של ה-bundle — כל תלות חדשה מגדילה את הגודל, אבל זה לא נראה ב-PR עד ש-LCP קופץ ב-30%. לדוגמה, ייבוא של lodash במלואו במקום lodash.get מוסיף 20 KB ב-gzip.
• כפילות קוד — אותה ספרייה ב-chunks שונים לאחר code splitting, מה שמגדיל את הגודל הכולל ב-10-15%.
• Bundle ראשוני מנופח — lazy loading לא מוגדר; המשתמש מוריד הכל בבת אחת, מה שמגדיל את TTI ב-2 שניות.
• חוסר baseline — בלי היסטוריית גודל, קשה לעקוב איזו גרסה גרמה לרגרסיה.

איך זה עובד

בכל PR או deployment, אנחנו בונים את ה-bundle, משווים את הגודל שלו ואת גדלי ה-chunks הבודדים מול baseline — ערכים מה-deployment הקודם או מגבלות קבועות. אם הסף נחצה, CI נכשל או משאיר אזהרה ב-PR. זה יכול לחסוך עד $500 בחודש על תחזוקת ביצועים.

הכלים מתחלקים לשתי קטגוריות:

איך bundlewatch עוזר לשלוט בגודל ה-bundle

התקינו אותו:

npm install --save-dev bundlewatch 

הגדירו ב-npm install --save-dev bundlewatch :

{
  "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 עם טבלה: גודל נוכחי, דלתא, סטטוס. פרטים נוספים ב-bundlewatch.

הגדרת size-limit: עמוק יותר מסתם מגבלות

package.json מנתח את עץ הייבוא: מציג משקל מודול תוך התחשבות ב-tree-shaking וב-gzip.

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

{ "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" } } } :

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

ב-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 }} :

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

size-limit מריץ את npm install --save-dev size-limit @size-limit/preset-app ומראה בדיוק מה מושך את הגודל.

למה מגבלות יחסיות נוחות יותר מאשר מוחלטות?

מגבלות מוחלטות מתיישנות ככל שהפרויקט גדל, והעלאה מתמדת של המספרים היא מייגעת. חלופה: בדיקת דלתא מול ענף הבסיס. אנחנו משתמשים בסקריפט שמשווה את גודל הענף הנוכחי עם הבסיס. הסקריפט בונה, שומר את הגודל הנוכחי, מביא את גודל ענף הבסיס מ-CI artifacts, ומחשב את הדלתא. אם הדלתא עולה על 10%, CI נכשל. גישה זו חוסכת זמן הגדרה ואינה דורשת עדכון ידני של מגבלות.

מה לבדוק מלבד הגודל הכולל

• מספר ה-chunks — גידול במספר ה-chunks מ-code splitting יכול להגדיל בקשות HTTP.
• גודל ה-bundle הראשוני בנפרד מה-chunks של lazy loading — זה משפיע על LCP ו-TTI.
• כפילויות תלויות — כאשר ספרייה אחת נמשכת למספר chunks בגרסאות שונות. נתחו עם .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 } ] .

השוואת גישות: bundlewatch מול size-limit

טעויות נפוצות ואיך להימנע מהן

חלק מהצוותים שוכחים להגדיר caching, מה שהופך את הבדיקה ל-5+ דקות. אנחנו שומרים ב-cache את package.json ו-{ "scripts": { "size": "size-limit", "analyze": "size-limit --why" } } , ומצמצמים את הזמן ל-40–60 שניות. טעות נוספת היא הגדרת מגבלות "בעין". הדרך הנכונה: מדדו גדלים נוכחיים והגדירו buffer של 10–15%.

מה כלול בעבודה

• בדיקת ה-bundle הנוכחי וזיהוי אזורים בעייתיים.
• הגדרת הכלי הנבחר (bundlewatch או size-limit) עם מגבלות מותאמות.
• אינטגרציה ל-CI/CD (GitHub Actions, GitLab CI, Bitbucket Pipelines).
• תיעוד של הקונפיגורציה ותהליך התחזוקה.
• הדרכת צוות על עבודה עם התראות וניתוח.
• תמיכה לאחר השחרור למשך חודש.

לוח זמנים משוער

הגדרה בסיסית של bundlewatch ב-pipeline CI קיים אורכת 4 עד 8 שעות. הגדרת size-limit עם ניתוח והתראות PR אורכת 1 עד 2 ימי עבודה. העלות מחושבת באופן אישי לאחר הערכת הפרויקט שלכם. קבלו ייעוץ — נספר לכם איזו אפשרות אופטימלית. הזמינו בדיקת bundle, ואנחנו נציע פתרונות קונקרטיים.