אופטימיזציה מקיפה של תמונות עבור 1С-ביטריקס: WebP, AVIF, srcset

אופטימיזציה של תמונות ב-Bitrix: היכן האתר מאבד מהירות

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

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

גרוע מכך, בעת עדכון התמונה התצוגות המקדימות הישנות לא תמיד נבנות מחדש — בדף נשאר קובץ מיושן, והחדש שוכב כמשקל מת.

השלישי — פורמטים. אפילו JPEG ו-PNG שנחתכו כראוי מפסידים לפורמטים מודרניים במשקל באותה איכות חזותית, ובלי המאפיין srcset הדפדפן של המכשיר הנייד מושך את גרסת הדסקטופ של התמונה.

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

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

מה נותנת אופטימיזציה מקיפה של תמונות

האפקט נמדד לא "בעין", אלא לפי מדדים שגם מנוע החיפוש וגם המבקר רואים. אופטימיזציה מקיפה של תמונות ב-1С-Битрикс היא לא אריזה מחדש חד-פעמית של קבצים, אלא שילוב של שלושה רבדים: פורמטים מודרניים, מסירה אדפטיבית וקישור נכון. נבחן מה בדיוק משתנה בכל אחד מהם.

משקל העמוד ומהירות הרינדור

הרווח העיקרי מגיע מהמרת גרפיקה רסטרית ל-WebP ו-AVIF תוך שמירת המקור כגיבוי. עבור גלריה או קטלוג טיפוסיים זה מקטין את משקל חלק המדיה פי 2–4 ללא אובדן איכות נראה לעין — בתנאי שההמרה מתבצעת בצד השרת, ולא "תוך כדי" בכל בקשה.

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

איך זה משתקף בנטישות ובהמרות

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

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

בנפרד כדאי לציין את הקישור: כותרות נכונות וגרסאות לקבצים מאפשרות להגיש ביקורים חוזרים כמעט באופן מיידי, בלי להעמיס על השרת ביצירה מחדש. אנחנו עובדים על שילוב של 1С-Битрикс ומנגנונים מובנים של הפלטפורמה, ולכן השינויים לא שוברים תבניות קיימות ולא דורשים בנייה מחדש של הקטלוג ידנית.

פורמטים ומצבי הגשה: WebP, AVIF, srcset

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

WebP כיום מגישים כל הדפדפנים הרלוונטיים, AVIF נותן משקל קטן noticeably פחות בתמונות, אך מקודד לאט יותר — סביר להחזיק אותו כמועמד שני ב-<picture> ולהציב אותו דרך <source type>, ולהשאיר את WebP ואת JPEG המקורי כגיבוי.

<cite>ביטריקס</cite> יודע לעבוד עם שני הפורמטים, אך ללא הגדרה מפורשת מגיש את מה שנמצא בתיקיית ההעלאה — כלומר את JPEG המקורי.

תמונות מסתגלות נבנות סביב srcset ו-sizes: הדפדפן בוחר בעצמו את הקובץ לפי רוחב החלון וצפיפות המסך, ולכן אין צורך להגיש לנייד את אותה תמונה כמו לצג.

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

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

כיצד אנו מיישמים אופטימיזציה: שלבי העבודה

העבודה מתבצעת באיטרציות: תחילה מודדים, לאחר מכן משנים, ואז בודקים על תעבורה אמיתית. להלן — הסדר הטיפוסי שאנו עוברים בפרויקטים עם 1С-Битрикс.

1. ביקורת תמונות. אוספים מלאי: כמה קבצים בספריית המדיה, אילו פורמטים ומשקל שולטים, היכן התמונות מוגשות בגודל המקורי במקום אדפטיבי. בוחנים כיצד בנויה יצירת התצוגות המקדימות ברכיבים ובתבניות, היכן הפלט מתבצע ישירות ממאפייני בלוק המידע בעקיפין למטפלים.
2. מדידת קו הבסיס. קובעים מדדים לפני השינויים: משקל העמוד, זמן הטעינה בחיבור סלולרי, שיעור התמונות ללא פורמטים מודרניים. ללא נקודת ייחוס זו לא ניתן להוכיח את האפקט לאחר מכן.
3. הגדרת הצינור. מפעילים המרה ל-WebP ו-AVIF, מגדירים הגשה דרך srcset עם מספר רזולוציות, מתקנים תבניות רכיבים כך שהפלט יעבור דרך מטפל אחיד ולא בקריאות מפוזרות.
4. הטמעה בסביבת הייצור. פורסים בשלבים: תחילה על מדור עם תעבורה גבוהה, לאחר מכן על השאר. את הפורמטים הישנים משאירים כאפשרות גיבוי לדפדפנים ללא תמיכה.
5. בדיקת התוצאה. משווים מדדים לקו הבסיס, בודקים את תקינות ההגשה במכשירים שונים, מוודאים שהמטמון וה-CDN אינם מגישים קבצים מיושנים.
6. נהלים וניטור. מעבירים כללי עבודה עם תמונות לעורכים, מגדירים בדיקה אוטומטית של העלאות חדשות — כדי שכעבור חצי שנה מנהל התוכן לא יאפס את כל האופטימיזציה.

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

מה הלקוח מקבל לידיו לאחר סיום העבודה

