שירותי אופטימיזציית ביצועים ל-1C-Bitrix

80% מאתרי ביטריקס איטיים בגלל טבלה אחת

b_iblock_element_property הוא מבנה EAV שבו כל שורה מאחסנת ערך אחד של מאפיין אחד של פריט אחד. קטלוג של 50,000 מוצרים עם 30 מאפיינים מייצר 1.5 מיליון שורות. הפילטר החכם מבצע JOIN של טבלה זו עם b_iblock_element על חמישה מאפיינים, ו-MySQL מבצע סריקת טבלה מלאה במשך 3–5 שניות. הניסיון שלנו מראה שללא התערבות בטבלה זו, האצת האתר בלתי אפשרית. אנו לוקחים פרויקטים שבהם זמן הטעינה ירד ל-8–10 שניות ומחזירים את ה-TTFB לפחות מ-200 אלפיות השנייה תוך 1–2 שבועות. אופטימיזציית מהירות האתר מתחילה בבדיקת שאילתות איטיות ומסתיימת בשיפוץ תשתית מקיף במפתח מלא.

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

איך להשיג TTFB מתחת ל-200 אלפיות השנייה?

אופטימיזציית שרת היא הצעד הראשון. תצורת Nginx חורגת מעבר ל-gzip פשוט. באופן ספציפי:

• gzip_comp_level 4-5 — גבוה יותר אינו מועיל, ה-CPU צורך יותר ממה שהוא חוסך ברוחב פס.
• brotli on עם brotli_static on עבור קבצים דחוסים מראש.
• HTTP/2 עם http2_max_concurrent_streams 128.
• fastcgi_cache עבור תגובות PHP — שמירה במטמון ברמת Nginx, תוך עקיפת PHP-FPM לחלוטין.
• worker_processes auto, worker_connections לפי מספר החיבורים המקבילים.

כוונון PHP-FPM: בחירה בין pm = dynamic ל-pm = static. מצב סטטי עובד הכי טוב עבור שרתים ייעודיים עם עומס צפוי מכיוון שהוא מונע תקורה של יצירת תהליכים. מצב דינמי חוסך זיכרון RAM בעומס נמוך. חשבו את pm.max_children כ-(доступная RAM - RAM для MySQL/Redis) / средний расход на процесс. עבור OPcache הגדר opcache.memory_consumption=256, opcache.max_accelerated_files=20000 ו-opcache.validate_timestamps=0 בסביבת ייצור (הפעל מחדש את PHP-FPM בעת פריסה).

MySQL/MariaDB: צוואר הבקבוק העיקרי הוא כמעט תמיד מסד הנתונים. הפעל slow_query_log עם סף של 0.5 שניות ונתח כל שאילתה דרך EXPLAIN. הגדר innodb_buffer_pool_size ל-70–80% מה-RAM הזמין בשרת ייעודי. צור אינדקסים מורכבים לחיפוש פאקטלי: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) על b_iblock_element_property. הרץ OPTIMIZE TABLE b_iblock_element_property לאחר פעולות המוניות.

איך להגדיר מטמון בשלוש רמות?

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

מטמון מרוכב. טכנולוגיית bitrix:composite מאפשרת ל-Nginx לשרת HTML מוכן מקובץ; PHP אינו מבוצע. אזורים דינמיים (עגלה, הרשאה) נטענים דרך בקשת AJAX באמצעות CBitrixComponent::setFrameMode(true). TTFB יורד מתחת ל-50 אלפיות השנייה. עם זאת, לא כל הרכיבים תואמים; $APPLICATION->ShowPanel() ופלט ישיר דרך echo שוברים את המטמון המרוכב. אנו בודקים כל עמוד דרך הפאנל 'ביצועים → אתר מרוכב'. לפי התיעוד הרשמי של ביטריקס על מטמון מרוכב, זוהי שיטת השמירה במטמון היעילה ביותר לפרויקטים בעלי עומס גבוה.

השוואה: מטמון מרוכב מהיר פי 10–20 ממטמון מנוהל בזמן עד הבייט הראשון.

Memcached / Redis. העבר מטמון ממערכת הקבצים: סשנים עוברים ל-Redis (session.save_handler = redis) — מהיר פי 10–50 מקבצים, בתוספת תמיכה בקלאסטר. מטמון רכיבים עובר ל-Memcached דרך .settings.php: 'cache' => ['type' => 'memcache']. כמו כן, הפעל מטמון שאילתות ORM כך שקריאות GetList() זהות לא יפגעו ב-MySQL בכל בקשה.

מהי הדרך המהירה ביותר לאופטימיזציה של מסד הנתונים של ביטריקס?

הגדרות ברירת המחדל של MySQL אינן מספיקות. אינדקסים — מורכבים לחיפוש פאקטלי, מכסים לשאילתות תכופות. MySQL עונה מהאינדקס ללא גישה לנתונים. אינדקסים חלקיים (MariaDB) לסינון לפי ACTIVE = 'Y'. בדוק אינדקסים שאינם בשימוש — כל אחד מאט פעולות INSERT/UPDATE.

