ההשפעות על הביצועים של טעינה מדורגת מדי

טיפים מבוססי-נתונים לטעינה מדורגת של תמונות, תוך התמקדות במדדי הליבה לבדיקת חוויית המשתמש (Core Web Vitals).

טכניקת טעינה איטית היא שיטה שמאפשרת לדחות את הורדת המשאב עד שהוא נחוץ, כדי לחסוך נתונים ולצמצם את התחרות על משאבים קריטיים ברשת. הוא הפך לתקן אינטרנט ב2019, והיום loading="lazy" לתמונות נתמך ברוב הדפדפנים העיקריים.

במדריך הזה נסכם את האופן שבו ניתחנו נתונים זמינים לכולם על שקיפות באינטרנט ובדקנו את הביצועים של טעינת תמונות בזמן אמת ברמת הדפדפן, כדי להבין את מאפייני השימוש והביצועים של התכונה הזו. בין הממצאים: טעינת פריטים בזמן אמת יכולה להיות כלי יעיל להפליא לצמצום הבייטים של תמונות מיותרות, אבל שימוש יתר בה יכול להשפיע לרעה על הביצועים. באופן ספציפי, מהניתוח הזה עולה שטעינה מהירה יותר של תמונות בחלון התצוגה הראשוני – תוך טעינה מדורגת של שאר התמונות – יכולה לספק את הטוב משני העולמות: פחות בייטים נטענים ומדדי הליבה לבדיקת חוויית המשתמש באתר משופרים.

אימוץ

לפי הנתונים האחרונים ב-HTTP Archive, 29% מהאתרים משתמשים בטעינה איטית מובנית של תמונות, והשימוש בה הולך וגדל במהירות.

תרשים עוגה שבו מוצג ש-WordPress מהווה 84.1% מהאימוץ של טעינת נכסים בזמן אמת, מערכות ניהול תוכן אחרות מהוות 2.3% ומערכות אחרות שאינן מערכות ניהול תוכן מהוות 13.5%.
פירוט של סוגי האתרים שמשתמשים בחיבור איטי של תמונות ברמת הדפדפן. (מקור).

שליחת שאילתות לנתונים הגולמיים בפרויקט HTTP Archive מאפשרת לנו להבין טוב יותר אילו סוגים של אתרים תורמים לאימוץ: 84% מהאתרים שמשתמשים בטעינה איטית של תמונות ברמת הדפדפן משתמשים ב-WordPress, 2% משתמשים במערכת ניהול תוכן אחרת וה-14% הנותרים לא משתמשים במערכת ניהול תוכן מוכרת. התוצאות האלה מראות בבירור איך WordPress מוביל את השימוש.

תרשים של סדרת זמן של אימוץ טעינת פריטים בזמן אמת, שבו WordPress היא המערכת הדומיננטית בהשוואה למערכות ניהול תוכן אחרות ולמערכות אחרות שלא הן מערכות ניהול תוכן, עם יחסי גודל דומים לתרשים הקודם. נראה שהשימוש הכולל גדל במהירות מ-1% ל-17%, מחודש יולי 2020 עד יוני 2021.
פירוט של סוגי האתרים שמשתמשים בחיבור איטי של תמונות ברמת הדפדפן. (מקור).

כדאי גם לשים לב לשיעור ההטמעה. לפני שנה, ביולי 2020, אתרי WordPress שמשתמשים בטעינה איטית היוו עשרות אלפי אתרים מתוך קורפוס של כ-6 מיליון אתרים (1% מתוך סך הכול). מאז, יותר ממיליון אתרים (14% מכלל האתרים) ב-WordPress בלבד החלו להשתמש בטעינת פריטים בזמן אמת.

ביצועים קורלציוניים

בבדיקה מעמיקה יותר ב-HTTP Archive, אפשר להשוות בין הביצועים של דפים עם טעינה איטית של תמונות ברמת הדפדפן לבין הביצועים של דפים ללא טעינה איטית של תמונות ברמת הדפדפן, לפי המדד 'המהירות שבה נטען רכיב התוכן הכי גדול' (LCP). נתוני ה-LCP מגיעים מחוויית משתמשים אמיתיים מהדוח לגבי חוויית המשתמש ב-Chrome ‏ (CrUX), בניגוד לבדיקות סינתטיות במעבדה. בתרשים הבא מוצגת תרשים תיבת-ו-שפיפור כדי להמחיש את ההתפלגויות של LCP ב-75% הרבעונים של כל דף: הקווים מייצגים את הרבעונים ה-10 וה-90, והתיבות מייצגות את הרבעונים ה-25 וה-75.

