איתור הזדמנויות לשיפור חוויית המשתמש באמצעות הכלים של Chrome לאינטרנט.
תאריך פרסום: 11 במאי 2021
היום נסקור תכונות חדשות בכלים של Lighthouse, PageSpeed ו-DevTools שיעזרו לכם לזהות את נקודות החולשה באתר במדדים של Web Vitals.
תזכורת לגבי הכלים: Lighthouse הוא כלי אוטומטי בקוד פתוח לשיפור האיכות של דפי אינטרנט. אפשר למצוא אותו בחבילת הכלים לניפוי באגים של כלי הפיתוח של Chrome ולהריץ אותו בכל דף אינטרנט, ציבורי או שדורש אימות. אפשר למצוא את Lighthouse גם ב-PageSpeed Insights, ב-CI וב-WebPageTest.
גרסה 7.x של Lighthouse כוללת תכונות חדשות, כמו צילומי מסך של רכיבים, שמאפשרים לבדוק בקלות חלקים בממשק המשתמש שמשפיעים על מדדי חוויית המשתמש (למשל, אילו צמתים תורמים לשינוי הפריסה).
הוספנו גם תמיכה בצילום מסך של רכיבים ב-PageSpeed Insights, כדי שתוכלו לזהות בקלות רבה יותר בעיות בבדיקות ביצועים חד-פעמיות של דפים.
מדידת מדדי הליבה לבדיקת חוויית המשתמש באתר
מערכת Lighthouse יכולה למדוד את מדדי הליבה לבדיקת חוויית המשתמש באתר באופן סינתטי, כולל הצגת התוכן הכי גדול (LCP), הזזת פריטי פריסה מצטברת (CLS) ומשך הזמן הכולל של החסימה (חלופה מעבדתית להשהיה לאחר קלט ראשוני (FID)). המדדים האלה משקפים את הטעינה, את יציבות הפריסה ואת המוכנות לאינטראקציה. בדוח מופיעים גם מדדים אחרים, כמו הצגת תוכן ראשוני (FCP) שמודגשים בעתיד של המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals).
בקטע 'מדדים' בדוח Lighthouse מופיעות גרסאות מעבדה של המדדים האלה. תוכלו להשתמש בו כתצוגת סיכום של ההיבטים של חוויית המשתמש שדורשים את תשומת הלב שלכם.
מדדי שדה, כמו אלה שמופיעים בדוח חוויית המשתמש ב-Chrome או ב-RUM, לא מוגבלים בדרך הזו, והם משלימים חשובים לנתוני המעבדה כי הם משקפים את החוויה של משתמשים אמיתיים. נתוני השדות לא יכולים להציע את סוגי נתוני האבחון שמקבלים בשיעור ה-Lab, כך ששני הסוגים פועלים זה לצד זה.
זיהוי נקודות לשיפור במדדי Web Vitals
זיהוי הרכיב מסוג Largest Contentful Paint (LCP)
LCP הוא מדד של חוויית הטעינה שחווים המשתמשים. היא מסמנת את הנקודה במהלך טעינת הדף שבה התוכן הראשי או ה'גדול ביותר' נטען והוא גלוי למשתמש.
ב-Lighthouse יש ביקורת בשם 'רכיב ה-Largest Contentful Paint' שמזהה את הרכיב שהיה ה-Largest Contentful Paint. העברת העכבר מעל הרכיב תדגיש אותו בחלון הראשי של הדפדפן.
אם הרכיב הזה הוא תמונה, המידע הזה הוא רמז שימושי שיכול לעזור לכם לבצע אופטימיזציה של טעינת התמונה. ב-Lighthouse יש כמה ביקורות של אופטימיזציה של תמונות שיעזרו לכם להבין אם אפשר לדחוס את התמונות בצורה טובה יותר, לשנות את הגודל שלהן או להעביר אותן בפורמט תמונה מודרני ואופטימלי יותר.
אפשר גם להשתמש ב-LCP Bookmarklet של Annie Sullivan כדי לזהות במהירות את רכיב ה-LCP עם מלבן אדום בלחיצה אחת.
טעינה מראש של תמונות שזוהו מאוחר כדי לשפר את ה-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> יכולה להתאים אם היא מתגלה בעומק מפל של שלושה או יותר.
טעינה מדורגת של תמונות שלא מופיעות במסך והימנעות מכך לגבי LCP
אפשר להשתמש בטעינה איטית של תמונות מחוץ למסך שלא חיוניות לחוויית המשתמש הראשונית. זוהי טכניקה שמאחרת את הורדת התמונה עד שהמשתמש גולל לידה. הטכניקה הזו יכולה לצמצם את התחרות על רוחב הפס ברשת על נכסים קריטיים, ובמקרים מסוימים לשפר את זמן ה-LCP. הביקורת 'עיכוב טעינה של תמונות שלא מופיעות מיד במסך' יכולה לעזור כאן:
לא מומלץ לטעון באופן מדורג תמונות קריטיות בחלק העליון והקבוע של הדף, כמו התמונה מסוג Largest Contentful Paint. הפעולה הזו עלולה לעכב את טעינת התמונה של LCP. מערכת Lighthouse תדגיש אם תמונת LCP נטענה באופן שגוי באמצעות הביקורת 'תמונת ה-LCP 'המהירות שבה נטען רכיב התוכן הכי גדול (LCP)' נטענה באופן מדורג:
זיהוי תרומות ל-CLS
המדד Cumulative Layout Shift (CLS) מודד את היציבות החזותית. המדד הזה מציג באופן כמותי את מידת התזוזות החזוניות של התוכן בדף. ב-Lighthouse יש ביקורת לניפוי באגים של CLS שנקראת 'יש להימנע משינויים משמעותיים בפריסה'.
בבדיקה הזו מודגשים רכיבי DOM שתורמים הכי הרבה לשינויים בדף. בעמודה Element שמימין תופיע הרשימה של רכיבי ה-DOM האלה, ובצד ימין תופיע התרומה הכוללת שלהם ל-CLS.
בזכות התכונה החדשה Lighthouse Element Screenshots, ניתן לראות תצוגה מקדימה ויזואלית של האלמנטים העיקריים שצוינו בביקורת וגם את שינוי מרחק התצוגה לתצוגה ברורה יותר:
לגבי מדד CLS לאחר הטעינה, יכול להיות שיהיה כדאי להציג באופן עקבי באמצעות ריבועים את הרכיבים שתרמו הכי הרבה ל-CLS. זו תכונה שאפשר למצוא בכלים של צד שלישי, כמו לוח הבקרה של המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) של SpeedCurve, ואני אוהב להשתמש בכלי ליצירת קובצי GIF של שינויי פריסה של Defaced כדי:
כדי לקבל תצוגה של בעיות שקשורות לתנודות בפריסת האתר בכל האתר, אני משתמש הרבה בדוח Core Web Vitals של Search Console. כך אפשר לראות את סוגי הדפים באתר עם CLS גבוה (במקרה הזה, הנתונים עוזרים לזהות בעצמכם אילו תבניות חלקיות כדאי להשקיע בהן זמן):
זיהוי CLS מתמונות ללא מידות
כדי להגביל את המדד Cumulative Layout Shift שנגרם על ידי תמונות ללא מידות, צריך לכלול מאפייני רוחב וגובה בתמונות וברכיבי הווידאו. הגישה הזו מבטיחה שהדפדפן יוכל להקצות את נפח האחסון הנכון במסמך בזמן טעינת התמונה.
כדי לקבל מידע מפורט על חשיבות החשיבה על מידות ויחס גובה-רוחב של תמונות, ראו איך להגדיר שוב את הגובה והרוחב בתמונות.
זיהוי CLS ממודעות
מודעות לבעלי תוכן דיגיטלי ב-Lighthouse מאפשרות לכם למצוא הזדמנויות לשיפור חוויית הטעינה של המודעות בדף, כולל גורמים שתורמים לשינוי הפריסה ומשימות ארוכות שעשויות להאריך את הזמן עד שהמשתמשים יוכלו להשתמש בדף. ב-Lighthouse אפשר להפעיל את התכונה הזו באמצעות הפלאגינים של הקהילה.
חשוב לזכור שהמודעות הן אחד מהגורמים העיקריים לשינויים בפריסת האתר. חשוב:
- חשוב להיזהר כשמציבים מודעות לא קבועות בחלק העליון של אזור התצוגה
- ביטול שינויים על ידי שמירת הגודל הגדול ביותר האפשרי של מיקום המודעה
להימנע מאנימציות לא מורכבות
אנימציות שלא מורכבות עלולות להיראות איטיות במכשירים ברמה נמוכה יותר, אם משימות JavaScript כבדות שומרות על השרשור הראשי עסוק. אנימציות כאלה עלולות לגרום לשינויים בפריסה.
אם Chrome מגלה שלא ניתן היה ליצור קומפוזיציה של אנימציה, הוא מדווח על כך ל-trace של DevTools ש-Lighthouse קורא, ומאפשר לו לרשום אילו רכיבים עם אנימציות לא נוצרו קומפוזיציה שלהם ומהן הסיבות לכך. אפשר למצוא אותם בביקורת הימנעות מאנימציות לא מורכבות.
עיכוב לאחר הקלט הראשון של ניפוי באגים / זמן החסימה הכולל / משימות ארוכות
הקלט הראשון מודד את הזמן מרגע האינטראקציה הראשונה של המשתמש עם הדף (למשל, לחיצה על קישור, הקשה על לחצן או שימוש בבקר מותאם אישית שמופעל על ידי JavaScript) עד למועד שבו הדפדפן יכול להתחיל לעבד גורמים מטפלים באירועים בתגובה לאותה אינטראקציה. JavaScript ארוך Tasks יכול להשפיע על המדד הזה ועל שרת ה-Proxy של המדד הזה, 'זמן החסימה הכולל'.
ב-Lighthouse יש ביקורת של הימנעות ממשימות ארוכות ב-thread הראשי, שבהן מופיעות המשימות הארוכות ביותר ב-thread הראשי. זה יעזור לזהות את הגורמים הגרועים ביותר לעיכוב בקלט. בעמודה הימנית אפשר לראות את כתובות ה-URL של הסקריפטים שאחראים למשימות ארוכות בשרשור הראשי.
בצד שמאל מוצגת משך הזמן של המשימות האלה. תזכורת: 'משימות ארוכות' הן משימות שנמשכות יותר מ-50 אלפיות השנייה. חסימת ה-thread הראשי מספיק ארוכה כדי להשפיע על קצב הפריימים או על זמן האחזור של הקלט.
אם אתם שוקלים להשתמש בשירותים של צד שלישי למעקב, אני גם אוהב את ציר הזמן החזותי של הפעלת ה-thread הראשי שבו רואים את העלויות האלה באופן חזותי, שמדגיש את המשימות בהורה וגם כמשימות צאצא שתרמו למשימות ארוכות שמשפיעות על האינטראקטיביות.
חסימת בקשות רשת כדי לראות את ההשפעה לפני ואחרי ב-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).
החלפת הטמעות יקרות של צד שלישי עם חזית
מקובל להשתמש במשאבים של צד שלישי כדי להטמיע סרטונים, פוסטים ברשתות חברתיות או ווידג'טים בדפים. כברירת מחדל, רוב התגים המוטמעים נטענים מיד, ויכול להיות שהם כוללים עומסי נתונים יקרים שמשפיעים לרעה על חוויית המשתמש. זה בזבוז זמן אם הצד השלישי לא קריטי (למשל, אם המשתמש צריך לגלול כדי לראות אותו).
דפוס אחד לשיפור הביצועים של ווידג'טים כאלה הוא טעינה איטית שלהם במהלך האינטראקציה של המשתמש. כדי לעשות זאת, אפשר ליצור תצוגה מקדימה קלה של הווידג'ט (חזית) ולטעון את הגרסה המלאה רק אם המשתמש יוצר איתו אינטראקציה. ב-Lighthouse יש ביקורת שתמליץ על משאבים של צד שלישי שאפשר לטעון אותם בהדרגה באמצעות חזית, כמו הטמעות של סרטוני YouTube.
כתזכורת, מערכת Lighthouse תדגיש קוד של צד שלישי שחוסם את ה-thread הראשי למשך יותר מ-250 אלפיות השנייה. כך אפשר לחשוף כל מיני סקריפטים של צד שלישי (כולל סקריפטים שנכתבו על ידי Google) שיכול להיות שווה לדחות או לטעון אותם באיטרציה, אם כדי להציג את התוצאה של הרינדור שלהם צריך לגלול.
מעבר ל-Core Web Vitals
בנוסף להדגשת המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals), הגרסאות האחרונות של Lighthouse ו-PageSpeed Insights גם מנסות לספק הנחיות קונקרטיות שאפשר לפעול לפיהן כדי לשפר את מהירות הטעינה של אפליקציות אינטרנט שמבוססות בעיקר על JavaScript, אם מפות המקור מופעלות.
הם כוללים אוסף הולך וגדל של ביקורות שיעזרו לכם להפחית את העלות של JavaScript בדף, למשל צמצום ההסתמכות על polyfills ועל עותקים כפולים שאולי לא נחוצים לחוויית המשתמש.
מידע נוסף על הכלים של מדדי הליבה לבדיקת חוויית המשתמש זמין בחשבון Twitter של צוות Lighthouse ובקטע What's new in DevTools.
תמונה ראשית (Hero) מאת Mercedes Mehling במשחק Unbounce.