הכנת תמונות 1C Bitrix: היכן הקטלוג נשבר
לרוב הקטלוג נשבר לא בשלב העימוד, אלא בכניסה — כאשר הכנת תמונות עבור 1C Bitrix נעשית "איך שיצא": הייצוא מ-1С מספק קישורים לקבצי המקור, המנהל מעלה את השאר ידנית, ובמסד הנתונים מוצאים שלוש קבוצות שונות של קבצים עבור מוצר אחד.
לאחר מכן המערכת פשוט מנגנת את מה שקיבלה: התצוגה המקדימה לא נחתכת, כי קובץ המקור קטן מהגודל הנדרש, וחלק מהקשרים הולכים לאיבוד בייבוא חוזר, כאשר ה-XML-ID של המוצר משתנה יחד עם בנייה מחדש של הפריט.
תצוגות מקדימות שבורות של מוצרים הן הסימפטום הבולט ביותר, אך לא היקר ביותר. גרוע מכך הוא מצב שבו התמונה קיימת פיזית, אך הקשר "קובץ — פריט קטלוג" אבד: הכרטיס נפתח עם גלריה ריקה, החיפוש והסינון לפי מאפיינים עובדים, וההמרה לסל נופלת סתם כך.
הסיבה בדרך כלל היא שהעלאת תמונות לקטלוג נעשית בעקיפין למנגנון התקני — דרך כתיבה ישירה לאחסון או דרך תיקיית ביניים שאותה מנקה לאחר מכן תחזוקה שגרתית.
הכשל הטיפוסי השלישי — קבצים מנופחים. התמונות מגיעות מהטלפון או מהספק ברזולוציה מקורית, ללא דחיסה וחיתוך; בקטלוג עם כמה אלפי פריטים זה הופך לעשרות גיגה-בייט, שמגובים כל לילה ומאטים את הגשת הדפים.
אופטימיזציה של תמונות הקטלוג כאן אינה עניין של "להקטין לפי העין", אלא של קו ייצור צפוי מראש: פורמט אחיד, בקרת גודל ומשקל, ויצירה אוטומטית של כל התצוגות המקדימות הנדרשות בעת ההעלאה.
מפרקים כיצד זה נסגר: מכללי שמות וקשירת קבצים ועד לתקנון בנייה מחדש של תצוגות מקדימות בעת עדכון הקטלוג.
מה נותנת הכנה נכונה של תמונות לקטלוג
הכנה נכונה של תמונות עבור 1C-Bitrix היא לא "לכווץ תמונות", אלא להביא את כל מערך התמונות של הקטלוג לתקן הנדסי אחיד: גודל, פורמט, משקל, סכימת שמות, קישור להצעות מסחריות.
כאשר הקטלוג מתמלא דרך החלפה עם 1С, התמונות נכנסות לאינפובלוק כמו שהן — ממצלמה, מייצוא של ספק, ממרקטפלייס. בסופו של דבר בעמוד מוצר אחד מתקיימים זה לצד זה קבצים של כמה מגה-בייט ותמונות ממוזערות, והשרת מגיש אותם ללא התאמה למסך.
מכאן שלוש השלכות מדידות. הראשונה — מהירות התצוגה של הקטלוג: עמוד רשימה עם מאה פריטים גורר אחריו מאה קבצים בגודל מלא, וזמן הרינדור גדל באופן ליניארי ממשקלם הכולל. השנייה — משקל עמוד המוצר: אם הגלריה לא מותאמת, התוכן העיקרי נטען בשניות, והמשתמש רואה מסגרות ריקות במקום תמונות.
השלישית — המרת כרטיסים: לפי מדידות שיעור הנטישה בטראפיק מובייל עוזב לפני שהתמונה נטענת, והמוצר פשוט לא מגיע לקונה.
אנחנו בונים את הכנת התמונות 1C Bitrix כחלק מההחלפה, ולא כתיקון ידני לאחר הייצוא. בקלט — כללים: למה אנחנו ממירים, לאיזה גודל חותכים, אילו תצוגות מקדימות מייצרים לכרטיס, לרשימה ולגרסת המובייל. בהמשך — עיבוד אוטומטי בעת הייבוא, כדי שהקטלוג יישאר קל בכל עדכון, ולא רק ביום ההשקה.
האפקט נראה במטריקות: מהירות טעינת הקטלוג מפסיקה להתדרדר עם גידול במספר המוצרים, משקל עמוד המוצר יורד באופן משמעותי, ושיעור הנטישה בגלל טעינה איטית נעלם מהדוחות. להלן נפרט כיצד זה בנוי ברמת האינפובלוק וההחלפה.
דרכים להכנה ולהעלאת תמונות: השוואה
ישנן בדיוק שלוש דרכים, והבחירה ביניהן נעשית לא לפי טעם, אלא לפי נפח הקטלוג ותדירות העדכונים. העלאה ידנית דרך ממשק הניהול מחזיקה מעמד עד למאות הראשונות של פריטים, עיבוד מרוכז מכסה מילוי חד-פעמי ומבצעים, וסנכרון מ-1С הוא כבר עניין של קטלוג שמשתנה מדי יום. להלן השוואה כנה עם המגבלות שמתגלות בחודש השני-שלישי של העבודה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| העלאה ידנית של מוצרים | עד 200-300 פריטים, עריכות נדירות, השקה ראשונית | מנהל התוכן שוקע בפעולות אחידות; פערים בין הכרטיס למלאי מצטברים בשקט |
| עיבוד מרוכז של תמונות | מילוי חד-פעמי, מבחרים עונתיים, החלפת ספק | דורש ייצוא וייבוא מחדש; באספקות יומיות הופך לשגרה |
| סנכרון תמונות מ-1С | קטלוג מ-500 פריטים, עדכונים מדי יום, מספר מחסנים | נדרשת הגדרת חילוף וכללי התאמה; הפעלה חד-פעמית ארוכה יותר מידנית |
ההבדל מתגלה בנפח. בהעלאה ידנית כל פריט חדש הוא מעבר נפרד על הכרטיס: לבחור קובץ, להמתין לעיבוד, לבדוק שהתמונה נכנסה למקום הנכון. במאה מוצרים זה עוד נסבל, באלף — כבר תקן עובד נפרד, והטעויות בלתי נמנעות: מק"טים מבולבלים, כפילויות, קישורים שבורים.
עיבוד מרוכז של תמונות מסיר את השגרה: התמונות מוכנות בקבוצה לפי כללים אחידים, מותאמות ליחס הצדדים ולמשקל הנדרשים, ואז נטענות במעבר אחד. זה הכלי הנכון למילוי חד-פעמי, אך הוא אינו פותר את העיקר — פערים בין הקטלוג באתר למערכת החשבונאית.
אוטומציה של הקטלוג דרך סנכרון תמונות 1С סוגרת בדיוק את החיבור הזה. התמונות מקושרות לפריט לפי מק"ט, החילוף לוקח רק את מה שהשתנה, ולא שופך את כל הקטלוג מחדש.
בפועל זה נראה כך: ספרן משנה תמונה במערכת החשבונאית — באתר היא מופיעה ללא מעורבות מנהל תוכן, והפער בין חלון הראווה למחסן מפסיק להיות הנורמה.
הבחירה תלויה בתדירות שבה משתנה המבחר. אם פעם ברבעון — עיבוד מרוכז יספיק. אם מדי יום — חשבו את עלות הפעולות הידניות והגדירו חילוף.
איך אנחנו בונים את תהליך הכנת התמונות
אנחנו בונים את התהליך כך שהקטלוג לא "יתפזר" באמצע: קודם מתעדים את המצב הקיים, אחר כך מגדירים את העיבוד, ורק לאחר מכן מעלים את המוצרים בקבוצות. להלן סדר העבודות שאנחנו חוזרים עליו בכל פרויקט.
- ביקורת תמונות הקטלוג. מייצאים רשימת מוצרים ובודקים לאילו פריטים אין תמונה, היכן יש כפילויות, היכן קבצי המקור קטנים מהגודל הנדרש, והיכן הסיומת אינה תואמת את תוכן הקובץ בפועל. בפלט — טבלת אי-התאמות עם עדיפות לפי קבוצות מוצרים.
- סכמת עיבוד התמונות. מגדירים כללים אחידים: פרופורציות הפריים, השוליים סביב הפריט, הרקע, סדר הפריימים בגלריה, סט זוויות צילום נוספות. הסכמה מסירה את הסיבה העיקרית לחוסר האחידות — כשכל ספק שולח תמונות בדרך משלו.
- הגדרת ההמרה. מגדירים יצירת גדלים נגזרים לכרטיס, לרשימה ולעמוד המפורט, פורמט הדחיסה והאיכות. את קבצי המקור שומרים בנפרד — מהם תמיד אפשר להרכיב מחדש תצוגות מקדימות בלי לאבד פרטים.
- בדיקת השיוך. בודקים שכל תמונה משויכת למוצר ולמבצע הנכונים, ושסדר המיון תואם את ההיגיון של חלון הראווה. שגיאות שיוך תופסים לפני הפרסום: בקטלוג חי חיפושן יקר יותר.
- נוהל העלאה. מתארים באיזה אופן אנחנו מקבלים תמונות, איך אנחנו נותנים שמות לקבצים, היכן מאחסנים ומי אחראי על הבדיקה. את הנוהל מעבירים לצוות שלכם — פריטים חדשים מתווספים בלעדינו.
- העלאה לבקרה. מעלים קבוצת פיילוט, בודקים את מהירות מסירת עמודי הקטלוג ואת תקינות הכרטיסים במסכים שונים. אם משהו סוטה מהציפייה — מתקנים את הסכמה, ולא קבצים בודדים.
- מסירה והדרכה. מראים לעובדים איך להשתמש בנוהל, ומשאירים צ'ק-ליסט לקליטה. בהמשך אפשר להמשיך את התמיכה בכוחות עצמכם או להעביר אלינו.
מה הלקוח מקבל לידיו לאחר העבודה
לאחר מסירת הפרויקט נשאר לכם קו עבודה פעיל להכנת תמונות, ולא ייצוא חד-פעמי. את כל התוצרים אנו מעבירים למאגר הפרויקט: ניתן לערוך אותם, להרחיב אותם ולהעביר אותם לספק חדש ללא פירוק לאחור.
- סקריפטים לעיבוד תמונות — הבאה ליחס גובה-רוחב אחיד, חיתוך לפי המוצר, יצירת תצוגות מקדימות וגדלים נוספים לכרטיס הקטלוג. פועלים באופן אצווה, מעבדים פריטים חדשים ומדלגים כראוי על קבצים שכבר הועלו.
- תצורת הקטלוג — מבנה המדורים, מאפייני המוצרים, שיוך תמונות להצעות מסחריות, כללי ירושת תמונות מפריט האב. מוגדר כך שמוצר חדש יופיע בקטלוג ללא עריכה ידנית של תבניות.
- תיעוד ההעלאה — תיאור הפורמטים והדרישות לקבצים, סדר העדכון דרך החלפה עם מערכת החשבונאות, ההתנהגות בעת ייצוא חוזר והחלפת תמונות.
- הוראות למנהל התוכן — נוהל שלב-אחר-שלב: כיצד להכין צילום, היכן למקם אותו, מה לבדוק לפני הפרסום. כתוב לאדם ללא רקע טכני.
- כללי שמות ואחסון — סכמה אחידה לשמות קבצים ומבנה תיקיות, כדי שלא ייווצרו כפילויות וגרסאות אבודות בעבודה מקבילה של מספר עובדים.
- סכמת גיבוי — מה ובאיזו תדירות נשמר, כיצד לשחזר את קבצי המקור אם ההחלפה נכשלה.
- רשימת בדיקה לקבלה — מכלול בדיקות: תקינות הגדלים, היעדר קישורים שבורים, מהירות תגובת עמודי הקטלוג לאחר העלאה המונית.
כל סעיף מלווה ברשומה קצרה במאגר — מה הוא עושה, אילו פרמטרים הוא מקבל, מה יקרה בעת שגיאה. זה מסיר את התלות במבצע מסוים: מנהל התוכן עובד לפי ההוראות, המפתח — לפי התיעוד, ולא לפי הזיכרון.
מקרה בוחן: האצת קטלוג של חנות מקוונת
קטלוג עם 40,000 פריטים, תמונות נטענות ישירות מייצוא 1С: חלק מהתצוגות המוקטנות שוקלות כמה מגה-בייט, וחלקן מוצגות דרך קישורים שבורים. כרטיס המוצר נפתח תוך 6-8 שניות, שיעור התמונות השבורות הגיע ל-12% — הקונה ראה מצייני מקום אפורים במקום המוצר ועזב.
פירקנו את השרשרת: הייצוא מ-1С שמר את המקוריים "כפי שהם", ללא שינוי גודל וללא פורמט אחיד.
הגדרנו צינור עיבוד תמונות — בעת העלאה ל-1C-Bitrix התמונה מובאת אוטומטית למצב תצוגה מסחרי: חיתוך לפי פרופורציות, יצירת כמה גדלים לכרטיס, לקטלוג ולמיניאטורה, המרה לפורמט דחיסה מודרני תוך שמירה על שקיפות. המקוריים נשארים באחסון, ולחזית החנות עוברות עותקים מוקלים.
בנפרד סגרנו את הקישורים השבורים: הוספנו בדיקה בשלב הייצוא — אם הקובץ אינו קריא או חסר, הפריט מסומן ואינו מפורסם עם תצוגה מוקטנת ריקה, אלא נכנס לדוח עבור מנהל התוכן. קודם לכן מוצרים כאלה עברו בשקט לאתר.
| מדד | לפני | אחרי |
|---|---|---|
| פתיחת כרטיס | 6-8 שנ' | 1.5-2 שנ' |
| שיעור התמונות השבורות | 12% | 0.3% |
| משקל עמוד הקטלוג | ~9 MB | ~1.8 MB |
| תפוקת החיפוש בקטלוג | 3-4 שנ' | 0.8 שנ' |
ההאצה בתפוקה נבעה לא רק משינוי הגודל: מטמון התמונות וכותרות המטמון התקינות הסירו בקשות חוזרות לשרת בעת דפדוף בקטלוג. העומס על השרת בזמני שיא ירד — העמודים מוגשים מהמטמון, ולא נבנים מחדש בכל בקשה.
חודש לאחר ההטמעה עומק הצפייה גדל ב-18%, הנטישה בכרטיסי המוצר ירדה כמעט בחצי. מנהלי התוכן הפסיקו לנקות תצוגות מוקטנות ידנית — הצינור עושה זאת בכל ייצוא.
במה שונה עיבוד באצוות מסנכרון מ-1С?
עיבוד באצוות וסנכרון מ-1С פותרים משימות שונות, אף ששניהם עוסקים בתמונות של מוצרים.
עיבוד באצוות הוא ריצה חד-פעמית על קטלוג קיים: הסקריפט לוקח קבצי מקור מתיקייה או מארכיון, מביא אותם לצורה אחידה (חיתוך לפי פרופורציות, הבאה לרקע לבן, יצירת סט גדלים לכרטיס, לרשימה ולעמוד מפורט), דוחס ומסדר אותם לפי המבנה ש-Bitrix מצפה לו.
סנכרון הוא חילוף קבוע: התמונה מקושרת למוצר לפי קוד או מק"ט ומתעדכנת בכל שינוי של הפריט במערכת החשבונאית.
ההבדל המרכזי הוא במקור האמת וברגע ההפעלה. בעיבוד באצוות האמת היא הקבצים על הדיסק, וההרצה ידנית או לפי לוח זמנים; בסנכרון האמת היא כרטיס המוצר ב-1С, והחילוף מתבצע לפי אירועים או לפי תקנון.
מכאן גם דרישות שונות: לעיבוד באצוות חשוב מבנה תיקיות צפוי ושמות אחידים, ולסנכרון — מזהים יציבים והגנה מפני דריסה של תמונות שכבר הועלו בחילוף חלקי.
השוואת השיטות נשענת על שלושה פרמטרים: נפח, תדירות שינויים וסטייה מותרת. אם הקטלוג נטען פעם אחת ואחר כך נערך לעתים רחוקות, עיבוד באצוות זול ומהיר יותר — הוא לא גורר אחריו חילוף של ספרי עזר ולא תלוי בזמינות המערכת החשבונאית.
אם המבחר משתנה מדי יום והתמונות מגיעות יחד עם התיאורים, בלי סנכרון 1С הקטלוג מתרחק במהירות מהמציאות: מופיעים מוצרים בלי תמונות או עם תמונות מיושנות.
בפועל הבחירה בגישה היא לעתים רחוקות "או-או". התרשים העובד הוא עיבוד באצוות ראשוני של כל הקטלוג, כדי להשיג במהירות חלון ראווה, ואחר כך סנכרון 1С על השינויים: הוא קולט פריטים חדשים ומעדכן תמונות בלי לעבור על כל המערך.
היברידי כזה מסיר את הכאב המרכזי — ריצות מלאות ארוכות בכל עדכון — ומשאיר אפשרות נסיגה: אם החילוף מסר תמונה שגויה, הגרסה הקודמת של הקובץ נשמרת ומוחזרת נקודתית.
אנחנו מנתחים קטלוג קונקרטי ואומרים היכן די בעיבוד חד-פעמי והיכן נדרש סנכרון קבוע — תארו את המשימה, נחזור עם הערכה ותוכנית.
ספקות טכניים נפוצים לגבי הכנת תמונות
לפני שמתחילים בדרך כלל שואלים את אותן שאלות: האם הקטלוג "יישבר", האם השרת יעמוד בזה, האם האיכות תאבד בעת דחיסה מחדש וכמה זמן זה ייקח. להלן תשובות ענייניות, בלי מילים כלליות.
אילו פורמטים של תמונות נתמכים והאם יהיה צורך לבנות את הקטלוג מחדש?
קטלוג על 1C-Bitrix עובד באופן תקני עם JPEG, PNG, WebP ו-GIF. אנחנו לא נוגעים בקבצי המקור: הקבצים המקוריים נשארים בתיקייה נפרדת, ואל כרטיסי המוצר מועלות עותקים שכבר הוכנו.
אם הקטלוג התמלא במשך שנים ובו פורמטים מעורבים, ההמרה מתבצעת באופן מרוכז, לפי כללים — בלי מעבר ידני על כל פריט. הקישורים הישנים לקבצים נשמרים, ולכן הדפים לא מאבדים מיקום בחיפוש.
האם העומס על השרת יגדל לאחר העלאת התמונות החדשות?
להיפך — תמונות שהוכנו כראוי מפחיתות אותו. אנחנו מביאים את הקבצים לגודל אחיד המתאים לכרטיס ודוחסים בלי אובדן איכות נראה לעין: הדף מעביר פחות נתונים, נפתח מהר יותר, והשרת מבזבז פחות משאבים על העברה. בנוסף אנחנו מגדירים מטמון וטעינה נדחית — תמונות כבדות לא מעכבות את המסך הראשון.
האם איכות התמונות תיפגע בעת הדחיסה?
לא, אם הדחיסה מוגדרת בהתאם לסוג המוצר. עבור בגדים וטקסטיל חשובים יותר הפרטים והצבע, עבור מכשור — קווים חדים, עבור פריטים קטנים — תקריב. אנחנו בוחרים את מידת הדחיסה בנפרד לפי קטגוריות ובודקים את התוצאה על כרטיסים אמיתיים, ולא "בעין". על המסך ההבדל אינו נראה, ומשקל הקובץ יורד פי כמה.
כמה זמן לוקח היישום והאם ניתן לחזור אחורה?
לוחות הזמנים תלויים בהיקף הקטלוג: חלון ראווה קטן — ימים ספורים, קטלוג גדול עם אלפי פריטים — בשלבים, לפי קטגוריות. לפני ההעלאה אנחנו יוצרים גיבוי, ולכן חזרה למצב הקודם אפשרית בכל שלב. העבודה מתבצעת בלי לעצור את האתר: הקונים רואים כרטיסים מעודכנים תוך כדי התהליך.
אם המקרה שלכם לא נכלל ברשימה — תארו את המשימה, נבחן בדיוק את התצורה שלכם ונחזור עם הערכה ותוכנית.
בואו נדון במשימה של הכנת תמונות לקטלוג שלכם
כדי לחזור עם הערכה ולא עם מילים כלליות, אנחנו צריכים להבין שלושה דברים: כמה פריטים יש בקטלוג, מאיפה מגיעים קבצי המקור ואיך בנויה הייצוא מ-1С.
לאחר מכן אנחנו בוחנים מה כבר מוגדר באינפובלוקים — סוגי מאפיינים, תבניות כרטיסים מפורטים, כללי ריסייז — ואיפה צוואר הבקבוק: בהכנת הקבצים, בטעינה או בהגשת התמונות למבקר.
תארו את המשימה בצורה חופשית — לאחר מכן נבהיר את הפרטים בעצמנו:
- היקף הקטלוג ומבנה המדורים: כמה מוצרים, לכמה פריטים כבר יש תמונות, ולכמה אין;
- מקור הנתונים: ייצוא מ-1С, מחירון ספק, העלאה ידנית דרך ממשק הניהול או תוכנית משולבת;
- המצב הנוכחי: איך התמונות מגיעות לאינפובלוק כעת ומה בדיוק לא מתאים — מהירות, איכות, כפילויות, עבודה ידנית;
- דרישות לאיכות: רזולוציה מינימלית, רקע אחיד, פרופורציות מותרות, האם נדרשים זוויות צילום נוספות וסימני מים;
- מגבלות: גישות לשרת ולממשק הניהול, תקנון פרסום, חלונות שבהם אסור לגעת בקטלוג;
- לוחות זמנים ועדיפויות: מה צריך לסגור קודם כל, ומה יכול לחכות לשלב הבא.
לפי הנתונים המקדמיים האלה אנחנו מכינים תוכנית עבודה: אילו צעדים נעשים בצד 1С, אילו — בצד Bitrix, היכן אנחנו מציבים עיבוד אוטומטי והיכן נדרשת בדיקה ידנית. בהערכה אנחנו מתעדים את ההיקף, השלבים ונקודות שבהן תוכלו לבדוק את התוצאה לפני המסירה הסופית.
אם במהלך הניתוח יצוצו שאלות טכניות — לגבי תאימות להגדרות הנוכחיות, לגבי העברת תמונות שכבר הועלו, לגבי ביטול שינויים — המהנדסים שלנו יבחנו אותן לפני ההתחלה. בואו נדון במשימה: שלחו את הנתונים המקדמיים, ואנחנו נחזור עם הערכת הפרויקט ותוכנית העבודה.