תרשים תיבות ושיניים שבו מוצגים האחוזונים ה-10, ה-25, ה-75 וה-90 של דפים שמשתמשים בטעינה איטית של תמונות ברמת הדפדפן ושל דפים שלא משתמשים בה. בהשוואה, ההתפלגות של LCP בדפים שלא משתמשים בהם מהירה יותר מזו של דפים שמשתמשים בהם.
הפיזור של חוויית ה-LCP של כל הדפים באחוזון ה-75, לפי חלוקה בין דפים שמשתמשים בטעינת תמונות איטית ברמת הדפדפן לבין דפים שלא משתמשים בטעינת תמונות איטית. (מקור).

הדף החציוני ללא טעינת נתונים בזמן אמת (lazy loading) כולל זמן LCP של 2,922 אלפיות השנייה ב-75% מהמקרים, לעומת 3,546 אלפיות השנייה בדף החציוני עם טעינת נתונים בזמן אמת. באופן כללי, באתרים שמשתמשים בטעינה איטית בדרך כלל יש ביצועים גרועים יותר של LCP.

חשוב לציין שמדובר בתוצאות קורלציוניות, והן לא מצביעות בהכרח על כך שהטעינה האיטית היא הסיבה לביצועים האיטיים יותר. באופן היפותטי, אם אתרים ב-WordPress נוטים להיות קצת איטיים יותר, והנתונים שלהם מהווים חלק גדול מהקבוצה של טעינה איטית, זה יכול להסביר את ההבדל. כדי למנוע את התנודות האלה, אפשר לצמצם את המיקוד לאתרי WordPress בלבד.

תרשים תיבה עם שפיציות שבו מוצגים האחוזונים ה-10, ה-25, ה-75 וה-90 של דפי WordPress שמשתמשים בטעינה איטית של תמונות ברמת הדפדפן ושל דפים שלא משתמשים בה. בהשוואה, זמן הטעינה של רכיב LCP בדפים שלא משתמשים בו מהיר יותר מאשר בדפים שמשתמשים בו, בדומה לתרשים הקודם.
התפלגות חוויית ה-LCP של דפי WordPress באחוזון ה-75, לפי שימוש בטעינת תמונות בזמן אמת ברמת הדפדפן. (מקור).

לצערנו, אותו דפוס מופיע גם כשבודקים לעומק דפים ב-WordPress. בדפים שמשתמשים בטעינת פריטים בזמן אמת, בדרך כלל זמן הטעינה של פריט ה-LCP ארוך יותר. הדף החציוני ב-WordPress ללא טעינת נתונים בזמן אמת (lazy loading) כולל זמן LCP של 3,495 אלפיות השנייה ב-75% מהמקרים, לעומת 3,768 אלפיות השנייה בדף החציוני עם טעינת נתונים בזמן אמת.

הנתונים האלה עדיין לא מוכיחים שהטעינה האיטית גורמת לדפים להיות איטיים יותר, אבל השימוש בה כן גורם לביצועים איטיים יותר. כדי לנסות לענות על השאלה לגבי הסיבה והתוצאה, הוגדרה בדיקת A/B במעבדה.

ביצועים תלויי-סיבה

מטרת הבדיקה הייתה להוכיח או להפריך את ההשערה שטעינה מדורגת מובנית של תמונות, כפי שהוטמעה בליבה של 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 (אלפיות השנייה) לאחר השבתת הטעינה המדרגתית של תמונות ברמת הדפדפן בדפי WordPress לדוגמה.

בתוצאות האלה מוצגת השוואה בין ערך 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) על ידי השבתת טעינת התמונות באיטרציות בדפדפן בדפי WordPress לדוגמה.

בתוצאות האלה מוצגת השוואה בין מספר הבייטים החציוני של התמונות (ב-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%
השינוי ב-LCP (במילי-שניות) בעקבות התיקון המוצע לטעינה מדורגת של תמונות ברמת הדפדפן בדפי WordPress לדוגמה.

התוצאות האלה מבטיחות הרבה יותר. טעינת פריטים באיטרציה (lazy loading) רק של התמונות שמתחת לקו החזית (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%
השינוי במספר הבייטים של התמונות (KB) בעקבות התיקון המוצע לטעינת תמונות איטית ברמת הדפדפן בדפי WordPress לדוגמה.

מבחינת הבייטים של התמונה, התיקון לא גורם לשום שינוי בהשוואה להתנהגות שמוגדרת כברירת מחדל. זה מצוין כי זה היה אחד מהיתרונות של הגישה הנוכחית.

לתיקון הזה יש כמה מגבלות. מערכת 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 חדשים יחסית של פלטפורמות אינטרנט יש יתרונות וחסרונות – הן נקראות 'תכונות מתקדמות' מסיבה כלשהי. אנחנו מתחילים להבין את הבעיות שקשורות לטעינה איטית של תמונות ברמת הדפדפן, אבל אנחנו גם רואים את היתרונות של השימוש בה כדי לשפר את הביצועים.

תמונה של Frankie Lopez ב-Unsplash