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

סקירה כללית

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

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

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

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

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

מטרת המדריך

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

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

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

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

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

מבוא

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

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

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

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

הגדרה

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

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

   

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

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

   

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

   

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

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

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

   

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

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

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

   

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

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

הסבר על הדוח

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

מדדים

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

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

צילומי מסך

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

הזדמנויות

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

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

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

אבחון

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

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

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

שלב 2: ניסוי

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

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

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

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

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

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

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

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

1. לוחצים על bundle.js ופותחים את הכרטיסייה 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')).

   

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. משאירים את ההגדרות כפי שהן ולוחצים על ניתוח טעינת הדף.

   

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

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

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

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

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

שינוי הגודל של התמונות עוזר לקצר את זמן הטעינה על ידי צמצום גודל הקובץ של התמונות. אם המשתמש צופה בתמונות במסך של מכשיר נייד ברוחב 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. לוחצים על הסרת משאבים שחוסמים את העיבוד כדי לראות את המשאבים החוסמים: lodash.js ו-jquery.js.

   

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

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

3. מתחילים להקליד Coverage ובוחרים באפשרות Show Coverage.

   

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

   

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

   

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

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

   

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

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

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

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

2. מתחילים להקליד 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. לוחצים על הקטע תזמונים כדי להרחיב אותו.

   

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

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

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. ממתינים לפריסה של הגרסה החדשה.

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.