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

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

חשוב לבצע אופטימיזציה של אפליקציית 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. הגרסה הזו כוללת פחות polyfills וסינטקס מודרני יותר של 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. מומלץ להוסיף מעקב אחר התקציב כחלק משילוב רציף (אפשר לעשות זאת גם באמצעות Angular CLI).