Typical scenario: a client runs an ad campaign on the main page of a 1C-Bitrix online store, and LCP on mobile exceeds 6 seconds. Half the visitors leave without waiting for the page to load. We regularly work on such projects and bring LCP down to 2.1 seconds in 5 business days. Over our years of work, we have accumulated experience hitting target metrics on dozens of projects — over 50 successful cases. For example, on one project we reduced LCP from 8.2 to 1.9 seconds in 5 days by implementing preload and a static slider. LCP optimization directly impacts conversion: improving LCP by 1 second increases it by 2–5%.
How to determine the LCP element on a page?
The browser automatically determines the LCP element — it is the largest content area visible in the viewport on first load. In a Bitrix store, these are typically:
- Main banner/slider on the homepage
- First product image on a category page
- Hero image on a landing page
You can check using several tools:
- Chrome DevTools → Performance → record trace → find LCP marker in Timings — DevTools highlights the element.
- Lighthouse in Desktop/Mobile mode — the report shows LCP and recommendations.
- WebPageTest — detailed loading waterfall with LCP indicated.
For precise analysis, use a combination: Lighthouse for quick assessment, DevTools for detailed breakdown.
Why LCP is bad: dependency chain
Typical chain for a banner in a Bitrix slider:
- Browser requests HTML → waits for TTFB (500 ms – 2 s)
- HTML is parsed →
<script src="swiper.min.js">in<head>is found — blocking - Swiper.js (200 KB) loads, parses, executes
- JS initializes the slider, creates
<img>in the DOM - Browser detects the image → starts loading
- Image loads (PNG/JPEG, 500 KB – 2 MB)
- LCP recorded
On a slow 3G connection this takes 8–12 seconds. Each step can be sped up. The most effective intervention is to break this chain before step 5 by informing the browser about the image in advance. Preloading images is 2–3 times more effective for LCP than simple JPEG compression.
What is TTFB and how does it affect LCP?
LCP cannot be less than TTFB — until the server sends HTML, the browser hasn't started working. TTFB (Time to First Byte) is the time from request to the first byte of the server response. On Bitrix sites TTFB is often inflated due to suboptimal SQL queries and missing caching. We solve this by analyzing slow queries, adding indexes, and configuring tagged component cache. On one project we found a slow query in the catalog module that took 2.3 seconds. We added a composite index on TABLE fields, and the query executed in 0.04 seconds. Goal: TTFB < 200 ms for cached pages. More details on TTFB can be found in the Wikipedia article: Time to first byte.
Preload the LCP image
The most effective action is to tell the browser about the LCP image before parsing the HTML body. Preload speeds up image loading by 0.5–1 second. This is 2–3 times more effective than simple image optimization.
<!-- Add to <head> BEFORE all scripts and styles -->
<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">
In Bitrix, add via AddHeadString() at the beginning of the template or directly in header.php:
// In component_epilog.php or header.php
if ($arResult['BANNER_IMAGE']) {
$GLOBALS['APPLICATION']->AddHeadString(
'<link rel="preload" as="image" href="' . $arResult['BANNER_IMAGE'] . '" fetchpriority="high">',
true // true = add to the beginning of head
);
}
fetchpriority="high" tells the browser to load this resource with the highest priority, ahead of other images.
Why static first slide is faster than JS initialization
The main banner in Bitrix is often implemented as a JS slider. The problem: JS initializes the slider after the script loads and executes — the image appears with a delay. Solution: render the first slide as static HTML, initialize the JS slider for subsequent interaction.
<!-- In template.php of the main banner component -->
$firstSlide = $arResult['ITEMS'][0];
?>
<!-- Static first slide — browser sees it immediately -->
<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 initializes after page load -->
<script defer>
document.addEventListener('DOMContentLoaded', function() {
new Swiper('#main-banner', { /* ... */ });
});
</script>
This approach yields an LCP gain of 1 to 2 seconds.
Image optimization
Format. WebP gives 25–35% smaller size compared to JPEG at the same visual quality. AVIF is another 20–30% smaller, but browser support is slightly worse. Format comparison table:
| Format | Size (rel.) | Quality | Browser Support |
|---|---|---|---|
| JPEG | 100% | High | All |
| WebP | 65–75% | Same | 95%+ |
| AVIF | 45–55% | Higher | 80%+ |
Bitrix can serve WebP via \Bitrix\Main\File\Image::resize() when enabled in .settings.php. For AVIF support, you need ImageMagick with AVIF support or an external service.
Size. An image 3000×2000 px for a banner on a 1920px screen is triple waste. Set sizes via CIBlock::GetPreviewPicture() or \Bitrix\Main\File\Image::resize():
$resizedImage = \CFile::ResizeImageGet(
$originalFileId,
['width' => 1920, 'height' => 600],
BX_RESIZE_IMAGE_PROPORTIONAL_ALT,
false,
false,
false,
90 // quality
);
Compression. Additional optimization via mozjpeg or oxipng at the server level: lossless quality 15–20% size reduction. Configure through the nginx module ngx_http_image_filter_module or an external optimizer on file upload via the OnFileSave event handler. More details on image configuration in Bitrix: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=103&LESSON_ID=10506
Recommendations for responsive images
A mobile user with a 375px screen should not load a 1920px banner. Use srcset:
<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="Main banner — LCP optimization for 1C-Bitrix">
In the Bitrix template: pre-generate multiple sizes via CFile::ResizeImageGet() and output in srcset. Even at this stage you will gain LCP improvement.
What's included in the work
Turnkey LCP optimization includes:
- Technical specification with current LCP analysis and recommendations
- Development and implementation of preload, static slider, WebP
- Configuration of responsive images and srcset
- TTFB optimization (indexes, cache, OPcache)
- Report with before/after measurements (LCP, TTFB, FID)
- Consultation on further maintenance
Comprehensive LCP optimization is an investment with quick payback. For example, improving LCP by 2–3 seconds with a 2% conversion rate can yield significant additional revenue. The exact budget is discussed individually after an audit.
LCP optimization timelines
| Task | Time | LCP improvement |
|---|---|---|
| Preload main image | 0.5 day | −0.5–1 s |
| Static first slide without JS dependency | 1–2 days | −1–2 s |
| WebP conversion + resize | 1 day | −0.5–1.5 s |
| TTFB optimization | 3–10 days | −1–3 s |
| Defer/async for non-critical scripts | 1 day | −0.3–0.8 s |
| Responsive images + srcset | 1–2 days | −0.5–1 s |
With comprehensive work, a realistic target is: LCP < 2.5 s for mobile, < 1.5 s for desktop on cached pages.
Over 5 years on the market, more than 50 implemented projects on speeding up Bitrix sites. We guarantee a measurable result — we record metrics before and after. Contact us for a free LCP audit. Get a consultation and find out how quickly your LCP can be improved.
More details about the LCP metric can be found in the Wikipedia article: Largest Contentful Paint.