אופטימיזציה של Web Vitals באמצעות Lighthouse

איתור הזדמנויות לשיפור חוויית המשתמש בעזרת הכלים של Chrome באינטרנט.

היום נעסוק בתכונות חדשות לכלים ב-Lighthouse, ב-PageSpeed ובכלי הפיתוח, כדי להבין איך אפשר לשפר את האתר באמצעות Web Vitals.

תזכורת לגבי הכלים: Lighthouse הוא כלי אוטומטי בקוד פתוח לשיפור האיכות של דפי אינטרנט. אפשר למצוא אותו בחבילה של כלי הפיתוח ל-Chrome לניפוי באגים ולהריץ אותו בכל דף אינטרנט, ציבורי או מחייב אימות. אפשר למצוא את Lighthouse גם ב-PageSpeed Insights, ב-CI וב-WebPageTest.

ב-Lighthouse 7.x יש תכונות חדשות כמו צילומי מסך של רכיבים, לצורך בדיקה ויזואלית קלה יותר של חלקים בממשק המשתמש, שמשפיעים על מדדים של חוויית משתמש (למשל, אילו צמתים תורמים לשינוי הפריסה).

בנוסף, שלחנו תמיכה בצילומי מסך של רכיבים ב-PageSpeed Insights כדי לאפשר זיהוי קל יותר של בעיות בהרצה חד פעמית של ביצועי הדפים.

מדידת מדדי הליבה לבדיקת חוויית המשתמש באתר

Lighthouse יכול למדוד סינתטי את המדדים של מדדי הליבה לבדיקת חוויית המשתמש באתר, כולל המהירות שבה נטען רכיב התוכן הכי גדול (LCP), שינוי פריסה מצטבר וזמן חסימה כולל (שרת proxy לשיעור עיכוב קלט ראשון). המדדים האלה משקפים את הטעינה, יציבות הפריסה והמוכנות לאינטראקציה. קיימים גם מדדים אחרים, כמו הצגת התוכן הראשון בדף בעתיד של מדדי הליבה לבדיקת חוויית המשתמש באתר.

הקטע Metrics בדוח Lighthouse כולל גרסאות Lab של המדדים האלה. אפשר להשתמש בדוח הזה כתצוגת סיכום לגבי ההיבטים של חוויית המשתמש שדורשים את תשומת ליבכם.

אין את המגבלה הזו למדדי השדות, כמו אלו שמופיעים בדוח חוויית המשתמש ב-Chrome או ב-RUM, והם משמשים כתוספת חשובה לנתוני שיעור ה-Lab, כי הם משקפים את החוויה של המשתמשים האמיתיים. נתוני השדות לא יכולים להציע את סוגי נתוני האבחון שמקבלים בשיעור ה-Lab, כך ששני הסוגים פועלים יחד.

זיהוי מקומות שבהם ניתן לשפר את דוח ה-Web Vitals

זיהוי הרכיב מסוג Largest Contentful Paint (LCP)

LCP הוא מדד של חוויית הטעינה הנתפסת. היא מסמנת את הנקודה במהלך טעינת הדף שבה התוכן הראשי או ה'גדול ביותר' נטען והוא גלוי למשתמש.

ב-Lighthouse יש ביקורת 'המהירות שבה נטען רכיב התוכן הכי גדול (LCP)', שמזהה מה היה רכיב התוכן הכי גדול (LCP). העברת העכבר מעל הרכיב תדגיש אותו בחלון הראשי של הדפדפן.

אם הרכיב הזה הוא תמונה, המידע הזה הוא רמז מועיל שכדאי לבצע אופטימיזציה של טעינת התמונה. ב-Lighthouse יש כמה בדיקות אופטימיזציה של תמונות, שנועדו לעזור לכם להבין אם אפשר לדחוס את התמונות, לשנות את הגודל שלהן או להציג אותן בפורמט תמונה מודרני ואופטימלי יותר.

אפשר גם להשתמש ב-LCP Bookmarklet של Annie Sullivan כדי לזהות במהירות את רכיב ה-LCP עם מלבן אדום בלחיצה אחת.

טעינה מראש של תמונות שהתגלו מאוחר יותר כדי לשפר את ה-LCP

כדי לשפר את ה-LCP, כדאי לטעון מראש את תמונות הגיבורים החשובות אם הן יגלו אותן מאוחר על ידי הדפדפן. גילוי מאוחר יכול להתרחש אם צריך לטעון חבילת 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 נטענה באופן שגוי באמצעות הביקורת 'תמונת ה-LCP 'המהירות שבה נטען רכיב התוכן הכי גדול (LCP)' נטענה באופן מדורג:

זיהוי תכנים שנוספו ל-CLS

