איך לשפר את מהירות האתר עם lazy load, ומתי הוא דווקא מזיק

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

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

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

הטבלה מסכמת את הסימנים ואת הבדיקה שמתאימה לכל אחד:

טעינה עצלה (lazy load) אומרת לדפדפן לא להוריד משאב מיד, אלא רק כשהוא מתקרב לאזור הנראה של המסך. לפי המדריך של web.dev, הדרך שמובנית בדפדפן היא המאפיין loading, ויש לו שני ערכים:

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

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

הדפדפן לא מחכה שהתמונה תיכנס בדיוק למסך. לפי web.dev, בכרום המרחק תלוי במהירות החיבור: בערך 1,250 פיקסלים בחיבור 4G ובערך 2,500 פיקסלים בחיבור 3G או איטי יותר. כך התמונה בדרך כלל כבר מוכנה כשהמבקר גולל אליה. לפי המדידות שמובאות שם, בחיבור 4G כ-97.5% מהתמונות שנטענו בעצלות סיימו להיטען בתוך 10 מילישניות מהרגע שהפכו לנראות. כשהטעינה העצלה מוגדרת נכון, המבקר לא אמור להרגיש אותה בכלל.

לפי אותו מדריך, המאפיין נתמך בכרום מגרסה 77, באדג' מגרסה 79, בפיירפוקס מגרסה 75 ובספארי מגרסה 15.4. בפועל כל דפדפן עדכני מכיר אותו, ודפדפן ישן שלא מכיר אותו פשוט טוען את התמונה מיד.

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

• לפי התיעוד למפתחים של וורדפרס, מאז גרסה 5.5 המערכת מוסיפה loading="lazy" לתמונות כברירת מחדל, ומאז גרסה 5.7 גם ל-iframes.
• מגרסה 6.3 יש לוורדפרס פונקציה שמחליטה אילו מאפייני טעינה לתת לכל תמונה. היא לא טוענת בעצלות את התמונות הראשונות בעמוד, ולתמונה שנראית כמו התמונה הראשית היא נותנת fetchpriority="high".
• אם מסיבה כלשהי צריך לכבות את הטעינה העצלה של וורדפרס לגמרי, יש לזה פילטר רשמי בשם wp_lazy_loading_enabled.

הקוד לכיבוי מלא נכנס לקובץ functions.php של תבנית הבת, או לתוסף סניפטים:

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

אם יש לך WP Rocket: לפי התיעוד של WP Rocket, כשה-LazyLoad שלהם פעיל, הטעינה העצלה של וורדפרס נכבית אוטומטית. ה-LazyLoad של WP Rocket עובד עם JavaScript, וכברירת מחדל הוא טוען תמונות שנמצאות בטווח של 300 פיקסלים מהמסך. ההגדרות נמצאות בלשונית Media, באזור LazyLoad.

את טווח ה-300 פיקסלים אפשר לשנות, והתיעוד של WP Rocket נותן לזה פילטר בשם rocket_lazyload_threshold. בדוגמה הזו הטווח יורד ל-100 פיקסלים, והקוד נכנס ל-functions.php של תבנית הבת או לתוסף סניפטים:

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

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

1. מריצים את העמוד ב-PageSpeed Insights ומסתכלים על LCP, הזמן עד שהתוכן הגדול ביותר במסך מופיע. לפי web.dev, ערך טוב הוא עד 2.5 שניות.
2. בחלק האבחון של הדוח רואים איזה אלמנט נבחר כ-LCP. אם זו תמונה, היא החשודה.
3. פותחים את קוד המקור של העמוד ומחפשים את התמונה. אם יש לה loading="lazy", או מאפיינים של תוסף כמו data-lazy-src של WP Rocket במקום src רגיל, היא נטענת בעצלות.

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

כדי להבין למה, web.dev מפרק את ה-LCP לארבעה חלקים: הזמן עד שהשרת שולח את הבייט הראשון, העיכוב עד שהדפדפן מתחיל להוריד את התמונה, זמן ההורדה, והעיכוב עד שהתמונה מצוירת. טעינה עצלה של התמונה הראשית מאריכה את החלק השני: הדפדפן יודע שהתמונה קיימת, אבל מחכה במקום להתחיל להוריד אותה.

יש כמה דרכים לתקן:

• ב-WP Rocket מוסיפים את שם הקובץ של התמונה, או מחלקת CSS שלה, לתיבה Excluded images or iframes בלשונית Media.
• בתבנית או בקוד, מוודאים שלתמונה הראשית יש loading="eager" או שאין לה מאפיין loading בכלל, ומוסיפים fetchpriority="high", כמו ש-web.dev ממליץ לתמונת LCP.
• אם אתה עובד רק עם הטעינה המובנית של וורדפרס, ברוב המקרים הוא כבר מטפל בזה מגרסה 6.3. ובכל זאת כדאי לבדוק בקוד המקור, כי תבנית או בונה עמודים יכולים לעקוף את ההחלטה שלו.

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

