Webpack משלבת את כל הקבצים המיובאים ומארזת אותם בקובץ פלט אחד או יותר שנקראים חבילות. חבילות הן פתרון נחמד, אבל ככל שהאפליקציה תתפתח, כך גם החבילות יגדלו. חשוב לעקוב אחרי הגדלים של החבילות כדי לוודא שהן לא גדלות מדי ומשפיעות על משך הזמן שלוקח לאפליקציה לטעון. ב-Webpack יש תמיכה בהגדרת תקציבי ביצועים על סמך גודל הנכס, והוא יכול לעקוב אחרי גודל החבילות בשבילכם.
כדי לראות איך זה עובד, הנה אפליקציה שמספרת את הימים שנותרו עד לשנה החדשה. הוא מבוסס על React ו-moment.js. (בדומה לאפליקציות בעולם האמיתי, שמסתמכות יותר ויותר על מסגרות וספריות. 😉)
מדידה
סדנת הקוד הזו כבר מכילה את האפליקציה עם webpack.
- לוחצים על Remix to Edit כדי לאפשר עריכה של הפרויקט.
- לוחצים על Terminal (הערה: אם הלחצן Terminal לא מופיע, יכול להיות שתצטרכו להשתמש באפשרות 'מסך מלא').
- כדי לקבל רשימה של הנכסים והגדלים שלהם לפי צבעים, מקלידים
webpack
במסוף.
webpack
החבילה הראשית מודגשת בצהוב כי היא גדולה מ-244KB (250KB).
האזהרות האלה מופעלות כברירת מחדל במצב ייצור, וערך הסף שמוגדר כברירת מחדל הוא 244KiB ללא דחיסה, גם לנכסים וגם לנקודות הכניסה (השילוב של כל הנכסים שנעשה בהם שימוש במהלך הטעינה הראשונית של הדף).
Webpack לא רק יזהיר אתכם, אלא גם ייתן לכם המלצה איך לצמצם את הגודל של החבילות. מידע נוסף על השיטות המומלצות זמין במאמר עקרונות בסיסיים של האינטרנט.
הגדרת תקציב ביצועים בהתאמה אישית
תקציב הביצועים המתאים תלוי באופי הפרויקט. תמיד עדיף לעשות מחקר משלכם. כלל טוב הוא להעביר פחות מ-170KB של משאבים בנתיב קריטי דחוסים או מוקטנים.
בהדגמה הפשוטה הזו, כדאי להגדיר תקציב שמרני יותר של 100KB (97.7KiB). ב-webpack.config.js
, מוסיפים את הפרטים הבאים:
module.exports = {
//...
performance: {
maxAssetSize: 100000,
maxEntrypointSize: 100000,
hints: "warning"
}
};
תקציב הביצועים החדש מוגדר בבייטים:
- 100,000 בייטים לנכסים ספציפיים (maxAssetSize)
- 100,000 בייטים לנקודת הכניסה (maxEntrypointSize)
במקרה כזה, יש רק חבילת מודולים אחת שמשמשת גם כנקודת הכניסה.
הערכים האפשריים של hints הם:
warning
(ברירת המחדל): תוצג הודעת אזהרה צהובה, אבל ה-build יעבור. מומלץ להשתמש באפשרות הזו בסביבות פיתוח.error
: מוצגת הודעת שגיאה בצבע אדום, אבל ה-build עדיין עובר. ההגדרה הזו מומלצת לגרסאות build בסביבת הייצור.false
: לא מוצגות אזהרות או שגיאות.
אופטימיזציה
מטרת תקציב הביצועים היא להזהיר אתכם על בעיות בביצועים לפני שיהיה קשה מדי לפתור אותן. תמיד יש יותר מדרך אחת לפתח אפליקציה, ויש שיטות שיעזרו לקצר את זמני הטעינה. (הרבה מהן מתועדות כאן במאמר אופטימיזציה של JavaScript. 🤓)
מסגרות וספריות מקלות על החיים של המפתחים, אבל למשתמשי הקצה לא ממש אכפת איך האפליקציות נוצרות, אלא רק שהן פונקציונליות ומהירות. אם אתם חורגים מהתקציב לצורכי ביצועים, כדאי לכם לחשוב על אופטימיזציות אפשריות.
בעולם האמיתי, בדרך כלל קשה להחליף מסגרות גדולות בצד הלקוח, ולכן חשוב להשתמש בהן בחוכמה. אחרי קצת מחקר, בדרך כלל אפשר למצוא חלופות קטנות יותר לספריות פופולריות שמבצעות את המשימה באותה מידה (date-fns היא חלופה טובה ל-moment.js). לפעמים עדיף לא להשתמש בכלל בספרייה או בפלטפורמה אם יש להן השפעה משמעותית על הביצועים.
הסרת קוד שלא בשימוש היא דרך טובה לבצע אופטימיזציה של אפליקציות שכוללות ספריות גדולות של צד שלישי. במדריך להסרת קוד שלא בשימוש מוסבר התהליך הזה בפירוט. הנה דרך מהירה לכתוב מחדש את קוד הספירה לאחור בלי להשתמש ב-moment.js.
בקובץ app/components/Countdown.jsx מסירים את:
const today = moment();
const yearEnd = moment().endOf('year');
const daysLeft = yearEnd.diff(today, 'days');
ומוחקים את השורה הבאה:
const moment = require('moment');
נדרשת קצת מתמטיקה, אבל אפשר להטמיע את אותו ספירה לאחור באמצעות JavaScript רגילה:
const today = new Date();
const year = today.getFullYear();
const yearEnd = new Date(year,11,31); //months are zero indexed in JS
const timeDiff = Math.abs(yearEnd.getTime() - today.getTime());
const daysLeft = Math.ceil(timeDiff / (1000 * 3600 * 24));
עכשיו מסירים את moment.js
מ-package.json
ומריצים שוב את webpack במסוף כדי ליצור את החבילה האופטימיזציה.
וואו! הצלחתם לחסוך 223KiB (230KB) והאפליקציה עומדת במסגרת התקציב.🎉
מעקב
הגדרת תקציב ביצועים ב-Webpack דורשת רק כמה שורות קוד, ותופיע אזהרה אם תוסיפו (בטעות) תלות גדולה. יש פתגם שאומר "מה שלא רואים לא זוכרים", אבל webpack יכול לוודא שתמיד תהיו מודעים להשלכות על הביצועים.