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