Automatic image optimization: where the bottleneck is
A catalog with several thousand items almost always runs into images, not the application server. While product cards are served as original files, the first screen of the list weighs tens of megabytes, and the browser spends time parsing them instead of rendering. By that moment, the user is already scrolling further—or leaving for a competitor.
The bottleneck in delivery is visible from measurements: server response time is normal, but the page on a mobile connection takes several seconds to assemble.
The reason is the queue of requests for images and the lack of adaptation to the screen: a phone receives the same file as a wide monitor.
The second reason is more persistent—heavy files in the catalog remain that way forever. The uploader does not recompress them on save, the template outputs the full size in the preview, and the folder grows along with the assortment. Backups and channel load also grow every time a section is opened.
Then metrics come into play: slow catalog loading on mobile reduces browsing depth and the share of users reaching the cart, and search engines factor page weight into ranking. It turns into a vicious circle—more impressions, but performance drops.
Let's break down how this is closed: automatic image optimization recompresses the file to WebP or AVIF on upload, prepares a set of sizes for different screens, and serves the required variant from cache. Next—what exactly needs to be configured so it works without manual work by a content manager.
What changes after implementation: effect in measurable values
After implementing automatic optimization, originals remain in storage as master copies, while the browser is served a variant in a modern format—for example, WebP—taking into account what a specific client supports.
On a catalog with product photos, this reduces the volume of image transfer by several times: the page sends less data on every view, and the same communication channel supports more simultaneous visitors.
Delivery speed increases not only because of the response size. The server stops spending resources on serving heavy files, static delivery moves to a caching layer, and application code handles page logic.
Under peak load, this is visible in response time and in the number of sessions the server holds without degradation.
Behavioral metrics also change: content appears on screen earlier, and users leave less often before they have seen a product or article. Browsing depth grows, and the bounce rate on the first screen decreases—especially on mobile connections.
A separate effect is stability under load. A class of failures related to serving originals disappears: timeouts, growth of the request queue, crashes during a newsletter or sale.
Optimization works at the delivery level, not as one-off manual processing: a file uploaded by an editor automatically receives the required variants.
Processing options: batch, on-demand, hybrid
The processing mode is chosen not by format, but by how the catalog lives. The same set—AVIF for modern browsers, WebP as a fallback—has a different preparation cost depending on the conversion moment: in advance, at request time, or at both points.
The question of adaptive sets for screens is resolved separately: several widths are generated from the original, and the markup tells the browser which one to take for a specific screen.
Without this, a phone pulls the desktop file—extra traffic and rendering delay visible in loading metrics.
| Mode | When it fits | Limitations |
|---|---|---|
| Batch catalog processing | The catalog is stable, files change rarely, a full set of derivatives is needed in advance | When templates or quality policies change, the entire catalog is rebuilt; during rebuild, two sets coexist and storage volume grows |
| On-demand processing | There are many images and they are updated constantly, and the catalog grows unpredictably | The first request is cold—it takes longer to serve; warm-up and cache are needed, otherwise all work falls on the application server |
| Hybrid mode | Popular pages are stable, while the long tail changes | Two cache policies and explicit invalidation by key: without it, versions of the same file diverge and the browser receives a stale image |
In practice, the choice of processing mode is rarely pure: a product catalog goes to batch, user content goes on-demand, and at the junction, popular pages are warmed up.
We fix the boundary between modes and invalidation rules in the configuration so behavior is predictable under any update scenario.
Optimization as a regular process: implementation stages
One-off image compression has an effect only until the first mass catalog upload. To keep the gain, image preparation is embedded into a regular process: let's break down the stages that go from audit to handover of regulations.
- Catalog delivery audit. We take a snapshot: which formats the server serves, the average image weight in a product card, the share of files without adaptive variants, and how many extra sizes are generated per photo.
- File processing scheme. We identify all image entry points—upload from the admin panel, batch catalog import, files from the repository. For each, we determine where the derivative version is created and where it is stored.
- Preparation pipeline setup. We connect transcoding to modern formats, sets of widths for layout resolutions, and rules for selecting a variant based on the visitor's browser capabilities.
- Compression quality check. We compare originals and results on typical cards: gradients, small text, product photos on a white background. Separately, we check that artifacts do not appear on previews in the list.
- Control on real traffic. We look at how many requests go to unprepared files, how the cache behaves when a product is updated, and what happens when reverting to a previous image version.
- Handover of regulations. We provide instructions for content managers, a checklist for adding a new section, and the procedure for changing a page template.
After the regulations are handed over, the customer's team connects new categories and page types itself—image preparation follows the same route, without one-off development tasks.
Configurations, regulations, and documentation: what we hand over
The engineering part of image optimization is not a checkbox in settings, but a set of configurations and rules by which files reach the site. We hand over everything so the team can change parameters itself and understand the consequences of each edit.
- Processing scheme — the file path from upload to the media library to delivery to the browser: where WebP and AVIF are generated, which size versions are created for high-density screens, and how the variant for a specific place in the template is selected.
- Quality configuration — compression parameters separately for photos, screenshots, and graphics with text, with thresholds below which the frame loses detail.
- Version storage policy — how many derivative files live next to the original, what is deleted on replacement, and how to roll back to the previous variant if the new one turns out worse.
- File output documentation — markup rules on the template side: where a set of sizes is mandatory, where lazy loading is used, and how priority is set for the first-screen image.
- Instructions for editors — what is permissible to upload directly, when a higher-resolution source is needed, and how to check the result in the preview before publishing.
- Publication regulations — the procedure for mass catalog updates: when derivative rebuild runs automatically and when manual verification is needed.
Each document is tied to a specific configuration file or automation step so it does not diverge from reality. A month after launch, we compare thresholds and rules with actual data and refine them.
Catalog case: metrics before and after implementation
Catalog case for an online store on 1C-Bitrix: about 40,000 product cards, each with 4-6 photos from a shoot.
Originals were placed into the catalog as is—without variants for mobile screens—so the category page pulled the entire gallery and was served directly by the application server.
What was changed
We assembled a derivative pipeline: on photo upload, WebP and AVIF are automatically generated in several widths; the original remains as the source and does not appear in the markup.
The page serves a set of variants, the browser selects the appropriate one based on screen and format support, and images below the first screen are lazy-loaded.
Derivatives are cached at the edge with versioning by content hash—when a photo is replaced, only its file is updated, and the rest of the cache is not purged.
Metrics before and after
- Category page volume — reduced by 6-8 times, down to the level of a regular text page.
- File delivery time from the edge — 4-5 times faster; cache hit rate increased from 40% to 94%.
- Full catalog load on a smartphone: 9-11 seconds — down to less than three.
- Peak image traffic moved from application servers to the edge, and the headroom for simultaneous visitors tripled.
The result of implementation is stable delivery speed as the catalog grows: a new product card or photo replacement does not require manual graphics rebuild, and storage and traffic costs stopped growing along with the number of products.
What to do if the catalog is already filled with heavy files?
A catalog with several thousand items is not re-uploaded entirely: changing names and paths resets what has accumulated—pages already in search results stop opening, external image links break, and search re-crawls sections that previously ranked.
Phased file migration lacks this drawback: the address remains the same, and only what is served at it changes.
Technically, it works like this. The original lies at the same path, and the server uses the request header to determine whether the browser supports AVIF or WebP and serves the appropriate variant; everyone else gets the original file.
An alternative is markup with multiple sources: the browser itself selects the format from those offered. The file name and page address do not change, so saved positions, links, and images in search results remain in place.
The gradual transition is built section by section, starting with the heaviest pages. Process a section—verify the actual weight and delivery speed, then move to the next. If quality drops on a particular page, the rule is disabled for it, not for the entire catalog.
Page reindexing does not require re-crawling all addresses: it is enough to notify search engines about the update—rebuild the sitemap with modification dates, submit it, and check in the webmaster panel that the bot receives the new format.
After that, only monitoring remains: the share of pages with the new format, average image weight, delivery time. The catalog transitions in several passes, without a drop in search visibility and without stopping the site.
Common technical questions: quality, cache, and old files
Image optimization runs into not the converter itself, but the questions that come up at acceptance: will the image lose its appearance, what to do with the previous catalog, and how to roll everything back if template edits go wrong. Below are answers to what customer engineers most often ask.
Will the images become noticeably worse?
Lossy compression is always a compromise between weight and detail, so we do not take parameters "by default" from the library.
We configure them on a reference sample: a typical product shot, a portrait, text on a card, a gradient background—and compare the result before and after visually and by pixel difference.
We look not only at the overall appearance but also at small details where compression usually reveals itself: contours, thin lines, noise on a solid background.
Where are converted versions stored?
Intermediate storage is moved to a separate directory or cache, while the original remains the source of truth.
A repeated run does not recompress what is already ready—it checks the file version and adds only new items, so editing one image does not trigger reprocessing of the entire catalog. The cache can be cleared at any time: it will be rebuilt from the originals.
How is a change rolled back?
The rollback procedure is flipping a flag in the configuration: delivery of converted files is disabled, and the site immediately returns to the original images.
No new build, no markup edits, no waiting for deployment—this is important if after release it turns out that some pages serve different content.
What about the old catalog and templates?
Old files are not renamed or deleted at the first stage: we mark them and continue serving them at their previous addresses so as not to break external links and bookmarks.
Templates where an image is inserted hard-coded or assembled in markup are handled selectively—compatibility with the current layout is checked on a copy before switching traffic.
If doubts remain about a specific catalog—describe the task: we will look at the structure, estimate the volume, and come back with a work plan.Let's start with the task: what to discuss and what data to send
To make the estimate based on facts rather than "by eye", we need a snapshot of the current state.
Everything needed is usually already at hand: environment configurations, page examples, and an understanding of who is responsible for infrastructure and release of updates.
- Task description: which sections automatic image optimization affects, where heavy files currently reside, and what users complain about.
- Examples of catalog and product card pages — 5–10 addresses with different image types: galleries, previews, banners, illustrations in text.
- Access to the infrastructure or its diagram: where originals are stored, what sits in front of the application, and who owns storage and file delivery.
- Environment constraints: prohibition on editing templates, mandatory support for old browsers, change regulations in production.
- Current metrics: load time, share of heavy pages, storage volume — using them, we will compare the result after implementation.
- Contact of an engineer on the customer side who knows the update release structure and approval procedure.
- Expectations for timelines and order of work start: pilot on one section or rollout across the entire site at once.
From this, we assemble an estimate and work plan: stages, risks, rollback points, and start order. Describe the task and send what is already available—we will come back with an estimate and plan.