Comprehensive Image Optimization for 1C-Bitrix: WebP, AVIF, srcset

Bitrix Image Optimization: Where a Site Loses Speed

The main bottleneck is almost always the same: source files are uploaded straight from a camera or from a layout into the media library — several megabytes per file — and 1C-Bitrix serves them in listings as-is.

A page with a dozen such images doesn't begin rendering until the browser has pulled all of them one by one. Loading speed drops not because of the server or the template, but because of image weight.

The second typical spot is size duplication. The component generates a preview for each output area, but the resize is done from the original rather than from an intermediate copy, and dozens of variants of a single frame pile up on disk.

Worse, when an image is updated, the old previews aren't always rebuilt — a stale file remains on the page, while the new one sits there as dead weight.

The third is formats. Even correctly sliced JPEGs and PNGs lose to modern formats in weight at the same visual quality, and without the srcset attribute a mobile device's browser pulls the desktop version of the frame.

On top of that, images without explicit dimensions and with lazy loading set on the first screen block rendering and spoil responsiveness metrics.

We break down how this is addressed: where to enable preview rebuilding, how to set up delivery of modern formats and adaptive sets so that page weight drops without losing image quality.

What comprehensive image optimization delivers

The effect is measured not "by eye" but by the metrics that both the search engine and the visitor see.

Comprehensive image optimization in 1C-Bitrix is not a one-time repackaging of files, but a combination of three layers: modern formats, adaptive delivery, and proper caching. Let's break down exactly what changes at each one.

Page weight and rendering speed

The main gain comes from converting raster graphics to WebP and AVIF while keeping the original as a fallback variant.

For a typical gallery or catalog, this reduces the weight of the media portion by 2–4 times without visible quality loss — provided that the conversion happens on the server side, rather than "on the fly" with every request.

The second layer is the srcset attribute with multiple sizes and explicit width/height. The browser itself selects the appropriate variant for the screen density, while the reserved dimensions eliminate layout shifts during loading.

Together, this shifts the key rendering metrics: content appears earlier, and layout shift drops to zero.

How this affects bounce rates and conversion

Timeout bounces are a direct consequence of heavy pages on mobile networks. When media weight drops by several times, the share of sessions where the user leaves before rendering noticeably decreases, and the depth of viewing grows.

For catalogs and product pages, this translates into a measurable increase in leads: the faster a product page opens, the higher the chance that it will be viewed to the end and added to the cart.

Caching deserves special mention: correct headers and file versioning make repeat visits almost instantaneous, without loading the server with repeated generation.

We work with the combination of 1C-Bitrix and the platform's built-in mechanisms, so the changes do not break existing templates and do not require manually rebuilding the catalog.

Delivery formats and modes: WebP, AVIF, srcset

The delivery format is not about "enabling WebP in the settings," but about choosing between three different architectures for storing images.

Where exactly the conversion happens determines the load on the server, the speed of the first response, and what a browser that cannot read the new format will receive.

WebP is now served by all current browsers, AVIF gives noticeably less weight on photos but takes longer to encode — it makes sense to keep it as the second candidate in <picture> and substitute it via <source type>, leaving WebP and the original JPEG as fallbacks.

<cite>Bitrix</cite> can work with both formats, but without explicit configuration it serves whatever is in the upload folder — that is, the original JPEG.

Adaptive images are built around srcset and sizes: the browser itself picks the file for the window width and screen density, so there is no need to serve the mobile the same image as the monitor.

We attach lazy loading to everything below the first screen, and we set priority loading for the images in the header and the first banner — otherwise they fall into the queue and delay rendering.

The practical takeaway: pre-generation plus srcset give predictable delivery without loading the CPU, while on-the-fly conversion remains for those places where the image appears at the moment of the request. Next we look at how this coexists with caching and a CDN.

How we implement optimization: stages of work

Work proceeds in iterations: first we measure, then we change, then we verify on real traffic. Below is the typical sequence we follow on projects with 1C-Bitrix.

