Lighthouse: אופטימיזציה של מהירות האתר

Kayce Basques

Sofia Emelianova

סקירה כללית

אפשר להשתמש בחלונית Lighthouse כדי להריץ ביקורת מקיפה של האתר. הלוח Lighthouse יוצר דוח שמספק תובנות לגבי הנושאים הבאים באתר שלכם:

• ביצועים
• נגישות
• שיטות מומלצות
• אופטימיזציה עבור מנועי חיפוש

... ועוד הרבה מדדים אחרים.

המדריך הבא יעזור לכם להתחיל להשתמש ב-Lighthouse ב-Chrome DevTools.

מידע נוסף על הדרכים האחרות שבהן Lighthouse יכול לשפר את איכות האתר זמין במסמכי העזרה של Lighthouse.

מטרת המדריך

במדריך הזה תלמדו איך להשתמש בכלים למפתחים של Chrome כדי למצוא דרכים להאיץ את טעינת האתרים.

אפשר להמשיך לקרוא את המדריך הזה או לצפות בגרסה הווידאו שלו:

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

דרישות מוקדמות

צריך להיות לכם ניסיון בסיסי בפיתוח אתרים, בדומה לקורס הזה.

אין צורך לדעת שום דבר על ביצועי עומס.

מבוא

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

החתול טוני.

שלב 1: מבצעים ביקורת באתר

כשרוצים לשפר את ביצועי הטעינה של אתר, תמיד כדאי להתחיל בביצוע ביקורת. לבדיקות יש שתי פונקציות חשובות:

• כך נוצר בסיס שאפשר למדוד בו שינויים עתידיים.
• הכלי מספק טיפים פרקטיים לגבי השינויים שצפויים להשפיע בצורה המשמעותית ביותר.

הגדרה

קודם כול, צריך להגדיר סביבת עבודה חדשה לאתר של רון, כדי שתוכלו לבצע בה שינויים בהמשך:

1. יוצרים רמיקס של הפרויקט של האתר ב-Glitch. הפרויקט החדש ייפתח בכרטיסייה. נתייחס לכרטיסייה הזו ככרטיסיית העריכה.

   

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

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

   

3. פותחים את כלי הפיתוח לצד ההדגמה.

   

נקודת מפתח: בשאר צילומי המסך במדריך הזה, DevTools מוצג בחלון נפרד.

הגדרת ערך בסיס

קו הבסיס הוא תיעוד של ביצועי האתר לפני ביצוע שיפורים בביצועים.

1. פותחים את החלונית Lighthouse. יכול להיות שהוא מוסתר מאחורי לוחות נוספים.

   הערה: הלוח הזה מופעל על ידי הכלי שקרוי על שמו – Lighthouse, כלי אוטומטי לשיפור האיכות של אפליקציות האינטרנט שלכם.

   

2. מוודאים שההגדרות של דוח Lighthouse תואמות לאלה שבצילום המסך. בהמשך מוסבר על האפשרויות השונות:

   • check_box פינוי נפח האחסון. הפעלת תיבת הסימון הזו תמחק את כל האחסון שמשויך לדף לפני כל ביקורת. משאירים את ההגדרה הזו פועלת אם רוצים לבדוק את חוויית המשתמש של מבקרים באתר בפעם הראשונה. משביתים את ההגדרה הזו כשרוצים להציג את חוויית הביקור החוזר.
   • check_box Enable JS sampling. האפשרות הזו מושבתת כברירת מחדל. כשהאפשרות הזו מופעלת, היא מוסיפה למעקב הביצועים מחסניות קריאה מפורטות של JavaScript, אבל עשויה להאט את יצירת הדוח. הנתונים מופיעים בקטע more_vert תפריט הכלים > הצגת נתוני המעקב המקוריים אחרי יצירת הדוח Lighthouse.
   • הדמיה של ויסות נתונים (ברירת מחדל) . האפשרות הזו מדמה את התנאים האופייניים של הגלישה במכשיר נייד. היא נקראת 'סימולציה' כי Lighthouse לא מגביל את הקצב בפועל במהלך תהליך הביקורת. במקום זאת, הוא רק מנבא כמה זמן ייקח לטעון את הדף בתנאים של נייד. לעומת זאת, ההגדרה ויסות נתונים (throttle) של כלי הפיתוח (מתקדם) מגבילה בפועל את המעבד והרשת, אבל תהליך הביקורת ארוך יותר.
   • Mode (מצב) > Navigation (Default) (ניווט (ברירת מחדל)). במצב הזה מתבצע ניתוח של טעינת דף יחידה, וזה מה שאנחנו צריכים במדריך הזה. מידע נוסף זמין במאמר שלושת המצבים.
   • Device‏ > Mobile. האפשרות לנייד משנה את מחרוזת סוכן המשתמש ומחקה אזור צפייה בנייד. אפשרות המחשב בעצם משביתה את השינויים בנייד.
   • Categories‏ > check_box Performance. אם תפעילו קטגוריה אחת, מערכת Lighthouse תיצור דוח עם קבוצת הבדיקות המתאימה בלבד. אם אתם רוצים לראות את סוגי ההמלצות שמתקבלות מהקטגוריות האחרות, אתם יכולים להשאיר אותן מופעלות. השבתת קטגוריות לא רלוונטיות מאיצה מעט את תהליך הביקורת.

