טיפים מבוססי-נתונים לטעינה איטית של תמונות, תוך התמקדות במדדי הליבה לבדיקת חוויית המשתמש (Core Web Vitals).
טעינה מושהית היא שיטה שדוחה הורדה של משאב עד שהוא נחוץ, כדי לשמר נתונים ולהפחית את התחרות על הרשת לגבי נכסים קריטיים. הוא הפך לתקן אינטרנט ב2019, והיום loading="lazy" לתמונות נתמך ברוב הדפדפנים העיקריים.
במדריך הזה נסכם את האופן שבו ניתחו נתוני שקיפות האינטרנט שזמינים לציבור וניסויים חד-פעמיים של A/B כדי להבין את מאפייני השימוש והביצועים של טעינת תמונות בגרילה ברמת הדפדפן. בין הממצאים: טעינת פריטים בזמן אמת יכולה להיות כלי יעיל להפליא לצמצום הבייטים של תמונות מיותרות, אבל שימוש יתר בה יכול להשפיע לרעה על הביצועים. הניתוח הזה מראה שטעינה מהירה יותר של תמונות באזור התצוגה הראשוני – תוך כדי טעינה מדורגת של השאר – יכולה לספק לנו את המיטב משני העולמות: פחות בייטים נטענים ומדדי ליבה לבדיקת חוויית המשתמש באתר.
אימוץ
לפי הנתונים האחרונים ב-HTTP Archive, 29% מהאתרים משתמשים בטעינה איטית מובנית של תמונות, והשימוש בה הולך וגדל במהירות.
שאילתות על הנתונים הגולמיים בפרויקט HTTP Archive כדי לקבל תמונה ברורה יותר לגבי סוגי האתרים שמובילים לאימוץ: 84% מהאתרים שמשתמשים בטעינה מדורגת של תמונות ברמת הדפדפן משתמשים ב-WordPress, 2% משתמשים במערכת ניהול תוכן אחרת ו-14% הנותרים לא משתמשים במערכת ניהול תוכן ידועה. התוצאות האלה מראות בבירור איך WordPress מוביל את השימוש.
כדאי לשים לב גם לשיעור ההטמעה. לפני שנה, ביולי 2020, אתרי WordPress שמשתמשים בטעינה איטית היוו עשרות אלפי אתרים מתוך קורפוס של כ-6 מיליון אתרים (1% מתוך סך הכול). מאז, יותר ממיליון אתרים (14% מכלל האתרים) ב-WordPress בלבד החלו להשתמש בטעינת פריטים בזמן אמת.
ביצועים קורלציוניים
בבדיקה מעמיקה יותר ב-HTTP Archive, אפשר להשוות בין הביצועים של דפים עם טעינה איטית של תמונות ברמת הדפדפן לבין הביצועים של דפים ללא טעינה איטית של תמונות ברמת הדפדפן, לפי המדד 'המהירות שבה נטען רכיב התוכן הכי גדול' (LCP). נתוני ה-LCP מגיעים מחוויות של משתמשים אמיתיים מדוח חוויית המשתמש ב-Chrome (CrUX) לעומת בדיקה סינתטית במעבדה. התרשים הבא משתמש בתרשים 'קופסה וריק' כדי להמחיש את ההתפלגויות של LCP באחוזון ה-75 של כל דף: הקווים מייצגים את האחוזונים ה-10 וה-90 והתיבות מייצגות את האחוזונים ה-25 וה-75.
הדף החציוני ללא טעינת נתונים בזמן אמת (lazy loading) כולל זמן LCP של 2,922 אלפיות השנייה ב-75% מהדפים, לעומת 3,546 אלפיות השנייה בדף החציוני עם טעינת נתונים בזמן אמת. באופן כללי, אתרים שמשתמשים בטעינה מדורגת נוטים להניב ביצועי LCP פחות טובים.
חשוב לציין שמדובר בתוצאות קורלציוניות, והן לא מצביעות בהכרח על כך שהטעינה האיטית נגרמת כתוצאה מהטעינה האיטית. באופן היפותטי, אם אתרים ב-WordPress נוטים להיות קצת איטיים יותר, והנתונים שלהם מהווים חלק גדול מהקבוצה של טעינה איטית, זה יכול להסביר את ההבדל. כדי למנוע את התנודות האלה, אפשר לצמצם את המיקוד לאתרי WordPress בלבד.
לצערנו, אותו דפוס מופיע גם כשבודקים לעומק דפים ב-WordPress. בדפים שמשתמשים בטעינת פריטים בזמן אמת, בדרך כלל זמן הטעינה של פריט ה-LCP ארוך יותר. הדף החציוני ב-WordPress ללא טעינת נתונים בזמן אמת (lazy loading) כולל זמן LCP של 3,495 אלפיות השנייה ב-75% מהמקרים, לעומת 3,768 אלפיות השנייה בדף החציוני עם טעינת נתונים בזמן אמת.
הנתונים האלה עדיין לא מוכיחים שהטעינה האיטית גורמת לדפים להיות איטיים יותר, אבל השימוש בה כן גורם לביצועים איטיים יותר. כדי לנסות לענות על שאלת הסיבתיות, הוגדרה בדיקת A/B מבוססת מעבדה.
ביצועים תלויי-סיבה
המטרה של בדיקת ה-A/B הייתה להוכיח או להפריך את ההשערה שטעינה מדורגת של תמונות מובנית, כפי שהוטמע בליבת WordPress, הובילה לביצועי LCP איטיים יותר ולפחות בייטים של תמונות. המתודולוגיה ששימשה הייתה לבדוק אתר להדגמה של WordPress בנושא עשרים ועשר. בדקנו גם את סוגי הדפים 'ארכיון' ו'דף יחיד', שהם כמו דפי הבית והמאמרים, במחשבים ובמכשירים ניידים עם הדמיה באמצעות WebPageTest. בדקנו כל שילוב של דפים עם טעינת פריטים בזמן אמת מופעלת ועם טעינת פריטים בזמן אמת מושבתת, והרצנו כל בדיקה תשע פעמים כדי לקבל את ערך החציון של LCP ואת מספר הבייטים של התמונות.
| סדרה | ברירת מחדל | הושבת | הבדל מברירת המחדל |
|---|---|---|---|
| twentytwentyone-archive-desktop | 2,029 | 1,759 | -13% |
| twentytwentyone-archive-mobile | 1,657 | 1,403 | -15% |
| twentytwentyone-single-desktop | 1,655 | 1,726 | 4% |
| twentytwentyone-single-mobile | 1,352 | 1,384 | 2% |
בתוצאות האלה מוצגת השוואה בין ערך LCP החציוני במילישניות לבדיקות בארכיון ולדפים בודדים במחשבים ובניידים. כשהטעינה האיטית הושבתה בדפי הארכיון, מדד ה-LCP השתפר בשיעור משמעותי. עם זאת, בדפים בודדים ההבדל היה קטן יותר.
נראה שהשבתת הטעינה הדרגתית מאיצה את מהירות הטעינה של דפים בודדים. עם זאת, ההבדל ב-LCP הוא קטן מסטיית תקן אחת גם בבדיקות למחשבים וגם בבדיקות לנייד, כך שאפשר לשייך אותו לשונות ולקבוע שהשינוי הוא נייטרלי באופן כללי. לשם השוואה, ההבדל בין דפי ארכיון הוא קרוב יותר לשתיים-שלוש סטיות תקן.
| סדרה | ברירת מחדל | הושבת | הבדל מברירת המחדל |
|---|---|---|---|
| twentytwentyone-archive-desktop | 577 | 1173 | 103% |
| twentytwentyone-archive-mobile | 172 | 378 | 120% |
| twentytwentyone-single-desktop | 301 | 850 | 183% |
| twentytwentyone-single-mobile | 114 | 378 | 233% |
בתוצאות האלה מוצגת השוואה בין מספר הבייטים החציוני של התמונות (ב-KB) בכל בדיקה. כצפוי, לטעינה איטית יש השפעה חיובית ברורה מאוד על הפחתת מספר הבייטים של התמונות. אם משתמש אמיתי יגלול דרך כל הדף, כל התמונות ייטענו בכל מקרה כשהן ייכנסו לאזור התצוגה, אבל התוצאות האלה מראות את הביצועים המשופרים של טעינת הדף הראשונית.
לסיכום התוצאות של בדיקת ה-A/B, שיטת הטעינה המושהית שבה משתמשים ב-WordPress עוזרת מאוד להפחית את מספר הבייטים של התמונות בזמן בדיקת LCP מאוחרת.
בדיקת תיקון
ההיבט החשוב ביותר בהטמעה הנוכחית של WordPress במסגרת הניסוי הזה הוא הטעינה הדרגתית של תמונות באזור התצוגה (בחלק העליון והקבוע). בפוסט בבלוג של מערכת ניהול התוכן מופיעה הודעה על כך שזהו דפוס שצריך להימנע ממנו, אבל נתוני הניסוי באותו זמן הצביעו על כך שההשפעה על LCP הייתה מינימלית וששווה לפשט את ההטמעה בליבה של WordPress.
על סמך הנתונים החדשים האלה, נוצר תיקון ניסיוני שמאפשר להימנע מעומס יתר בזמן טעינת תמונות שנמצאות מעל למסך. התיקון נבדק באותם תנאים שבהם נבדקה בדיקת ה-A/B הראשונה.
| סדרה | ברירת מחדל | הושבת | תיקון | ההבדל מברירת המחדל | ההבדל לעומת השבתה |
|---|---|---|---|---|---|
| twentytwentyone-archive-desktop | 2,029 | 1,759 | 1,749 | -14% | -1% |
| twentytwentyone-archive-mobile | 1,657 | 1,403 | 1,352 | -18% | -4% |
| twentytwentyone-single-desktop | 1,655 | 1,726 | 1,676 | 1% | -3% |
| twentytwentyone-single-mobile | 1,352 | 1,384 | 1,342 | 1%- | -3% |
התוצאות האלה מבטיחות הרבה יותר. טעינת פריטים באיטרציות (lazy loading) רק של התמונות שמתחת לקו החזית (below the fold) מובילה לביטול מוחלט של רגרסיית ה-LCP, ואולי אפילו לשיפור קל בהשוואה להשבתה מוחלטת של טעינת פריטים באיטרציות. איך אפשר לטעון מהר יותר מבלי להשתמש בטעינה איטית בכלל? הסבר אחד לכך הוא שבגלל שלא נטענות תמונות שמתחת לקצה המסך, יש פחות תחרות על הרשת עם התמונה של LCP, וכך היא נטענת מהר יותר.
| סדרה | ברירת מחדל | הושבת | תיקון | ההבדל מברירת המחדל | ההבדל מ'מושבת' |
|---|---|---|---|---|---|
| thashyone-Archive-desktop | 577 | 1173 | 577 | 0% | -51% |
| twentytwentyone-archive-mobile | 172 | 378 | 172 | 0% | -54% |
| twentytwentyone-single-desktop | 301 | 850 | 301 | 0% | -65% |
| thashyone-single-mobile | 114 | 378 | 114 | 0% | -70% |
מבחינת בייטים של תמונות, בתיקון אין שום שינוי בהשוואה להתנהגות ברירת המחדל. זה מצוין כי זה היה אחד מהיתרונות של הגישה הנוכחית.
לתיקון הזה יש כמה מגבלות. מערכת WordPress קובעת אילו תמונות יטענו באיטרציה בצד השרת, כלומר היא לא יודעת דבר על גודל אזור התצוגה של המשתמש או על כך שהתמונות נטענות בהתחלה בתוך אזור התצוגה. לכן, התיקון משתמש בהיוריסטיקה לגבי המיקום היחסי של התמונות בתגי העיצוב כדי לנחש אם התמונה נטענת באזור התצוגה. באופן ספציפי, אם התמונה היא התמונה הראשונה בדף או התמונה הראשונה בתוכן הראשי, ההנחה היא שהיא מופיעה בחלק העליון של הדף או קרוב אליו, והיא לא תטען באיטרציה.
תנאים ברמת הדף, כמו מספר המילים בכותרת או כמות הטקסט בפסקה בתחילת התוכן הראשי, יכולים להשפיע אם התמונה נמצאת בתוך אזור התצוגה. יש גם תנאים ברמת המשתמש שעשויים להשפיע על הדיוק של שיטות הניתוח, במיוחד גודל אזור התצוגה והשימוש בקישורי עוגן שמשנים את מיקום הגלילה בדף.
מהסיבות האלה, חשוב לציין שהתיקון מכויל רק כדי לספק ביצועים טובים במקרה הכללי, וייתכן שיהיה צורך בכוונון עדין כדי שהתוצאות האלה יהיו רלוונטיות לכל התרחישים בעולם האמיתי.
הטמעה
עכשיו, אחרי שזיהינו דרך טובה יותר לטעינה מדורגת של תמונות, כל החיסכון בתמונות וביצועי LCP מהירים יותר. איך אתרים יכולים להתחיל להשתמש בה? השינוי בעל העדיפות הגבוהה ביותר הוא שליחת תיקון לליבת WordPress כדי להטמיע את התיקון הניסיוני. ההנחיות בפוסט בבלוג בנושא טעינה מדורגת ברמת הדפדפן למערכת ניהול תוכן יעודכנו גם הן כדי להבהיר את ההשפעות השליליות של טעינה מדורגת בחלק העליון והקבוע, ואיך מערכות ניהול תוכן יכולות להשתמש בהיוריסטיקה כדי להימנע ממנה.
מכיוון שהשיטות המומלצות האלה חלות על כל מפתחי האתרים, כדאי גם לסמן אנטי-דפוסים בטעינה מדורגת בכלים כמו Lighthouse. כדי לעקוב אחרי ההתקדמות של הביקורת הזו, אפשר לעיין בבקשה להוספת תכונה ב-GitHub. עד אז, מפתחים יכולים להוסיף רישום מפורט יותר ביומן לנתוני השדה שלהם כדי למצוא מקרים שבהם רכיבי LCP נטענים באיטרציה.
new PerformanceObserver((list) => {
const latestEntry = list.getEntries().at(-1);
if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
console.warn('Warning: LCP element was lazy loaded', latestEntry);
}
}).observe({type: 'largest-contentful-paint', buffered: true});
קטע הקוד של JavaScript שלמעלה יעריך את רכיב ה-LCP האחרון וירשום ביומן אזהרה אם הוא נטען באיטרציה.
הנתונים האלה מדגישים גם את הצדדים השליליים של טכניקת הטעינה האיטית ואת הפוטנציאל לשיפורים ב-API ברמת הפלטפורמה. לדוגמה, יש בעיה פתוחה ב-Chromium בנושא ניסוי בטעינה מיידית של התמונות הראשונות באופן מקורי, בדומה לתיקון, למרות המאפיין loading.
סיכום
אם באתר שלכם נעשה שימוש בטעינת תמונות איטית ברמת הדפדפן, כדאי לבדוק איך היא מוטמעת ולהריץ בדיקות A/B כדי להבין טוב יותר את עלויות הביצועים שלה. כדאי לטעון תמונות מהר יותר מעל למסך. אם יש לך אתר ב-WordPress, אני מקווה שבקרוב יופיע תיקון ב-WordPress. אם אתם משתמשים במערכת ניהול תוכן אחרת, חשוב לוודא שהיא מודעת לבעיות הביצועים האפשריות שמתוארות כאן.
לניסיון של ממשקי API חדשים יחסית של פלטפורמות אינטרנט יש יתרונות וחסרונות – הן נקראות 'תכונות מתקדמות' מסיבה כלשהי. אנחנו מתחילים להבין את הבעיות שקשורות לטעינה איטית של תמונות ברמת הדפדפן, אבל אנחנו גם רואים את היתרונות של השימוש בה כדי לשפר את הביצועים.
תמונה של Frankie Lopez ב-Unsplash