1. Image audit. We build an inventory: how many files are in the media library, which formats and weights prevail, where images are served at their original size instead of adaptive ones. We look at how thumbnail generation is arranged in components and templates, where output goes directly from infoblock properties bypassing handlers.
2. Baseline measurement. We record metrics before changes: page weight, load time on a mobile connection, share of images without modern formats. Without this reference point, the effect cannot be proven later.
3. Pipeline setup. We enable conversion to WebP and AVIF, configure delivery via srcset with multiple resolutions, and adjust component templates so that output goes through a single handler rather than scattered calls.
4. Production rollout. We roll out in stages: first on a high-traffic section, then on the rest. We keep legacy formats as a fallback for browsers without support.
5. Result verification. We compare metrics against the baseline, check delivery correctness on different devices, and make sure the cache and CDN are not serving stale files.
6. Regulations and monitoring. We hand over image-handling rules for editors and set up automatic checks for new uploads — so that six months later a content manager doesn't reduce all the optimization to zero.

Each stage ends with an artifact: an audit report, a configuration, a list of modified templates, or a regulation. This allows returning to any step and understanding what exactly produced the effect.

What the client receives upon completion of the work

The work does not end with "we enabled WebP and AVIF" — it ends with the handover of a complete package that your team can continue to work with without us. Everything that was changed in production is documented in configurations and regulations, not in chat messages.

• Configurations: rules for conversion to WebP and AVIF, sets of widths for srcset, quality thresholds, behavior when serving the original to browsers that do not support modern formats.
• Processing pipeline diagram: exactly where re-compression occurs — during upload to the media library, during resize by a component, or via a batch job over the already accumulated archive — with failure points and the order of re-running.
• Caching policies: lifetime of generated variants, invalidation when the source is replaced, rules for CDN and reverse proxy, so that after updating an image the old file is not served.
• Cleanup regulations: lifecycle rules for deleting orphaned variants and limiting storage growth, so that the directory does not grow uncontrollably.
• Documentation: what is configured and where, how to add a new width or format, how to roll back a change if metrics have dropped.
• Before/after report: LCP and page weight measurements on a representative sample before and after the work, indicating which templates benefited the most.
• Coverage map: a list of templates and sections where adaptive delivery is already working, and where exceptions remain — with timelines and reasons.

Each item has been agreed upon with your engineers: configurations are stored in the version control system, regulations — in your knowledge base. The handover is accompanied by a walkthrough, so that changes are made deliberately, not at random.

Case study: how we sped up an online store's catalog

The client is an online store on 1C-Bitrix with a catalog of several thousand product items.

Each product card pulled the original JPEGs straight from the uploads folder: the same photo was served at full size in the listing, in the product card, and in the "similar" block.

A category page weighed close to 9 MB, and the first render on mobile stretched to 6-7 seconds — under those conditions, some shoppers left before the catalog ever loaded.

What we did

We reworked the image output at the component template level and hooked up the built-in resize mechanism with WebP and AVIF generation: the browser receives a modern format, while the original JPEG remains a fallback for older clients.

For each product card we wrote a srcset with several widths so that a phone doesn't download the desktop version of the image. We set up lazy loading for everything below the first screen, and priority loading for the main product photo.

We separately closed the regression gap: the rule for clearing the resize cache was tied to the element save event, otherwise after editing a price or description a product card could serve a stale thumbnail.

We ran the catalog through thumbnail regeneration so that no "holes" from old products remained.

Metrics before and after

Page weight dropped fivefold thanks to formats and adaptive sizes, not by degrading quality — visually the images are indistinguishable. The bounce rate fell by 17 percentage points, and add-to-cart conversion grew by 18% relative to the period before the changes.

Measurements were taken on the same set of pages and the same traffic so that the comparison would be fair.

If your catalog runs on Bitrix and product cards take longer than two seconds to load — describe your task, and we'll come back with an estimate and a plan of work on images.

How does on-the-fly conversion differ from pre-generation?

