Lighthouse הוא כלי אוטומטי לשיפור האיכות של האתר שלכם. נותנים לה כתובת URL, והיא מספקת רשימה של המלצות לשיפור ביצועי הדפים, להנגשת דפים, לציות לשיטות מומלצות ועוד. אפשר להפעיל אותו מתוך כלי הפיתוח ל-Chrome, כתוסף ל-Chrome או אפילו כמודול של צומת, שימושי לאינטגרציה רציפה (CI).
בעבר, צוות Lighthouse מספק הרבה טיפים לשיפור הביצועים של טעינת דפים, כמו הפעלה של דחיסת טקסט או הורדה של סקריפטים שחוסמים עיבוד. צוות Lighthouse ממשיך לשלוח ביקורות חדשות כדי לתת לכם עצות מועילות עוד יותר לשיפור המהירות של האתרים שלכם. בפוסט הזה תוכלו למצוא סיכום של ביקורות ביצועים שימושיות שאולי לא ידעתם עליהן, כמו:
- פירוט העבודה ב-thread הראשי
- טעינה מראש של בקשות מרכזיות
- זמן ההפעלה של JavaScript ארוך
- הימנעות מהפניות אוטומטיות של דפים
- JavaScript שאינו בשימוש
- נעשה שימוש במדיניות לא יעילה בנושא מטמון לגבי נכסים סטטיים
- נמנעים מנסיעות הלוך ושוב יקרות לכל מקור
- שימוש בפורמטים של סרטונים לתוכן אנימציה
- כל הטקסט נשאר גלוי במהלך טעינות של webfont
- CSS ו-JavaScript לא מוגזמים
- כללי CSS שאינם בשימוש
פירוט עבודות ב-thread הראשי
אם השתמשתם פעם בחלונית הביצועים בכלי הפיתוח, זה יכול להיות קצת מטלה אנחנו שמחים להודיע שהמידע הזה זמין עכשיו בצורה נוחה ונוחה, באמצעות הביקורת החדשה של Main Thread Work Breakdown.
![פירוט של הפעילות ב-thread הראשי ב-Lighthouse.](https://developer.chrome.google.cn/static/blog/lighthouse-load-performance/image/a-breakdown-main-thread-e3b2e284a3af3.png?authuser=0000&hl=he)
האבחון החדש מאפשר להעריך את כמות הפעילות וסוג הפעילות במהלך טעינת דף. בעזרת האבחון הזה תוכלו לטפל בבעיות בביצועי הטעינה שקשורות לפריסה, להערכת הסקריפט, לניתוח ולפעילות אחרת.
טעינה מראש של בקשות מרכזיות
כשהדפדפנים מאחזרים משאבים, הם מוצאים הפניות אליהם במסמך ובמשאבי המשנה שלו. לפעמים זה לא אופטימלי, כי חלק מהמשאבים הקריטיים מתגלים בשלב מאוחר בתהליך טעינת הדף. למרבה המזל, rel=preload
מאפשר למפתחים לרמוז לדפדפנים תואמים אילו משאבים צריך לאחזר בהקדם האפשרי. הביקורת החדשה לגבי Preload Key Requests מאפשרת למפתחים לדעת לאילו משאבים כדאי לטעון את המשאבים מוקדם יותר עד rel=preload
.
![הביקורת Preload Key requests Lighthouse
תמליץ על רשימת משאבים שכדאי לשקול לבצע טעינה מראש.](https://developer.chrome.google.cn/static/blog/lighthouse-load-performance/image/the-preload-key-requests-7202b7a2648b5.png?authuser=0000&hl=he)
חשוב מאוד לבדוק ולהשוות את השינויים בביצועים עם rel=preload
וגם בלעדיו, כי הם יכולים להשפיע על ביצועי הטעינה בדרכים לא צפויות. לדוגמה, טעינה מראש של תמונה גדולה יכולה לעכב את העיבוד הראשוני, אבל החיסרון הוא שהתמונה שנטענה מראש תופיע מוקדם יותר בפריסה.
ודא תמיד שהתוצאות יהיו מעניינות!
זמן ההפעלה של JavaScript ארוך
כשטוענים יותר מדי JavaScript, הדף עלול שלא להגיב בזמן שהדפדפן מנתח, מהדר ומפעיל אותו. סקריפטים ופרסומות של צד שלישי הם מקור מיוחד של פעילות סקריפטים מוגזמת, שעלולה לפגוע אפילו במכשירים רבי עוצמה. הביקורת החדשה זמן ההפעלה של JavaScript גבוה חושפת כמה זמן צריכת המעבד (CPU) צורכת לכל סקריפט בדף, יחד עם כתובת ה-URL שלו:
![מגדלור שבו מוצגת כמות ההערכות, הניתוח וזמן ההידור של הסקריפטים בדף.](https://developer.chrome.google.cn/static/blog/lighthouse-load-performance/image/lighthouse-displaying-am-5e29efaa34f93.png?authuser=0000&hl=he)
כשמריצים את הביקורת הזו, אפשר גם להפעיל תגים של צד שלישי בחלונית הרשת ולסנן את הרשימה כדי לזהות משאבי סקריפטים של צד שלישי. בעזרת נתוני הביקורת, תוכלו למצוא מקורות של פעילות JavaScript מוגזמת שהופכת דפים ממהירות למהירות לאיחורים. בסקריפטים ספציפיים לאפליקציה שלכם, תוכלו להשתמש בשיטות כמו פיצול קוד וניעור עצים כדי להגביל את כמות ה-JavaScript בכל דף באתר.
אין הפניות לכתובות URL אחרות של דפים
לפעמים, כשדפדפן מבקש כתובת URL, השרת יכול להגיב באמצעות קוד סטטוס ברמה 300. פעולה זו גורמת לדפדפן להפנות מחדש לכתובת אתר אחרת. הפניות אוטומטיות נחוצות לצורך אופטימיזציה למנועי חיפוש ונוחות, אבל הן מוסיפות זמן אחזור לבקשות. זה נכון במיוחד אם הם מפנים למקורות אחרים, מה שעלול לגרום לחיפוש DNS נוסף ולזמן משא ומתן נוסף של חיבור/TLS.
![שרשרת הפניה, כפי שהיא מופיעה בחלונית הרשת בכלים למפתחים של Chrome.](https://developer.chrome.google.cn/static/blog/lighthouse-load-performance/image/a-redirect-chain-seen-t-c3da7204aa81c.png?authuser=0000&hl=he)
הפניות אוטומטיות אינן רצויות לדפי נחיתה באתר. כדי לעזור לכם לקצר את זמן האחזור ולשפר את ביצועי הטעינה, עכשיו תוכלו למצוא ב-Lighthouse את הביקורת הימנעות מהפניות אוטומטיות של דפים, שמאפשרת לדעת מתי ניווט גורם להפניות אוטומטיות.
![רשימה של הפניות אוטומטיות לדפים ב-Lighthouse.](https://developer.chrome.google.cn/static/blog/lighthouse-load-performance/image/a-list-page-redirects-l-72c6c3f600ea1.png?authuser=0000&hl=he)
שימו לב שקשה להפעיל את הביקורת הזו בגרסת DevTools של Lighthouse, כי היא מנתחת את כתובת ה-URL הנוכחית בסרגל הכתובות של הדף, שמשקפת את הפתרון של כל ההפניות האוטומטיות. סביר להניח שהביקורת הזו תאוכלס ב-CLI של הצומת.
JavaScript שאינו בשימוש
קוד מת יכול להיות בעיה חמורה באפליקציות עתירות JavaScript. אין לה עלויות ביצוע כי אף פעם לא משתמשים בה, אבל יש לה השפעות לא רצויות אחרות. עדיין מתבצעת הורדה, ניתוח והידור של קוד המת על ידי הדפדפן. המצב הזה משפיע על ביצועי הטעינה ועל זמן האתחול של JavaScript. בדומה לחלונית הכיסוי בכלי הפיתוח, הביקורת Unused JavaScript חושפת את קטע ה-JavaScript שהורדו על ידי הדף הנוכחי, אבל אף פעם לא נעשה בו שימוש.
![מגדלור שבו מוצגת כמות ה-JavaScript שלא בשימוש בדף.](https://developer.chrome.google.cn/static/blog/lighthouse-load-performance/image/lighthouse-displaying-am-a23812d7b204e.png?authuser=0000&hl=he)
בעזרת הביקורת הזו תוכלו לזהות קוד מת באפליקציות שלכם ולהסיר אותו, כדי לשפר את ביצועי הטעינה ולהפחית את השימוש במשאבי המערכת. טיפ למתקדמים: כדי למצוא את המידע הזה, אפשר גם להשתמש בחלונית כיסוי הקוד בכלי הפיתוח של Chrome!
נעשה שימוש במדיניות לא יעילה בנושא מטמון לגבי נכסים סטטיים
עצות רבות לגבי ביצועים בדרך כלל מתמקדות בהאצת מהירות האתר למשתמשים חדשים, אבל חשוב גם להשתמש בשמירה במטמון כדי לשפר את ביצועי הטעינה למשתמשים חוזרים. שימוש במדיניות לא יעילה לגבי מטמון בנכסים סטטיים בודק את הכותרות במטמון של משאבי הרשת, ומודיע לכם אם כללי המדיניות של המטמון של משאבים סטטיים הם לא סטנדרטיים.
![טבלת נכסים סטטיים](https://developer.chrome.google.cn/static/blog/lighthouse-load-performance/image/static-assets-table-dea15788be084.png?authuser=0000&hl=he)
בעזרת הביקורת הזו תוכלו למצוא ולתקן בקלות בעיות במדיניות המטמון הנוכחית. הפעולה הזו תשפר מאוד את הביצועים של משתמשים חוזרים, והם יעריכו את המהירות הנוספת!
נמנעים מנסיעות הלוך ושוב יקרות לכל מקור
כשדפדפנים מאחזרים משאבים מהשרת, יכול להיות שייקח הרבה זמן לבצע חיפוש DNS וליצור חיבור לשרת.
בעזרת rel=preconnect
מפתחים יכולים להסוות את זמן האחזור על ידי יצירת חיבורים לשרתים אחרים לפני שהדפדפן היה מוכן. בעזרת הביקורת להימנע מנסיעות הלוך ושוב יקרות לכל מקור תוכלו לגלות הזדמנויות להשתמש ב-rel=preconnect
!
![רשימת מקורות מומלצים ל-rel=preconnectin Lighthouse.](https://developer.chrome.google.cn/static/blog/lighthouse-load-performance/image/a-list-origins-recommend.png?authuser=0000&hl=he)
rel=preconnect
ב-Lighthouse.כשזמן האחזור של נכסים ממקורות שונים מתקצר, המשתמשים יבחינו בכך שדברים מתקדמים קצת יותר מהר. הביקורת החדשה במסגרת Lighthouse תעזור לכם לגלות הזדמנויות חדשות להשתמש ב-rel=preconnect
כדי לעשות זאת.
שימוש בפורמטים של סרטונים לתוכן אנימציה
קובצי GIF מונפשים הם ענקים, ולרוב הם צורכים לפחות כמה מאות קילו-בייט אם לא כמה מגה-בייט של נתונים. אם חשוב לכם לטעון את הביצועים, כדאי לכם להמיר את קובצי ה-GIF האלה לווידאו. למרבה המזל, תוכלו להיעזר בביקורת שימוש בפורמטים של סרטונים לתוכן מונפש.
![המלצה להמיר קובץ GIF לסרטון ב-Lighthouse.](https://developer.chrome.google.cn/static/blog/lighthouse-load-performance/image/a-recommendation-convert-f5f2e89da90f5.png?authuser=0000&hl=he)
אם יש באתר קובצי GIF בגודל של יותר מ-100KB, הביקורת הזו תסומן באופן אוטומטי ותפנה אתכם להנחיות שונות לגבי המרתם לווידאו והטמעה שלהם. אתרים כמו Imgur שיפרו באופן משמעותי את ביצועי הטעינה על ידי המרת קובצי ה-GIF שלהם לווידאו. בנוסף, אם האתר שלכם נמצא בתוכנית אירוח עם רוחב פס של מכסת מאמרים ללא תשלום, החיסכון הפוטנציאלי בעלויות אמור להספיק כדי לשכנע אתכם.
כל הטקסט נותר גלוי במהלך טעינת גופן אינטרנט
כשטוענים גופני אינטרנט לדפים, לעיתים קרובות דפדפנים מעבדים טקסט בלתי נראה עד שהגופן נטען. התופעה הזו, שנקראת הפלאש של טקסט בלתי נראה (FOIT)), יכולה להתאים לכם מבחינת העיצוב, אבל למעשה זו בעיה. לא ניתן לקרוא טקסט שחסום לעיבוד שלו לפני שהוא עובר רינדור והופך לגלוי. בזמן אחזור גבוה ו/או חיבורים עם רוחב פס גבוה, המשמעות היא שחסר חלק מרכזי בחוויית המשתמש. היא גם יכולה להיות סוג של בעיה בביצועים תפיסתיים, מאחר שהדף לא מציג תוכן משמעותי במהירות האפשרית. למרבה המזל, הביקורת כל הטקסט נשאר גלוי במהלך טעינה של גופן אינטרנט עוזרת למצוא הזדמנויות לתיקון הבעיה באתר.
![מגדלור שבו מוצגות המלצות לשיפור
רינדור הגופנים.](https://developer.chrome.google.cn/static/blog/lighthouse-load-performance/image/lighthouse-giving-recomme-5ae7ecd78d527.png?authuser=0000&hl=he)
אם מערכת Lighthouse מזהה גופני אינטרנט באפליקציה שלכם שמעכבים את עיבוד הטקסט, יש כמה פתרונות אפשריים. ניתן לשלוט בעיבוד טקסט באמצעות font-display
מאפיין CSS ו/או Font Browser API.
אם אתם רוצים להתעמק בנושא, כדאי לקרוא את מדריך מקיף לאסטרטגיות טעינת גופנים, מדריך מצוין של זאק Leatherman, שהוא משאב מצוין לטעינת גופנים אופטימלית.
CSS ו-JavaScript לא מוגבלים
הקטנה היא שיטה מומלצת, כי יש חשיבות רבה לביצועים באינטרנט, ויש לה סיבה טובה. המשאבים האלה מצמצמים משמעותית את הגודל של משאבים מבוססי טקסט, מה שמביא לשיפור בביצועים של הטעינה. אבל אפשר להתעלם מהאופטימיזציה הזו, במיוחד אם תהליכי ה-build לא מטפלים בה. הביקורות של Minify CSS ו-Minify JavaScript (הקטנת JavaScript) יאספו רשימה של משאבים לא מזוהים שהוא ימצא בדף הנוכחי. משם תוכלו לבצע פעולות על ידי הקטנת הקבצים האלה באופן ידני, או הרחבת מערכת ה-build כדי לעשות זאת בשבילכם.
כללי CSS שאינם בשימוש
מכיוון שהאתר מתחיל להשתבש קצת יותר זמן, בלתי נמנע שהפסולת שנשארה מארגון מחדש של הקוד מתחילה להצטבר. אחד מהם הוא סוג של כללי CSS שלא נמצאים בשימוש, שכבר לא נחוצים לאתר, אבל עדיין צורכים רוחב פס. לנוחותכם, כללי CSS שאינם בשימוש חושפים אילו משאבי CSS בדף מכילים CSS שאינו בשימוש.
![מגדלור שמציג רשימה של משאבי CSS שמכילים כללי CSS שלא נמצאים בשימוש.](https://developer.chrome.google.cn/static/blog/lighthouse-load-performance/image/lighthouse-showing-list-4c81bbd36a223.png?authuser=0000&hl=he)
אם מערכת Lighthouse מוצאת בדף CSS שאינו בשימוש, יש דרכים להסיר אותו. UnCSS הוא שירות אחד כזה שעושה את זה עבורכם באופן אוטומטי (אבל צריך להשתמש בו בזהירות). כדי להשתמש בשיטה ידנית יותר, צריך להשתמש בחלונית כיסוי הקוד בכלי הפיתוח. אבל חשוב לזכור ש-CSS שלא נמצא בשימוש בדף אחד עשוי להיות נחוץ בדף אחר. גישה נוספת יכולה להיות פיצול ה-CSS לקבצים ספציפיים לתבנית שנטענים רק לפי הצורך. לא משנה מה תחליטו, הכלי Lighthouse יהיה שם כדי להודיע לכם אם השינויים בשירות ה-CSS שלכם גדלים.
כדאי לנסות את Lighthouse
אם אתם מתלהבים מהביקורות החדשות האלה, כדאי לעדכן את Lighthouse ולנסות אותן.
- התוסף Lighthouse ל-Chrome אמור להתעדכן באופן אוטומטי, אבל אפשר לעדכן אותו באופן ידני דרך
chrome://extensions
. - בכלי הפיתוח, אפשר להריץ את Lighthouse בחלונית הביקורת. Chrome מתעדכן לגרסה חדשה מדי 6 שבועות בערך, לכן ייתכן שביקורות חדשות יותר לא יהיו זמינות. אם אתם לא יודעים להשתמש בביקורות העדכניות ביותר, תוכלו להוריד את Chrome Canary כדי להריץ את הקוד העדכני ביותר של Chrome.
- למשתמשי צמתים: מריצים את
npm update lighthouse
או אתnpm update lighthouse -g
אם התקנתם את Lighthouse באופן גלובלי.
תודה מיוחדת לקייס באסקי, פטריק הולסה, אדי אוסמאני ווינראטה סינגל על המשוב החשוב שלהם, ששיפר משמעותית את איכות המאמר.