עצות מבוססות-נתונים לגבי טעינה מדורגת של תמונות תוך התייחסות ל-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, אפשר להשוות בין הביצועים של דפים עם או בלי טעינה מדורגת של תמונות ברמת הדפדפן בעזרת מדד ה-LCP) הכי גדול (LCP). נתוני ה-LCP מגיעים מחוויות של משתמשים אמיתיים מדוח חוויית המשתמש ב-Chrome (CrUX) לעומת בדיקה סינתטית במעבדה. התרשים הבא משתמש בתרשים 'קופסה וריק' כדי להמחיש את ההתפלגויות של LCP באחוזון ה-75 של כל דף: הקווים מייצגים את האחוזונים ה-10 וה-90 והתיבות מייצגות את האחוזונים ה-25 וה-75.
לדף החציוני ללא טעינה מדורגת יש LCP באחוזון ה-75 של 2,922 אלפיות השנייה, בהשוואה ל-3,546 אלפיות השנייה עם דף חציוני עם טעינה מדורגת. באופן כללי, אתרים שמשתמשים בטעינה מדורגת נוטים להניב ביצועי LCP פחות טובים.
חשוב לציין שהתוצאות האלה הן מתאם, והן לא בהכרח מצביעות על כך שטעינה מדורגת היא הסיבה לביצועים האיטיים יותר. באופן היפותטי, אם אתרי WordPress נוטים להיות מעט איטיים יותר, ובהינתן ההרכב של קבוצת הטעינה הדרגתית, זה יכול להסביר את ההבדל. כדי למנוע שונות זו, ניתן לצמצם את המיקוד באופן ספציפי לאתרי WordPress.
לצערנו, דפוס הזה מופיע גם כשמציגים פירוט של דפי WordPress. בדפים שנעשה בהם שימוש בטעינה מדורגת יש ביצועי LCP איטיים יותר. לדף החציוני ב-WordPress ללא טעינה מדורגת, ה-LCP באחוזון ה-75 הוא 3,495 אלפיות השנייה, בהשוואה ל-3,768 אלפיות השנייה עבור הדף החציוני עם טעינה מדורגת.
זה עדיין לא מוכיח שטעינה מדורגת גורמת להאטת הנתונים של דפים, אבל השימוש בה חופף לביצועים איטיים יותר. כדי לנסות לענות על שאלת הסיבתיות, הוגדרה בדיקת A/B מבוססת מעבדה.
ביצועים סיבתיים
המטרה של בדיקת ה-A/B הייתה להוכיח או להפריך את ההשערה שטעינה מדורגת של תמונות מובנית, כפי שהוטמע בליבת WordPress, הובילה לביצועי LCP איטיים יותר ולפחות בייטים של תמונות. המתודולוגיה ששימשה הייתה לבדוק אתר להדגמה של WordPress בנושא עשרים ועשר. סוגי הארכיון והדף היחיד נבדקו, שהם כמו דפי הבית ודפי המאמר, במחשבים שולחניים ובמכשירים ניידים שעברו אמולציה באמצעות WebPageTest. כל שילוב של דפים שהופעלה בהם טעינה מדורגת ובלי טעינה מדורגת, וכל בדיקה פעלה תשע פעמים כדי לקבל את ערך ה-LCP החציוני ומספר הבייטים של התמונות.
| סדרה | ברירת מחדל | הושבת | הבדל מברירת המחדל |
|---|---|---|---|
| thashyone-arch-desktop | 2,029 | 1,759 | -13% |
| tעשרyone-Archive-mobile | 1,657 | 1,403 | -15% |
| עשרים וועד שולחן עבודה | 1,655 | 1,726 | 4% |
| thashyone-single-mobile | 1,352 | 1,384 | 2% |
התוצאות האלה משוות את ערך ה-LCP החציוני באלפיות השנייה בבדיקות בארכיון ובדף יחיד במחשב ובנייד. כשהטעינה המדורגת הושבתה בדפי ארכיון, ה-LCP השתפר בשיעור משמעותי. עם זאת, בדפים בודדים זה השפיע פחות.
נראה שהשבתת הטעינה הדרגתית מאיצה את מהירות הטעינה של דפים בודדים. עם זאת, ההבדל ב-LCP קטן מסטיית תקן אחת גם בבדיקות של מחשבים וגם במכשירים ניידים. לכן אפשר לשייך זאת לשונות, ולחשב את השינוי ניטרלי כפי שהוא. לשם השוואה, ההבדל בין דפי ארכיון הוא קרוב יותר לשתיים-שלוש סטיות תקן.
| סדרה | ברירת מחדל | הושבת | הבדל מברירת המחדל |
|---|---|---|---|
| thashyone-arch-desktop | 577 | 1173 | 103% |
| tעשרyone-Archive-mobile | 172 | 378 | 120% |
| עשרים וועד שולחן עבודה | 301 | 850 | 183% |
| thashyone-single-mobile | 114 | 378 | 233% |
התוצאות האלו משוות את המספר החציוני של בייטים של תמונות (ב-KB) בכל בדיקה. כצפוי, לטעינה מושהית יש השפעה חיובית ברורה מאוד על צמצום מספר הבייטים של התמונות. אם משתמש אמיתי היה גולל את כל הדף, כל התמונות נטענים בכל זאת כשעוברים לאזור התצוגה, אבל התוצאות האלה מראות את הביצועים המשופרים של טעינת הדף הראשונית.
לסיכום התוצאות של בדיקת ה-A/B, שיטת הטעינה המושהית שבה משתמשים ב-WordPress עוזרת מאוד להפחית את מספר הבייטים של התמונות בזמן בדיקת LCP מאוחרת.
בדיקת תיקון
ההיבט החשוב ביותר בהטמעה הנוכחית של WordPress במסגרת הניסוי הזה הוא הטעינה הדרגתית של תמונות באזור התצוגה (בחלק העליון והקבוע). בפוסט בבלוג של מערכת ניהול התוכן מודיע על כך כדפוס שיש להימנע ממנו, אבל נתונים ניסיוניים נכון לעכשיו ציינו שההשפעה על LCP הייתה מזערית והיה שווה לפשט את ההטמעה בליבה של WordPress.
בהתחשב בנתונים החדשים האלה, נוצר תיקון ניסיוני שמונע טעינה מדורגת של תמונות שמופיעות בחלק העליון והקבוע, והתיקון נבדק באותם התנאים כמו בדיקת ה-A/B הראשונה.
| סדרה | ברירת מחדל | הושבת | fix | הבדל מברירת המחדל | ההבדל לעומת השבתה |
|---|---|---|---|---|---|
| thashyone-arch-desktop | 2,029 | 1,759 | 1,749 | -14% | 1%- |
| tעשרyone-Archive-mobile | 1,657 | 1,403 | 1,352 | -18% | 4%- |
| עשרים וועד שולחן עבודה | 1,655 | 1,726 | 1,676 | 1% | -3% |
| thashyone-single-mobile | 1,352 | 1,384 | 1,342 | 1%- | -3% |
התוצאות האלה מבטיחות הרבה יותר. טעינה מדורגת רק של תמונות בחלק התחתון והקבוע מובילה לביטול מלא של רגרסיית ה-LCP ואולי גם לשיפור קל בהשוואה להשבתה מוחלטת של טעינה מדורגת. איך זה יכול להיות מהיר יותר מאשר טעינה מדורגת בכלל? הסבר אחד הוא שאם לא טוענים תמונות בחלק הנגלל, יש פחות תחרות בין הרשת עם תמונת ה-LCP, מה שמאפשר לה להיטען מהר יותר.
| סדרה | ברירת מחדל | הושבת | fix | הבדל מברירת המחדל | ההבדל לעומת השבתה |
|---|---|---|---|---|---|
| thashyone-arch-desktop | 577 | 1173 | 577 | 0% | 51%- |
| tעשרyone-Archive-mobile | 172 | 378 | 172 | 0% | 54%- |
| עשרים וועד שולחן עבודה | 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 חדשים יחסית של פלטפורמות אינטרנט כרוכה גם בסיכונים וגם בתגמולים. מסיבה כלשהי, הם נקראים תכונות חדשניות. אנחנו מתחילים להבין את הקושי של טעינה מדורגת של תמונות ברמת הדפדפן, אבל אפשר לראות גם את היתרונות של השימוש בה כדי לשפר את הביצועים.
צילום של פרנקי לופז ב-Un אימייל