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

Kayce Basques

Sofia Emelianova

מטרת המדריך

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

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

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

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

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

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

מבוא

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

טוני החתול.

שלב 1: בדיקת האתר

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

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

הגדרה

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

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

   

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

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

   

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

   

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

הגדירו בסיס

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

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

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

   

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

   • check_box פינוי נפח אחסון. הפעלת תיבת הסימון הזו גורמת לניקוי כל האחסון המשויך לדף לפני כל ביקורת. השאירו את ההגדרה מופעלת אם אתם רוצים לבדוק איך מבקרים שמבקרים באתר שלכם חווים את החוויה הראשונה שלהם. אפשר להשבית את ההגדרה הזו אם רוצים חוויה של ביקור חוזר.
   • check_box הפעלה של דגימת JS. האפשרות הזו מושבתת כברירת מחדל. כשההגדרה מופעלת, המערכת מוסיפה מחסניות קריאות מפורטות של JavaScript למעקב הביצועים, אבל עלולה להאט את יצירת הדוחות. המעקב זמין בתפריט 'כלים' more_vert > הצגת המעקב ללא ויסות נתונים אחרי יצירת הדוח Lighthouse.
   • סימולציה של ויסות נתונים (throttle) (ברירת מחדל) . האפשרות הזו מדמה את התנאים האופייניים של גלישה במכשיר נייד. התכונה נקראת 'Simulated' כי לא ניתן לבצע ויסות נתונים (throttle) ב-Lighthouse במהלך תהליך הביקורת. במקום זאת, הוא רק מבצע אקסטרפולציה של הזמן שייקח לדף להיטען בתנאים לניידים. לעומת זאת, ההגדרה ויסות נתונים (throttle) (מתקדם) של כלי פיתוח לעומת זאת, מווסתת את המעבד (CPU) והרשת שלך, מה שמוביל לתהליך ביקורת ארוך יותר.
   • מצב > ניווט (ברירת מחדל). המצב הזה מנתח טעינת דף יחידה וזה מה שדרוש לנו במדריך הזה. מידע נוסף זמין במאמר שלושת המצבים.
   • מכשיר > נייד. האפשרות לנייד משנה את המחרוזת של סוכן המשתמש ומדמה אזור תצוגה של נייד. אפשרות שולחן העבודה כמעט פשוט משביתה את השינויים בנייד.
   • קטגוריות > check_box ביצועים. אם מפעילים קטגוריה אחת, מערכת Lighthouse תיצור דוח רק עם קבוצת הביקורות התואמת. אפשר להשאיר את הקטגוריות האחרות מופעלות כדי לראות את סוגי ההמלצות שהן מספקות. השבתת קטגוריות לא רלוונטיות מזרזת מעט את תהליך הביקורת.

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

   

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

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

הסבר על הדוח

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

מדדים

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

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

צילומי מסך

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

הזדמנויות

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

לוחצים על הזדמנות כדי לקבל מידע נוסף עליה.

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

אבחון

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

בדיקות שעברו בהצלחה

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

שלב 2: ניסוי

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

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

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

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

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

פותחים את החלונית רשת ומסמנים את התיבה הגדרות > שימוש בשורות בקשה גדולות.

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

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

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

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

   

2. חיפוש כותרת content-encoding בקטע כותרות תגובה. לא אמור להופיע קובץ כזה, כלומר 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 תתחיל לפרוס את גרסת ה-build החדשה של האתר. אם סמל האמוג'י שמח בפינה הימנית התחתונה, פריסה מוצלחת.

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

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

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

   

2. הקטע כותרות תגובה של 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. אפשר לבדוק את זה בשורת הסטטוס בחלק התחתון של החלונית רשת.

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

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

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

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

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

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

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

1. לוחצים על הסרת משאבים שחוסמים עיבוד כדי להציג את המשאבים החוסמים: lodash.js ו-jquery.js.

   

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

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

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

   

   הכרטיסייה כיסוי תיפתח בחלונית ההזזה.

   

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

   

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

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

   

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

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

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

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

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

   

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

   

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

   

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

באופן כללי, הכרטיסייה Request block שימושית להדמיה של אופן הפעולה של הדף כשאין משאב נתון זמין.

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

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. הציון הכולל שלך אמור להשתפר שוב.

   

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

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

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

פחות עבודה בשרשור הראשי

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

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

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

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

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

   

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

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

   

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

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

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

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

   

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

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

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

   

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

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

   

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

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

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. ממתינים לפריסה של ה-build החדש.
4. צריך לבדוק את הדף שוב.

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

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

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

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

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

סיכום

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

השלבים הבאים

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

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