Cumulative Layout Shift (CLS) הוא מדד של היציבות החזותית. הוא מציין את מידת השינוי החזותי של תוכן הדף. ב-Lighthouse יש ביקורת לניפוי באגים ב-CLS בשם "הימנעות משינויים גדולים בפריסה".

הביקורת הזו מדגישה את רכיבי ה-DOM שתורמים הכי הרבה לשינויים בדף. בעמודה Element שמימין תופיע הרשימה של רכיבי ה-DOM האלה, ובצד ימין תופיע התרומה הכוללת שלהם ל-CLS.

בזכות הפיצ'ר החדש של Lighthouse Element Screenshots, ניתן לראות תצוגה מקדימה ויזואלית של האלמנטים העיקריים שצוינו בבדיקה וגם לשנות את מרחק התצוגה בתצוגה ברורה יותר:

ב-CLS לאחר הטעינה, כדאי לשים לב לערך חזותי באופן קבוע עם מלבנים, אילו רכיבים תרמו הכי הרבה ל-CLS. את הפיצ'ר הזה אפשר למצוא בכלים של צדדים שלישיים, כמו מרכז הבקרה של מדדי הליבה לבדיקת חוויית המשתמש באתר ב-speedCurve, ולהשתמש בו ב-אוסף ה-GIF של Defaced Layout Shift ל:

כדי לקבל תצוגה של בעיות שקשורות לשינוי בפריסה של האתר כולו, דוח מדדי הליבה לבדיקת חוויית המשתמש באתר של Search Console חוסך לי הרבה כסף. כך אני יכול לראות את סוגי הדפים באתר עם CLS גבוה (במקרה זה, כדי לעזור בזיהוי עצמי של חלקי תבניות שעליי להקדיש להם את הזמן):

זיהוי CLS מתמונות ללא מידות

כדי להגביל את ההשפעה של שינוי הפריסה המצטבר על תמונות ללא מידות, צריך לכלול בתמונות וברכיבי הווידאו את מאפייני הרוחב והגובה. הגישה הזו מבטיחה שהדפדפן יוכל להקצות את השטח הנכון במסמך בזמן שהתמונה נטענת.

כדי לקבל מידע מפורט על חשיבות החשיבה על מידות ויחס גובה-רוחב של תמונות, ראו איך להגדיר שוב את הגובה והרוחב בתמונות.

זיהוי CLS ממודעות

בעזרת Publisher Ads for Lighthouse אפשר לאתר הזדמנויות לשיפור חוויית הטעינה של המודעות בדף, כולל תרומות לשינוי הפריסה ומשימות ארוכות שעלולות לגרום למשתמשים לזמן שבו המשתמשים יוכלו להשתמש בדף. ב-Lighthouse אפשר להפעיל את האפשרות הזו דרך יישומי פלאגין לקהילה.

חשוב לזכור שמודעות הן אחד מהתורמים הגדולים ביותר לשינויי הפריסה באינטרנט. חשוב לדעת:

• כדאי להיזהר כשמציבים מודעות לא במיקום קבוע ליד החלק העליון של אזור התצוגה
• ביטול שינויים על ידי שמירת הגודל הגדול ביותר האפשרי של מיקום המודעה

להימנע מאנימציות לא מורכבות

אנימציות לא מורכבות עלולות להציג את עצמן כמהירות במכשירים פשוטים יותר אם משימות JavaScript כבדות גורמות לעומס על ה-thread הראשי. אנימציות כאלה יכולות לכלול שינויי פריסה.

אם דפדפן Chrome מגלה שלא ניתן ליצור אנימציה, הוא מדווח על חומרי העזר של כלי הפיתוח לקריאת Lighthouse, וכך יכול לראות אילו רכיבים עם אנימציות לא הורכבו, ומאיזו סיבה. אפשר למצוא אותם בביקורת הימנעות מאנימציות לא מורכבות.

עיכוב לאחר הקלט הראשון של ניפוי באגים / זמן החסימה הכולל / משימות ארוכות

הקלט הראשון מודד את הזמן מרגע האינטראקציה הראשונה של המשתמש עם הדף (למשל, לחיצה על קישור, הקשה על לחצן או שימוש בבקר מותאם אישית שמופעל על ידי JavaScript) עד למועד שבו הדפדפן יכול להתחיל לעבד גורמים מטפלים באירועים בתגובה לאותה אינטראקציה. JavaScript ארוך Tasks יכול להשפיע על המדד הזה ועל שרת ה-Proxy של המדד הזה, 'זמן החסימה הכולל'.

ב-Lighthouse יש ביקורת של הימנעות ממשימות ארוכות ב-thread הראשי, שבהן מופיעות המשימות הארוכות ביותר ב-thread הראשי. המידע הזה יכול לעזור לזהות את הגורמים הבעייתיים ביותר בעיכוב הקלט. בעמודה השמאלית אנחנו רואים את כתובת ה-URL של הסקריפטים שאחראים למשימות ארוכות ב-thread הראשי.

