טיפים מבוססי-נתונים לטעינה איטית של תמונות, תוך התמקדות במדדי הליבה לבדיקת חוויית המשתמש (Core Web Vitals).
טכניקת טעינה איטית היא שיטה שמאפשרת לדחות את הורדת המשאב עד שהוא נחוץ, כדי לחסוך נתונים ולצמצם את התחרות על משאבים קריטיים ברשת. הוא הפך לתקן אינטרנט ב2019, והיום loading="lazy" לתמונות נתמך ברוב הדפדפנים העיקריים.
במדריך הזה נסכם את האופן שבו ניתחו נתוני שקיפות האינטרנט שזמינים לציבור וניסויים חד-פעמיים של A/B כדי להבין את מאפייני השימוש והביצועים של טעינת תמונות בגרילה ברמת הדפדפן. הממצאים הראו שטעינה מדורגת יכולה להיות כלי יעיל להפליא לצמצום בייטים של תמונות שלא נדרשים, אבל שימוש יתר עלול להשפיע לרעה על הביצועים. באופן ספציפי, מהניתוח הזה עולה שטעינה מיידית יותר של תמונות בחלון התצוגה הראשוני – תוך טעינה מדורגת נדיבה של שאר התמונות – יכולה לספק את הטוב משני העולמות: פחות בייטים נטענים ומדדי הליבה לבדיקת חוויית המשתמש באתר משופרים.
אימוץ
לפי הנתונים האחרונים ב-HTTP Archive, 29% מהאתרים משתמשים בטעינה איטית מובנית של תמונות, והשימוש בה הולך וגדל במהירות.
שאילתות על הנתונים הגולמיים בפרויקט HTTP Archive כדי לקבל תמונה ברורה יותר לגבי סוגי האתרים שמובילים לאימוץ: 84% מהאתרים שמשתמשים בטעינה מדורגת של תמונות ברמת הדפדפן משתמשים ב-WordPress, 2% משתמשים במערכת ניהול תוכן אחרת ו-14% הנותרים לא משתמשים במערכת ניהול תוכן ידועה. התוצאות האלה מראות בבירור איך WordPress מוביל את השימוש.
כדאי לשים לב גם לשיעור ההטמעה. לפני שנה, ביולי 2020, אתרי WordPress שמשתמשים בטעינה איטית היוו עשרות אלפי אתרים מתוך קורפוס של כ-6 מיליון אתרים (1% מתוך סך הכול). השימוש בטעינה מדורגת ב-WordPress בלבד גדל מאז ליותר ממיליון אתרים (14% בסך הכול).
ביצועים קורלציוניים
בבדיקה מעמיקה יותר ב-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 במעבדה.
ביצועים תלויי-סיבה
מטרת הבדיקה הייתה להוכיח או להפריך את ההשערה שטעינה מדורגת מובנית של תמונות, כפי שהוטמעה בליבה של 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 עוזרת לצמצם את מספר הבייטים של התמונות, אבל על חשבון עיכוב בזמן הטעינה של התוכן הוויזואלי.
בדיקת תיקון
ההיבט החשוב ביותר בהטמעה הנוכחית של 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, וכך היא נטענת מהר יותר.
| סדרה | ברירת מחדל | הושבת | תיקון | ההבדל מברירת המחדל | ההבדל מ'מושבת' |
|---|---|---|---|---|---|
| twentytwentyone-archive-desktop | 577 | 1173 | 577 | 0% | -51% |
| twentytwentyone-archive-mobile | 172 | 378 | 172 | 0% | -54% |
| twentytwentyone-single-desktop | 301 | 850 | 301 | 0% | -65% |
| twentytwentyone-single-mobile | 114 | 378 | 114 | 0% | -70% |
מבחינת הבייטים של התמונה, אין שינוי בכלל בתיקון בהשוואה להתנהגות שמוגדרת כברירת מחדל. זה מצוין כי זה היה אחד מהיתרונות של הגישה הנוכחית.
התיקון הזה כרוך בכמה אזהרות. מערכת WordPress קובעת אילו תמונות יטענו באיטרציה בצד השרת, כלומר היא לא יודעת דבר על גודל אזור התצוגה של המשתמש או על כך שהתמונות נטענות בהתחלה בתוך אזור התצוגה. לכן התיקון מבוסס על שיטות ניתוח נתונים (heuristics) לגבי המיקום היחסי של התמונות ברכיב ה-Markup, כדי לנחש אם הן נטענות בחלון התצוגה. באופן ספציפי, אם התמונה היא התמונה הראשונה בדף או התמונה הראשונה בתוכן הראשי, ההנחה היא שהיא מופיעה בחלק העליון של הדף או קרוב אליו, והיא לא תטען באיטרציה.
תנאים ברמת הדף, כמו מספר המילים בכותרת או כמות הטקסט בפסקה בתחילת התוכן הראשי, יכולים להשפיע על המיקום של התמונה בחלון התצוגה. יש גם תנאים ברמת המשתמש שעשויים להשפיע על הדיוק של שיטות הניתוח, במיוחד גודל אזור התצוגה והשימוש בקישורי עוגן שמשנים את מיקום הגלילה בדף.
לכן, חשוב לזכור שהתיקון מכוונן רק לספק ביצועים טובים באופן כללי, ויכול להיות שיהיה צורך לבצע שינויים עדינים כדי שהתוצאות האלה יתאימו לכל התרחישים בעולם האמיתי.
הטמעה
עכשיו, אחרי שזיהינו דרך טובה יותר לטעינה איטית של תמונות, אחרי שסיפרנו על כל החיסכון בתמונות ועל ביצועי LCP מהירים יותר, איך אתרים יכולים להתחיל להשתמש בה? השינוי בעדיפות הגבוהה ביותר הוא שליחת תיקון לליבת WordPress כדי ליישם את התיקון הניסיוני. ההנחיות בפוסט בבלוג טעינה איטית ברמת הדפדפן למערכות ניהול תוכן יתעדכנו גם הן כדי להבהיר את ההשפעות השליליות של טעינה איטית מעל למסך, ואת האופן שבו מערכות ניהול תוכן יכולות להשתמש בהיוריסטיקה כדי להימנע מכך.
מאחר שהשיטות המומלצות האלה רלוונטיות לכל מפתחי האינטרנט, כדאי גם לסמן דפוסים של טעינה איטית (lazy loading) בכלים כמו 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 חדשים יחסית של פלטפורמות אינטרנט יש יתרונות וחסרונות – הן נקראות 'תכונות מתקדמות' מסיבה כלשהי. אנחנו מתחילים להבין את הבעיות שקשורות לטעינה איטית של תמונות ברמת הדפדפן, אבל אנחנו גם רואים את היתרונות של השימוש בה כדי לשפר את הביצועים.
תמונה של פרנקי לופז ב-Un פעילות