שירותי פיתוח קטלוג וסינון ב-1C-Bitrix

פיתוח קטלוג 1C-Bitrix: איך להפוך פילטר של 4 שניות לתגובה מיידית

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

כיצד משפיעים בלוקי מידע על ביצועי הקטלוג?

בלוקי מידע הם הבסיס של הקטלוג, אבל בפרויקטים עם עשרות אלפי מוצרים, הם הופכים לצוואר בקבוק. ה-bitrix:catalog.smart.filter הסטנדרטי מייצר JOINs על 6–8 טבלאות מאפיינים (b_iblock_element_property), מה שמוביל את MySQL לסריקה מלאה. אנו משנים את הגישה: במהלך התכנון, אנו קובעים אילו מאפיינים נכנסים לבלוק המידע ואילו לבלוקים Highload. עבור נתוני ייחוס (מותגים, ערים, טבלאות מידות) אנו משתמשים ב-HLB: הם עובדים עם טבלה נפרדת ללא תקורה של b_iblock_element_property. כאשר תפריט נפתח 'ערים' נטען במשך 8 שניות בגלל 5000 ערכים — זהו אות להעביר אותם ל-HLB. קטלוג של 80,000 מוצרים עם פילטר של 4 שניות מפסיד הכנסות משמעותיות מדי שנה בגלל נטישת לקוחות — הארכיטקטורה הנכונה מספקת חיסכון כזה. צרו קשר כדי להעריך את התועלת לפרויקט שלכם.

מהו האינדקס הפאקטי ולמה הוא חשוב?

ליבת הביצועים נמצאת כאן. ללא אינדקס פאקטי, כל לחיצה על פילטר היא שאילתת SQL עם JOINs על b_iblock_element, b_iblock_element_property, b_catalog_price, ועוד כמה טבלאות. על 100,000 מוצרים, שאילתה כזו אורכת 2–4 שניות. עם אינדקס פאקטי — 30–80 אלפיות שנייה. לפי התיעוד הרשמי, האינדקס הפאקטי מפחית את זמן ביצוע השאילתות עשרות מונים (בפרויקטים אמיתיים — עד פי 50). המנגנון: 1C-Bitrix יוצר טבלה b_catalog_smart_filter שבה הוא מאחסן שילובים מחושבים מראש של 'סעיף + מאפיין + ערך + מספר מוצרים'. בעת סינון, המנוע ניגש לטבלה השטוחה הזו במקום לאסוף נתונים מהמבנה הנורמלי של בלוקי מידע.

טעויות נפוצות בהגדרת האינדקס הפאקטי כוללות אי-יצירת האינדקס לכל הסעיפים, שכחת הגדרת אינדוקס מחדש ברקע לאחר ייבוא המוני — מה שגורם למונה המאפיינים לא להתאים למספר המוצרים בפועל. הכללת כל המאפיינים בפאקט, אפילו אלה השירותיים, מנפחת את טבלת b_catalog_smart_filter. בקטלוגים עם מעל 300,000 פריטים, גודלה יכול לעלות על גיגה-בייט — ניטור דרך SHOW TABLE STATUS LIKE 'b_catalog_smart_filter' הוא חיוני. מסקנה: האינדקס הפאקטי מספק האצה רדיקלית, אך דורש הגדרה קפדנית ואינדוקס מחדש אוטומטי דרך הסוכן CIBlockCatalog::ReindexFacet או cron.

מדוע בלוקים Highload מהירים יותר מבלוקי מידע עבור נתוני ייחוס?

בפועל, הארכיטקטורה הטובה ביותר היא היברידית. מוצרים וסעיפים חיים בבלוקי מידע — שם יש לכם SEO, עורך ויזואלי ורכיבי קטלוג סטנדרטיים. מאפייני ייחוס עם אלפי ערכים מועברים לבלוקים Highload. נתוני משתמש (מועדפים, פריטים שנצפו, השוואות) גם הם עוברים ל-HLB — הם גדלים במהירות, ובלוקי מידע לא מיועדים לכך. רוצים לדעת איזו ארכיטקטורה לבחור לקטלוג שלכם? צרו קשר — ננתח את מבנה הנתונים שלכם ונספק המלצות.