בצד שמאל ניתן לראות את משך הזמן של המשימות האלה. תזכורת: 'משימות ארוכות' הן משימות שנמשכות יותר מ-50 אלפיות השנייה. חסימת ה-thread הראשי מספיק ארוכה כדי להשפיע על קצב הפריימים או על זמן האחזור של הקלט.

אם אתם שוקלים להשתמש בשירותי צד שלישי למעקב, אני גם אוהב את ציר הזמן החזותי של הפעלת ה-thread הראשי שבו רואים את העלויות האלה באופן חזותי, שמדגיש גם את המשימות ברמת ההורה וגם את משימות הצאצא שתורמות למשימות ארוכות שמשפיעות על האינטראקטיביות.

חסימה של בקשות רשת כדי לראות את ההשפעה לפני/אחריה ב-Lighthouse

בכלי הפיתוח ל-Chrome יש תמיכה בחסימת בקשות רשת כדי לראות את ההשפעה של הסרה או אי-זמינות של משאבים ספציפיים. האפשרות הזו יכולה לעזור לכם להבין את העלות של סקריפטים נפרדים (למשל, הטמעות של צד שלישי או כלי מעקב) על מדדים כמו Total Block Time (TBT) ו-Time to Interactive.

חסימה של בקשות רשת עובדת גם עם Lighthouse! בואו נסתכל על דוח Lighthouse לגבי אתר מסוים. ציון Perf הוא 63/100 עם TBT של 400 אלפיות השנייה. בעיון בקוד, גילינו שהאתר הזה טוען polyfill של Intersection Observer ב-Chrome, שאין צורך בו. בואו נחסום אותו!

אפשר ללחוץ לחיצה ימנית על סקריפט בחלונית DevTools Network וללחוץ על Block Request URL כדי לחסום אותו. כאן נעשה זאת עבור ה-polyfill של Intersection Observer.

לאחר מכן נוכל להפעיל מחדש את Lighthouse. הפעם אנחנו יכולים לראות שציון הביצועים השתפר (70/100) מכיוון שזמן החסימה הכולל (400 אלפיות שנייה => 300 אלפיות שנייה).

החלפת הטמעות יקרות של צד שלישי עם חזית

מקובל להשתמש במשאבים של צד שלישי כדי להטמיע סרטונים, פוסטים ברשתות חברתיות או ווידג'טים בדפים. כברירת מחדל, רוב ההטמעה שנטענו באופן יסודי באופן מיידי עשויה לכלול מטענים ייעודיים (payloads) יקרים שמשפיעים לרעה על חוויית המשתמש. זה בזבוז אם הצד השלישי לא קריטי (למשל, אם המשתמש צריך לגלול כדי לראות אותו).

אחת הדפוסים לשיפור הביצועים של ווידג'טים כאלה היא טעינה מדורגת בהתאם לאינטראקציות של המשתמשים. ניתן לעשות זאת על ידי עיבוד תצוגה מקדימה קטנה של הווידג'ט (חזית) ולטעון את הגרסה המלאה רק אם המשתמש מקיים אינטראקציה איתו. ב-Lighthouse יש ביקורת שתמליץ על משאבים של צד שלישי שאפשר לטעון אותם בהדרגה באמצעות חזית, כמו הטמעות של סרטוני YouTube.

תזכורת: ב-Lighthouse ידגיש קוד של צד שלישי שחוסם את ה-thread הראשי למשך יותר מ-250 אלפיות השנייה. המצב הזה עלול לחשוף את כל סוגי הסקריפטים של צדדים שלישיים (כולל סקריפטים שנוצרו על ידי Google) שעדיף לדחות את הטעינה שלהם או לטעון אותם באופן מדורג אם צריך לגלול כדי לצפות בהם.

מעבר למדדי הליבה לבדיקת חוויית המשתמש באתר

מעבר להדגשת הדוח בנושא Core Web Vitals, גם הגרסאות האחרונות של Lighthouse ו-PageSpeed Insights נועדו לספק הכוונה מעשית לשיפור המהירות שבה אפליקציות אינטרנט עמוסות ב-JavaScript יכולות להיטען אם מפות המקור מופעלות.

ההנחיות כוללות אוסף הולך וגדל של ביקורות להפחתת העלות של JavaScript בדף שלכם, כמו צמצום ההסתמכות על פוליגונים וכפילויות שייתכן שאינן נחוצות לחוויית המשתמש.

למידע נוסף על הכלים בנושא Core Web Vitals, מומלץ לעקוב אחר חשבון Twitter של צוות Lighthouse ובמאמר מה חדש בכלי הפיתוח.

תמונה ראשית (Hero) מאת Mercedes Mehling במשחק Unbounce.