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

Sofia Emelianova
Sofia Emelianova

סקירה כללית

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

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

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

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

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

מטרת המדריך

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

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

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

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

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

מבוא

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

החתול טוני.

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

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

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

הגדרה

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

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

    המקור המקורי והכרטיסייה של הכלי לעריכה אחרי שלוחצים על 'רמיקס'.

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

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

    כרטיסיית ההדגמה.

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

    כלי פיתוח וההדגמה.

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

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

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

    חלונית Lighthouse.

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

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

    דוח Lighthouse לגבי ביצועי האתר.

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

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

דוח עם שגיאה.

הסבר על הדוח

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

דירוג הביצועים הכולל.

מדדים

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

הקטע 'מדדים'.

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

צילומי מסך

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

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

הזדמנויות

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

הקטע 'הזדמנויות'.

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

מידע נוסף על ההזדמנות לדחיסת טקסט.

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

אבחון

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

הקטע 'אבחון'.

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

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

הקטע 'ביקורות שעברו בהצלחה'.

שלב 2: ניסוי

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

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

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

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

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

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

העמודה 'גודל' בחלונית 'רשת' שבה מוצגות שורות בקשה גדולות.

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

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

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

    הכרטיסייה Headers (כותרות).

  2. בקטע Response Headers (כותרות תגובה), מחפשים כותרת 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')).

    עריכה של Server.js.

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

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

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

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

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

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

    הקטע 'כותרות התגובה' מכיל עכשיו כותרת של קידוד תוכן.

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

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

    הלחצן 'ביצוע בדיקה'.

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

    דוח Lighthouse אחרי הפעלת דחיסת טקסט.

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

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

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

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

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

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

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

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

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

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

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

    דוח Lighthouse אחרי שינוי גודל התמונות.

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

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

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

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

  • שינוי הגודל של תמונות במהלך תהליך ה-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 ובוחרים באפשרות Show Coverage.

    פתיחת תפריט הפקודות מהחלונית של Lighthouse.

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

    הכרטיסייה 'כיסוי'.

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

    דוח הפריטים הנכללים באינדקס.

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

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

    הצגת קובץ jQuery בחלונית המקורות.

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

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

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

  1. לוחצים על הכרטיסייה Network ופותחים שוב את Command Menu.
  2. מתחילים להקליד blocking ובוחרים באפשרות הצגת הבקשות לחסימה. הכרטיסייה Request Blocking (חסימת בקשות) נפתחת.

    הכרטיסייה 'חסימת בקשות'.

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

    הוספת דפוס לחסימת כל בקשה לספרייה 'libs'.

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

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

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

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

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

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

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

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

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

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

    הגדרת הגבלת קצב העברת הנתונים של המעבד והרשת בחלונית &#39;ביצועים&#39;

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

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

    המעקב אחר טעינת הדף בחלונית &#39;ביצועים&#39;.

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

הקטע &#39;סקירה כללית&#39; בניתוח.

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

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

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

    הקטע &#39;תזמונים&#39;.

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

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

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

    הקטע הראשי.

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

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

    הפעילות של mineBitcoin.

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

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

    הכרטיסייה &#39;מלמטה למעלה&#39;.

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

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

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

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

    דוח Lighthouse אחרי הגדרת webpack לשימוש במצב ייצור.

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

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

דוח Lighthouse אחרי הסרת קוד JavaScript מיותר.

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