עצות מבוססות-נתונים לגבי טעינה עצלה של תמונות, תוך התמקדות במדדי ליבה לבדיקת חוויית המשתמש באתר.
טעינה עצלה היא שיטה לדחייה של הורדה של משאב עד שיש בו צורך, וכך חוסכת לכם נתונים ומפחיתה את המחלוקת ברשת לגבי נכסים קריטיים. זה הפך לסטנדרט באינטרנט ב-2019, והיום loading="lazy" לתמונות נתמך על ידי רוב הדפדפנים הנפוצים. זה נשמע נהדר, אבל האם יש דבר כזה כמו טעינה עצלה?
הפוסט הזה מסכם את האופן שבו ניתחנו נתונים שזמינים לציבור לגבי שקיפות באינטרנט ובדיקות A/B אד הוק כדי להבין את מאפייני האימוץ והביצועים של טעינה מדורגת של תמונות מותאמות. מה שגילינו הוא שטעינה מושהית יכולה להיות כלי יעיל להפליא לצמצום בייטים לא נחוצים של תמונות, אבל שימוש יתר יכול להשפיע לרעה על הביצועים. ליתר ביטחון, הניתוח שלנו מראה שטעינה חזקה יותר של תמונות באזור התצוגה הראשוני, בעוד שטעינה עצלה של כל השאר, יכולה לספק לנו את המיטב משני העולמות: פחות בייטים של טעינה ומדדי ליבה לבדיקת חוויית המשתמש באתר.
אימוץ
לפי הנתונים העדכניים ביותר בארכיון HTTP, 17% מהאתרים משתמשים בטעינה עצלה של תמונות מותאמות, ושיעור האימוץ הולך וגדל במהירות. דריסת רגל רבה בסביבה העסקית היא יוצאת מן הכלל עבור API חדש יחסית.
הרצת שאילתות על הנתונים הגולמיים בפרויקט ארכיון HTTP מאפשרת לנו להבין טוב יותר אילו סוגי אתרים מעודדים אימוץ: 84% מהאתרים שמשתמשים בטעינה מדורגת של תמונות מקוריות משתמשים ב-WordPress, 2% משתמשים במערכת ניהול תוכן אחרת ו-14% הנותרים לא משתמשים במערכת ניהול תוכן ידועה. התוצאות האלה מבהירות איך WordPress מובילה את החיוב באימוץ.
כדאי גם לשים לב לשיעור ההטמעה. לפני שנה ביולי 2020, אתרי WordPress שמשתמשים בטעינה מדורגת כללו עשרות אלפי אתרים במאגר של כ-6 מיליון אתרים (1% מסך כל האתרים). השימוש בטעינה מדורגת ב-WordPress בלבד גדל מאז ליותר ממיליון אתרים (14% מסך כל האתרים).
ביצועים יחסיים
ניתוח מעמיק יותר בארכיון HTTP, מאפשר לנו להשוות את הביצועים של דפים עם ובלי טעינה מדורגת של תמונות מותאמות למדד המהירות שבה נטען רכיב התוכן הכי גדול (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 עם העיצוב ttwoytevenyone. בדקנו גם את סוגי הדפים בארכיון וגם את סוגי הדפים הבודדים, כמו דפי הבית ודפי המאמר, במחשבים ובאמולציה של מכשירים ניידים באמצעות WebPageTest. בדקנו כל שילוב של דפים, עם ובלי טעינה מדורגת, והרצנו כל בדיקה תשע פעמים כדי לקבל את ערך ה-LCP החציוני ואת מספר הבייטים של התמונות.
| סדרה | ברירת מחדל | הושבת | הפרש מברירת המחדל |
|---|---|---|---|
| tevenyttentyone-archive-desktop | 2,029 | 1,759 | -13% |
| tevenyttentyone-archive-mobile | 1,657 | 1,403 | -15% |
| tevenytevenyone-single-desktop | 1,655 | 1,726 | 4% |
| tevenytevenyone-single-mobile | 1,352 | 1,384 | 2% |
התוצאות שלמעלה משווים את ערך ה-LCP החציוני באלפיות השנייה של בדיקות בארכיון ובדפים בודדים במחשבים ובניידים. כשהשבתנו את הטעינה המושהית בדפי הארכיון, ראינו שיפור משמעותי ב-LCP. עם זאת, ההבדל בדפים בודדים היה ניטרלי יותר.
חשוב לציין שההשפעה של השבתת הטעינה המושהית בעצם מייעלת את המהירות של הדפים הנפרדים. עם זאת, ההבדל ב-LCP הוא פחות מפרטי סטיית תקן אחת בבדיקות של מחשבים שולחניים וניידים, ולכן אנחנו מייחסים זאת לשונות ורואים בשינוי ניטרלי באופן כללי. לשם השוואה, ההבדל בין דפי ארכיון דומה יותר לשתיים עד שלוש סטיות תקן.
| סדרה | ברירת מחדל | הושבת | הפרש מברירת המחדל |
|---|---|---|---|
| tevenyttentyone-archive-desktop | 577 | 1173 | 103% |
| tevenyttentyone-archive-mobile | 172 | 378 | 120% |
| tevenytevenyone-single-desktop | 301 | 850 | 183% |
| tevenytevenyone-single-mobile | 114 | 378 | 233% |
התוצאות שלמעלה משווים את המספר החציוני של הבייטים (ב-KB) של התמונות בכל בדיקה. כמו כן, לטעינה מושהית יש השפעה חיובית ברורה מאוד על צמצום מספר הבייטים של התמונות. אם משתמש אמיתי היה צריך לגלול את כל הדף למטה, כל התמונות ייטענו בכל זאת כשהן עוברות לאזור התצוגה, אבל התוצאות האלה מציגות את הביצועים המשופרים של הטעינה הראשונית של הדף.
לסיכום התוצאות של בדיקת ה-A/B, שיטת הטעינה המושהית שבה WordPress משתמשת, עוזרת לצמצם באופן ברור את הבייטים של התמונות, אבל במחיר של LCP מאוחר.
בדיקת תיקון
לפני שנלמד איך התיקון מיושם, בואו נראה איך פועלת טעינה מושהית ב-WordPress היום. ההיבט החשוב ביותר בהטמעה הנוכחית הוא הטעינה מדורגת של תמונות בחלק העליון והקבוע (בתוך אזור התצוגה). הפוסט בבלוג של מערכת ניהול התוכן מאשר את זה כדפוס שכדאי להימנע ממנו, אבל הנתונים מהניסוי באותו זמן הצביעו על כך שההשפעה על LCP הייתה מינימלית וכדאי לפשט את ההטמעה בליבה של WordPress.
על סמך הנתונים החדשים האלה יצרנו תיקון ניסיוני שמונע טעינה מדורגת של תמונות שמופיעות בחלק העליון והקבוע, ובדקנו אותן באותם תנאים כמו בבדיקת ה-A/B הראשונה.
| סדרה | ברירת מחדל | הושבת | fix | הפרש מברירת המחדל | ההבדל לעומת מושבת |
|---|---|---|---|---|---|
| tevenyttentyone-archive-desktop | 2,029 | 1,759 | 1,749 | -14% | -1% |
| tevenyttentyone-archive-mobile | 1,657 | 1,403 | 1,352 | -18% | -4% |
| tevenytevenyone-single-desktop | 1,655 | 1,726 | 1,676 | 1% | -3% |
| tevenytevenyone-single-mobile | 1,352 | 1,384 | 1,342 | -1% | -3% |
התוצאות האלה מבטיחות הרבה יותר. בטעינה הדרגתית רק של התמונות בחלק הנגלל, התוצאה היא היפוך מלא של הרגרסיה של LCP, ואולי אפילו שיפור קל בהשוואה להשבתה מוחלטת של ה-LCP. איך זה יכול להיות מהיר יותר מאשר טעינה עצלה בכלל? אחד ההסברים הוא שאם לא טוענים תמונות בחלק הנגלל, יש פחות תחרות ברשת עם תמונת ה-LCP, ולכן הטעינה מהירה יותר.
| סדרה | ברירת מחדל | הושבת | fix | הפרש מברירת המחדל | ההבדל לעומת מושבת |
|---|---|---|---|---|---|
| tevenyttentyone-archive-desktop | 577 | 1173 | 577 | 0% | -51% |
| tevenyttentyone-archive-mobile | 172 | 378 | 172 | 0% | -54% |
| tevenytevenyone-single-desktop | 301 | 850 | 301 | 0% | -65% |
| tevenytevenyone-single-mobile | 114 | 378 | 114 | 0% | -70% |
מבחינת בייטים של תמונות, אין שום שינוי בתיקון בהשוואה להתנהגות ברירת המחדל. זה דבר נהדר, כי זו הייתה אחת מנקודות החוזק של הגישה הנוכחית.
יש כמה אזהרות לגבי התיקון הזה. ו-WordPress קובעת אילו תמונות ייטענו בהדרגה בצד השרת, כלומר לא ידוע לה לגבי גודל אזור התצוגה של המשתמש ואם תמונות ייטענו בהתחלה. לכן התיקון משתמש בהיוריסטיקה לגבי המיקום היחסי של התמונות בתגי העיצוב כדי לנחש אם הן יהיו באזור התצוגה. באופן ספציפי, אם התמונה היא התמונה הראשונה בדף או התמונה הראשונה בתוכן הראשי, ההנחה היא שהיא נמצאת בחלק העליון והקבוע (או קרוב אליו), ולא תתבצע טעינה מדורגת. תנאים ברמת הדף, כמו מספר המילים בכותרת או כמות הטקסט בפסקה בתחילת התוכן הראשי, עשויים להשפיע על הצגת התמונה באזור התצוגה. יש גם תנאים ברמת המשתמש שעשויים להשפיע על הדיוק של ההיוריסטיקה, במיוחד גודל אזור התצוגה והשימוש בקישורים לעוגן שמשנים את מיקום הגלילה בדף. לכן, חשוב להבין שהתיקון מכויל רק כדי לספק ביצועים טובים באופן כללי, ויכול להיות שיהיה צורך לבצע התאמות כדי שהתוצאות האלה יהיו רלוונטיות לכל התרחישים בעולם האמיתי.
אנחנו משיקים אותו
עכשיו, אחרי שזיהינו דרך טובה יותר לטעינה מדורגת של תמונות, החיסכון בתמונות וביצועי ה-LCP מהירים יותר, איך נוכל לגרום לאתרים להתחיל להשתמש בה? השינוי בעדיפות הגבוהה ביותר הוא שליחת תיקון לליבה של WordPress כדי ליישם את התיקון הניסיוני. בנוסף, נעדכן את ההנחיות בבלוג טעינה מדורגת ברמת הדפדפן ל-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 חדשים יחסית של פלטפורמות אינטרנט יכולות להיות כרוכה גם בסיכונים וגם בפרסים – מסיבה כלשהי, הם נקראים תכונות מתקדמות. בעוד שאנחנו מתחילים להבין את שפע היתרונות של טעינה עצלה של תמונות מקוריות, אנחנו רואים גם את היתרונות של שימוש בשיטה הזו כדי לשפר את הביצועים.
צילום של פרנקי לופז ב-UnFlood