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

bookmark_border קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

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

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

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

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

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

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

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

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

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

חזית הבניין

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

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

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

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

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

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

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

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

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

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

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

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

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