העבודה אינה מסתיימת ב"הדלקנו WebP ו-AVIF" — היא מסתיימת בהעברת ערכה שלמה, שלפיה הצוות שלכם יוכל להמשיך לתפקד בלעדינו. כל מה ששונה בפרודקשן מתועד בקונפיגורציות ובנהלים, ולא בהתכתבות.

• קונפיגורציות: כללי המרה ל-WebP ול-AVIF, סטים של רוחבים ל-srcset, ספי איכות, התנהגות בעת הגשת המקור לדפדפן ללא תמיכה בפורמטים מודרניים.
• תרשים צינור העיבוד: היכן בדיוק מתרחשת הדחיסה מחדש — בעת העלאה לספריית המדיה, בעת ריסייז על ידי קומפוננטה או במשימה מרוכזת על ארכיון שכבר נצבר — עם נקודות כשל וסדר הרצה חוזרת.
• מדיניות מטמון: זמן חיים של וריאנטים שנוצרו, ביטול תוקף בעת החלפת המקור, כללים ל-CDN ולפרוקסי הפוך, כדי שלאחר עדכון התמונה לא יוגש קובץ ישן.
• נוהל ניקוי: כללי lifecycle למחיקת וריאנטים יתומים והגבלת גידול האחסון, כדי שהספרייה לא תתפח ללא שליטה.
• תיעוד: מה והיכן מוגדר, כיצד להוסיף רוחב או פורמט חדש, כיצד לבצע רולבק לשינוי אם המדדים ירדו.
• דוח לפני/אחרי: מדידות LCP ומשקל עמודים על מדגם מייצג לפני העבודה ואחריה, עם ציון אילו תבניות הרוויחו הכי הרבה.
• מפת כיסוי: רשימת תבניות ומדורים שבהם הגשה אדפטיבית כבר עובדת, והיכן נותרו חריגים — עם לוחות זמנים וסיבה.

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

מקרה בוחן: כיצד האצנו את הקטלוג של חנות אינטרנטית

הלקוח — חנות אינטרנטית על 1С-Битрикс עם קטלוג של כמה אלפי פריטי סחורה. כל כרטיס משך קובצי JPEG מקוריים ישירות מתיקיית ההעלאות: אותה תמונה בדיוק הוגשה בגודל מלא גם ברשימה, גם בכרטיס וגם בבלוק "דומים".

עמוד הקטגוריה שקל כמעט 9 MB, והרינדור הראשון במובייל התארך ל-6-7 שניות — במצב כזה חלק מהקונים עזבו בלי להמתין לקטלוג.

מה עשינו

פירקנו את הצגת התמונות ברמת תבנית הרכיבים וחיברנו את מנגנון השינוי גודל המובנה עם יצירת WebP ו-AVIF: הדפדפן מקבל פורמט מודרני, וה-JPEG המקורי נשאר כגיבוי ללקוחות ישנים. לכל כרטיס רשמנו srcset עם כמה רוחבים, כדי שהטלפון לא יוריד את גרסת התמונה למחשב. הגדרנו טעינה נדחית לכל מה שמתחת למסך הראשון, וטעינה בעדיפות גבוהה לתמונת המוצר הראשית.

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

מדדים לפני ואחרי

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

אם יש לכם קטלוג על Битрикс והכרטיסים נטענים יותר משתי שניות — תארו את המשימה, נחזור עם הערכה ותוכנית עבודה לתמונות.

במה שונה המרה על־המוטס מיצירה מראש?

המרה על־המוטס מיירטת בקשה למקור דרך מטפל ומחזירה גרסה דחוסה ברגע הפנייה: הקובץ המקורי נשאר על הדיסק, ו־WebP או AVIF נבנים למידה ולצפיפות מסך מסוימות. היתרון — אין צורך לדעת מראש אילו רוחבים יידרשו, והאחסון אינו גדל.

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

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

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

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

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

אנו בוחנים את מבנה העמודים, נפח המדיה ומלאי המשאבים, ולאחר מכן קובעים את המצב ואת כללי המטמון — כך אופטימיזציה של תמונות ב־Битрикс אינה הופכת למקור קבוע להאטות.

ספקות טכניים נפוצים בנוגע לאופטימיזציה

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

האם האיכות תיפגע?

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

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

מה עם דפדפנים ישנים ותאימות?

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

מהם הסיכונים וכיצד אנו מבצעים rollback?

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

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

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

בואו נדון במשימת אופטימיזציה של תמונות

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

• הפורמט והמשקל הנוכחיים של התמונות: אילו סוגי קבצים נמצאים בספריית המדיה, גודל ממוצע ומקסימלי, והאם קיימים קבצי מקור ברזולוציה גבוהה.
• כיצד נוצרות תצוגות מקדימות: מנגנונים סטנדרטיים של Битрикс, מודולים של צד שלישי או חיתוך ידני — מכך תלוי היכן לשלב את ההמרה.
• נקודות הפלט: תבניות רכיבים, בלוקי מידע, סליידרים, כרטיסי מוצרים — היכן בדיוק התמונה נכנסת לסימון והאם ניתן למסור אותה דרך srcset.
• דרישות לאיכות: מידת דחיסה מותרת, עדיפות לדיוק חזותי או למהירות טעינה, האם נדרש AVIF או שמספיק WebP.
• תשתית: תצורת שרת האינטרנט, קיום CDN, מטמון, גישה לממיר בצד השרת.
• מגבלות על הרשאות ותקנון: חלונות עבודה, סביבת בדיקה, סדר העלאה לפרודקשן.

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