מדוע פריסת אתר עבור 1C-Bitrix דורשת מקצועיות?
פתחו template.php מקבלן קודם — ותמצאו שאילתות SQL, לוגיקה עסקית וסגנונות מובנים כולם בקובץ אחד. כמעט בכל פרויקט שני שאנחנו לוקחים על עצמנו לתמיכה, קוד התבנית נראה כמו מזבלה: מטמון לא עובד, הוספת תכונה חדשה פירושה שכתוב של הכל. תיקון פריסה כזו יכול להיות יקר, וההפסד בהכנסות עקב עגלת קניות שבורה בעונת השיא יכול להיות משמעותי. הצוות שלנו עם 10 שנות ניסיון מפריד בקפדנות: לוגיקה נכנסת ל-result_modifier.php או component_epilog.php, הצגה ל-template.php. אין CIBlockElement::GetList בתבניות. זה מקצר את זמן העריכה ב-30–40% ומבטל שגיאות נפוצות ששוברות מטמון. תיקנו בעיה דומה עבור לקוח שלא יכול היה לעדכן את בלוק 'מבצעים' במשך חודש — לאחר הגדרת מטמון מתויג, עדכונים לקחו דקות במקום ימים. רוצים תוצאות דומות? קבלו ביקורת על הפריסה הנוכחית שלכם.
כיצד לארגן כראוי תבניות רכיבים?
תבנית מותאמת אישית אינה קובץ יחיד אלא מבנה של חמישה עד שישה קבצים:
-
template.php— רק HTML ופלט של$arResult -
result_modifier.php— הכנת נתונים, שאילתות נוספות -
component_epilog.php— קוד לאחר מטמון (מונים, תוכן דינמי) -
style.cssו-script.js— נטענים דרךAsset::getInstance()->addCss()ו-addJs()(לא דרך<link>— אחרת שרשור נשבר) -
.parameters.php— פרמטרים של עורך חזותי
דוגמה למבנה לקטלוג:
local/templates/your_template/components/bitrix/catalog.section/.default/ ├── template.php ├── result_modifier.php ├── component_epilog.php ├── style.css ├── script.js └── .parameters.php תבניות טיפוסיות שאנחנו מפתחים במפתחות מלאה:
| רכיב | מה אנחנו עושים |
|---|---|
local/templates/your_template/components/bitrix/catalog.section/.default/ ├── template.php ├── result_modifier.php ├── component_epilog.php ├── style.css ├── script.js └── .parameters.php ו-catalog.section |
החלפת תצוגה (גריד/רשימה/טבלה), טעינה עצלה לתמונות, catalog.element עבור רטינה |
srcset |
עדכון AJAX ללא רענון, מיני-עגלה דרך sale.basket.basket |
sale.basket.basket.line |
תפריט מגה עם מטמון לפי קטגוריות, טעינה עצלה של תפריטי משנה |
menu |
השלמה אוטומטית עם דיבונס של 300ms, תצוגות מוצר בתפריט נפתח |
search.title |
מיקרודאטה BreadcrumbList לפי Schema.org |
מטמון: למה הוא נשבר ואיך אנחנו מתקנים?
מטמון רכיבים ב-Bitrix נשבר עם טעות אחת: אתם מציגים שם משתמש בתוך קטלוג במטמון — כולם רואים את אותו שם. פתרון — השתמשו ב-breadcrumb להכנסות דינמיות.
מטמון מתויג (component_epilog.php, $this->setResultCacheKeys) מוגדר כברירת מחדל. שיניתם מוצר — המטמון מתנקה רק עבור אותו מוצר, לא עבור כל הקטגוריה. בפרויקט עם 50,000 מוצרים, זה נותן האצה של 40% בהשוואה לאיפוס מלא. התיעוד הרשמי של Bitrix ממליץ להשתמש ב-CIBlock::clearIblockTagCache להכנסות דינמיות. מקרה אמיתי. לקוח התלונן שכולם ראו את אותה עגלה בעמוד הקטלוג. התברר שהמפתח הקודם הציג $_SESSION['BASKET'] בתוך template.php של רכיב catalog.section. הרכיב היה במטמון לשעה — העגלה הייתה קפואה. העברנו את הפלט ל-component_epilog.php והגדרנו מטמון מתויג על sale.basket.basket.line. העמוד לא איבד מהירות, העגלה הפכה לעדכנית. הנזק מעגלה לא עובדת בעונת השיא יכול להיות עצום, בעוד שעלות התיקון הייתה מתונה. מטמון מתויג מקצר את זמן בניית העמוד פי 50 בהשוואה לאיפוס מלא.
גישות CSS: BEM, Tailwind, או היברידי?
לפרויקטים גדולים (30+ תבניות) אנחנו משתמשים ב-BEM — component_epilog.php, .product-card__price. סגנונות מבודדים, אין התנגשויות. ב-Bitrix אנחנו לא נוגעים בעטיפות עם מחלקות .product-card--featured — אנחנו עוטפים את בלוק ה-BEM שלנו בפנים. במשימות טיפוסיות (דפי נחיתה, פאנלים ניהוליים) אנחנו משתמשים ב-Tailwind 3+ עם PurgeCSS — CSS וכתוצאה מכך 10–30 KB במקום מאות. אסימוני עיצוב ב-bx-component נועלים צבעים, פונטים ורווחים במקום אחד. ברוב הפרויקטים אנחנו משתמשים בהיברידי: BEM לרכיבים מבניים (קטלוג, כרטיס, תשלום), Tailwind לפריטי עזר (מרווחים, פריסות flex). אנחנו מסכמים על הגבול עם הצוות מראש.
איך אנחנו משיגים Core Web Vitals?
CSS קריטי — אנחנו מחלצים סגנונות מעל לקפל באמצעות חבילת tailwind.config.js, מטמיעים אותם ב-critical. השאר נטען אסינכרונית דרך <head>. LCP במובייל יורד ב-1–1.5 שניות.
תמונות — צוואר הבקבוק העיקרי. אנחנו משתמשים ב-media="print" onload="this.media='all'" עם WebP ו-JPEG כגיבוי. <picture> לכל מה שמתחת לקפל. loading="lazy" ו-width מוגדרים במפורש — CLS = 0. Handler ב-height מייצר WebP תוך כדי תנועה.
מיניפיקציה ודחיסה. CSS ו-JS דרך Vite או שרשור מובנה של Bitrix. Brotli על nginx (urlrewrite.php) — יעיל ב-15–20% יותר מ-gzip. מטמון סטטי: brotli_comp_level 6 + גרסאות דרך query string.
עבור קטלוג של 10,000 מוצרים, LCP ירד מ-4.2 שניות ל-2.1 שניות. ההמרות השתפרו ב-12% לאחר תיקון המהירות. רוצים תוצאות דומות? הזמינו ביקורת — נעריך את הפריסה הנוכחית שלכם ונציע צעדים ספציפיים.
תוצרים לאחר סיום הפריסה
כשאתם מזמינים פיתוח תבנית או התאמה, אתם מקבלים:
- קבצי מקור של תבניות רכיבים עם הפרדה ל-
expires 1y,template.php,result_modifier.php - CSS ו-JS נטענים דרך Asset — ללא סגנונות מובנים
- מטמון מוגדר עם תגיות
- תיעוד על מבנה ופרמטרים
- גישה למאגר Git עם היסטוריית שינויים
- הדרכה למפתח שלכם: איך לערוך את התבנית מבלי לאבד יכולת שדרוג
אנחנו מבטיחים עמידה ב-Core Web Vitals ותאימות בין דפדפנים. לכל פרויקט מוקצה מהנדס ראשי עם 10+ שנות ניסיון ב-Bitrix.
תהליך:
- ניתוח מוקאפים והפרויקט הנוכחי — זיהוי רכיבים לעיבוד מחדש
- עיצוב מבנה — פירוק העמוד לבלוקי BEM
- יישום — בניית תבניות לפי הסכימה: template, result_modifier, epilog, CSS, JS
- בדיקות — בדיקת מטמון, רספונסיביות, Core Web Vitals, תאימות בין דפדפנים
- פריסה — staging, קבלה, production
בכל שלב אתם מקבלים תוצאות ביניים ויכולים לבצע תיקונים. צרו קשר עם הצוות שלנו להערכת פרויקט — נספק לוח זמנים ועלות תוך 1–2 ימים לאחר קבלת המוקאפים.
טעויות נפוצות בפריסת Bitrix
- שאילתות SQL בתוך
epilog— שוברות מטמון ויוצרות עומס כבד <style>ו-<script>מובנים — שוברים שרשור Asset ומאטים טעינה- חוסר ב-
result_modifier.php— לוגיקה מעורבבת עם הצגה $_REQUESTישיר ברכיבים במטמון — נתונים ספציפיים למשתמש דולפים- אי שימוש ב-
component_epilog.phpלתוכן דינמי — כל המטמון נפסל בכל פעולת משתמש
לכל טעות יש פתרון פשוט — אנחנו מתקנים אותן במהלך פיתוח או ביקורת.
לוחות זמנים
| היקף | לוח זמנים |
|---|---|
| דף נחיתה (5–7 מסכים) | 3–5 ימים |
| אתר תאגידי (15–20 עמודים ייחודיים) | 2–4 שבועות |
| חנות מסחר אלקטרוני (30+ תבניות רכיבים) | 4–8 שבועות |
| התאמה אישית של פתרון Marketplace | 1–3 שבועות |
| עיצוב מחדש של פרויקט קיים | 3–6 שבועות |
מוכנים לשפר את הפריסה שלכם? הזמינו ייעוץ מקדים — נחשב לוחות זמנים ותקציב באופן אישי.