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

קייס בסקית

Twitter GitHub תקלה

סופיה אמליאנובה

GitHub

מטרת המדריך

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

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

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

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

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

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

מבוא

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

טוני החתול.

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

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

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

הגדרה

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

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

   

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

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

   

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

   

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

הגדרת בסיס

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

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

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

   

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

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

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

   

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

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

הסבר על הדוח

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

מדדים

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

חלק זה מספק מדידות כמותיות של ביצועי האתר. כל מדד מספק תובנות לגבי היבט אחר של הביצועים. לדוגמה, באמצעות הצגת תוכן ראשוני (First Contentful Paint) אפשר לדעת מתי התוכן צולם לראשונה במסך. זו אבן דרך חשובה בתפיסת הטעינה של הדף על ידי המשתמשים, ואילו 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. ממתינים ל-גליץ' כדי לפרוס את גרסת ה-build החדשה של האתר. אמוג'י שמח בפינה הימנית התחתונה מציין שהפריסה בוצעה בהצלחה.

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

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

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

   

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

   

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

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

   

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

   

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

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

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

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

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

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

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

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

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

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 הראשי

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

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

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

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

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

   

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

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

   

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

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

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

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

   

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

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

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

   

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

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

   

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

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

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

   

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

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

כמו תמיד, עדיין יש מה לעשות, למשל, להפחית את המדדים Largest Contentful Paint (LCP) ו-Cumulative Layout Shift (CLS).

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

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

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

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

סיכום

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

השלבים הבאים

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

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