התיקון הוא לתת לכל תמונה width ו-height, או aspect-ratio ב-CSS, וכך הדפדפן שומר לה מקום עוד לפני שהיא הגיעה. במדריך של web.dev על טעינה עצלה כתוב שבלי מידות, טעינה עצלה חוסכת משאבי רשת במחיר של יותר קפיצות.

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

כאן טעינה עצלה עלולה לא רק להאט, אלא לשבור את התצוגה.

WP Rocket מציע אפשרות נפרדת בשם LazyLoad for CSS background images, באותה לשונית Media. לפי התיעוד שלהם, היא מחליפה את כתובות תמונות הרקע במשתני CSS וטוענת אותן עם JavaScript כשהאלמנט מתקרב למסך. התיעוד לא מזכיר קרוסלות במפורש, אבל הוא כן ממליץ להחריג אלמנט כשהתמונה או הפריסה נשברות בגלל הטעינה העצלה.

ראיתי את זה קורה באתר תיירות: טעינה עצלה של תמונות רקע ב-CSS (אפשרות ב-WP Rocket) השאירה שקופיות בקרוסלה ריקות, וביטול האפשרות פתר את הבעיה.

אלה הסימנים, ואיך מוצאים את האשמה:

• קרוסלה, סליידר או באנר שמופיעים ריקים או חלקיים, בעיקר אחרי שעוברים בין שקופיות.
• WP Rocket מציעים לבדוק תקלות תצוגה כשמוסיפים ?nowprocket לסוף הכתובת, וכך העמוד מוצג בלי האופטימיזציות שלהם. אם עם התוספת השקופיות מלאות ובלעדיה הן ריקות, אחת האופטימיזציות אשמה.
• כדי למצוא איזו, התיעוד שלהם ממליץ לכבות את האפשרויות בלשוניות File Optimization ו-Media, לבדוק בחלון גלישה בסתר בלי להיות מחובר, ולהדליק אותן חזרה אחת אחרי השנייה.

ויש שתי דרכים לתקן:

• לכבות את LazyLoad for CSS background images, כמו במקרה שתיארתי.
• או להשאיר אותה פעילה ולהחריג את האלמנט הבעייתי דרך התיבה Excluded images or iframes, עם שם קובץ, קובץ CSS או מחלקת CSS. התיעוד של WP Rocket ממליץ על ההחרגה בדיוק בשני מצבים: כשהתמונה או הפריסה נשברות בגלל הטעינה העצלה, וכשתמונות הרקע נמצאות בחלק העליון וצריכות להיטען מיד.

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

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

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

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

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

1. לפני: מריצים PageSpeed Insights על כמה עמודים מייצגים, במובייל ובדסקטופ, ושומרים צילום מסך.
2. שינוי אחד: מחריגים את התמונה הראשית, או מכבים את האפשרות לתמונות רקע, או מוסיפים מידות. לא הכול ביחד.
3. אחרי: מנקים מטמון, מריצים שוב, ובודקים גם בעין שכל התמונות והשקופיות מופיעות.

כדאי גם להבין מה רואים בדוח. לפי התיעוד של PageSpeed Insights, נתוני השטח מגיעים ממשתמשים אמיתיים ומכסים את 28 הימים האחרונים, ולכן הם מתעדכנים בהדרגה. נתוני המעבדה מגיעים מ-Lighthouse, בדיקה אחת בסביבה מדומה, והם משתנים מיד. נתוני המעבדה מראים אם התיקון עשה משהו, ונתוני השטח מראים אם המבקרים הרגישו את זה.

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

למעקב לאורך זמן יש את דוח Core Web Vitals ב-Search Console. הוא מבוסס על נתונים של משתמשים אמיתיים, מקבץ כתובות דומות לקבוצות ומראה אילו מהן טובות, טעונות שיפור או גרועות. אחרי תיקון אפשר לבקש ממנו לאמת את התיקון, ותהליך המעקב נמשך 28 ימים.

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

• התמונה הראשית לא נטענת בעצלות, אבל ה-LCP עדיין איטי. כנראה שהבעיה בשרת, בגודל התמונה, בקבצים שחוסמים את הציור, או בכך שהתמונות לא מוגשות משרת קרוב לגולש (במדריך CDN מה זה הסברתי מתי זה משנה). בכל מקרה, זו כבר לא בעיה של הטעינה העצלה עצמה.
• חלקים מהעמוד נעלמים ואתה לא מצליח לבודד איזו אופטימיזציה אחראית. אם הבעיה היא ב-CSS וב-JavaScript עצמם ולא בתמונות, זה כבר נושא נפרד, שכתבתי עליו במדריך אופטימיזציה לקוד האתר.
• הקרוסלה או הסליידר נבנו בקוד מותאם, וההחרגה ב-WP Rocket לא פותרת.
• האתר הוא חנות, ותמונות מוצר שלא נטענות פוגעות ישירות במכירות.

ולפני כל שינוי בקוד של אתר חי, צריך גיבוי מלא.