טעינה נדחית של תמונות ב-Bitrix: היכן המהירות נשברת
טעינה נדחית של תמונות ב-Bitrix לרוב אינה עובדת דווקא במקום שבו היא נחוצה ביותר — בקטלוגים ובגלריות. התבנית מציגה את כל כרטיסי המוצרים בבת אחת, הדפדפן מקבל סימון עם מאות <img> ומתחיל למשוך אותם במקביל למסך הראשון.
בסופו של דבר מהירות טעינת העמוד נקבעת לא לפי המשקל של החלק הנראה, אלא לפי הנפח הכולל של כל הגלריה, כולל אותם 40 כרטיסים שהמשתמש עוד לא גלל אליהם.
זה כואב במיוחד במובייל: הערוץ צר, והתמונות הכבדות של הקטלוג מתחרות על רוחב הפס עם משאבים קריטיים — עיצוב, גופנים, סקריפטים של הממשק. הזמן עד למסך הראשון גדל, המשתמש רואה בלוקים אפורים ריקים במקום מוצרים ועוזב לפני שהתמונות נטענות.
בנוסף, הקבצים עצמם לרוב אינם מותאמים: מקוריים מ-1С או ייצוא של ספק נמסרים ברזולוציה מלאה, בלי גדלים אדפטיביים לרשת הקטלוג.
נקודת כשל טיפוסית שנייה — טעינה דינמית. קטלוג עם "הצג עוד" או גלילה אינסופית מוסיף כרטיסים חדשים דרך AJAX, אבל מאפייני הטעינה הנדחית לא מיושמים עליהם: הסקריפט מכניס <img> מוכן עם כתובת ישירה, והדפדפן מיד מתחיל להוריד את כל הקבצים החדשים. עמוד שבהתחלה נטען מהר מאבד את היתרון בכל שלב של עימוד.
השכבה השלישית — מטמון ודחיסה. אפילו טעינה נדחית מוגדרת היטב לא תציל אם השרת מוסר תמונות בלי פורמטים מודרניים ובלי כותרות מטמון נכונות: הדפדפן מוריד מחדש את אותו הדבר בכל מעבר בקטלוג. כאן חשוב שטעינה עצלה תשתלב עם גרסאות אדפטיביות לרוחב המסך ועם מדיניות מטמון בצד מסירת הסטטיקה.
מפרקים איך זה נסגר: היכן מספיק תיקון בתבנית הרכיב, היכן נדרש מאפיין טעינה נייטיבי, והיכן — בנייה מחדש של הצגת הגלריה וטיפול בכרטיסים שנוספים דינמית.
מה נותן טעינה נדחית: השפעות מדידות
טעינה נדחית משנה לא את "תחושת האתר", אלא כמויות מדידות קונקרטיות. נבחן מה בדיוק משתנה לאחר ההטמעה וכיצד לבדוק זאת.
ההשפעה הראשונה — מהירות רינדור המסך הראשון. הדפדפן מפסיק למשוך את כל תמונות הקטלוג בבת אחת ומבקש רק את אלו שנכנסות לאזור הנראה. בעמודים עם רשימות מוצרים ארוכות או גלריות, הזמן עד להופעת התוכן מתקצר פי כמה, ומדד Largest Contentful Paint עובר לאזור הירוק. השיפור מורגש במיוחד במקומות שבהם קודם לכן היו כמה עשרות תמונות למסך אחד.
ההשפעה השנייה — הפחתת העומס על השרת והערוץ. בקשות לקבצים פוחתות, נפח הנתונים הנמסרים בביקור הראשון יורד פי כמה, ופיקי עומס בעת סריקת הקטלוג על ידי רובוט מפסיקים להיתקל במגבלות. זו לא "אופטימיזציה" מופשטת, אלא צמצום ישיר של מספר הפניות לדיסק ורוחב הפס לכל ביקור.
ההשפעה השלישית — תוצאות החיפוש במובייל. עבור מכשירים ניידים טעינה נדחית פועלת בצורה חדה יותר: נחסך התעבורה של המשתמש, העמוד הופך לאינטראקטיבי מהר יותר, ומדדי ההתנהגות — עומק הצפייה והזמן בעמוד — עולים. מנועי החיפוש מעריכים את הגרסה הניידת לפי המהירות בפועל, וכאן הרווח מתגלגל למיקומים.
ההשפעה הרביעית — נעלם סוג שלם של כשלים. עמודים כבדים מפסיקים ליפול בגלל פסק זמן בערוץ חלש, תמונות לא "נופלות" בעת ניתוק החיבור, והשרת לא חוטף עומס יתר ברגע פרסום מנה חדשה של מוצרים. אלו הן התקלות שתוקנו קודם לכן באופן ידני לאחר תלונות.
ניתן לבדוק את ההשפעה לפני ואחרי: מודדים את זמן הרינדור, מספר הבקשות ונפח התעבורה בעמוד קטלוג טיפוסי. ההבדל מתועד בדוח — אתם רואים מה בדיוק השתנה, ולא מאמינים על סמך מילה.
דרכי מימוש: תכונה מקורית, סקריפט, מודול
טעינה נדחית ב-1С-Битрикс נפתרת בשלוש דרכים, והבחירה ביניהן היא בחירה בין היקף השינויים בתבנית לבין השליטה בהתנהגות.
התכונה המקורית loading="lazy" פועלת ברמת הדפדפן: די להציב אותה בתבנית הרכיב או בהגדרות פלט המאפיין של בלוק המידע, והתמונות שמתחת למסך הראשון מפסיקות להיטען מיד. סקריפט מעניק שליטה על סף ההפעלה ועל החלפת המקור, ומודול — מעטפת מוכנה עם מטמון וסטים אדפטיביים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
תכונה מקורית loading="lazy" |
תבניות טיפוסיות, גלריות, קטלוג; מינימום שינויים | אין שליטה על הסף; חלק מהדפדפנים הישנים מתעלמים מהתכונה |
| סקריפט טעינה נדחית | קידוד מורכב, סליידרים, תמונות רקע | דורש שינויים ב-JS של התבנית ובדיקה כשהסקריפט מושבת |
| מודול Битрикс | תבניות רבות וסוגי תוכן רבים, נדרש תקן אחיד | תלות בעדכוני המודול, התאמה למבנה האתר |
תאימות דפדפנים — קריטריון מרכזי: טעינה נדחית מקורית נתמכת בכל המנועים העדכניים, אך עבור ישנים נדרש מסלול חלופי. הסקריפט סוגר את הפער הזה, אולם כשהסקריפט מושבת התמונות חייבות להישאר גלויות — אחרת העמוד מאבד תוכן. המודול פותר זאת ברמת ההגדרות, אך מוסיף שכבת הפשטה בין התבנית לפלט התמונה.
בפועל גם שילוב עובד: תכונה מקורית כבסיס, סקריפט — ממוקד לסליידרים ולרקעים, מודול — כשהתבניות נמנות בעשרות ונדרש תקנון אחיד. אנו מנתחים את מבנה התבניות ובוחרים אפשרות בהתאם לו, ולא להפך.
סדר יישום טעינה מדורגת באתר
היישום מתחיל בביקורת של הסימון הנוכחי: בודקים כיצד מוצגות תמונות בתבניות הרכיבים, אילו מאפיינים כבר הוגדרו, היכן תמונות נטענות במסך הראשון ואסור שייפלו תחת טעינה מדורגת. בשלב זה מתעדים נקודות שבהן החלפת מאפיינים תשבור את הפריסה או את התנהגות הסליידרים, הגלריות והקרוסלות העצלות.
- ביקורת סימון ותבניות. עוברים על רכיבי הקטלוג, דפי הפרטים, הבאנרים ובלוקי המידע, אוספים רשימה של מקומות הצגת התמונות ומסמנים את אלה שנראים מיד עם הפתיחה.
- הגדרת התבנית. בתבניות הרכיבים ובאזורים המשותפים הכלולים מגדירים מאפייני טעינה מדורגת עבור תמונות מחוץ למסך הראשון, קובעים מידות מיכלים כדי שלא יהיו קפיצות בפריסה בעת הטעינה.
- חיבור המנגנון. מגדירים את אמצעי הליבה התקניים ומחברים מטפל שטוען את התמונה עם התקרבות לאזור התצוגה, עם מרווח מרחק עד להופעתה בפריים.
- חריגים ועדיפויות. מחוץ לטעינה מדורגת מוציאים את הלוגו, הבאנר הראשי ותמונות המסך הראשון — הם חייבים להיטען מיד, אחרת הדף "מהבהב" ומאבד במהירות הרינדור.
- בדיקות במכשירים. בודקים את ההתנהגות בניידים, בטאבלטים ובשולחני, בדפדפנים שונים, בחיבור איטי ועם JavaScript מושבת — התוכן חייב להישאר נגיש.
- מדידות לפני ואחרי. משווים את נפח הנתונים הנטענים ואת הזמן עד לרינדור המסך הראשון, מתעדים את התוצאה לפי תבניות מפתח.
- נהלי תמיכה. מוסרים מסמך: אילו תבניות הושפעו, כיצד להוסיף תמונות חדשות, מה לבדוק בעת הצגת בלוקים חדשים, כדי שטעינה מדורגת לא תכובה בעריכות אקראיות.
לאחר מסירת הנהלים, דפים ובלוקים חדשים מוצגים לפי הכללים שכבר הוגדרו — צוות התמיכה לא שובר את המנגנון בעת עריכות תוכן, ומהירות הטעינה נשארת יציבה.
מדיניות ותצורה: מה מקבעים בתבניות
טעינה דחויה אינה קיימת בנפרד מהתבנית: אם לא מקבעים את הסימון והמאפיינים בקוד, הרי שעיצוב מחדש ראשון או כרטיס קטלוג חדש יחזירו תגי <img> כבדים למסך הראשון. לכן אנו מעבירים את ההסכמות מ"על הנייר" לארטיפקטים שרואה גם המפתח וגם מנהל התוכן.
מה מקבעים בתבניות הרכיבים
התיקונים מתבצעים בתבניות הרכיבים, ולא בליבה — עדכוני הפלטפורמה אינם מוחקים אותם. עבור כל מקום הצגת תמונה מגדירים התנהגות באופן מפורש: תמונת המסך הראשון נטענת מיד, כל מה שמתחת — עם הופעתו באזור התצוגה, עם מידות שמורות מראש, כדי שהפריסה לא "תקפוץ".
- תבניות רכיבים ששונו: מאפייני טעינה דחויה, מידות מיכל, סטים לרוחבי מסך שונים.
- כללים לספריית המדיה: אילו מידות נוצרות בעת ההעלאה, אילו פורמטים נחשבים עיקריים, מה עושים עם קבצי המקור.
- הגדרות מטמון: זמן חיים של מטמון התבניות והרכיבים, איפוס בעת שינוי אלמנטים משויכים, כדי שעריכת תמונה תגיע מיד לעמוד.
- מדיניות דחיסת תמונות: דרגת הדחיסה והפורמטים בפלט, אחידים לכל הקטלוג והתוכן.
- סכימת עדיפויות: מה נטען ראשון, מה נדחה, מה נטען רק בעת גלילה עד הבלוק.
- הנחיות למנהלי תוכן: כיצד להעלות תמונות כדי שהכללים לא יישברו בשלב האכלוס.
כיצד זה קשור למטמון
טעינה דחויה ומטמון מתנגשים אם מגדירים אותם בנפרד: מטמון אגרסיבי מחזיר סימון ישן, וניקוי "ליתר ביטחון" הורג את הרווח במהירות. אנו מגדירים איפוס מתויג — בעת שינוי אלמנט מתבטל רק המטמון המשויך, שאר העמודים נשארים חמים. כך מנהל התוכן משנה תמונה ורואה מיד את התוצאה, והמבקר אינו ממתין לבנייה מחדש של העמוד.
היכן אנו מיישמים זאת
את הכללים אנו מתארים עבור הפלטפורמה 1С-Битрикс והמהדורה שלה Битрикс24, תוך התחשבות באופן שבו הפרויקט בנוי — בלוקי מידע וספריית מדיה. התוצאה — סט תצורות והנחיות שלפיהם צוות הלקוח יכול להמשיך להוסיף עמודים בלי לחזור לשאלת המהירות בכל פעם.
מקרה בוחן: האצת קטלוג של חנות מקוונת
קטלוג עם 800+ פריטים, עם מסננים ועימוד, טען את העמוד הראשון תוך 6-7 שניות בחיבור סלולרי ממוצע. הבעיה לא הייתה בשרת: העמוד החזיר את התגיות במהירות, אבל הדפדפן משך באופן סינכרוני את כל תצוגות המוצרים המקדימות, כולל אלו שהיו רחוק מחוץ למסך.
בנייד זה יצר את התרחיש הגרוע ביותר — המשתמש ראה מסך לבן, לא המתין ועזב, ובאנליטיקה זה שקע כנטישות שאי אפשר להבדיל מ"לא מצאתי את מה שחיפשתי".
מה נמדד לפני ההטמעה
נלקחו מדדי בסיס בשלושה תרחישים: כניסה קרה לקטלוג, מעבר לפי מסנן וגלילה בעימוד. תועד זמן עד להופעת התוכן הראשון, זמן עד לרינדור מלא ושיעור ההפעלות שהסתיימו לפני הגלילה הראשונה.
בנפרד חושב משקל העמוד הראשון — הוא היה גדול פי כמה ממה שנדרש לאזור הנראה, מכיוון שהטעינה בוצעה בזרם אחד יחד עם התגיות.
מה שינו
הוטמעה טעינה נדחית של תמונות ברמת תבנית רכיב הקטלוג: תצוגות מקדימות מחוץ למסך מקבלות מקור רק כאשר הן מתקרבות לאזור הנראה, עם מרווח של מסך-שניים כדי שלא יהיו קפיצות בגלילה מהירה.
עבור דפדפנים ללא תמיכה מובנית הושאר מנגנון חלופי באמצעות מעקב אחר מיקום האלמנט, והתמונות עצמן הומרו לפורמטים מודרניים עם אפשרות חלופית. במקביל קובעו מידות הקונטיינרים כדי שהתגיות לא "יקפצו" בעת הצבת התמונות.
מדדים לאחר
התוכן הראשון בנייד החל להופיע פי 2.5-3 מהר יותר, הרינדור המלא של העמוד הראשון נכנס לטווח שבו המשתמש לא מספיק לעזוב. משקל הטעינה הראשונית הצטמצם בערך פי שלושה — נטען רק מה שבאמת נראה.
שיעור הנטישות לפני הגלילה הראשונה ירד באופן ניכר, ועומק הצפייה בקטלוג עלה: אנשים החלו לגלול לעמוד השני והשלישי, מה שכמעט לא קרה קודם לכן.
את הפרויקט הוביל מהנדס האינטגרציות שלנו 1С-Битрикс — השינויים נגעו רק לתבנית התצוגה ולא נגעו בלוגיקת שליפת המוצרים, ולכן עדכוני הקטלוג והמחירים המשיכו להסתנכרן כסדרם.
במה שונה טעינה עצלה מקורית מטעינה מבוססת סקריפט?
המנגנון העצל המקורי הוא המאפיין loading="lazy" בתג <img>, שמעובד על ידי הדפדפן עצמו. הוא אינו דורש ספריות, אינו חוסם את התהליך הראשי ואינו מוסיף בקשות לאתחול: המנוע עצמו מחליט מתי האלמנט מתקרב לאזור התצוגה וטוען את המשאב.
הגרסה המבוססת סקריפט היא ספרייה חיצונית או קוד עצמאי המבוסס על מצפי הצטלבות, שתופס את הטעינה באמצעות החלפת src ב-data-src ומפעיל את ההצבה ידנית.
ההבדל בהתנהגות מתגלה בתרחישי קצה. המנגנון המקורי פועל כראוי כאשר JavaScript מושבת, בעת הדפסת העמוד ובמצב קריאה — התמונות עדיין יוצגו. המבוסס סקריפט תלוי בהרצת הקוד: אם הסקריפט לא נטען, קרס בשגיאה או נחסם על ידי מדיניות אבטחה, המשתמש יראה מסגרות ריקות.
לעומת זאת, הסקריפט מספק ספי הפעלה ניתנים לשליטה, טעינה בלחיצה, ערכות אדפטיביות למסכים שונים ואנימציית הופעה — דברים שהמאפיין המקורי אינו יודע לעשות.
התמיכה בדפדפנים במנגנון המקורי רחבה, אך אינה מוחלטת: מנועים ישנים מתעלמים מהמאפיין וטוענים הכל מיד, מה שבטוח אך אינו מניב רווח. הגרסה המבוססת סקריפט פועלת באופן זהה בכל מקום שבו JavaScript מורץ — זה היתרון העיקרי שלה במאגר מכשירים מיושן.
עבור אינדוקס ההבדל מהותי. רובוטי חיפוש מריצים JavaScript לא תמיד ולא באופן מיידי, וחלק מהזוחלים של רשתות חברתיות כלל אינם מפעילים אותו. בגישה מבוססת סקריפט בקוד המקור נמצא data-src ולא src — הרובוט עלול שלא לראות את כתובת התמונה ולא לקשר אותה לעמוד.
המאפיין המקורי משאיר src אמיתי בסימון, ולכן התמונה מאונדקסת כרגיל, והדחייה נוגעת רק לרגע הטעינה. עבור גלריות, קטלוגים וכרטיסי מוצר הדבר משפיע ישירות על הופעה בחיפוש לפי תמונות.
מסקנה מעשית: המנגנון המקורי הוא שכבה בסיסית לתמונות תוכן, המבוסס סקריפט — במקומות שבהם נדרשים ספים, אדפטיביות ואנימציה. סכימה משולבת עונה על שתי הדרישות: הסימון נשאר קריא לרובוטים, וההתנהגות — ניתנת לשליטה.
ספקות טכניים נפוצים בעת ההטמעה
טעינה מדורגת ב-1С-Битрикс כמעט תמיד מוטמעת מעל תבנית קיימת שכבר פועלת, ולכן השאלות הראשונות של הלקוח הן לא "איך מפעילים", אלא "מה יישבר". להלן ניתוח של הספקות הטכניים שעולים לרוב בשלב ההערכה.
האם זה תואם לתבנית ולרכיבים הנוכחיים?
כן, אם התכונות loading="lazy" ו-decoding="async" מתווספות לתגי <img> ברמת הפלט, ולא על ידי עריכה ידנית של הקוד.
ב-Битрикс זה נעשה באמצעות עיבוד תוצאות הרכיבים, תבניות החדשות והקטלוג: הסקריפט עובר על ה-HTML המוכן ומוסיף את התכונות מבלי לשנות את מבנה ה-DOM. סליידרים מותאמים אישית, גלריות וקרוסלות מדורגות מוחרגים מהעיבוד — יש להם לוגיקת טעינה משלהם, והתערבות שוברת את המעבר.
המסך הראשון (באנר, לוגו, תמונת המוצר המרכזית) נשאר בכוח עם loading="eager", אחרת זמן הרינדור של התוכן הראשי גדל.
האם תוצאות החיפוש ייפגעו?
לא, בתנאי שהסימון תקין. רובוטי החיפוש מריצים JavaScript וטוענים תמונות מדורגות בזמן סריקה, והתכונה loading עבורם היא אות תקני, ולא הסתרת תוכן. הסיכון מתעורר בתרחיש אחד: אם התמונות מוזרקות על ידי סקריפט ללא src ב-HTML המקורי, הרובוט עלול שלא לראות אותן בסימון.
לכן אנחנו משאירים src אמיתי ומוסיפים רק את תכונת הטעינה המדורגת — התמונה נשארת במסמך, ורק רגע בקשת הקובץ משתנה.
כיצד מבוצעת החזרה לאחור ומה עם מטמון הדפדפן?
התיקונים מבוצעים כמודול או מטפל נפרד, ולא מפוזרים across התבניות, — החזרה לאחור מסתכמת בניתוק חיבור אחד, ללא שחזור קבצים מגיבוי. מטמון הדפדפן אינו מפריע לכך: התכונות נמסרות ב-HTML, ולא בסטטיקה, ולכן לאחר איפוס המטמון המרוכב של Битрикс השינויים נראים מיד. אם נעשה שימוש במצב מרוכב, מחממים את המטמון מחדש — אחרת חלק מהדפים ימסרו סימון ישן.
נדון במשימה שלך להאצת האתר
תאר את המצב הנוכחי: איזה אזור מאט, כמה תמונות יש בעמוד, כיצד בנויה הפריסה ומאיפה מגיעות התמונות — מספריית המדיה, מאינפובלוקים או מאחסון חיצוני. זה מספיק כדי לחזור עם הערכת עבודה ותוכנית ליישום טעינה עצלה של תמונות ב-Bitrix, בלי מילים כלליות ועצות "אוניברסאליות".
מה ננתח ונכלול בתוכנית:
- פרופיל טעינת העמוד הנוכחי: אילו תמונות נטענות מיד, כמה הן, איזה חלק מהן נופל למסך הראשון;
- סכימת החיבור של הטעינה העצלה — דרך הגדרות הרכיבים, התבנית או סקריפט נפרד, עם אפשרות חלופית לדפדפנים ישנים;
- התנהגות כאשר JavaScript מושבת ועבור רובוטים של מנועי חיפוש, כדי שהתמונות יישארו באינדקס;
- יצירה וקישור (caching) של עותקים מוקטנים, כדי שההגשה לא תיתקע בגודל המקור;
- תאימות לתבניות הנוכחיות, לסליידרים, לגלריות ולמודולי הקישור;
- סדר ההפצה: תחילה קו בדיקה, לאחר מכן בהדרגה לאתר החי עם אפשרות לחזרה מהירה;
- תקנון תמיכה באתר לאחר היישום — מי וכיצד עוקב אחר תמונות והגדרות חדשות.
עבור כל סעיף ניתן הערכה ברורה: מה עושים, באיזה סדר, מה בודקים בפלט. תאר את המשימה — נחזור עם תוכנית ולוחות זמנים.