3. לוחצים על ניתוח של טעינת הדף. אחרי 10 עד 30 שניות, בחלונית Lighthouse יוצג דוח על ביצועי האתר.

   

טיפול בשגיאות בדוחות

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

הסבר על הדוח

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

מדדים

גוללים למטה לקטע מדדים ולוחצים על הרחבת התצוגה. כדי לקרוא מסמכי עזרה על מדד מסוים, לוחצים על מידע נוסף….

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

צילומי מסך

בהמשך מופיע אוסף של צילומי מסך שמראים איך הדף נראה בזמן הטעינה.

הזדמנויות

הקטע הבא הוא הזדמנויות, שמספק טיפים ספציפיים לשיפור ביצועי הטעינה של הדף הספציפי הזה.

אפשר ללחוץ על הזדמנות כדי לראות פרטים נוספים לגביה.

לוחצים על מידע נוסף… כדי לראות מסמכי עזרה שמסבירים למה ההזדמנות חשובה ומציעים המלצות ספציפיות לפתרון הבעיה.

אבחון

בקטע אבחון מוצג מידע נוסף על הגורמים שמשפיעים על זמן הטעינה של הדף.

ביקורות שעברו

בקטע בדיקות שעברו מוצגים הדברים שהאתר עושה בצורה נכונה. לוחצים כדי להרחיב את הקטע.

שלב 2: ניסוי

בקטע Opportunities (הזדמנויות) בדוח Lighthouse מופיעים טיפים לשיפור הביצועים של הדף. בקטע הזה מטמיעים את השינויים המומלצים בקוד, ובודקים את האתר אחרי כל שינוי כדי למדוד את ההשפעה שלו על מהירות האתר.

הפעלת דחיסת טקסט

בדוח צוין שהפעלת דחיסת טקסט היא אחת מההזדמנויות המובילות לשיפור הביצועים של הדף.

דחיסת טקסט היא הפעולה של הקטנת או דחיסת גודל קובץ טקסט לפני השליחה שלו ברשת. זה דומה לדחיסה של תיקייה לפני שליחתה באימייל כדי לצמצם את הגודל שלה.

לפני שמפעילים את דחיסת הנתונים, יש כמה דרכים לבדוק באופן ידני אם משאבי הטקסט דחוסים.

פותחים את החלונית Network ומסמנים את התיבה Settings > Use large request rows.

נקודת מפתח: אם העמודה Size לא מופיעה בטבלה של בקשות הרשת, לוחצים לחיצה ימנית על כותרת הטבלה ובוחרים באפשרות Size.

בכל תא של Size מוצגים שני ערכים. הערך העליון הוא גודל המשאב שהורדתם. הערך התחתון הוא הגודל של המשאב ללא דחיסה. אם שני הערכים זהים, המשמעות היא שהמשאב לא נדחס בזמן שהוא נשלח ברשת. בדוגמה הזו, הערכים העליון והתחתון של bundle.js הם 1.4 MB.

אפשר גם לבדוק אם יש דחיסה על ידי בדיקת כותרות ה-HTTP של המשאב:

1. לוחצים על bundle.js ופותחים את הכרטיסייה Headers.

   

2. מחפשים כותרת content-encoding בקטע Response Headers. לא אמור להופיע קו, כלומר bundle.js לא עבר דחיסה. כשמשאב דחוס, הכותרת הזו בדרך כלל מוגדרת לערך gzip, deflate או br. הסבר על הערכים האלה זמין במאמר הוראות.

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

