טעינה מדורגת של תמונות ורכיבי <iframe>

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

במקרה של טעינת תמונות בזמן אמת, כדאי לדחות את טעינת התמונות שמחוץ לאזור התצוגה הראשוני כדי לצמצם את התחרות על רוחב הפס למשאבים קריטיים יותר באזור התצוגה הראשוני. כך אפשר לשפר את Largest Contentful Paint ‏ (LCP) של דף במקרים מסוימים שבהם חיבורי הרשת חלשים, והקצאת רוחב הפס מחדש יכולה לעזור למועמדים ל-LCP לטעון ולצייר מהר יותר.

לגבי רכיבי <iframe>, אפשר לשפר את הזמן מאינטראקציה לציור הבא (INP) של דף במהלך ההפעלה באמצעות טעינה איטית שלהם. הסיבה לכך היא ש-<iframe> הוא מסמך HTML נפרד לגמרי עם משאבי משנה משלו. אפשר להריץ רכיבי <iframe> בתהליך נפרד, אבל לרוב הם משתפים תהליך עם שרשורים אחרים, וכך עלולים להיווצר תנאים שבהם הדפים יהיו פחות תגובה להזנת משתמש.

לכן, כדאי להשתמש בשיטה של דחיית הטעינה של תמונות ורכיבי <iframe> מחוץ למסך. היא לא מחייבת מאמץ רב ומניבה תשואה טובה למדי מבחינת הביצועים. המודול הזה מסביר איך מבצעים טעינה איטית של שני סוגי הרכיבים האלה כדי לספק חוויית משתמש מהירה וטובה יותר במהלך תקופת ההפעלה הקריטית של הדף.

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

אפשר להוסיף את המאפיין loading לרכיבי <img> כדי להורות לדפדפנים איך לטעון אותם:

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

חשוב גם לציין שאם משתמשים באלמנט <picture>, עדיין צריך להחיל את המאפיין loading על אלמנט הצאצא <img>, ולא על האלמנט <picture> עצמו. הסיבה לכך היא שרכיב <picture> הוא מאגר שמכיל רכיבי <source> נוספים שמפנים לתמונות מועמדות שונות, והתמונה שנבחרת על ידי הדפדפן חלה ישירות על רכיב הצאצא <img>.

לא לבצע טעינה מדורגת של תמונות שנמצאות באזור התצוגה הראשוני

צריך להוסיף את המאפיין loading="lazy" רק לרכיבי <img> שממוקמים מחוץ לאזור התצוגה הראשוני. עם זאת, יכול להיות שיהיה קשה לדעת מה המיקום המדויק של רכיב ביחס לאזור התצוגה לפני שהדף יומר. צריך להביא בחשבון גדלים שונים של אזור תצוגה, יחסי גובה-רוחב ומכשירים שונים.

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

עם זאת, יש מקרים שבהם ברור למדי שצריך להימנע משימוש ב-loading="lazy". לדוגמה, מומלץ מאוד להשמיט את המאפיין loading="lazy" מרכיבי <img> במקרים של תמונות ראשיות, או בתרחישי שימוש אחרים של תמונות שבהם סביר להניח שרכיבי <img> יופיעו מעל לקו החיתוך או ליד החלק העליון של הפריסה בכל מכשיר. חשוב לעשות זאת במיוחד לגבי תמונות שסביר להניח יהיו מועמדות ל-LCP.

תמונות שנטענות באיטרציה צריכות להמתין עד שהדפדפן יסיים את הפריסה כדי לדעת אם המיקום הסופי של התמונה נמצא בחלון התצוגה. כלומר, אם לאובייקט <img> בחלון התצוגה הגלוי יש מאפיין loading="lazy", הוא מבוקש רק אחרי שכל קובצי ה-CSS מורידים, מנותחים ומוחלים על הדף – בניגוד לאחזור ברגע שהוא מתגלה על ידי סורק ההטענה מראש בקוד המטא הגולמי.

מכיוון שהמאפיין loading ברכיב <img> נתמך בכל הדפדפנים העיקריים, אין צורך להשתמש ב-JavaScript כדי לטעון תמונות באיטרציה (lazy load). הוספת JavaScript נוסף לדף כדי לספק יכולות שהדפדפן כבר מספק משפיעה על היבטים אחרים של ביצועי הדף, כמו INP.

הדגמה של טעינה מדורגת של תמונות

טעינה מדורגת של רכיבי <iframe>

טעינת רכיבי <iframe> באיטרציות עד שהם גלויים בחלון התצוגה יכולה לחסוך כמות משמעותית של נתונים ולשפר את טעינת המשאבים הקריטיים הנדרשים לטעינת הדף ברמה העליונה. בנוסף, מאחר שרכיבי <iframe> הם למעשה מסמכי HTML שלמים שנטענים במסמך ברמה העליונה, הם יכולים לכלול מספר רב של משאבי משנה – במיוחד JavaScript – שיכולים להשפיע באופן משמעותי על INP של הדף אם הזמן הנדרש לעיבוד המשימות בתוך המסגרות האלה ארוך.

