עצות מבוססות-נתונים לטעינה מדורגת של תמונות, תוך התחשבות ב-Core Web Vitals.
טעינה מדורגת היא שיטה שבה ההורדה של משאב נדחית עד שהוא נדרש, כדי לחסוך בנתונים ולצמצם את התחרות על רוחב הפס של הרשת לנכסים קריטיים. הוא הפך לתקן אינטרנט ב-2019, וכיום רוב הדפדפנים המובילים תומכים ב-loading="lazy" לתמונות.
במדריך הזה מוסבר איך ניתחנו נתונים זמינים לציבור לגבי שקיפות באינטרנט ובדיקות A/B אד-הוק כדי להבין את מאפייני ההטמעה והביצועים של טעינה מדורגת של תמונות ברמת הדפדפן. בין הממצאים: טעינה מדורגת יכולה להיות כלי יעיל מאוד להפחתת בייטים מיותרים של תמונות, אבל שימוש יתר יכול להשפיע לרעה על הביצועים. באופן קונקרטי, הניתוח הזה מראה שטעינה מוקדמת של תמונות בתוך אזור התצוגה הראשוני – תוך טעינה מדורגת של השאר – יכולה לתת לנו את הטוב משני העולמות: פחות בייטים נטענים ושיפור ב-Core Web Vitals.
אימוץ
לפי הנתונים העדכניים ביותר ב-HTTP Archive, טעינה מדורגת מובנית של תמונות נמצאת בשימוש ב-29% מהאתרים, והשימוש בה גדל במהירות.
שאילתות על הנתונים הגולמיים בפרויקט HTTP Archive נותנות לנו הבנה ברורה יותר לגבי סוגי האתרים שמובילים את האימוץ: 84% מהאתרים שמשתמשים בטעינה מדורגת של תמונות ברמת הדפדפן משתמשים ב-WordPress, 2% משתמשים במערכת ניהול תוכן אחרת, ו-14% הנותרים לא משתמשים במערכת ניהול תוכן מוכרת. התוצאות האלה מראות בבירור ש-WordPress מובילה בהטמעה.
כדאי גם לשים לב לקצב האימוץ. לפני שנה, ביולי 2020, אתרי WordPress שמשתמשים בטעינה מדורגת היוו עשרות אלפי אתרים מתוך מאגר של כ-6 מיליון (1% מהסך הכולל). מאז, השימוש בטעינה מדורגת ב-WordPress לבדה גדל ליותר ממיליון אתרים (14% מהסה"כ).
ביצועים מתואמים
בחינה מעמיקה יותר של HTTP Archive מאפשרת להשוות בין הביצועים של דפים עם ובלי טעינה מדורגת של תמונות ברמת הדפדפן, באמצעות המדד "המהירות שבה נטען רכיב התוכן הכי גדול" (LCP). נתוני ה-LCP מגיעים מחוויות של משתמשים אמיתיים מהדוח על חוויית המשתמש ב-Chrome (CrUX), בניגוד לבדיקות סינתטיות במעבדה. בתרשים הבא נעשה שימוש בתרשים קופסה כדי להמחיש את ההתפלגות של האחוזון ה-75 של ה-LCP בכל דף: הקווים מייצגים את האחוזונים ה-10 וה-90 והקופסאות מייצגות את האחוזונים ה-25 וה-75.
האחוזון ה-75 של ה-LCP בדף החציוני ללא טעינה מדורגת הוא 2,922 אלפיות השנייה, בהשוואה ל-3,546 אלפיות השנייה בדף החציוני עם טעינה מדורגת. באופן כללי, אתרים שמשתמשים בטעינה מדורגת נוטים להציג ביצועי LCP נמוכים יותר.
חשוב לציין שהתוצאות האלה הן מתואמות, והן לא בהכרח מצביעות על כך שהטעינה המדורגת היא הגורם לביצועים האיטיים יותר. באופן היפותטי, אם אתרי WordPress נוטים להיות קצת יותר איטיים, ובהתחשב בכך שהם מהווים חלק גדול מקבוצת הטעינה המדורגת, זה יכול להסביר את ההבדל. כדי לבטל את השונות הזו, אפשר לצמצם את המיקוד ספציפית לאתרי וורדפרס.
לצערנו, אותה תבנית מופיעה כשמתעמקים בדפי WordPress. דפים שמשתמשים בטעינה מדורגת נוטים להציג ביצועי LCP איטיים יותר. האחוזון ה-75 של ה-LCP בדף WordPress חציוני ללא טעינה מדורגת הוא 3,495 אלפיות השנייה, בהשוואה ל-3,768 אלפיות השנייה בדף חציוני עם טעינה מדורגת.
זה עדיין לא מוכיח שטעינה מדורגת גורמת להאטה של הדפים, אבל השימוש בה קשור לביצועים איטיים יותר. כדי לנסות לענות על שאלת הסיבתיות, הוגדרה בדיקת A/B במעבדה.
ביצועים סיבתיים
המטרה של בדיקת ה-A/B הייתה להוכיח או להפריך את ההשערה שהטעינה המובנית של תמונות ב-WordPress, כפי שהיא מיושמת בליבה של WordPress, גרמה לביצועים איטיים יותר של LCP ולפחות בייטים של תמונות. המתודולוגיה שבה השתמשנו הייתה לבדוק אתר הדגמה של WordPress עם העיצוב twentytwentyone. נבדקו גם סוגי הארכיון וגם סוגי הדפים הבודדים, שדומים לדפי הבית ולדפי המאמרים, במחשבים ובמכשירים ניידים מדומים באמצעות 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, שיטת הטעינה המדורגת שבה משתמשים בוורדפרס עוזרת באופן ברור מאוד להפחית את מספר הבייטים של התמונות, אבל המחיר הוא עיכוב ב-LCP.
בדיקת התיקון
ההיבט החשוב ביותר של ההטמעה הנוכחית של טעינה מדורגת ב-WordPress בניסוי הזה הוא שהיא טוענת באופן מדורג תמונות בתוך אזור התצוגה (בחלק העליון של דף הנחיתה). בפוסט בבלוג של CMS מצוין שזה דפוס שכדאי להימנע ממנו, אבל נתונים ניסיוניים באותו זמן הצביעו על כך שההשפעה על ה-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% |
התוצאות האלה הרבה יותר מבטיחות. טעינה מדורגת רק של התמונות שמתחת לקו הגלילה גורמת להיפוך מוחלט של הרגרסיה של ה-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 קובעת אילו תמונות ייטענו בטעינה מדורגת בצד השרת, כלומר היא לא יודעת מה גודל אזור התצוגה של המשתמש או אם התמונות נטענות בהתחלה בתוכו. לכן, התיקון משתמש ביוריסטיקה לגבי המיקום היחסי של התמונות בתגי העיצוב כדי לנחש אם הן נטענות באזור התצוגה. באופן ספציפי, אם התמונה היא התמונה הראשונה שמוצגת בדף או התמונה הראשונה בתוכן הראשי, המערכת מניחה שהיא נמצאת בחלק העליון של הדף, או קרוב אליו, והיא לא תיטען בטעינה מדורגת.
תנאים ברמת הדף, כמו מספר המילים בכותרת או כמות הטקסט בפסקה בתחילת התוכן הראשי, יכולים להשפיע על השאלה אם התמונה נמצאת באזור התצוגה. יש גם תנאים ברמת המשתמש שעשויים להשפיע על הדיוק של ההיוריסטיקה, במיוחד גודל אזור התצוגה והשימוש בקישורים לכותרות שמשנים את מיקום הגלילה בדף.
לכן, חשוב להבין שהתיקון מכויל רק כדי לספק ביצועים טובים במקרה הכללי, וייתכן שיהיה צורך בכוונון עדין כדי שהתוצאות האלה יהיו רלוונטיות לכל התרחישים בעולם האמיתי.
הטמעה
עכשיו, אחרי שזיהינו דרך טובה יותר לטעינה מדורגת של תמונות, איך אתרים יכולים להתחיל להשתמש בה כדי לחסוך בנפח של התמונות ולשפר את ביצועי ה-LCP? השינוי בעדיפות הגבוהה ביותר הוא לשלוח תיקון לליבה של WordPress כדי להטמיע את התיקון הניסיוני. ההנחיות בפוסט בבלוג Browser-level lazy-loading for CMSs (טעינה מדורגת ברמת הדפדפן במערכות ניהול תוכן) יעודכנו גם הן כדי להבהיר את ההשפעות השליליות של טעינה מדורגת בחלק העליון ואיך מערכות ניהול תוכן יכולות להשתמש בהיוריסטיקה כדי להימנע מכך.
השיטות המומלצות האלה רלוונטיות לכל מפתחי האתרים, ולכן כדאי גם לסמן דפוסי אנטי-תבנית של טעינה מדורגת בכלים כמו 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 חדשים יחסית של פלטפורמות אינטרנט יכולה להיות כרוכה בסיכונים וגם בתגמולים – לא סתם קוראים להם תכונות חדשניות. אנחנו מתחילים להבין את המורכבות של טעינה מדורגת של תמונות ברמת הדפדפן, אבל אנחנו גם רואים את היתרונות של השימוש בה כדי לשפר את הביצועים.