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

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

הכישורים שלנו:

שאלות נפוצות

נתקלנו במקרים שבהם PageSpeed Insights נותן ציון 38 עם LCP של 4.2 שניות. TTFB הוא 1.8 שניות, והתוכן המלא כבר נמצא ב-HTML. הבעיה אינה הרשת או ה-JS בצד הלקוח—העמוד איטי לייצור בשרת. כלי האבחון של Bitrix קיימים אך לעיתים רחוקות משתמשים בהם נכון. לצוות שלנו יש ניסיון של 10+ שנים עם Bitrix וביצענו 50+ פרויקטי אופטימיזציה. הניסיון שלנו מראה שב-80% מהמקרים, צוואר הבקבוק הוא קאשינג לא אופטימלי או שאילתות N+1 בתבניות. עמודי קטלוג עם מאות מוצרים פגיעים במיוחד—שאילתות SQL יכולות לעלות על 400. ללא גישה שיטתית, תיקון צוואר בקבוק אחד עשוי לא להשפיע אם הקאשינג לא מופעל בכל הרמות. אופטימיזציה של עיבוד עמודים ב-1C-Bitrix דורשת ביקורת מקיפה ופעולות עוקבות. לקוח אחד חסך $500 בחודש בעלויות שרת לאחר האופטימיזציה.

מדוע עיבוד עמודים ב-1C-Bitrix איטי?

סיבות עיקריות:

  • רכיבים שעובדים עם מצב קאשינג לא עקבי (SHOW_PAGE_EXEC_TIME).
  • לולאות בתבניות שמייצרות שאילתות SQL מסוג N+1.
  • קאשינג מתויג (Tagged caching) מושבת.
  • מצב Composite לא מוגדר.
  • סוכני Bitrix (Agents) לא מותאמים.

כיצד לאבחן עיבוד עמודים איטי ב-Bitrix?

אלגוריתם אבחון בן ארבעה שלבים:

  1. הפעל את פאנל הדיבאג: קבועים SHOW_SQL_STAT ו-dbconn.php ב-CACHE_TYPE=N.
  2. נתח את מספר שאילתות ה-SQL וזמן הביצוע—נורמלי הוא עד 100 שאילתות ב-0.5 שניות.
  3. זהה רכיבים ללא קאש או עם GetByID.
  4. בדוק אם יש שאילתות N+1 בתבניות (לדוגמה, קריאות $_GET["show_page_exec_time"] или константа: define('SHOW_PAGE_EXEC_TIME', true); define('SHOW_SQL_STAT', true); בתוך לולאות).

אבחון באמצעות כלי Bitrix סטנדרטיים

הפעל את פאנל הדיבאג:

$_GET["show_page_exec_time"] или константа:
define('SHOW_PAGE_EXEC_TIME', true);
define('SHOW_SQL_STAT', true);

הפאנל בתחתית העמוד מציג:

  • זמן ביצוע כולל
  • מספר שאילתות SQL וזמן כולל
  • צריכת זיכרון

עמוד בעייתי טיפוסי: 400+ שאילתות SQL, 1.5–2.5 שניות על SQL לעומת 0.3 שניות על PHP. רכיבים רצים עם מצבי קאשינג לא עקביים. תיעוד 1C-Bitrix ממליץ על קאשינג מתויג כדי להאיץ עמודים.

מהן שאילתות N+1 וכיצד לחסל אותן?

הגורם הנפוץ ביותר ל-400+ שאילתות הוא לולאה על תוצאות עם שאילתה פנימית. זה ידוע כ-בעיית שאילתות N+1.

// Плохо: запрос на каждый элемент
foreach ($arResult['ITEMS'] as &$item) {
    $item['SECTION'] = \CIBlockSection::GetByID($item['IBLOCK_SECTION_ID'])->GetNext();
}

פתרון עם שאילתה מצטברת לפני הלולאה:

$sectionIds = array_unique(array_column($arResult['ITEMS'], 'IBLOCK_SECTION_ID'));
$sections = [];
$res = \CIBlockSection::GetList([], ['ID' => $sectionIds], false, ['ID', 'NAME', 'CODE']);
while ($s = $res->GetNext()) {
    $sections[$s['ID']] = $s;
}
foreach ($arResult['ITEMS'] as &$item) {
    $item['SECTION'] = $sections[$item['IBLOCK_SECTION_ID']] ?? null;
}

באילו כלי פרופילינג להשתמש?

ל-Bitrix אין פרופיילר מובנה ברמת רכיב. הדרך הפשוטה ביותר היא להתקין את מודול Performance Monitor של Bitrix מחנות האפליקציות. לחלופין, השתמשו ב-xhprof/Tideways עם עטיפה מותאמת אישית. להערכה מהירה, אפשר להוסיף handler ב-// Плохо: запрос на каждый элемент foreach ($arResult['ITEMS'] as &$item) { $item['SECTION'] = \CIBlockSection::GetByID($item['IBLOCK_SECTION_ID'])->GetNext(); } שמציג את 10 הרכיבים האיטיים ביותר, אך זה דורש זהירות. לפרופילינג מתקדם, שקלו להשתמש ב-APCu או Redis לקאשינג כדי לשפר את אופטימיזציית ה-SQL של Bitrix.

כיצד להגדיר מצב Composite?

