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

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

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

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

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

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

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

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

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

הערה: המאפיין loading לא משפיע עדיפות הרשת של התמונה. כדי לשנות את עדיפות הרשת, אפשר להשתמש אחזור Priority API. שימו לב התמונה באזור התצוגה הגלוי עם fetchpriority="high" ו-loading="lazy" עדיין ממתין עד שכל שירותי ה-CSS שהורדו ונותחו.

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

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

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

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

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

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

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

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

הערה: Chrome שומר מקום ומציג placeholder עדיין מתבצע אחזור של <iframe> שנטען באופן מדורגת במסגרת מאמץ כדי למנוע שינויים בפריסה. עם זאת, עדיין כדאי לשקול להשתמש width של הרכיב <iframe> וגם height וגם עיצוב נוסף ב-CSS כדי לצמצם את שינויי הפריסה.

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

חזית הבניין

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"eager"

תשובה נכונה!

"lazy"

אפשר לנסות שוב.

מתי ניתן להשתמש בפתרונות של טעינה מדורגת שמבוססים על JavaScript?

לכל משאב שאפשר לטעון באופן מדורג.

אפשר לנסות שוב.

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

תשובה נכונה!

מתי שימוש בחזית היא שיטה שימושית?

בכל הטמעה של צד שלישי שצורכת כמות גדולה של נתונים, בלי קשר לצרכים של המשתמש.

אפשר לנסות שוב.

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

תשובה נכונה!

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

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