1. בכרטיסיית העריכה, פותחים את הקובץ server.js ומוסיפים את שתי השורות הבאות (מודגשות):

   ...
   const fs = require('fs');
   const compression = require('compression');
   
   app.use(compression());
   app.use(express.static('build'));
   ...
   

2. חשוב להוסיף את app.use(compression()) לפני app.use(express.static('build')).

   

   הערה: בדרך כלל צריך להתקין את החבילה compression באמצעות npm i -S compression, אבל זה כבר בוצע בשבילכם.

3. ממתינים עד שמערכת Glitch פורסת את הגרסה החדשה של האתר. אמוג'י שמח בפינה הימנית התחתונה מציין שהפריסה הושלמה.

משתמשים בתהליכי העבודה שלמדתם קודם כדי לבדוק באופן ידני אם הדחיסה פועלת:

1. חוזרים לכרטיסייה של ההדגמה וטוענים מחדש את הדף.

   עכשיו העמודה Size אמורה להציג שני ערכים שונים למשאבי טקסט כמו bundle.js. הערך העליון של 269 KB עבור bundle.js הוא גודל הקובץ שנשלח ברשת, והערך התחתון של 1.4 MB הוא גודל הקובץ ללא דחיסה.

   

2. הקטע Response Headers (כותרות התגובה) של bundle.js אמור לכלול עכשיו כותרת content-encoding: gzip.

   

מריצים שוב את דוח Lighthouse בדף כדי למדוד את ההשפעה של דחיסת הטקסט על ביצועי הטעינה של הדף:

1. פותחים את החלונית Lighthouse ולוחצים על ביצוע ביקורת… בסרגל הפעולות שבחלק העליון.

   

2. משאירים את ההגדרות כפי שהן ולוחצים על ניתוח טעינת הדף.

   

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

דחיסת טקסט בעולם האמיתי

ברוב השרתים יש תיקונים פשוטים כאלה להפעלת דחיסת הנתונים. פשוט מחפשים איך מגדירים את השרת שבו אתם משתמשים כדי לדחוס טקסט.

שינוי הגודל של תמונות

לפי הדוח החדש, שינוי הגודל של התמונות הוא הזדמנות גדולה נוספת.

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

1. בדוח, לוחצים על גודל תמונות תקין כדי לראות אילו תמונות צריך לשנות את הגודל שלהן. נראה שכל 4 התמונות גדולות מהנדרש.

   

2. חזרה לכרטיסיית העריכה, פותחים את src/model.js.

3. מחליפים את const dir = 'big' ב-const dir = 'small'. בספרייה הזו יש עותקים של אותן תמונות שגודלן השתנה.

4. בודקים שוב את הדף כדי לראות איך השינוי הזה משפיע על ביצועי הטעינה.

   

נראה שהשינוי משפיע רק במידה קטנה על ציון הביצועים הכולל. עם זאת, דבר אחד שהציון לא מראה בבירור הוא כמה נתוני רשת אתם חוסכים למשתמשים. הגודל הכולל של התמונות הישנות היה כ-6.1MB, והוא עכשיו רק כ-633KB. אפשר לבדוק את זה בשורת הסטטוס שבתחתית החלונית Network.

שינוי גודל של תמונות בעולם האמיתי

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

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

הסרת משאבים שחוסמים את העיבוד

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

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

לכן, המשימה הראשונה היא למצוא קוד שלא צריך להריץ בטעינת הדף.

1. לוחצים על Eliminate render-blocking resources (הסרת משאבים שחוסמים את העיבוד) כדי לראות את המשאבים החוסמים: lodash.js ו-jquery.js.

   

2. בהתאם למערכת ההפעלה, מקישים על אחד מהמקשים הבאים כדי לפתוח את תפריט הפקודות:

   • ב-Mac, מקישים על Command+Shift+P
   • ב-Windows,‏ Linux או ChromeOS, מקישים על Control+Shift+P.

3. מתחילים להקליד Coverage ובוחרים באפשרות הצגת הכיסוי.

   

   הכרטיסייה כיסוי נפתחת במגירה.

   

4. לוחצים על רענון טעינה מחדש. בכרטיסייה Coverage מוצגת סקירה כללית של חלק הקוד ב-bundle.js, ב-jquery.js וב-lodash.js שמופעל במהלך טעינת הדף.

   

   בצילום המסך הזה מוצג ש-74% ו-30% מקובצי jQuery ו-Lodash לא נמצאים בשימוש, בהתאמה.

