מה למדנו מהמעבר למאפיין הטעינה הסטנדרטי
המטרה שלי בפוסט הזה היא לשכנע את המפתחים והתורמים של פלטפורמות CMS (כלומר, האנשים שמפתחים את ליבות ה-CMS) שעכשיו זה הזמן להטמיע תמיכה בתכונה של טעינה מדורגת של תמונות ברמת הדפדפן. אני גם אשתף המלצות על איך להבטיח חוויית משתמש באיכות גבוהה ולאפשר התאמה אישית על ידי מפתחים אחרים בזמן הטמעה של טעינה מדורגת. ההנחיות האלה מבוססות על הניסיון שלנו בהוספת תמיכה ל-WordPress, וגם על העזרה שסיפקנו ל-Joomla, ל-Drupal ול-TYPO3 בהטמעת התכונה.
לא משנה אם אתם מפתחים של פלטפורמת CMS או משתמשים ב-CMS (כלומר, אנשים שיוצרים אתרים באמצעות CMS), אתם יכולים להשתמש בפוסט הזה כדי לקבל מידע נוסף על היתרונות של טעינה מדורגת ברמת הדפדפן ב-CMS. בקטע השלבים הבאים מפורטות הצעות לעידוד פלטפורמת ה-CMS להטמיע טעינה מדורגת.
רקע
בשנה האחרונה,
טעינה מדורגת של תמונות ורכיבי iframe באמצעות המאפיין loading
הפכה לחלק מתקן WHATWG HTML
והשימוש בה הולך ומתרחב בדפדפנים שונים.
אבל אבני הדרך האלה הן רק הבסיס לאינטרנט מהיר יותר שחוסך במשאבים.
עכשיו המערכת המבוזרת של האינטרנט צריכה להשתמש במאפיין loading.
מערכות ניהול תוכן מפעילות כ-60% מהאתרים, ולכן הפלטפורמות האלה ממלאות תפקיד חיוני בהטמעת תכונות של דפדפנים מודרניים באינטרנט. כמה מערכות ניהול תוכן פופולריות בקוד פתוח, כמו WordPress, Joomla ו-TYPO3, כבר הטמיעו תמיכה במאפיין loading בתמונות. נבחן את הגישות שלהן ואת המסקנות שרלוונטיות לאימוץ התכונה גם בפלטפורמות אחרות של מערכות ניהול תוכן. טעינה מדורגת של מדיה היא תכונה חשובה לביצועים באינטרנט, שאתרים צריכים להפיק ממנה תועלת בקנה מידה גדול. לכן מומלץ להטמיע אותה ברמת הליבה של מערכת ניהול התוכן.
למה כדאי להטמיע טעינה מדורגת כבר עכשיו
תקנון
הטמעה של תכונות דפדפן לא סטנדרטיות במערכות CMS מאפשרת בדיקה נרחבת ויכולה להציף תחומים פוטנציאליים לשיפור. עם זאת, יש הסכמה כללית בין מערכות ניהול התוכן שכל עוד תכונה של דפדפן לא עברה תהליך תקינה, עדיף להטמיע אותה כתוסף או פלאגין לפלטפורמה הרלוונטית. רק אחרי שהתכונה עוברת תהליך סטנדרטיזציה, אפשר לשקול להטמיע אותה בליבה של הפלטפורמה.
תמיכה בדפדפנים
גם התמיכה של הדפדפן בתכונה היא שיקול דומה: רוב המשתמשים במערכת ניהול התוכן צריכים להיות מסוגלים ליהנות מהתכונה. אם יש אחוז ניכר של דפדפנים שבהם התכונה עדיין לא נתמכת, צריך לוודא שלפחות אין לה השפעה שלילית על הדפדפנים האלה.
ערכי הסף של המרחק מאזור התצוגה
אחת הבעיות הנפוצות בהטמעות של טעינה מדורגת היא שהן מגדילות את הסיכוי שהתמונה לא תיטען כשהיא תהפוך לגלויה באזור התצוגה של המשתמש, כי מחזור הטעינה מתחיל בשלב מאוחר יותר. בניגוד לפתרונות קודמים שמבוססים על JavaScript, דפדפנים ניגשים לזה באופן שמרני ויכולים גם לשפר את הגישה שלהם על סמך נתונים מחוויית המשתמש בעולם האמיתי, וכך למזער את ההשפעה. לכן, פלטפורמות CMS יכולות לאמץ בבטחה טעינה מדורגת ברמת הדפדפן.
המלצות לגבי חוויית המשתמש
דרישה למאפייני מימדים ברכיבים
כדי למנוע שינויי פריסה, ההמלצה הוותיקה היא שתוכן מוטמע כמו תמונות או מסגרות iframe תמיד יכלול את מאפייני המימדים width ו-height, כדי שהדפדפן יוכל להסיק את יחס הגובה-רוחב של הרכיבים האלה לפני שהוא טוען אותם בפועל. ההמלצה הזו רלוונטית גם אם הרכיב נטען בטעינה מדורגת וגם אם לא. עם זאת, בגלל הסבירות הגבוהה יותר ב-0.1% שתמונה לא תיטען במלואה כשהיא נמצאת באזור התצוגה, היא הופכת למעט יותר רלוונטית כשטעינה מדורגת מופעלת.
עדיף שמערכות ניהול תוכן יספקו מאפייני מידות לכל התמונות ורכיבי ה-iframe. אם זה לא אפשרי לכל רכיב כזה, מומלץ לדלג על טעינה מדורגת של תמונות שלא מספקות את שני המאפיינים האלה.
הימנעו מטעינה מדורגת של רכיבים בחלק העליון והמרכזי של הדף
נכון לעכשיו, מומלץ להוסיף במערכות ניהול תוכן מאפייני loading="lazy" רק לתמונות ולרכיבי iframe שנמצאים מתחת לקו המשוער, כדי למנוע עיכוב במדד הצגת התוכן הכי גדול (LCP), שיכול להיות משמעותי במקרים מסוימים, כפי שהתגלה ביולי 2021. עם זאת, חשוב להבין שקשה להעריך את המיקום של רכיב ביחס לאזור התצוגה לפני תהליך הרינדור. זה נכון במיוחד אם מערכת ניהול התוכן משתמשת בגישה אוטומטית להוספת מאפייני loading, אבל גם אם מדובר בהתערבות ידנית, צריך להביא בחשבון כמה גורמים, כמו הגדלים השונים של אזורי התצוגה ויחסי הגובה-רוחב. עם זאת, מומלץ מאוד לא להשתמש בטעינה מדורגת לתמונות ראשיות ולתמונות או לרכיבי iframe אחרים שסביר להניח שיופיעו בחלק העליון ויתפסו את רוב המסך.
הימנעות משימוש ב-JavaScript כחלופה
אפשר להשתמש ב-JavaScript כדי לספק טעינה מדורגת לדפדפנים שעדיין לא תומכים במאפיין loading, אבל מנגנונים כאלה תמיד מסתמכים על הסרה ראשונית של המאפיין src של תמונה או iframe, מה שגורם לעיכוב בדפדפנים שכן תומכים במאפיין. בנוסף, הטמעה של פתרון כזה שמבוסס על JavaScript בממשקי המשתמש של מערכת ניהול תוכן בקנה מידה גדול מגדילה את הסיכוי לבעיות פוטנציאליות. זו אחת מהסיבות לכך שאף מערכת ניהול תוכן גדולה לא אימצה טעינה מדורגת בליבה שלה לפני שהתכונה הזו הפכה לתכונה סטנדרטית בדפדפנים.
המלצות טכניות
הפעלת טעינה מדורגת כברירת מחדל
ההמלצה הכללית למערכות CMS שמטמיעות טעינה מדורגת ברמת הדפדפן היא להפעיל אותה כברירת מחדל, כלומר צריך להוסיף את loading="lazy" לתמונות ולרכיבי iframe, ורצוי רק לרכיבים שכוללים מאפייני מידות.
כשהתכונה מופעלת כברירת מחדל, נחסכים יותר משאבי רשת מאשר אם היה צריך להפעיל אותה באופן ידני, למשל לכל תמונה בנפרד.
ככל האפשר, צריך להוסיף את loading="lazy" רק לרכיבים שסביר להניח שיופיעו בחלק הנגלל.
לפעמים קשה להטמיע את הדרישה הזו במערכת ניהול תוכן (CMS) כי אין מודעות בצד הלקוח ויש גדלים שונים של אזורי תצוגה. במקרים כאלה, מומלץ לפחות להשתמש בשיטות היוריסטיות משוערות כדי להשמיט רכיבים כמו תמונות ראשיות שסביר להניח שיופיעו בחלק העליון של הדף, כך שהן לא ייטענו בטעינה חמדנית.
אישור שינויים בכל רכיב
למרות שצריך להוסיף את loading="lazy" לתמונות ולרכיבי iframe כברירת מחדל, חשוב לאפשר השמטה של המאפיין בתמונות מסוימות, למשל כדי לבצע אופטימיזציה ל-LCP. אם הקהל של מערכת ניהול התוכן נחשב בממוצע לקהל עם יותר ידע טכני, אפשר להציג רכיב אינטראקטיבי בכל תמונה ו-iframe שמאפשר לבטל את ההסכמה לטעינה מדורגת של הרכיב הזה.
לחלופין או בנוסף, אפשר לחשוף API למפתחים של צד שלישי כדי שהם יוכלו לבצע שינויים דומים באמצעות קוד.
לדוגמה, ב-WordPress אפשר לדלג על המאפיין loading בתג HTML או בהקשר שלם או ברכיב HTML ספציפי בתוכן.
התאמת תוכן קיים
באופן כללי, יש שתי גישות להוספת המאפיין loading לרכיבי HTML במערכת ניהול תוכן:
- אפשר להוסיף את המאפיין מתוך עורך התוכן בקצה העורפי, ולשמור אותו באופן קבוע במסד הנתונים.
- להוסיף את המאפיין תוך כדי עיבוד התוכן ממסד הנתונים בקצה הקדמי.
מומלץ להוסיף את המאפיין למערכת ניהול התוכן (CMS) בזמן אמת במהלך העיבוד, כדי להחיל את היתרונות של הטעינה הדרגתית גם על תוכן קיים. אם אפשר היה להוסיף את המאפיין רק דרך העורך, רק קטעי תוכן חדשים או כאלה ששונו לאחרונה היו מקבלים את היתרונות, מה שהיה מפחית באופן משמעותי את ההשפעה של מערכת ניהול התוכן על חיסכון במשאבי הרשת. בנוסף, הוספת המאפיין באופן דינמי תאפשר לבצע שינויים בקלות בעתיד, אם היכולות של טעינה מדורגת ברמת הדפדפן יורחבו עוד יותר.
הוספת המאפיין תוך כדי תנועה אמורה לטפל במאפיין loading שעשוי להיות קיים ברכיב, ולאפשר למאפיין כזה לקבל קדימות. כך, מערכת ניהול התוכן או תוסף שלה יכולים גם להטמיע את הגישה מבוססת-העורך בלי לגרום להתנגשות עם מאפיינים כפולים.
אופטימיזציה של הביצועים בצד השרת
כשמוסיפים את המאפיין loading לתוכן תוך כדי תנועה באמצעות (לדוגמה) תוכנת ביניים בצד השרת, המהירות היא שיקול. בהתאם למערכת ניהול התוכן, אפשר להוסיף את המאפיין באמצעות מעבר ב-DOM או ביטויים רגולריים. מומלץ להשתמש בביטויים רגולריים כדי לשפר את הביצועים.
מומלץ להשתמש בביטויים רגולריים כמה שפחות. לדוגמה, ביטוי רגולרי אחד שאוסף את כל התגים img ו-iframe בתוכן, כולל המאפיינים שלהם, ואז מוסיף את המאפיין loading לכל מחרוזת תגים לפי הצורך. לדוגמה, ב-WordPress יש ביטוי רגולרי כללי אחד לביצוע פעולות שונות בזמן אמת על רכיבים מסוימים, והוספת loading="lazy" היא רק אחת מהן, באמצעות ביטוי רגולרי אחד כדי להקל על תכונות מרובות. סוג האופטימיזציה הזה הוא סיבה נוספת לכך שמומלץ להשתמש בטעינה מדורגת בליבה של מערכת ניהול התוכן ולא בתוסף – היא מאפשרת אופטימיזציה טובה יותר של הביצועים בצד השרת.
השלבים הבאים
בדקו אם יש כרטיס קיים של הגשת בקשה להוספת תכונה כדי להוסיף תמיכה בתכונה במערכת ניהול התוכן שלכם, או פתחו כרטיס חדש אם עדיין אין כזה. אפשר להשתמש בהפניות לפוסט הזה לפי הצורך כדי לתמוך בהצעה.
אתם יכולים לשלוח לי ציוץ (felixarntz@) עם שאלות או הערות, או כדי להוסיף את מערכת ניהול התוכן שלכם לרשימה שבדף הזה אם הוספתם תמיכה בטעינה מדורגת ברמת הדפדפן. אם נתקלת באתגרים אחרים, אשמח לשמוע עליהם כדי לנסות למצוא פתרון.
אם אתם מפתחים של פלטפורמת CMS, כדאי לבדוק איך מערכות CMS אחרות הטמיעו טעינה מדורגת:
אתם יכולים להשתמש במסקנות מהמחקר ובהמלצות הטכניות מהפוסט הזה כדי להתחיל לתרום קוד למערכת ניהול התוכן שלכם, למשל בצורה של תיקון או בקשת משיכה.