איתור הזדמנויות לשיפור חוויית המשתמש באמצעות הכלים של Chrome לאינטרנט.
תאריך פרסום: 11 במאי 2021
היום נסקור תכונות חדשות בכלים של Lighthouse, PageSpeed ו-DevTools שיעזרו לכם לזהות את נקודות החולשה באתר במדדי Web Vitals.
Lighthouse הוא כלי אוטומטי ברישיון קוד פתוח שבעזרתו מבצעים בדיקות לגבי ביצועים, נגישות, אפליקציות מסוג Progressive Web App, אופטימיזציה למנועי חיפוש ועוד. אפשר למצוא אותו בחבילת הכלים לניפוי באגים של כלי הפיתוח של Chrome ולהריץ אותו בכל דף אינטרנט, ציבורי או שדורש אימות. אפשר למצוא את Lighthouse גם ב-PageSpeed Insights, ב-CI וב-WebPageTest.
גרסה 7.x של Lighthouse כוללת תכונות חדשות, כמו צילומי מסך של רכיבים, שמאפשרים לבדוק בקלות חלקים בממשק המשתמש שמשפיעים על מדדי חוויית המשתמש (למשל, אילו צמתים תורמים לשינוי הפריסה).
הוספנו גם תמיכה בצילום מסך של רכיבים ב-PageSpeed Insights, כדי שתוכלו לזהות בקלות רבה יותר בעיות בבדיקות ביצועים חד-פעמיות של דפים.
מדידת מדדי הליבה לבדיקת חוויית המשתמש באתר
Lighthouse יכול למדוד באופן סינתטי את מדדי הליבה לבדיקת חוויית המשתמש באתר, כולל המהירות שבה נטען רכיב התוכן הכי גדול (LCP), מדד יציבות חזותית (CLS) ומשך הזמן הכולל של החסימה (חלופה מעבדתית למהירות התגובה לאינטראקציה ראשונה). המדדים האלה משקפים את הטעינה, את יציבות הפריסה ואת המוכנות לאינטראקציה. בדוח מופיעים גם מדדים אחרים, כמו הצגת תוכן ראשוני (FCP) שמודגשים בעתיד המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals).
בקטע 'מדדים' בדוח Lighthouse מופיעות גרסאות מעבדה של המדדים האלה. תוכלו להשתמש בו כתצוגת סיכום של ההיבטים של חוויית המשתמש שדורשים את תשומת הלב שלכם.
מדדי שדה, כמו אלה שמופיעים בדוח חוויית המשתמש ב-Chrome או ב-RUM, לא מוגבלים בדרך הזו, והם משלימים חשובים לנתוני המעבדה כי הם משקפים את החוויה של משתמשים אמיתיים. נתוני השדה לא יכולים לספק את סוגי המידע האבחוני שמקבלים במעבדה, ולכן השניים הולכים יד ביד.
זיהוי נקודות לשיפור במדדי Web Vitals
זיהוי הרכיב מסוג Largest Contentful Paint (LCP)
LCP הוא מדד של חוויית הטעינה שחווים המשתמשים. הוא מסמן את הנקודה במהלך טעינת הדף שבה התוכן הראשי – או 'הגדול ביותר' – נטען ומוצג למשתמש.
ב-Lighthouse יש ביקורת בשם 'רכיב ה-Largest Contentful Paint' שמזהה את הרכיב שהיה ה-Largest Contentful Paint. כשמציבים את הסמן מעל הרכיב, הוא מודגש בחלון הראשי של הדפדפן.
אם הרכיב הזה הוא תמונה, המידע הזה הוא רמז שימושי לכך שיכול להיות שתרצו לבצע אופטימיזציה של טעינת התמונה. ב-Lighthouse יש כמה ביקורות של אופטימיזציה של תמונות שיעזרו לכם להבין אם אפשר לדחוס את התמונות בצורה טובה יותר, לשנות את הגודל שלהן או להעביר אותן בפורמט תמונה מודרני ואופטימלי יותר.
כדאי גם להשתמש ב-LCP Bookmarklet של Annie Sullivan, כדי לזהות במהירות את רכיב ה-LCP באמצעות מלבן אדום בלחיצה אחת בלבד.
טעינה מראש של תמונות שזוהו מאוחר כדי לשפר את ה-LCP
כדי לשפר את המדד 'המהירות שבה נטען רכיב התוכן הכי גדול', כדאי לטעון מראש את התמונות החשובות של 'הגיבור' אם הדפדפן מגלה אותן מאוחר. גילוי מאוחר יכול לקרות אם צריך לטעון חבילת JavaScript לפני שהתמונה תהיה גלויה.
יש כמה שאלות נפוצות שאנחנו מקבלים לגבי טעינת תמונות LCP מראש, שגם כדאי להתייחס אליהן בקצרה.
האם אפשר לטעון מראש תמונות רספונסיביות? כן.
נניח שיש לנו תמונה ראשית רספונסיבית כפי שצוינה באמצעות srcset ו-sizes בהמשך:
<img src="lighthouse.jpg"
srcset="lighthouse_400px.jpg 400w,
lighthouse_800px.jpg 800w,
lighthouse_1600px.jpg 1600w" sizes="50vw" alt="A helpful
Lighthouse">
בזכות המאפיינים imagesrcset ו-imagesizes שנוספו למאפיין link, אנחנו יכולים לטעון מראש תמונה רספונסיבית באמצעות אותה לוגיקה לבחירת תמונה שמשמשת את srcset ו-sizes:
<link rel="preload" as="image" href="lighthouse.jpg"
imagesrcset="lighthouse_400px.jpg 400w,
lighthouse_800px.jpg 800w,
lighthouse_1600px.jpg 1600w"
imagesizes="50vw">
האם בביקורת יוצגו גם הזדמנויות טעינה מראש אם תמונה של LCP מוגדרת באמצעות רקע CSS? כן.
כל תמונה שמסומנת כתמונה של LCP, בין שבאמצעות רקע CSS ובין שבאמצעות <img>, היא מועמדת אם היא מזוהה בעומק של שלוש שכבות או יותר בתרשים Waterfall.
טעינה מדורגת של תמונות שלא מופיעות במסך והימנעות מכך לגבי LCP
אפשר להשתמש בטעינה איטית של תמונות מחוץ למסך שלא חיוניות לחוויית המשתמש הראשונית. זוהי טכניקה שמאחרת את הורדת התמונה עד שהמשתמש גולל לידה. כך אפשר לצמצם את התחרות על רוחב הפס ברשת על נכסים קריטיים, ובמקרים מסוימים לשפר את זמן ה-LCP. הבדיקה 'עיכוב טעינה של תמונות שלא מופיעות מיד במסך' יכולה לעזור לכם בנושא הזה:
לא מומלץ לטעון באופן מדורג תמונות קריטיות בחלק העליון והקבוע של הדף, כמו התמונה מסוג Largest Contentful Paint. הפעולה הזו עלולה לעכב את טעינת התמונה של LCP. אם התמונה מסוג LCP נטענת באופן מדורג בצורה שגויה, מערכת Lighthouse תדגיש זאת באמצעות הביקורת 'התמונה מסוג Largest Contentful Paint נטענה באופן מדורג':
זיהוי גורמים שמשפיעים על CLS
המדד Cumulative Layout Shift (CLS) מודד את היציבות החזותית. המדד הזה מציג באופן כמותי את מידת התזוזות החזוניות של התוכן בדף. ב-Lighthouse יש ביקורת לניפוי באגים של CLS שנקראת 'יש להימנע משינויים משמעותיים בפריסה'.
בבדיקה הזו מודגשים רכיבי DOM שתורמים הכי הרבה לשינויים בדף. בעמודה Element (רכיב) בצד ימין תוצג רשימת רכיבי ה-DOM האלה, ובצד ימין תוצג ההשפעה הכוללת שלהם על CLS.
בזכות התכונה החדשה של Lighthouse, 'צילומי מסך של רכיבים', אנחנו יכולים לראות תצוגה מקדימה חזותית של הרכיבים המרכזיים שצוינו בבדיקת האבטחה, וגם ללחוץ כדי להתקרב ולקבל תצוגה ברורה יותר:
לגבי מדד CLS לאחר הטעינה, יכול להיות שיהיה כדאי להציג באופן עקבי באמצעות ריבועים את הרכיבים שתרמו הכי הרבה ל-CLS. זו תכונה שאפשר למצוא בכלים של צד שלישי, כמו לוח הבקרה של המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) ב-SpeedCurve. אני אוהב להשתמש בכלי ליצירת קובצי GIF של שינויי פריסה של Defaced כדי:
כדי לקבל תצוגה של בעיות שקשורות לתנודות בפריסת האתר בכל האתר, אני משתמש בדוח המדדים הבסיסיים של חוויית המשתמש ב-Search Console. כך אפשר לראות את סוגי הדפים באתר עם CLS גבוה (במקרה הזה, הנתונים עוזרים לזהות בעצמכם אילו תבניות חלקיות כדאי להשקיע בהן זמן):
זיהוי CLS מתמונות ללא מידות
כדי להגביל את המדד Cumulative Layout Shift שנגרם על ידי תמונות ללא מידות, צריך לכלול מאפייני רוחב וגובה בתמונות וברכיבי הווידאו. הגישה הזו מבטיחה שהדפדפן יוכל להקצות את נפח האחסון הנכון במסמך בזמן טעינת התמונה.
במאמר חשוב שוב להגדיר את הגובה והרוחב של התמונות מוסבר למה חשוב להתייחס למאפיינים האלה.
זיהוי CLS ממודעות
מודעות לבעלי תוכן דיגיטלי ב-Lighthouse מאפשרות לכם למצוא הזדמנויות לשיפור חוויית הטעינה של המודעות בדף, כולל גורמים שתורמים לשינוי הפריסה ומשימות ארוכות שעשויות להאריך את הזמן עד שהמשתמשים יוכלו להשתמש בדף. ב-Lighthouse אפשר להפעיל את התכונה הזו באמצעות הפלאגינים של הקהילה.
חשוב לזכור שהמודעות הן אחד מהגורמים העיקריים לשינויים בפריסת האתר. חשוב:
- חשוב להיזהר כשמציבים מודעות לא קבועות בחלק העליון של אזור התצוגה
- כדי למנוע שינויים בגודל המודעה, כדאי להקצות את הגודל הגדול ביותר האפשרי למיקום המודעה
אין להשתמש באנימציות ללא הרכבת שכבות
אנימציות שלא מורכבות עלולות להיראות איטיות במכשירים ברמה נמוכה יותר, אם משימות JavaScript כבדות שומרות על השרשור הראשי עסוק. אנימציות כאלה עלולות לגרום לשינויים בפריסה.
אם Chrome מגלה שלא ניתן היה ליצור קומפוזיציה של אנימציה, הוא מדווח על כך ל-Lighthouse ב-DevTools, שמאפשרת ל-Lighthouse לרשום אילו רכיבים עם אנימציות לא אוחדו ולמה. אפשר למצוא אותם בביקורת הימנעות מאנימציות לא מורכבות.
ניפוי באגים של השהיה לאחר קלט ראשוני / זמן חסימה כולל / משימות ארוכות
המדד 'קלט ראשוני' מודד את הזמן מרגע האינטראקציה הראשונית של משתמש עם דף (למשל, לחיצה על קישור, הקשה על לחצן או שימוש בבקר מותאם אישית שמופעל על ידי JavaScript) עד לרגע שבו הדפדפן מסוגל להתחיל לעבד פונקציות טיפול באירועים בתגובה לאינטראקציה. משימות JavaScript ארוכות יכולות להשפיע על המדד הזה ועל המדד החלופי שלו, 'זמן חסימה כולל'.
ב-Lighthouse יש ביקורת בשם יש להימנע ממשימות ארוכות בתהליכון הראשי, שמציגה את המשימות הארוכות ביותר בשרשור הראשי. הבדיקה הזו יכולה לעזור לכם לזהות את המשימות שמאטות את הקלט במידה הרבה ביותר. בעמודה הימנית אפשר לראות את כתובות ה-URL של הסקריפטים שאחראים למשימות ארוכות בשרשור הראשי.
בצד שמאל מוצגת משך הזמן של המשימות האלה. רצינו רק להזכיר: משימות ארוכות הן משימות שמתבצעות במשך יותר מ-50 אלפיות השנייה. הפעולה הזו נחשבת לחסימה של ה-thread הראשי למשך זמן מספיק כדי להשפיע על קצב הפריימים או על זמן האחזור של הקלט.
אם אתם שוקלים להשתמש בשירותים של צד שלישי למעקב, כדאי לכם לבדוק גם את ציר הזמן של ביצוע הליבה של Calibre, שמציג את העלויות האלה באופן חזותי. בתרשים הזה מודגשות גם משימות הורה וגם משימות צאצא שתורמות למשימות ארוכות שמשפיעות על האינטראקטיביות.
חסימת בקשות רשת כדי לראות את ההשפעה לפני ואחרי ב-Lighthouse
בכלים למפתחים של Chrome יש תמיכה בחסימת בקשות רשת כדי לראות את ההשפעה של הסרת משאבים ספציפיים או של חוסר זמינות שלהם. המידע הזה יכול לעזור לכם להבין את העלות של סקריפטים ספציפיים (למשל, רכיבי הטמעה או שירותי מעקב של צד שלישי) על מדדים כמו זמן החסימה הכולל (TBT) וזמן הטעינה עד לאפשרות אינטראקציה.
חסימה של בקשות רשת פועלת גם עם Lighthouse! נבחן בקצרה את הדוח של Lighthouse לאתר. ציון הביצועים הוא 63/100 עם זמן אחזור משוער (TBT) של 400 אלפיות השנייה. אחרי שבדקנו את הקוד, גילינו שהאתר הזה טוען ב-Chrome polyfill של Intersection Observer, שלא נחוץ. קדימה, נחסום אותו!
אפשר ללחוץ לחיצה ימנית על סקריפט בחלונית Network של כלי הפיתוח ולבחור באפשרות Block Request URL כדי לחסום אותו. כאן נעשה זאת עבור ה-polyfill של Intersection Observer.
לאחר מכן נוכל להריץ מחדש את Lighthouse. הפעם אפשר לראות שציון הביצועים השתפר (70/100) וגם זמן החסימה הכולל (400ms => 300ms).
החלפת הטמעות יקרות של צד שלישי בחזית (Facade)
מקובל להשתמש במקורות מידע של צד שלישי כדי להטמיע דפים, סרטונים, פוסטים ברשתות חברתיות או ווידג'טים. כברירת מחדל, רוב התגים המוטמעים נטענים מיד, ויכול להיות שהם כוללים עומסי נתונים יקרים שמשפיעים לרעה על חוויית המשתמש. זה בזבוז זמן אם הצד השלישי לא קריטי (למשל, אם המשתמש צריך לגלול כדי לראות אותו).
דפוס אחד לשיפור הביצועים של ווידג'טים כאלה הוא טעינה איטית שלהם במהלך האינטראקציה של המשתמש. כדי לעשות זאת, אפשר ליצור תצוגה מקדימה קלה של הווידג'ט (חזית) ולטעון את הגרסה המלאה רק אם המשתמש יוצר איתו אינטראקציה. ב-Lighthouse יש ביקורת שממליצה על משאבים של צד שלישי שאפשר לטעון באופן מדורג באמצעות תבנית Facade, כמו הטמעות של סרטוני YouTube.
כתזכורת, מערכת Lighthouse תדגיש קוד של צד שלישי שחוסם את ה-thread הראשי למשך יותר מ-250 אלפיות השנייה. כך אפשר לחשוף כל מיני סקריפטים של צד שלישי (כולל סקריפטים שנכתבו על ידי Google) שיכול להיות שווה לדחות או לטעון אותם באיטרציה, אם כדי להציג את התוצאה של הרינדור שלהם צריך לגלול.
מעבר ל-Core Web Vitals
בנוסף להדגשת המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals), הגרסאות האחרונות של Lighthouse ו-PageSpeed Insights גם מנסות לספק הנחיות קונקרטיות שאפשר לפעול לפיהן כדי לשפר את מהירות הטעינה של אפליקציות אינטרנט שמבוססות בעיקר על JavaScript, אם מפות המקור מופעלות.
הם כוללים אוסף הולך וגדל של ביקורות שיעזרו לכם להפחית את העלות של JavaScript בדף, למשל צמצום ההסתמכות על polyfills ועל עותקים כפולים שאולי לא נחוצים לחוויית המשתמש.
מידע נוסף על הכלים של המדדים הבסיסיים של חוויית המשתמש זמין בחשבון Twitter של צוות Lighthouse ובקטע What's new in DevTools.