מצב Composite הוא מנגנון מובנה של Bitrix שמאחסן עמודים שלמים ומחליף בלוקים דינמיים (עגלה, אימות) באמצעות AJAX. הוא נותן TTFB של 50–100 אלפיות השנייה למשתמשים מחוברים. עם זאת, Composite דורש התאמת תבנית—לא ניתן להפעיל אותו בכפתור ללא התאמות רכיבים. אנו ממליצים עליו לפרויקטים עם דרישות מהירות גבוהות.

הגדרת Composite שלב אחר שלב:

  1. הפעל Composite בלוח הניהול: "הגדרות" → "הגדרות מוצר" → "אתר Composite".
  2. ודא שכל הבלוקים הדינמיים (עגלה, טופס התחברות) הועברו לפונקציות דחויות או לוידג'טים של AJAX.
  3. הגדר חריגים לעמודים שלא צריך לשמור במטמון (לדוגמה, עמוד תשלום).
  4. בדוק עם Composite מופעל עבור מנהלים.

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

השוואת סוגי קאשינג

סוג קאשינג מהירות מורכבות הגדרה
קאשינג קבצים סטנדרטי בינוני (TTFB 200–500 אלפיות השנייה) נמוכה
מתויג (Bitrix Cache Engine) גבוה (TTFB 100–200 אלפיות השנייה) בינונית
מצב Composite מקסימלי (TTFB 50–100 אלפיות השנייה) גבוהה (דורש התאמת תבנית)

סיבות לביצועים איטיים של רכיבים

רכיב ללא קאש או עם קאש NONE

$APPLICATION->IncludeComponent('bitrix:catalog', '.default', [
    'CACHE_TYPE' => 'N', // <- убийца производительности
]);

שנה ל:

'CACHE_TYPE' => 'A', // автоматически по настройкам сайта 'CACHE_TIME' => 3600, // секунды 

עבור רכיבים תלויי משתמש (עגלה, אזור אישי), קאשינג ברמת רכיב לא עובד—השתמשו בגישת AJAX: הגישו את התבנית מהמטמון, טענו נתונים אישיים בנפרד.

קאשינג מושבת ברכיב Composite

רכיב Composite (לדוגמה, $sectionIds = array_unique(array_column($arResult['ITEMS'], 'IBLOCK_SECTION_ID')); $sections = []; $res = \CIBlockSection::GetList([], ['ID' => $sectionIds], false, ['ID', 'NAME', 'CODE']); while ($s = $res->GetNext()) { $sections[$s['ID']] = $s; } foreach ($arResult['ITEMS'] as &$item) { $item['SECTION'] = $sections[$item['IBLOCK_SECTION_ID']] ?? null; } ) מנהל את הקאשינג של רכיבי המשנה שלו. אם בהגדרות הסעיף יש "אל תשמור במטמון", הקאשינג מושבת עבור כל העץ, כולל סעיפי רשימת מוצרים. בדקו בהגדרות האתר: init.php. קאשינג מתויג (Bitrix Cache Engine) מהיר פי 3 מקאשינג קבצים סטנדרטי—השתמשו בו.

אופטימיזציית תבניות

מיניפיקציה של תבניות PHP. Bitrix מרכיב עמודים מעשרות כוללים (includes). כל $APPLICATION->IncludeComponent('bitrix:catalog', '.default', [ 'CACHE_TYPE' => 'N', // <- убийца производительности ]); הוא קריאת מערכת קבצים. בשרתי HDD, זה לוקח 5–15 אלפיות השנייה לכל קובץ. פתרון: OPcache עם 'CACHE_TYPE' => 'A', // автоматически по настройкам сайта 'CACHE_TIME' => 3600, // секунды בסביבת ייצור (אינבלידציה ידנית של מטמון לאחר פריסה).

העבירו בלוקים כבדים ל-AJAX. וידג'טים כמו "מוצרים דומים", "נצפו לאחרונה", "פופולרי בקטגוריה" הם מועמדים ל-AJAX. העמוד הראשי נטען מהר, והווידג'טים נטענים במקביל.

דוגמת תוצאה

חנות מקוונת לחומרי בניין עם 180,000 פריטים. לפני האופטימיזציה: TTFB 2.1 שניות, 380 שאילתות SQL לעמוד קטגוריה. אחרי: ביטלנו bitrix:catalog בשלושה רכיבים, חיסלנו שתי שאילתות N+1, הפעלנו OPcache עם Настройки → Настройки продукта → Кэширование. תוצאה: TTFB 420 אלפיות השנייה, 38 שאילתות SQL, LCP 1.9 שניות. הפחתת עומס השרת אפשרה חיסכון משמעותי בשכירות VPS ($500 בחודש).

שלבי האופטימיזציה

שלב תוכן משך
ביקורת פרופיל 5 עמודים מובילים, זיהוי צווארי בקבוק, דוח עם המלצות 1–2 ימים
אופטימיזציית קאש הגדרת קאשינג לרכיבים, הפעלת קאש מתויג, בדיקת Composite 1–2 ימים
חיסול N+1 שיפוץ תבניות עם שאילתות מצטברות, אופטימיזציית קריאות API 2–5 ימים
Composite הגדרה והתאמת תבנית למצב Composite, בדיקות 2–4 ימים
מסירה העברת תיעוד, גישות, הדרכת מפתח, אחריות ל-30 יום יום אחד

תוצרים כוללים: תיעוד שינויים, גישה לכלי פרופילינג, הדרכת מפתח, ואחריות ביצועים ל-30 יום.

בקשו ביקורת ביצועים לאתר שלכם—אנחנו מוצאים צווארי בקבוק ביום אחד. או קבלו ייעוץ על אופטימיזציית עיבוד. צרו קשר לאבחון.