On-the-fly conversion intercepts the request to the original through a handler and serves the compressed variant at the moment of access: the source stays on disk, while WebP or AVIF is assembled for a specific size and screen density. The plus — you don't need to know in advance which widths will be needed, and storage doesn't grow.

The minus — every first request for a new "size + format" combination goes into re-encoding, and under load this is noticeable: the processor is busy encoding, response time grows, and on a weak server the queue of requests accumulates faster than it is processed.

Pre-generation moves this work to the moment of file upload or into a background task: variants in the required formats and sizes are created once and sit ready.

Delivery turns into serving static files — the server doesn't spend resources on encoding on every visit, and the response is predictable.

The limitation is the opposite: the set of sizes is fixed in advance, and if the layout or grid changes, some of the derivatives will have to be rebuilt.

On the other hand, with mass upload of a catalog or gallery, pre-generation removes the peak load that would otherwise fall on the first views.

Choosing a mode is a question of traffic profile and hardware. If images are uploaded rarely and the audience is small, on-the-fly conversion is simpler to maintain: fewer artifacts, nothing to clean up.

When the catalog is large and there are many visitors, pre-generation pays off — the server serves ready files, and the load on the processor doesn't depend on the number of requests.

In practice, a hybrid works more often: common sizes and formats are prepared in advance, while rare combinations are assembled on the fly with caching of the result.

Then repeated accesses to the same variant are no longer re-encoded, and the load peak falls only on the first request.

We look at the page structure, the volume of media, and the resource headroom, after which we fix the mode and cache rules — this way image optimization in Bitrix doesn't turn into a constant source of slowdowns.

Common technical concerns about optimization

Before implementation, the same set of questions usually comes up: will the layout break, will the image lose quality, what about support for old browsers. Let's go through them one by one — with technical details, because that's where things most often get stuck.

Won't quality drop?

A lossy compression format produces a visually identical result at a lower weight if the compression level is matched to the image type.

For photos and banners we select the parameters separately, while for logos and icons with sharp edges we keep a lossless format — otherwise artifacts will appear on the contours.

The original is always preserved: if the quality of a specific file turns out to be insufficient, we roll it back to the source without rebuilding the page.

What about old browsers and compatibility?

Serving is built on a set of sources: the browser itself chooses a supported format, and if it doesn't recognize any of the modern ones — it gets a familiar one. A user on an outdated device sees the same image, just a heavier one.

Additionally, we serve different sizes for the screen width so that a phone doesn't pull a desktop-sized canvas. We check compatibility on real devices, not just in an emulator.

What are the risks and how do we roll back?

The main risk is not the format itself, but a mass rebuild without a backup. That's why we first take a snapshot of the media library and the database, run the processing on a copy, verify the result against control pages, and only then launch it on the production environment.

Rollback is restoring the original files from the copy; the output settings remain in place, so a repeat run doesn't require doing the manual work again.

If you still have doubts about your project — describe the task, and we'll come back with an estimate and a plan.

Let's discuss the image optimization task

To make the estimate substantive rather than a "rough guess," before calculating we need to understand the current state of the catalog and how images are served to visitors.

Below is what we clarify during the first conversation and what data we request: based on it, we calculate the scope of work, the migration order, and the points where a rollback is possible.

• Current format and weight of images: what file types are in the media library, the average and maximum size, whether there are high-resolution source files.
• How thumbnails are generated: built-in Bitrix mechanisms, third-party modules, or manual cropping — this determines where to embed the conversion.
• Output points: component templates, information blocks, sliders, product cards — exactly where the image enters the markup and whether it can be served via srcset.
• Quality requirements: acceptable compression level, priority of visual accuracy or loading speed, whether AVIF is needed or WebP is sufficient.
• Infrastructure: web server configuration, availability of a CDN, caching, access to the converter on the server side.
• Access and policy constraints: maintenance windows, a test environment, the procedure for deploying to production.

With this set, we come back with a plan: which formats we enable, how we configure adaptive sets, what we do with already uploaded files, and how we verify the result on real pages. Describe your task — we'll clarify the details and come back with an estimate and a work plan.