תקציבי ביצועים עם Angular CLI

כדאי לעקוב אחרי הגדלים של החבילות לאורך זמן כדי לוודא שהאפליקציה תמשיך לפעול במהירות.

Minko Gechev

חשוב לבצע אופטימיזציה של אפליקציה של Angular, אבל איך מוודאים שהביצועים שלה לא יורדים עם הזמן? באמצעות הצגת מדדי ביצועים ומעקב אחריהם בכל שינוי בקוד.

אחד המדדים החשובים הוא גודל ה-JavaScript שנשלח עם האפליקציה. כדי לוודא שהאופטימיזציות שלכם ימשיכו לפעול לאורך זמן, כדאי להגדיר תקציב ביצועים ולעקוב אחריו בכל build או בקשת משיכה.

חישוב תקציב הביצועים

אתם יכולים להשתמש במחשבון התקציב הזה באינטרנט כדי להעריך כמה קוד JavaScript האפליקציה שלכם יכולה לטעון, בהתאם לזמן לפעולה אינטראקטיבית שאתם שואפים להשיג.

מחשבון תקציב

הגדרת תקציב ביצועים ב-Angular CLI

אחרי שמגדירים תקציב יעד ל-JavaScript, אפשר לאכוף אותו באמצעות ממשק שורת הפקודה (CLI) של Angular. כדי לראות איך זה עובד, אפשר לעיין באפליקציה לדוגמה הזו ב-GitHub.

התקציב הבא מוגדר ב-angular.json:

"budgets": [{
  "type": "bundle",
  "name": "main",
  "maximumWarning": "170kb",
  "maximumError": "250kb"
}]

זהו סיכום של הפרטים שצריך לציין:

  • יש תקציב לחבילת JavaScript שנקראת main.
  • אם החבילה main תהיה גדולה מ-170KB, תופיע אזהרה ב-Angular CLI במסוף כשתיצרו את האפליקציה.
  • אם החבילה main תהיה גדולה מ-250KB, ה-build ייכשל.

עכשיו מנסים ליצור את האפליקציה על ידי הפעלת ng build --prod.

השגיאה הבאה אמורה להופיע במסוף:

תקלה בתקציב

כדי לתקן את שגיאת ה-build, כדאי לעיין ב-app.component.ts, שכולל ייבוא מ-rxjs/internal/operators. זהו ייבוא פרטי שלא אמור להיות בשימוש על ידי צרכנים של rxjs. זה מגדיל משמעותית את גודל החבילה. לאחר העדכון לייבוא הנכון, rxjs/operators והרצת ה-build שוב, ניתן לראות שהוא עובר בהצלחה את בדיקת התקציב.

חשוב לזכור שהטעינה הדיפרנציאלית מופעלת כברירת מחדל ב-Angular CLI, ולכן הפקודה ng build יוצרת שני גרסאות build של האפליקציה:

  • גרסה ל-build לדפדפנים עם תמיכה ב-ECMAScript 2015. ה-build הזה כולל פחות מילויי polyfill ותחביר JavaScript מודרני יותר. התחביר הזה מאפשר להביע יותר דברים, וכתוצאה מכך החבילות קטנות יותר.
  • גרסה ל-build לדפדפנים ישנים ללא תמיכה ב-ECMAScript 2015. התחביר הישן פחות חזותי ודורש יותר polyfills, מה שמוביל לחבילות גדולות יותר.

קובץ index.html של האפליקציה לדוגמה מפנה לשני ה-builds, כך שדפדפנים מודרניים יכולים ליהנות מה-build הקטן יותר של ECMAScript 2015, ודפדפנים ישנים יותר יכולים לעבור ל-build של ECMAScript 5.

אכיפת התקציב כחלק מאינטגרציה רציפה (CI)

אינטגרציה רציפה (CI) היא דרך נוחה לעקוב אחרי התקציב של האפליקציה לאורך זמן. למרבה המזל, הדרך המהירה ביותר להגדיר את זה היא ליצור את האפליקציה באמצעות Angular CLI – בלי שלבים נוספים. בכל פעם שחבילה של JavaScript חורגת מהתקציב, התהליך ייסגר עם קוד 1 וה-build ייכשל.

אם אתם מעדיפים, אתם יכולים גם לאכוף תקציב ביצועים באמצעות bundlesize ו-Lighthouse. ההבדל העיקרי בין תקציבי הביצועים ב-Angular CLI לבין Lighthouse הוא מתי מתבצעות הבדיקות. הבדיקה מתבצעת על ידי Angular CLI בזמן ה-build, תוך בדיקה של נכסי הייצור ואימות של המידות שלהם. עם זאת, Lighthouse פותח את הגרסה הפרוסה של האפליקציה וממדוד את גודל הנכס. לכל אחת מהגישות יש יתרונות וחסרונות. הבדיקה שמתבצעת על ידי Angular CLI פחות חזקה אבל מהירה הרבה יותר, כי היא חיפוש יחיד בדיסק. לעומת זאת, ערכת LightWallet של Lighthouse יכולה לבצע בדיקה מדויקת מאוד על ידי שימוש במשאבים שנטענים באופן דינמי, אבל יש לפרוס ולפתוח את האפליקציה בכל פעם שמריצים אותה.

הבדיקה bundlesize דומה מאוד לבדיקת התקציב של Angular CLI. ההבדל העיקרי הוא שבדיקה bundlesize יכולה להציג את תוצאות הבדיקה ישירות בממשק המשתמש של GitHub.

סיכום

כדי לוודא שהביצועים של אפליקציית Angular לא יורדים עם הזמן, כדאי להגדיר תקציבי ביצועים באמצעות Angular CLI:

  1. מגדירים בסיס להקצאת המשאבים באמצעות מחשבון תקציב או בהתאם לשיטות של הארגון.
  2. הגדרת תקציבי גודל ב-angular.json מתחת ל-projects.[PROJECT-NAME].architect.build.configurations.production.budgets
  3. התקציבים יוטלו באופן אוטומטי על כל גרסה מוצרית באמצעות Angular CLI.
  4. כדאי לשקול להוסיף מעקב אחרי התקציב כחלק מאינטגרציה רציפה (CI) (אפשר להשיג אותו גם באמצעות Angular CLI).