פילטרי SEO: איך לקבל URLs ידידותיים ל-SEO ולא להיענש על ידי Yandex?

הפילטר הסטנדרטי מייצר ?filter[brand]=apple&filter[color]=black — מנועי חיפוש או שאינם מאנדקסים URLs כאלה או מחשיבים אותם ככפולים. אבל השאילתה 'מחשבים ניידים של Apple שחורים' היא התעבורה הנמוכה-תדר הממירה ביותר. אנו יוצרים URLs ידידותיים ל-SEO: /catalog/noutbuki/brand-apple/color-black/ עם title, description ו-H1 ייחודיים. לא תבניות כמו 'קנה {מותג} במינסק', אלא כאלה משמעותיות המשקפות את השילוב הספציפי.

• URLs קנוניים — למניעת כפילויות של /brand-apple/color-black/ ו-/color-black/brand-apple/.
• בקרה על מספר השילובים המאונדקסים — 10 מאפיינים עם 20 ערכים כל אחד מייצרים מיליוני דפים; Yandex מעניש על כך.
• מפת אתר אוטומטית לדפי פילטר SEO.
• ממשק ניהול למנהל — הם מחליטים אילו צמתים לאנדקס.

הזמינו הטמעת פילטרי SEO — קבלו כלי מוכן למשיכת תעבורה נמוכת-תדר עם גידול בהמרה עד 30%.

אילו שיטות מספקות שיפור משמעותי בביצועים?

• שליפת שדות נחוצים בלבד דרך arSelect — ללא SELECT * על בלוקי מידע.
• קאשינג מתויג מנוהל: כאשר מוצר מתווסף, הקאש נבנה מחדש אוטומטית.
• קאש מורכב למשתמשים אנונימיים: TTFB < 100 אלפיות שנייה, HTML מוגש ללא הרצת PHP.
• אינדקסים על מאפיינים המשמשים בסינון — בלעדיהם MySQL סורקת את כל טבלת b_iblock_element_property.
• ניטור TTFB: אם הקטלוג מגיב לאט מ-500 אלפיות שנייה, אנו בודקים את יומן השאילתות האיטיות.

מה כולל פיתוח קטלוג מקיף על 1C-Bitrix

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

• ביקורת על ארכיטקטורת הקטלוג והסינון הנוכחית.
• תיעוד פרויקט המתאר את סכמת הנתונים, חלוקה בין בלוקי מידע ובלוקים Highload, והרכב הפאקט.
• פילטר חכם מוכן עם מצב AJAX, קיבוץ ושמירת מצב.
• אינדקס פאקטי מוגדר עם אינדוקס מחדש ב-cron.
• פילטרי SEO עם URLs ידידותיים ל-SEO, תגי מטא ייחודיים, קנוניקלים ומפת אתר.
• שילוב תצוגה מהירה ומיון (AJAX, התאמה למובייל).
• תיעוד תפעולי למנהלים: כיצד להוסיף מאפיינים, לנהל אינדקסים ושילובי SEO.
• תמיכה אחריות ל-30 יום לאחר המסירה — אנו פותרים תקלות ועונים על שאלות.

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

אנו לא רק מתקינים רכיבים. התהליך כולל:

1. ביקורת על הקטלוג הנוכחי — ניתוח מבנה המאפיינים, זיהוי צווארי בקבוק, בדיקת אינדקסים וקאש.
2. תכנון ארכיטקטורה — חלוקת נתונים בין בלוקי מידע ו-HLB, קביעת הרכב הפאקט.
3. פיתוח הפילטר החכם — התאמת תבנית, מצב AJAX, קיבוץ, שמירת מצב.
4. הגדרת אינדקס פאקטי — יצירה, אינדוקס מחדש ב-cron, ניטור.
5. פילטרי SEO — URLs ידידותיים ל-SEO, תגי מטא, קנוניקלים, מפת אתר.
6. שילוב תצוגה מהירה ומיון — חלון AJAX עם תמונה, מחיר, זמינות, טעינה מראש במעבר עכבר. במובייל — פאנל תחתון במקום פופ-אפ.
7. הדרכת מנהלים — כיצד לנהל מאפיינים, אינדקסים ושילובי SEO.
8. תמיכת אחריות — 30 יום לאחר המסירה.

לוח זמנים להטמעה

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