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

סקירה כללית

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

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

... ומדדים רבים נוספים.

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

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

מטרת המדריך

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

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

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

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

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

מבוא

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

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

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

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

הגדרה

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

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

   

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

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

   

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

   

הגדירו בסיס

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

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

   

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

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

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

   

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

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

הסבר על הדוח

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

מדדים

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

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

צילומי מסך

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

הזדמנויות

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

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

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

אבחון

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

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

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

שלב 2: ניסוי

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

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

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

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

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

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

בכל תא של 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')).

   

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

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

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

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

   

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

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

   

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

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

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

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

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

   

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

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

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

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

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

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

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

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

   

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

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

   

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

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

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

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

   

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

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

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

   

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

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

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

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

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

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

סיכום

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

השלבים הבאים

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

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