הטמעות של צד שלישי הן תרחיש לדוגמה נפוץ לשימוש ברכיבי <iframe>. לדוגמה, בנגני וידאו מוטמעים או בפוסטים ברשתות חברתיות נעשה בדרך כלל שימוש ברכיבי <iframe>, ולעיתים קרובות הם דורשים מספר משמעותי של משאבי משנה, שגם הם יכולים לגרום למאבק על רוחב הפס במשאבי הדף ברמה העליונה. לדוגמה, טעינת קוד מוטמע של סרטון YouTube באופן איטי חוסכת יותר מ-500KB במהלך טעינת הדף הראשונית, בעוד שטעינת הפלאגין של לחצן ה'לייק' של Facebook באופן איטי חוסכת יותר מ-200KB – רובם קוד JavaScript.

בכל מקרה, בכל פעם שיש לכם <iframe> בחלק הנגלל של דף, מומלץ מאוד להשתמש בטעינה איטית אם לא חיוני לטעון אותו מראש, כי כך אפשר לשפר משמעותית את חוויית המשתמש.

המאפיין loading לרכיבי <iframe>

המאפיין loading ברכיבי <iframe> נתמך גם בכל הדפדפנים העיקריים. הערכים של המאפיין loading וההתנהגויות שלהם זהים לאלה של רכיבי <img> שמשתמשים במאפיין loading:

• "eager" הוא ערך ברירת המחדל. הוא מורה לדפדפן לטעון את ה-HTML של הרכיב <iframe> ואת המשאבים המשניים שלו באופן מיידי.
• "lazy" דוחה את טעינת ה-HTML של רכיב <iframe> ואת המשאבים המשניים שלו עד שהוא נמצא במרחק מוגדר מראש מאזור התצוגה.

הדגמה של טעינה מדורגת של מסגרות iframe

חזית הבניין

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

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

זוהי הזדמנות מצוינת להציג תמונה סטטית שדומה מבחינה ויזואלית להטמעת הסרטון, וכך לחסוך ברוחב פס משמעותי. אחרי שהמשתמש לוחץ על התמונה, היא מוחלפת בהטמעה בפועל של <iframe>, שמפעילה את ההורדה של ה-HTML של רכיב <iframe> של הצד השלישי והמשאבים המשניים שלו.

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

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

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

אפשר בהחלט ליצור חזיתות משלכם, אבל יש גם אפשרויות קוד פתוח לצדדים שלישיים פופולריים יותר, כמו lite-youtube-embed לסרטונים ב-YouTube, lite-vimeo-embed לסרטונים ב-Vimeo ו-React Live Chat Loader לווידג'טים של צ'אט.

ספריות של טעינת JavaScript באיטרציה

אם אתם צריכים לטעון באיטרציות אלמנטים מסוג <video>, תמונות מסוג poster של אלמנט <video>, תמונות שנטענות על ידי מאפיין ה-CSS background-image או אלמנטים אחרים שלא נתמכים, תוכלו לעשות זאת באמצעות פתרון לטעינה באיטרציות שמבוסס על JavaScript, כמו lazysizes או yall.js, כי טעינה באיטרציות של סוגי המשאבים האלה היא לא תכונה ברמת הדפדפן.

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

רוב הספריות האלה פועלות באמצעות Intersection Observer API – ובנוסף Mutation Observer API אם ה-HTML של הדף משתנה אחרי הטעינה הראשונית – כדי לזהות מתי רכיב נכנס למסך של המשתמש. אם התמונה גלויה – או מתקרבת לאזור התצוגה – ספריית JavaScript מחליפה את המאפיין הלא סטנדרטי (לרוב data-src או מאפיין דומה) במאפיין הנכון, כמו src.

נניח שיש לכם סרטון שמחליף קובץ GIF מונפש, אבל אתם רוצים לטעון אותו באיטרציה עם פתרון JavaScript. אפשר לעשות זאת באמצעות yall.js באמצעות דפוס ה-markup הבא:

<!-- The autoplay, loop, muted, and playsinline attributes are to
     ensure the video can autoplay without user intervention. -->
<video class="lazy" autoplay loop muted playsinline width="320" height="480">
  <source data-src="video.webm" type="video/webm">
  <source data-src="video.mp4" type="video/mp4">
</video>

כברירת מחדל, yall.js עוקב אחרי כל רכיבי ה-HTML שעומדים בדרישות עם הכיתה "lazy". אחרי שהקוד yall.js נטען ומופעל בדף, הסרטון לא נטען עד שהמשתמש גולל אותו לתוך אזור התצוגה. בשלב הזה, המאפיינים data-src באלמנט <video> וברכיבי הצאצא <source> שלו מוחלפים במאפיינים src, שמפעילים בקשה להורדת הסרטון והפעלה אוטומטית שלו.

בוחנים את הידע

השלב הבא: שליפה מראש (prefetch) ועיבוד מראש

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