5. לוחצים על השורה jquery.js. הקובץ נפתח בחלונית מקורות ב-DevTools. אם לצד שורת קוד מופיעה פס ירוק, סימן שהיא בוצעה. אם מופיעה פס אדום לצד שורת קוד, סימן שהקוד לא בוצע, ובהחלט לא נדרש לטעינת הדף.

   

6. גוללים קצת בקוד של jQuery. חלק מהשורות שמתבצעת בהן 'הפעלה' הן למעשה רק הערות. אפשר גם להריץ את הקוד הזה דרך כלי למינימיזציה שמסיר את התגובות, כדי לצמצם את הגודל של הקובץ.

בקיצור, כשעובדים עם קוד משלכם, הכרטיסייה Coverage יכולה לעזור לכם לנתח את הקוד, שורה אחרי שורה, ולשלוח רק את הקוד שנחוץ לטעינת הדף.

האם הקבצים jquery.js ו-lodash.js נחוצים בכלל לטעינת הדף? בכרטיסייה Request Blocking אפשר לראות מה קורה כשמשאבים לא זמינים.

1. לוחצים על הכרטיסייה Network ופותחים שוב את Command Menu.

2. מתחילים להקליד blocking ובוחרים באפשרות Show Request Blocking. הכרטיסייה Request Blocking (חסימת בקשות) נפתחת.

   

