תרחיש טיפוסי: לקוח מריץ קמפיין פרסומי בעמוד הראשי של חנות מקוונת מבוססת 1C-Bitrix, ו-LCP בנייד עולה על 6 שניות. מחצית מהמבקרים עוזבים בלי לחכות לטעינת העמוד. אנחנו עובדים על פרויקטים כאלה באופן קבוע ומצליחים להוריד את ה-LCP ל-2.1 שניות תוך 5 ימי עסקים. במהלך שנות העבודה שלנו צברנו ניסיון בעמידה ביעדים על עשרות פרויקטים — מעל 50 מקרי הצלחה. לדוגמה, בפרויקט אחד הורדנו את ה-LCP מ-8.2 ל-1.9 שניות תוך 5 ימים על ידי הטמעת preload וסליידר סטטי. אופטימיזציית LCP משפיעה ישירות על המרות: שיפור של שנייה אחת ב-LCP מגדיל אותן ב-2–5%.
איך לקבוע מהו אלמנט ה-LCP בעמוד?
הדפדפן קובע אוטומטית את אלמנט ה-LCP — זהו אזור התוכן הגדול ביותר הנראה ב-viewport בטעינה הראשונה. בחנות Bitrix, אלה בדרך כלל:
- באנר/סליידר ראשי בעמוד הבית
- תמונת המוצר הראשונה בעמוד קטגוריה
- תמונת Hero בעמוד נחיתה
אפשר לבדוק באמצעות מספר כלים:
- Chrome DevTools → Performance → הקלטת trace → מצאו סמן LCP ב-Timings — DevTools מדגיש את האלמנט.
- Lighthouse במצב Desktop/Mobile — הדוח מציג LCP והמלצות.
- WebPageTest — waterfall טעינה מפורט עם ציון LCP.
לניתוח מדויק, השתמשו בשילוב: Lighthouse להערכה מהירה, DevTools לפירוט מעמיק.
למה LCP גרוע: שרשרת תלויות
שרשרת טיפוסית לבאנר בסליידר Bitrix:
- הדפדפן מבקש HTML → ממתין ל-TTFB (500 ms – 2 s)
- ה-HTML מנותח →
<script src="swiper.min.js">ב-<head>נמצא — חוסם - Swiper.js (200 KB) נטען, מנותח, ומופעל
- JS מאתחל את הסליידר, יוצר
<img>ב-DOM - הדפדפן מזהה את התמונה → מתחיל לטעון
- התמונה נטענת (PNG/JPEG, 500 KB – 2 MB)
- ה-LCP נרשם
בחיבור 3G איטי זה לוקח 8–12 שניות. אפשר לזרז כל שלב. ההתערבות היעילה ביותר היא לשבור את השרשרת לפני שלב 5 על ידי יידוע הדפדפן על התמונה מראש. טעינה מוקדמת של תמונות יעילה פי 2–3 ל-LCP מאשר דחיסת JPEG פשוטה.
מה זה TTFB ואיך הוא משפיע על LCP?
LCP לא יכול להיות קטן מ-TTFB — עד שהשרת שולח HTML, הדפדפן לא התחיל לעבוד. TTFB (Time to First Byte) הוא הזמן מהבקשה ועד הבייט הראשון של תגובת השרת. באתרי Bitrix TTFB לרוב מנופח בגלל שאילתות SQL לא אופטימליות וחוסר caching. אנחנו פותרים זאת על ידי ניתוח שאילתות איטיות, הוספת אינדקסים והגדרת tagged component cache. בפרויקט אחד מצאנו שאילתה איטית במודול הקטלוג שלקחה 2.3 שניות. הוספנו אינדקס מורכב על שדות TABLE, והשאילתה רצה ב-0.04 שניות. מטרה: TTFB < 200 ms לעמודים עם cache. פרטים נוספים על TTFB ניתן למצוא בערך ויקיפדיה: Time to first byte.
Preload לתמונת LCP
הפעולה היעילה ביותר היא ליידע את הדפדפן על תמונת ה-LCP לפני ניתוח גוף ה-HTML. Preload מאיץ את טעינת התמונה ב-0.5–1 שנייה. זה יעיל פי 2–3 מאופטימיזציית תמונות פשוטה.
<!-- Добавить в <head> ДО всех скриптов и стилей -->
<link rel="preload" as="image" href="/upload/resize_cache/iblock/banner_main.webp" fetchpriority="high" imagesrcset="/upload/resize_cache/iblock/banner_main_800.webp 800w, /upload/resize_cache/iblock/banner_main_1600.webp 1600w" imagesizes="100vw">
ב-Bitrix, הוסיפו דרך <!-- Добавить в <head> ДО всех скриптов и стилей --> <link rel="preload" as="image" href="/upload/resize_cache/iblock/banner_main.webp" fetchpriority="high" imagesrcset="/upload/resize_cache/iblock/banner_main_800.webp 800w, /upload/resize_cache/iblock/banner_main_1600.webp 1600w" imagesizes="100vw"> בתחילת התבנית או ישירות ב-AddHeadString():
// В component_epilog.php или header.php
if ($arResult['BANNER_IMAGE']) {
$GLOBALS['APPLICATION']->AddHeadString(
'<link rel="preload" as="image" href="' . $arResult['BANNER_IMAGE'] . '" fetchpriority="high">',
true // true = добавить в начало head
);
}header.php אומר לדפדפן לטעון משאב זה בעדיפות הגבוהה ביותר, לפני תמונות אחרות.
למה שקופית ראשונה סטטית מהירה יותר מאתחול JS
הבאנר הראשי ב-Bitrix מיושם לרוב כסליידר JS. הבעיה: JS מאתחל את הסליידר אחרי שהסקריפט נטען ומופעל — התמונה מופיעה באיחור. פתרון: הציגו את השקופית הראשונה כ-HTML סטטי, ואתחלו את סליידר ה-JS לאינטראקציה לאחר מכן.
// В template.php компонента главного баннера
$firstSlide = $arResult['ITEMS'][0];
?>
<!-- Статичный первый слайд — браузер видит сразу -->
<div class="banner-slider" id="main-banner">
<div class="swiper-slide swiper-slide-active">
<img src="<?= $firstSlide['IMG']['SRC'] ?>" width="<?= $firstSlide['IMG']['WIDTH'] ?>" height="<?= $firstSlide['IMG']['HEIGHT'] ?>" fetchpriority="high" alt="<?= htmlspecialchars($firstSlide['NAME']) ?>">
</div>
</div>
<!-- JS инициализируется после загрузки страницы -->
<script defer>
document.addEventListener('DOMContentLoaded', function() {
new Swiper('#main-banner', {
/* ... */
});
});
</script>גישה זו מניבה רווח LCP של 1 עד 2 שניות.
אופטימיזציית תמונות
פורמט. WebP נותן גודל קטן ב-25–35% בהשוואה ל-JPEG באותה איכות חזותית. AVIF קטן בעוד 20–30%, אבל תמיכת הדפדפנים מעט פחות טובה. טבלת השוואת פורמטים:
| פורמט | גודל (יחסי) | איכות | תמיכת דפדפנים |
|---|---|---|---|
| JPEG | 100% | גבוהה | כל הדפדפנים |
| WebP | 65–75% | זהה | 95%+ |
| AVIF | 45–55% | גבוהה יותר | 80%+ |
Bitrix יכול לשרת WebP דרך // В component_epilog.php или header.php if ($arResult['BANNER_IMAGE']) { $GLOBALS['APPLICATION']->AddHeadString( '<link rel="preload" as="image" href="' . $arResult['BANNER_IMAGE'] . '" fetchpriority="high">', true // true = добавить в начало head ); } כשזה מופעל ב-fetchpriority="high". לתמיכת AVIF, יש צורך ב-ImageMagick עם תמיכת AVIF או בשירות חיצוני.
גודל. תמונה בגודל 3000×2000 px לבאנר על מסך 1920px היא בזבוז משולש. הגדירו גדלים דרך // В template.php компонента главного баннера $firstSlide = $arResult['ITEMS'][0]; ?> <!-- Статичный первый слайд — браузер видит сразу --> <div class="banner-slider" id="main-banner"> <div class="swiper-slide swiper-slide-active"> <img src="<?= $firstSlide['IMG']['SRC'] ?>" width="<?= $firstSlide['IMG']['WIDTH'] ?>" height="<?= $firstSlide['IMG']['HEIGHT'] ?>" fetchpriority="high" alt="<?= htmlspecialchars($firstSlide['NAME']) ?>"> </div> </div> <!-- JS инициализируется после загрузки страницы --> <script defer> document.addEventListener('DOMContentLoaded', function() { new Swiper('#main-banner', { /* ... */ }); }); </script> או \Bitrix\Main\File\Image::resize():
$resizedImage = \CFile::ResizeImageGet(
$originalFileId,
['width' => 1920, 'height' => 600],
BX_RESIZE_IMAGE_PROPORTIONAL_ALT,
false,
false,
false,
90 // качество
);דחיסה. אופטימיזציה נוספת דרך mozjpeg או oxipng ברמת השרת: הפחתת גודל של 15–20% ללא אובדן איכות. הגדירו דרך מודול nginx .settings.php או אופטימיזטור חיצוני בהעלאת קבצים דרך מטפל האירועים CIBlock::GetPreviewPicture(). פרטים נוספים על הגדרת תמונות ב-Bitrix: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=103&LESSON_ID=10506
המלצות לתמונות רספונסיביות
משתמש נייד עם מסך 375px לא צריך לטעון באנר של 1920px. השתמשו ב-\Bitrix\Main\File\Image::resize():
<img src="/upload/banners/banner_1200.webp"
srcset="/upload/banners/banner_480.webp 480w, /upload/banners/banner_800.webp 800w, /upload/banners/banner_1200.webp 1200w, /upload/banners/banner_1920.webp 1920w"
sizes="100vw"
width="1920"
height="600"
fetchpriority="high"
alt="Главный баннер — оптимизация LCP для 1С-Битрикс">בתבנית Bitrix: צרו מראש מספר גדלים דרך $resizedImage = \CFile::ResizeImageGet( $originalFileId, ['width' => 1920, 'height' => 600], BX_RESIZE_IMAGE_PROPORTIONAL_ALT, false, false, false, 90 // качество ); והציגו ב-ngx_http_image_filter_module. כבר בשלב זה תשיגו שיפור LCP.
מה כלול בעבודה
אופטימיזציית LCP כוללת:
- מפרט טכני עם ניתוח LCP נוכחי והמלצות
- פיתוח והטמעה של preload, סליידר סטטי, WebP
- הגדרת תמונות רספונסיביות ו-srcset
- אופטימיזציית TTFB (אינדקסים, cache, OPcache)
- דוח עם מדידות לפני/אחרי (LCP, TTFB, FID)
- ייעוץ לתחזוקה שוטפת
אופטימיזציית LCP מקיפה היא השקעה עם החזר מהיר. לדוגמה, שיפור LCP ב-2–3 שניות עם שיעור המרה של 2% יכול להניב הכנסות נוספות משמעותיות. התקציב המדויק נקבע באופן אישי לאחר ביקורת.
לוחות זמנים לאופטימיזציית LCP
| משימה | זמן | שיפור LCP |
|---|---|---|
| Preload לתמונה הראשית | 0.5 יום | −0.5–1 ש' |
| שקופית ראשונה סטטית ללא תלות ב-JS | 1–2 ימים | −1–2 ש' |
| המרת WebP + שינוי גודל | יום אחד | −0.5–1.5 ש' |
| אופטימיזציית TTFB | 3–10 ימים | −1–3 ש' |
| Defer/async לסקריפטים לא קריטיים | יום אחד | −0.3–0.8 ש' |
| תמונות רספונסיביות + srcset | 1–2 ימים | −0.5–1 ש' |
בעבודה מקיפה, יעד ריאלי הוא: LCP < 2.5 ש' לנייד, < 1.5 ש' לשולחני בעמודים עם cache.
מעל 5 שנים בשוק, יותר מ-50 פרויקטים מיושמים להאצת אתרי Bitrix. אנחנו מבטיחים תוצאה מדידה — אנו מתעדים מדדים לפני ואחרי. צרו קשר לביקורת LCP. נחזור עם ייעוץ, ותגלו כמה מהר אפשר לשפר את ה-LCP שלכם.
פרטים נוספים על מדד ה-LCP ניתן למצוא בערך ויקיפדיה: Largest Contentful Paint.

