למצוא הזדמנויות לשיפור חוויית המשתמש בעזרת כלי האינטרנט של Chrome.
תאריך פרסום: 11 במאי 2021
היום נסקור תכונות חדשות של כלים ב-Lighthouse, ב-PageSpeed וב-DevTools שיעזרו לכם לזהות איך אפשר לשפר את האתר ב-Web Vitals.
תזכורת קצרה לגבי הכלים: Lighthouse הוא כלי אוטומטי בקוד פתוח לשיפור האיכות של דפי אינטרנט. הוא נמצא בחבילת כלי ניפוי הבאגים כלי הפיתוח ל-Chrome, ואפשר להריץ אותו בכל דף אינטרנט, בין אם הוא ציבורי או דורש אימות. אפשר למצוא את Lighthouse גם ב-PageSpeed Insights, ב-CI וב-WebPageTest.
Lighthouse 7.x כולל תכונות חדשות כמו צילומי מסך של רכיבים, שמאפשרים לבדוק בקלות רבה יותר חלקים בממשק המשתמש שמשפיעים על מדדי חוויית המשתמש (למשל, אילו צמתים תורמים לשינוי פריסת הדף).
הוספנו גם תמיכה בצילומי מסך של רכיבים ב-PageSpeed Insights, כדי שיהיה קל יותר לזהות בעיות בבדיקות ביצועים חד-פעמיות של דפים.
מדידת Core Web Vitals
Lighthouse יכול למדוד באופן סינתטי את Core Web Vitals, כולל המהירות שבה נטען רכיב התוכן הכי גדול (LCP), מדד יציבות חזותית (CLS) וסה"כ זמן חסימה (TBT) (פרוקסי מעבדה למהירות התגובה לאינטראקציה ראשונה (FID)). המדדים האלה משקפים את זמני הטעינה, את יציבות הפריסה ואת המוכנות לאינטראקציה. יש שם גם מדדים אחרים, כמו הצגת תוכן ראשוני (FCP), שמודגשים במאמר The future of Core Web Vitals (העתיד של מדדי הליבה לבדיקת חוויית המשתמש באתר).
הקטע "מדדים" בדוח Lighthouse כולל גרסאות מעבדה של המדדים האלה. אתם יכולים להשתמש בתצוגה הזו כסיכום של ההיבטים בחוויית המשתמש שדורשים את תשומת הלב שלכם.
מדדי שדה, כמו אלה שמופיעים בדוח על חוויית המשתמש ב-Chrome או ב-RUM, לא מוגבלים בצורה הזו והם משלימים את נתוני המעבדה כי הם משקפים את החוויה של משתמשים אמיתיים. נתוני השדה לא יכולים לספק את סוגי המידע לאבחון שאתם מקבלים במעבדה, ולכן השניים משלימים זה את זה.
איך לזהות איפה אפשר לשפר את מדדי חוויית המשתמש באתר (Web Vitals)
זיהוי הרכיב מסוג Largest Contentful Paint (LCP)
המהירות שבה נטען רכיב התוכן הכי גדול (LCP) היא מדד של חוויית הטעינה הנתפסת. הוא מסמן את הנקודה במהלך טעינת הדף שבה התוכן העיקרי – או "הגדול ביותר" – נטען ומוצג למשתמש.
ב-Lighthouse יש בדיקה של "הרכיב מסוג Largest Contentful Paint" שמזהה איזה רכיב היה ה-LCP. אם תעבירו את העכבר מעל הרכיב, הוא יודגש בחלון הראשי של הדפדפן.
אם הרכיב הזה הוא תמונה, המידע הזה הוא רמז שימושי לכך שכדאי לבצע אופטימיזציה לטעינה של התמונה הזו. Lighthouse כולל כמה בדיקות לאופטימיזציה של תמונות, כדי לעזור לכם להבין אם אפשר לשפר את הדחיסה של התמונות, לשנות את הגודל שלהן או להציג אותן בפורמט תמונה מודרני ואופטימלי יותר.
כדאי גם להשתמש בסימנייה של LCP שיצרה אנני סאליבן, כדי לזהות במהירות את רכיב ה-LCP באמצעות מלבן אדום בלחיצה אחת.
כדי לשפר את ה-LCP, כדאי לטעון מראש תמונות שמתגלות בשלב מאוחר
כדי לשפר את ה-LCP, טענו מראש את תמונות ה-Hero החשובות אם הדפדפן מגלה אותן באיחור. גילוי מאוחר יכול לקרות אם צריך לטעון חבילת 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), לא צריכות להיטען באופן מדורג. זה יכול לעכב את טעינת התמונה של ה-LCP. Lighthouse ידגיש אם תמונת LCP נטענת באופן מדורג בצורה שגויה באמצעות הביקורת "תמונת Largest Contentful Paint נטענה באופן מדורג":
זיהוי תרומות ל-CLS
מדד יציבות חזותית (CLS) מודד את היציבות החזותית. הוא מודד את מידת התזוזה של התוכן בדף. ב-Lighthouse יש בדיקה לניפוי באגים ב-CLS שנקראת "Avoid large layout shifts" (הימנעות משינויים גדולים בפריסה).
הבדיקה הזו מדגישה את רכיבי ה-DOM שהכי משפיעים על השינויים בדף. בעמודה Element שמימין תופיע רשימה של רכיבי ה-DOM האלה, ומשמאל תופיע התרומה הכוללת שלהם ל-CLS.
הודות לתכונה החדשה "צילומי מסך של רכיבים" ב-Lighthouse, אנחנו יכולים לראות תצוגה מקדימה חזותית של הרכיבים העיקריים שצוינו בבדיקה, וגם ללחוץ כדי להגדיל את התצוגה ולקבל תמונה ברורה יותר:
ב-CLS אחרי הטעינה, יכול להיות שכדאי להציג באופן קבוע מלבנים שממחישים אילו רכיבים תרמו הכי הרבה ל-CLS. התכונה הזו קיימת בכלים של צד שלישי כמו מרכז הבקרה של Core Web Vitals של SpeedCurve, ואני אוהב להשתמש ב-Layout Shift GIF Generator של Defaced כדי:
כדי לקבל תצוגה של בעיות בשינוי פריסה באתר כולו, אני משתמש הרבה בדוח Core Web Vitals של Search Console. כך אני יכול לראות את סוגי הדפים באתר שלי עם CLS גבוה (במקרה הזה, זה עוזר לי לזהות בעצמי על אילו חלקי תבניות אני צריך להשקיע את הזמן שלי):
זיהוי CLS מתמונות ללא מידות
כדי להגביל את מדד יציבות חזותית (CLS) שנגרם בגלל תמונות ללא מידות, צריך לכלול מאפייני גודל של רוחב וגובה ברכיבי התמונות והסרטונים. הגישה הזו מבטיחה שהדפדפן יוכל להקצות את כמות המקום הנכונה במסמך בזמן שהתמונה נטענת.
במאמר Setting Height And Width On Images Is Important Again מוסבר בהרחבה למה חשוב להגדיר את המידות ויחס הגובה-רוחב של התמונות.
זיהוי CLS ממודעות
Publisher Ads for Lighthouse מאפשר לכם למצוא הזדמנויות לשיפור חוויית הטעינה של המודעות בדף, כולל תרומה לשינוי פריסה ולמשימות שנמשכות הרבה זמן, שעלולות לעכב את המועד שבו המשתמשים יוכלו להשתמש בדף. ב-Lighthouse, אפשר להפעיל את זה דרך פלאגינים של הקהילה.
חשוב לזכור שמודעות הן אחד הגורמים העיקריים לשינויי פריסה באינטרנט. חשוב:
- היזהרו כשאתם מציבים מודעות לא במיקום קבוע ליד החלק העליון של אזור התצוגה
- כדי למנוע תזוזות, כדאי להקצות למיקום המודעה בדף את הגודל המקסימלי האפשרי
הימנעות מאנימציות לא מורכבות
אנימציות שלא מורכבות עלולות להיראות איטיות במכשירים פשוטים יותר אם משימות JavaScript כבדות מעסיקות את ה-thread הראשי. אנימציות כאלה יכולות לגרום לשינויים בפריסה.
אם Chrome מזהה שלא ניתן היה לבצע קומפוזיציה של אנימציה, הוא מדווח על כך למעקב של כלי הפיתוח ל-Chrome ש-Lighthouse קורא, וכך הוא יכול להציג רשימה של הרכיבים עם האנימציות שלא בוצעה להם קומפוזיציה, ואת הסיבה לכך. אפשר למצוא אותם בבדיקה Avoid non-composited animations.
ניפוי באגים במהירות התגובה לאינטראקציה ראשונה (FID) / סה"כ זמן חסימה (TBT) / משימות שנמשכות הרבה זמן
השהיה לאחר קלט ראשוני מודדת את הזמן שעובר מהרגע שבו משתמש יוצר אינטראקציה ראשונה עם דף (למשל, כשהוא לוחץ על קישור, לוחץ על כפתור או משתמש בפקד מותאם אישית שמופעל על ידי JavaScript) ועד לרגע שבו הדפדפן יכול להתחיל לעבד גורמים מטפלים באירועים בתגובה לאינטראקציה הזו. משימות JavaScript ארוכות יכולות להשפיע על המדד הזה ועל המדד שמייצג אותו, "סה"כ זמן חסימה" (TBT).
Lighthouse כולל את הבדיקה Avoid long main-thread tasks (הימנעות ממשימות ארוכות ב-thread הראשי), שמציינת את המשימות הארוכות ביותר ב-thread הראשי. הבדיקה הזו יכולה לעזור לכם לזהות את המשימות שמאטות את הקלט במידה הרבה ביותר. בעמודה השמאלית אפשר לראות את כתובת ה-URL של הסקריפטים שאחראים למשימות הארוכות בשרשור הראשי.
משמאל אפשר לראות את משך הזמן של המשימות האלה. תזכורת: משימות שנמשכות הרבה זמן הן משימות שהביצוע שלהן נמשך יותר מ-50 אלפיות השנייה. מצב כזה נחשב לחסימה של ה-thread הראשי למשך זמן ארוך מספיק כדי להשפיע על קצב הפריימים או על זמן האחזור של הקלט.
אם אתם שוקלים להשתמש בשירותים של צד שלישי למעקב, אני ממליץ גם על ציר הזמן של הביצוע ב-main-thread של Calibre, שמאפשר להמחיש את העלויות האלה ומדגיש גם את משימות ההורה וגם את משימות הצאצא שתורמות למשימות שנמשכות הרבה זמן ומשפיעות על האינטראקטיביות.
חסימת בקשות לאחזור מהרשת כדי לראות את ההשפעה לפני ואחרי ב-Lighthouse
כלי הפיתוח ל-Chrome תומכים בחסימת בקשות לאחזור מהרשת כדי לראות את ההשפעה של הסרת משאבים ספציפיים או של חוסר הזמינות שלהם. המידע הזה יכול לעזור לכם להבין את ההשפעה של סקריפטים ספציפיים (למשל, הטמעות או כלי מעקב של צד שלישי) על מדדים כמו סה"כ זמן חסימה (TBT) ומהירות ההגעה לפונקציונליות מלאה (TTI).
חסימת בקשות לאחזור מהרשת פועלת גם עם Lighthouse. בואו נסתכל על דוח Lighthouse של אתר מסוים. ציון הביצועים הוא 63 מתוך 100, עם TBT של 400 מילישניות. אם נבחן את הקוד, נראה שהאתר הזה טוען polyfill של Intersection Observer ב-Chrome, וזה לא נחוץ. בואו נחסום אותו!
אפשר ללחוץ לחיצה ימנית על סקריפט בחלונית "רשת" של כלי הפיתוח, ואז ללחוץ על Block Request URL כדי לחסום אותו. כאן נעשה את זה עבור ה-polyfill של Intersection Observer.
עכשיו אפשר להריץ שוב את Lighthouse. הפעם אפשר לראות שציון הביצועים השתפר (70 מתוך 100), וגם סה"כ זמן החסימה (מ-400 מילישניות ל-300 מילישניות).
החלפת הטמעות יקרות של צד שלישי בדוגמאות לפיתוח
הרבה פעמים משתמשים במשאבים של צד שלישי כדי להטמיע בדפים סרטונים, פוסטים ברשתות חברתיות או ווידג'טים. כברירת מחדל, רוב ההטמעות נטענות באופן מיידי ויכולות להגיע עם מטענים ייעודיים (payload) יקרים שמשפיעים לרעה על חוויית המשתמש. זה בזבוז אם הצד השלישי לא קריטי (למשל, אם המשתמש צריך לגלול לפני שהוא רואה אותו).
אחת הדרכים לשפר את הביצועים של ווידג'טים כאלה היא לטעון אותם באופן מדורג (lazy-load) באינטראקציה של המשתמש. כדי לעשות את זה, אפשר להציג תצוגה מקדימה קלה של הווידג'ט (חזית) ולטעון את הגרסה המלאה רק אם המשתמש יוצר איתה אינטראקציה. ב-Lighthouse יש בדיקה שתמליץ על משאבים של צד שלישי שאפשר לטעון באופן מדורג באמצעות חזית, כמו הטמעות של סרטונים ב-YouTube.
תזכורת: Lighthouse ידגיש קוד של צד שלישי שחוסם את ה-thread הראשי למשך יותר מ-250 אלפיות השנייה. כך אפשר לחשוף כל מיני סקריפטים של צד שלישי (כולל כאלה שנוצרו על ידי Google) שכדאי לדחות או לטעון בטעינה מדורגת אם מה שהם מעבדים דורש גלילה כדי לצפות בו.
מעבר ל-Core Web Vitals
בנוסף להדגשת Core Web Vitals, הגרסאות האחרונות של Lighthouse ו-PageSpeed Insights מנסות גם לספק הנחיות קונקרטיות שאפשר לפעול לפיהן כדי לשפר את מהירות הטעינה של אפליקציות אינטרנט עם הרבה JavaScript, אם מפות המקור מופעלות.
הם כוללים אוסף הולך וגדל של בדיקות להפחתת העלות של JavaScript בדף, כמו הפחתת ההסתמכות על polyfills וכפילויות שאולי לא נחוצות לחוויית המשתמש.
כדי לקבל מידע נוסף על הכלים של Core Web Vitals, כדאי לעקוב אחרי חשבון הטוויטר של צוות Lighthouse ולעיין במאמר מה חדש בכלי הפיתוח.