אפשר לזהות הזדמנויות לשיפור חוויית המשתמש באמצעות הכלים של Chrome באינטרנט.
היום נעסוק בתכונות כלים חדשות ב-Lighthouse, ב-PageSpeed וב-DevTools, שיעזרו לזהות איך האתר שלכם יכול להשתפר ב-Web Vitals.
כרענון לגבי הכלים, Lighthouse הוא כלי אוטומטי בקוד פתוח לשיפור האיכות של דפי אינטרנט. אפשר למצוא אותו בחבילת כלי הפיתוח ל-Chrome של הכלים לניפוי באגים, ולהריץ אותו בכל דף אינטרנט, גלוי לכולם או שנדרש אימות. אפשר למצוא את Lighthouse גם ב-PageSpeed Insights, CI ו-WebPageTest.
Lighthouse 7.x כולל תכונות חדשות כמו צילומי מסך של אלמנטים, כדי לאפשר בדיקה חזותית קלה יותר של חלקים בממשק המשתמש שמשפיעים על מדדי חוויית המשתמש (למשל, אילו צמתים משפיעים על שינוי הפריסה).
בנוסף, שלחנו תמיכה בצילומי מסך של הרכיבים ב-PageSpeed Insights, כדי לזהות בקלות בעיות בניהול חד-פעמי של בעיות בדפים.
מדידה של דוח המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals)
באמצעות Lighthouse אפשר למדוד באופן סינתטי את המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals), כולל Largest Contentful Paint, Cumulative Layout Shift וזמן החסימה הכולל (שרת proxy לשיעור ה-Lab של השהיה לאחר קלט ראשוני). המדדים האלה משקפים טעינה, יציבות הפריסה ומוכנות לאינטראקציה. תוכלו לראות גם מדדים אחרים כמו הצגת תוכן ראשוני (FCP) המודגשת בעתיד של דוח המדדים הבסיסיים של חוויית המשתמש.
הקטע 'מדדים' בדוח Lighthouse כולל גרסאות ניסוי של המדדים האלה. תוכלו להיעזר בו כתצוגת סיכום של ההיבטים בחוויית המשתמש שדורשים את תשומת הלב שלכם.
למדדי השדות, כמו אלה שנמצאים בדוח חוויית המשתמש של Chrome או ב-RUM, אין המגבלה הזו והם משלימים מאוד את נתוני שיעור ה-Lab, כי הם משקפים את החוויה של משתמשים אמיתיים. נתוני השטח לא יכולים לכלול את סוגי פרטי האבחון שאתם מקבלים בשיעור ה-Lab, ולכן שני הסוגים האלה נמצאים ביד.
זיהוי המקומות שבהם אפשר לשפר את דוח ה-Web Vitals
זיהוי הרכיב מסוג Largest Contentful Paint (LCP)
LCP הוא מדד של חוויית הטעינה החשודה. הנקודה מסומנת במהלך טעינת הדף כאשר התוכן הראשי או 'הגדול ביותר' נטען וגלוי למשתמש.
ב-Lighthouse יש ביקורת מסוג Largest Contentful Paint (LCP) שמזהה איזה רכיב היה ה-Largest Contentful Paint (LCP). העברת העכבר מעל הרכיב תדגיש אותו בחלון הדפדפן הראשי.
אם הרכיב הזה הוא תמונה, המידע הזה הוא רמז שימושי שכדאי לבצע אופטימיזציה של טעינת התמונה. Lighthouse כולל מספר בדיקות לאופטימיזציה של תמונות, כדי לעזור לכם להבין אם צריך לדחוס את התמונות, לשנות את הגודל שלהן או להעלות אותן בפורמט מודרני יותר אופטימלי.
LCP Bookmarklet מאת אנני סאליבן יכול לעזור לכם לזהות במהירות את רכיב ה-LCP עם מלבן אדום בלחיצה אחת בלבד.
כדי לשפר את ה-LCP, יש לטעון מראש תמונות שהתגלו לאחרונה
כדי לשפר את Largest Contentful Paint (LCP), כדאי לטעון מראש את התמונות הקריטיות הראשיות (Hero) אם הדפדפן מגלה אותן בשלב מאוחר. גילוי מאוחר יכול לקרות אם צריך לטעון חבילת JavaScript לפני שהתמונה תהיה גלויה.
יש כמה שאלות נפוצות לגבי טעינה מראש של תמונות LCP, שכדאי לבדוק בקצרה.
האם אפשר לטעון מראש תמונות רספונסיביות? כן.
נניח שיש לנו תמונה ראשית (Hero) רספונסיבית כפי שצוינה באמצעות 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 (LCP) נטענה באופן מדורג:
זיהוי התכנים שנוספו על ידי CLS
המדד Cumulative Layout Shift (CLS) הוא מדד של היציבות החזותית. היא כימת את התדירות שבה התוכן של הדף משתנה. ב-Lighthouse יש ביקורת לניפוי באגים ב-CLS בשם "הימנעות משינויי פריסה גדולים".
הביקורת הזו מדגישה רכיבי DOM שתורמים הכי הרבה לתנודות בדף. בעמודה Element שמשמאל, תראו את הרשימה של רכיבי DOM האלה ובצד שמאל את התרומה הכוללת שלהם ל-CLS.
בזכות התכונה החדשה 'צילומי מסך של רכיבי Lighthouse', אנחנו יכולים לראות תצוגה מקדימה ויזואלית של הרכיבים המרכזיים שצוינו בביקורת וגם לחיצה לשינוי מרחק התצוגה כדי לראות טוב יותר:
ב-CLS לאחר הטעינה, יכול להיות ערך חזותי עקבי עם מלבנים – אילו רכיבים הכי תרמו ל-CLS. זו תכונה שאפשר למצוא בכלים של צד שלישי, כמו מרכז הבקרה של דוח המדדים הבסיסיים של חוויית המשתמש של SpeedCurve, ושעדיף להשתמש במחולל קובצי GIF של Layout Shift ב-Defaced כדי:
כדי לבחון את כל הבעיות בשינויי הפריסה באתר כולו, הדוח המדדים הבסיסיים של חוויית המשתמש של Search Console יחסוך לי זמן רב. כך אני יכולה לראות את סוגי הדפים באתר עם ערך CLS גבוה (במקרה הזה, עזרה בזיהוי עצמי לגבי חלקי התבנית שעליי להקדיש להם את הזמן):
זיהוי נתוני CLS מתמונות ללא מימדים
כדי להגביל את ההשפעות של Cumulative Layout Shift (CLS) שנובעות מתמונות ללא מימדים, צריך לכלול את מאפייני הגודל של הרוחב והגובה בתמונות וברכיבי הווידאו. הגישה הזו מבטיחה שהדפדפן יוכל להקצות את השטח הנכון במסמך בזמן טעינת התמונה.
קראו את המאמר הגדרת גובה ורוחב בתמונות חשובות שוב כדי לקבל פירוט טוב על חשיבות החשיבה על מידות התמונה ויחס הגובה-רוחב.
זיהוי CLS מפרסומות
Publisher Ads for Lighthouse מאפשר לכם למצוא הזדמנויות לשפר את חוויית הטעינה של המודעות בדף, כולל תרומות לשינוי הפריסה ומשימות ארוכות שעשויות לעכב את המועד שבו המשתמשים יוכלו להשתמש בדף. ב-Lighthouse אפשר להפעיל את האפשרות הזו דרך יישומי פלאגין של קהילה.
חשוב לזכור שמודעות הן אחת מהתורמים הגדולים ביותר לשינויי פריסה באינטרנט. חשוב:
- כדאי להיזהר כשמציבים מודעות לא דביקות ליד החלק העליון של אזור התצוגה
- מניעת שינויים על ידי שמירת הגודל הגדול ביותר האפשרי למיקום המודעה
לא להשתמש באנימציות לא מורכבות
אנימציות שאינן מורכבות עלולות להציג את עצמן כאיטיות במכשירים מתקדמים, אם משימות JavaScript כבדות גורמות לשיבושים בשרשור הראשי. באנימציות כאלה יכולות לחול שינויי פריסה.
אם Chrome מגלה שלא ניתן היה ליצור אנימציה, הוא ידווח עליה ל-Lighthouse של כלי הפיתוח כדי לבצע מעקב, וכך לפרט אילו רכיבים עם אנימציות לא הורכבו ומאיזו סיבה. ההגדרות האלה מופיעות בביקורת הימנעות מאנימציות לא מורכבות.
השהיה לאחר קלט ראשוני בניפוי באגים / זמן חסימה כולל / משימות ארוכות
המדד 'קלט ראשון' מודד את הזמן שעובר מרגע האינטראקציה הראשונה של משתמש עם הדף (למשל, לחיצה על קישור, הקשה על לחצן או שימוש בפקד מותאם אישית שמופעל על ידי JavaScript) עד לרגע שבו הדפדפן יכול להתחיל לעבד את רכיבי ה-handler של האירועים בתגובה לאינטראקציה. משימות JavaScript ארוכות יכולות להשפיע על המדד הזה ועל שרת ה-proxy של המדד הזה, 'זמן חסימה כולל'.
Lighthouse כולל בדיקה להימנע ממשימות ארוכות ב-thread הראשי, שבה מפורטות המשימות הארוכות ביותר ב-thread הראשי. כך אפשר לזהות את הגורמים המשמעותיים ביותר לעיכוב בקלט. בעמודה השמאלית אנחנו רואים את כתובת ה-URL של הסקריפטים שאחראים למשימות ארוכות ב-thread הראשי.
משמאל אפשר לראות את משך הזמן של המשימות האלה. חשוב לזכור שמשימות ארוכות הן משימות שפועלות במשך יותר מ-50 אלפיות השנייה. לכן, ה-thread הראשי נחסם למשך מספיק זמן כדי להשפיע על קצב הפריימים או על זמן האחזור של הקלט.
אם אני רוצה לשקול שימוש בשירותי צד שלישי למעקב, אני מעדיפה את קו הזמן הוויזואלי של ביצוע ה-thread הראשי ב-Calibre להמחשת העלויות האלה. המידע הזה מדגיש גם משימות של הורה וגם משימות הצאצא שתורמים למשימות ארוכות שמשפיעות על האינטראקטיביות.
חסימה של בקשות רשת כדי לראות את ההשפעה לפני או אחרי ב-Lighthouse
בכלי הפיתוח ל-Chrome יש תמיכה בחסימה של בקשות רשת, כדי לבדוק איך משאבים ספציפיים הוסרו או לא זמינים. כך תוכלו להבין את העלות של סקריפטים נפרדים (למשל, כמו הטמעות או כלי מעקב של צד שלישי), במדדים כמו זמן חסימה כולל (TBT) והזמן עד לפעילות מלאה.
חסימת בקשות לרשת פועלת גם עם Lighthouse! נציץ בדוח של אתר ב-Lighthouse. דירוג Perf הוא 63/100 עם TBT של 400 אלפיות שנייה. אנחנו בוחנים את הקוד וגילינו שהאתר הזה טוען מילוי אוטומטי של Intersection Experienceer ב-Chrome, וזה לא הכרחי. בואו נחסום אותו!
אפשר ללחוץ לחיצה ימנית על סקריפט בחלונית DevTools Network וללחוץ על Block Request URL כדי לחסום אותו. כאן נבצע את הפעולה הזו עבור ה-Polyfill של הצומת הבין-לאומי.
בשלב הבא אפשר להריץ מחדש את Lighthouse. הפעם אפשר לראות שציון הביצועים השתפר (70/100) מפני שזמן החסימה הכולל (400 אלפיות שנייה => 300 אלפיות שנייה).
החלפת הטמעות יקרות של צדדים שלישיים בחזית
מקובל להשתמש במשאבים של צד שלישי להטמעת סרטונים, פוסטים ברשתות חברתיות או ווידג'טים בדפים. כברירת מחדל, רוב ההטמעות נטענות מיד באופן מיידי, וכוללות מטענים ייעודיים (payloads) יקרים שמשפיעות לרעה על חוויית המשתמש. זה בזבוז אם הצד השלישי לא קריטי (לדוגמה, אם המשתמש צריך לגלול לפני שהוא רואה את הקוד).
אחת הדפוסים לשיפור הביצועים של ווידג'טים כאלה היא טעינה מדורגת שלהם באינטראקציה עם משתמש. כדי לעשות זאת, אפשר להציג תצוגה מקדימה פשוטה של הווידג'ט (חזית), ולטעון את הגרסה המלאה רק אם המשתמש יוצר אינטראקציה עם הווידג'ט. ב-Lighthouse יש המלצה על משאבים של צד שלישי שאפשר להטעין בצורה מדורגת עם חזית, כמו הטמעות של סרטונים ב-YouTube.
תזכורת: ב-Lighthouse תדגיש קוד של צד שלישי שחוסם את ה-thread הראשי למשך יותר מ-250 אלפיות השנייה. באופן הזה ייתכן לחשוף כל מיני סקריפטים של צד שלישי (כולל סקריפטים שנכתבו על ידי Google) שייתכן שעדיף לדחות או לבצע טעינה מדורגת אם מה שהם מעבדים מחייב גלילה כדי להציג אותו.
יותר מדוח המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals)
נוסף על דוח המדדים הבסיסיים של חוויית המשתמש, הגרסאות האחרונות של Lighthouse ו-PageSpeed Insights מנסות גם לספק הנחיות מפורטות לשיפור מהירות הטעינה של אפליקציות אינטרנט שעולות הרבה ב-JavaScript, אם הפעלתם מפות מקור.
הבדיקות האלה כוללות אוסף הולך וגדל של ביקורות להפחתת העלות של JavaScript בדף, כמו הפחתת ההסתמכות על Polyfills וכפילויות שאולי לא נחוצות לחוויית המשתמש.
למידע נוסף על הכלים של דוח המדדים הבסיסיים של חוויית המשתמש, אפשר לעקוב אחר חשבון Twitter של צוות Lighthouse ומה חדש ב-DevTools.