3. לוחצים על הוספת דפוס, מקלידים /libs/* בתיבת הטקסט ומקישים על Enter כדי לאשר.

   

4. טוענים מחדש את הדף. הבקשות של jQuery ו-Lodash מוצגות באדום, כלומר הן נחסמו. הדף עדיין נטען והוא אינטראקטיבי, כך שנראה שאין צורך במשאבים האלה בכלל.

   

5. לוחצים על הסרת כל הדפוסים כדי למחוק את דפוס החסימה /libs/*.

באופן כללי, הכרטיסייה Request Blocking (חסימת בקשות) שימושית כדי לדמות את התנהגות הדף כשמשאב מסוים לא זמין.

עכשיו מסירים מהקוד את ההפניות לקבצים האלה ובודקים שוב את הדף:

1. חזרה לכרטיסיית העריכה, פותחים את template.html.

2. מוחקים את תגי <script> התואמים:

   <head>
       ...
       <meta name="viewport" content="width=device-width, initial-scale=1">
       <script src="/libs/lodash.js"></script>
       <script src="/libs/jquery.js"></script>
       <title>Tony's Favorite Foods</title>
   </head>
   

3. ממתינים עד שהאתר יבנה מחדש ויפורס מחדש.

4. בודקים שוב את הדף בחלונית Lighthouse. הציון הכולל אמור להשתפר שוב.

   

אופטימיזציה של הנתיב הקריטי לעיבוד בעולם האמיתי

נתיב העיבוד הקריטי מתייחס לקוד שדרוש לטעינת דף. באופן כללי, אפשר לזרז את הטעינה של הדף על ידי שליחת קוד קריטי בלבד במהלך הטעינה של הדף, ולאחר מכן להשתמש בטעינה איטית (lazy-loading) לכל שאר הקוד.

• סביר להניח שלא תמצאו סקריפטים שתוכלו להסיר באופן מיידי, אבל לעיתים קרובות תגלו שאפשר לבקש סקריפטים רבים באופן אסינכרוני במקום לבקש אותם במהלך טעינת הדף. שימוש ב-async או ב-defer
• אם אתם משתמשים ב-framework, כדאי לבדוק אם יש לו מצב ייצור. במצב הזה יכול להיות שייעשה שימוש בתכונה כמו tree shaking כדי להסיר קוד מיותר שחוסם את העיבוד הקריטי.

לבצע פחות עבודה ב-thread הראשי

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

בשרשור הראשי הדפדפן מבצע את רוב העבודה הנדרשת כדי להציג דף, כמו ניתוח והפעלה של HTML,‏ CSS ו-JavaScript.

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

המטרה היא להשתמש בחלונית ביצועים כדי לנתח את העבודה שהשרשור הראשי מבצע בזמן טעינת הדף, ולמצוא דרכים לדחות או להסיר עבודה מיותרת.

1. פותחים את ביצועים > הגדרות הצילום ומגדירים את הרשת ל-3G איטי ואת מעבד ל-האטה פי 6.

   

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

2. לוחצים על רענון טעינה מחדש. כלי הפיתוח טוענים מחדש את הדף ואז יוצרים תצוגה חזותית של כל הפעולות שהם נאלצו לבצע כדי לטעון את הדף. נתייחס לתצוגה החזותית הזו בתור המסלול.

   

בתרשים מתועדת הפעילות באופן כרונולוגי, מימין לשמאל. התרשימים של FPS,‏ CPU ו-NET בחלק העליון מספקים סקירה כללית של הפריימים לשנייה, פעילות המעבד ופעילות הרשת.

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

בודקים את המעקב כדי למצוא דרכים לבצע פחות עבודה ב-JavaScript:

1. לוחצים על הקטע Timings כדי להרחיב אותו.

   

   יש כמה מדדים של User Timing מ-React. נראה שהאפליקציה של Tony משתמשת במצב הפיתוח של React. מעבר למצב הייצור של React צפוי להניב שיפורים קלים בביצועים.

2. לוחצים שוב על Timings כדי לכווץ את הקטע הזה.

3. עיינו בקטע ראשי. בקטע הזה מוצג יומן כרונולוגי של הפעילות בשרשור הראשי, מימין לשמאל. בציר y (למעלה למטה) מוצגות הסיבות לאירועים.

   

   בדוגמה הזו, האירוע Evaluate Script גרם להפעלה של הפונקציה (anonymous), שהפעלה את __webpack__require__, שהפעלה את ./src/index.jsx וכן הלאה.

4. גוללים לתחתית הקטע ראשי. כשמשתמשים ב-framework, רוב הפעילות ברמה העליונה נובעת מה-framework, שבדרך כלל לא בשליטתכם. הפעילות שנגרמה על ידי האפליקציה שלכם מופיעה בדרך כלל בתחתית המסך.

   

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

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

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

   

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

   בעמודה זמן עצמי מוצג משך הזמן שהוקצה ישירות לכל פעילות. במקרה הזה, כ-82% מהזמן של ה-thread הראשי הושפע מהפונקציה mineBitcoin.

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

1. בכרטיסייה של העורך, פותחים את webpack.config.js.
2. משנים את "mode":"development" ל-"mode":"production".
3. ממתינים לפריסה של ה-build החדש.

4. בודקים שוב את הדף.

   

כדי לצמצם את הפעילות של JavaScript, מסירים את הקריאה ל-mineBitcoin:

1. בכרטיסייה של העורך, פותחים את src/App.jsx.
2. מסמנים את הקריאה ל-this.mineBitcoin(1500) ב-constructor בתור תגובה.
3. ממתינים לפריסה של הגרסה החדשה.
4. בודקים שוב את הדף.

כמו תמיד, עדיין יש דברים שאפשר לעשות, למשל לצמצם את המדדים Largest Contentful Paint ו-Cumulative Layout Shift.

הצלחה: אבל נראה שהשינוי האחרון גרם לעלייה משמעותית בביצועים!

ביצוע פחות עבודה ב-thread הראשי בעולם האמיתי

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

אם אתם מעדיפים גישה שדומה יותר ל-console.log(), ה-API של User Timing מאפשר לכם לסמן באופן שרירותי שלבים מסוימים במחזור החיים של האפליקציה, כדי לעקוב אחרי משך הזמן של כל אחד מהשלבים האלה.

סיכום

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

השלבים הבאים

כדאי להריץ בדיקות באתר שלכם. אם אתם צריכים עזרה בפירוש הדוח או כדי למצוא דרכים לשיפור ביצועי הטעינה, כדאי לבדוק את כל הדרכים לקבלת עזרה מקהילת DevTools:

• אפשר לדווח על באגים במסמך הזה במאגר developer.chrome.com.
• אפשר לדווח על באגים ב-DevTools בכתובת באגים ב-Chromium.
• אפשר לדון בתכונות ובשינויים ברשימת התפוצה. אין להשתמש ברשימת הדיוור לשליחת שאלות תמיכה. במקום זאת, כדאי להשתמש ב-Stack Overflow.
• ב-Stack Overflow תוכלו לקבל עזרה כללית בנושא השימוש בכלי הפיתוח. תמיד צריך להשתמש ב-Chromium Bugs כדי לשלוח בקשות לדיווח על באגים.
• אפשר לשלוח לנו ציוץ ב-‎@ChromeDevTools.