חלוקה (Partitioning). עבור טבלאות עם מיליוני שורות: b_stat_session, b_search_content_stem ובלוקים בעלי עומס גבוה עם היסטוריה. חלק לפי תאריך — שאילתה עבור 'הזמנות בחודש' אינה סורקת שלוש שנים של נתונים. חלוקה פותרת גם את בעיית השאילתות המקבילות במהלך סנכרון עם 1C באמצעות CommerceML.

מקרה אמיתי: קטלוג של 200,000 מוצרים, 50 מאפיינים. סינון לפי 10 מאפיינים לקח 12 שניות. לאחר יצירת אינדקסים מורכבים על (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) וחלוקת b_iblock_element_property לפי IBLOCK_ID, זמן הביצוע ירד ל-0.3 שניות. עומס MySQL ירד פי 40.

ניקוי. במשך שנה או שנתיים, כל מסד נתונים צובר: אינדקס חיפוש מיושן, רשומות שפג תוקפן ב-b_cache_tag, היסטוריה ב-b_iblock_element_prop_s*, יומנים ב-b_event_log התופסים ג'יגה-בייט. אנו מגדירים ניקוי קבוע באמצעות סוכנים.

צד לקוח ו-CDN

תמונות מהוות 60–80% ממשקל העמוד. המר ל-WebP דרך CFile::ResizeImageGet() עם BX_RESIZE_IMAGE_PROPORTIONAL + המרה. השתמש ב-srcset + sizes — לעולם אל תטען תמונת 3000px לתוך בלוק של 400px. הוסף loading="lazy" לכל מה שמתחת לקו הגלילה. AVIF מציע חיסכון נוסף של 20–30% לעומת WebP.

אופטימיזציית CSS/JS: השתמש במודול המובנה של ביטריקס למיזוג ומיניפיקציה דרך 'הגדרות → אופטימיזציית CSS/JS'. החל PurgeCSS / UnCSS — בפרויקט ביטריקס טיפוסי, 60–70% מה-CSS אינו בשימוש. השתמש ב-defer / async עבור JS שאינו קריטי והטמע CSS קריטי ב-<head> ל-FCP מיידי.

גופנים: הוסף <link rel="preload" as="font" crossorigin> עבור הגופן הראשי. הגדר font-display: swap — טקסט נראה מיד. צור תת-קבוצות דרך pyftsubset — שמור רק קירילית + לטינית, גודל הקובץ קטן פי 3–5.

CDN: Cloudflare, BunnyCDN, AWS CloudFront, או ספקים רוסיים (Selectel CDN, VK Cloud CDN). הגש נכסים סטטיים (CSS, JS, תמונות, גופנים) דרך CDN עם Cache-Control: public, max-age=31536000, immutable עבור קבצים עם hash. השתמש באופטימיזציית תמונות בזמן אמת (imgproxy, Cloudflare Polish) ללא עומס על השרת המקורי.

מדוע יש צורך בבדיקת עומסים?

לא benchmarks סינתטיים, אלא תרחישים אמיתיים: k6 / wrk לסימולציית מסלולים — קטלוג → סינון → כרטיס מוצר → עגלה → תשלום. מדוד RPS, זמן תגובה (p50, p95, p99), שיעור שגיאות. השתמש ב-Xdebug (callgrind) או Blackfire לפרופילינג PHP כדי למצוא צווארי בקבוק. תוצאת הבדיקה נותנת תמונה אובייקטיבית של היכן באמת האיטיות, לא היכן 'נראה'. לאחר האופטימיזציה, הרץ שוב כדי לתעד שיפורים.

תוצאות

מה כלול בעבודה?

1. בדיקת ביצועים נוכחית — ניתוח שאילתות איטיות, פרופילינג PHP, בדיקת מטמון, CDN, הגדרות שרת.
2. תצורת שרת — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. אופטימיזציית מטמון — מטמון מנוהל, אתר מרוכב, תצורת TTL, מטמון מתויג.
4. עבודה על מסד הנתונים — יצירת אינדקסים, חלוקה, ניקוי, ארגון מחדש של טבלת EAV.
5. צד לקוח — תמונות (WebP/AVIF), CSS/JS (מיניפיקציה, דחייה), גופנים (preload, תת-קבוצות).
6. CDN — חיבור, הגדרת כללי שמירה במטמון.
7. בדיקת עומסים — תרחישי משתמש אמיתיים, דוח מדדים.
8. תיעוד — תיאור כל השינויים, המלצות לתחזוקה שוטפת.
9. אחריות — תמיכה למשך חודש לאחר המסירה, הבטחת יציבות כל האופטימיזציות.

ניטור

ללא ניטור, הכל מתדרדר תוך חצי שנה. מודול חדש, יומנים שלא נוקו, שינוי תבנית — והמהירות חוזרת למקור. השתמש ב-web-vitals API לניטור משתמשים אמיתיים (RUM) ממבקרים בפועל. הגדר ניטור סינתטי עם Pingdom או UptimeRobot לבדיקות קבועות ממיקומים שונים. הגדר התראות — TTFB > 500 אלפיות השנייה או LCP > 3 שניות מפעילים הודעה.

לוחות זמנים ועלות

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