Preparing Product Photos for Bitrix — Optimization and Upload

Preparing photos for 1C Bitrix: where the catalog breaks

Most often, the catalog breaks not at the layout stage, but at the input — when photo preparation for 1C Bitrix is done "however it turns out": the 1C export provides links to source files, the manager uploads the rest by hand, and the database ends up with three different sets of files for a single product.

After that, the system honestly plays back what it received: previews are not cropped because the source is smaller than the required size, and some bindings are lost during re-import, when the product's XML-ID changes along with the rebuilding of the nomenclature.

Broken product previews are the most noticeable symptom, but not the most expensive one.

Worse is when the image physically exists but the "file — catalog item" link is lost: the product page opens with an empty gallery, search and property filters work, yet add-to-cart conversion drops for no apparent reason.

The cause is usually that image uploads into the catalog bypass the standard mechanism — through direct writes to storage or through an intermediate folder that scheduled maintenance later cleans up.

The third typical failure is bloated files. Photos arrive from a phone or from a supplier at full resolution, without compression or cropping; in a catalog with several thousand items, this turns into tens of gigabytes that get backed up every night and slow down page delivery.

Catalog photo optimization here is not about "shrinking it by eye," but about a predictable pipeline: a single format, control over dimensions and weight, and automatic generation of all required previews on upload.

Let's break down how this gets solved: from file naming and binding rules to the procedure for rebuilding previews when the catalog is updated.

What proper image preparation gives a catalog

Proper preparation of photos for 1C-Bitrix is not "compressing images," but bringing the entire array of catalog images to a single engineering standard: size, format, weight, naming scheme, linkage to trade offers.

When a catalog is populated through exchange with 1C, images land in the information block as-is — straight from the camera, from a supplier's export, from a marketplace.

As a result, files several megabytes in size sit side by side with thumbnails on the same product page, and the server serves them without any adaptation for the screen.

This leads to three measurable consequences. First — catalog delivery speed: a list page with a hundred items pulls along a hundred full-size files, and time to render grows linearly with their total weight.

Second — product page weight: if the gallery is not optimized, the main content takes seconds to load, and the user sees empty frames instead of photos.

Third — card conversion: based on measurements, the bounce rate on mobile traffic rises before the image finishes loading, and the product simply never reaches the buyer.

We build 1C Bitrix photo preparation as part of the exchange, not as manual editing after export. At the input — rules: what we convert to, what size we crop to, which previews we generate for the card, the list, and the mobile version.

Then — automatic processing during import, so the catalog stays lightweight with every update, not just on launch day.

The effect is visible in the metrics: catalog loading speed stops degrading as the number of products grows, product page weight drops many times over, and the share of bounces due to slow loading disappears from the reports. Below we break down how this works at the level of the information block and the exchange.

Methods of preparing and uploading photos: a comparison

There are exactly three methods, and the choice between them is driven not by preference but by catalog size and update frequency.

Manual uploading through the admin panel holds up until the first few hundred items, batch processing covers one-off catalog fills and sales, and synchronization from 1C is about a catalog that changes every day.

Below is an honest comparison with the limitations that surface in the second or third month of operation.

The difference shows up at scale. With manual uploading, each new item is a separate pass through the product page: select a file, wait for processing, check that the photo landed in the right place.

At a hundred products it is still tolerable; at a thousand it is already a dedicated employee's salary, and mistakes are inevitable: mixed-up SKUs, duplicates, broken links.

Batch photo processing removes the routine: images are prepared in batches according to uniform rules, brought to the required aspect ratio and weight, then uploaded in a single pass.

It is the right tool for a one-off catalog fill, but it does not solve the main problem — discrepancies between the catalog on the website and the accounting system.

Catalog automation through 1C image synchronization addresses exactly this link. Photos are tied to stock items by SKU, the exchange picks up only what has changed instead of re-transferring the entire catalog.

In practice it looks like this: the inventory specialist changes a photo in the accounting system — it appears on the website without the content manager's involvement, and a discrepancy between the storefront and the warehouse stops being the norm.

The choice depends on how often the assortment changes. If once a quarter, batch processing is enough. If daily, calculate the cost of manual operations and set up the exchange.

How we structure the photo preparation process

We build the process so that the catalog does not "drift" halfway through: first we record the current state, then we set up processing, and only then do we upload products in batches. Below is the order of work that we repeat on every project.

1. Catalog image audit. We export the product list and check which items have no photos, where there are duplicates, where the source files are smaller than the required size, and where the extension does not match the actual file content. The output is a discrepancy table prioritized by product groups.
2. Photo processing scheme. We define uniform rules: frame proportions, margins around the subject, background, order of shots in the gallery, and the set of additional angles. The scheme eliminates the main cause of inconsistency — when each supplier sends photos in their own way.
3. Conversion setup. We configure the generation of derivative sizes for the card, list, and detail page, the compression format, and quality. We store the source files separately — previews can always be rebuilt from them without losing detail.
4. Link verification. We check that each photo is linked to the correct product and SKU, and that the sort order matches the storefront logic. We catch linking errors before publication: finding them on a live catalog is more costly.
5. Upload regulations. We describe in what form we accept photos, how we name files, where we place them, and who is responsible for verification. We hand the regulations over to your team — new items are added without us.
6. Control upload. We upload a pilot batch, check the page delivery speed of the catalog and the correctness of the cards on different screens. If something diverges from expectations, we adjust the scheme, not individual files.
7. Handover and training. We show employees how to use the regulations and leave an acceptance checklist. After that, support can be handled in-house or handed over to us.

What the client receives after the work

After the project is delivered, you are left with a working pipeline for preparing photos, not a one-off export. We hand over all artifacts to the project repository: they can be edited, extended, and passed on to a new contractor without having to reverse-engineer them.

• Image processing scripts — bringing images to a uniform aspect ratio, cropping by product, generating thumbnails and additional sizes for the catalog card. They run in batches, process new arrivals, and correctly skip files that have already been uploaded.
• Catalog configuration — the structure of sections, product properties, linking images to product variants, and rules for inheriting images from the parent item. Configured so that a new product appears in the catalog without manual template edits.
• Upload documentation — a description of file formats and requirements, the procedure for updating via exchange with the accounting system, and the behavior during re-export and photo replacement.
• Instructions for the content manager — a step-by-step procedure: how to prepare an image, where to put it, what to check before publishing. Written for a person without a technical background.
• Naming and storage rules — a unified file naming scheme and folder structure to avoid duplicates and lost versions when several employees work in parallel.
• Backup scheme — what is saved and how often, and how to restore the source files if a replacement went wrong.
• Acceptance checklist — a set of checks: correct dimensions, absence of broken links, and the page delivery speed of catalog pages after a mass upload.

Each item is accompanied by a short entry in the repository — what it does, what parameters it accepts, and what happens on an error.

This removes dependence on a specific contractor: the content manager works from the instructions, and the developer works from the documentation rather than from memory.

Case study: speeding up an online store catalog

A catalog of 40,000 items, images loaded directly from a 1C export: some thumbnails weigh several megabytes, some are served via broken links.

A product page opened in 6-8 seconds, and the share of broken images reached 12% — the shopper saw gray placeholders instead of the product and left.

We broke down the chain: the 1C export stored originals "as is," without resizing and without a single format.

We set up a photo preparation pipeline — when uploaded to 1C-Bitrix, an image is automatically brought to product form: cropping to proportions, generating several sizes for the product card, catalog, and thumbnail, converting to a modern compression format while preserving transparency. The originals remain in storage, and lightweight copies go to the storefront.

We addressed broken links separately: we added a check at the export stage — if a file can't be read or is missing, the item is flagged and is not published with an empty thumbnail, but instead goes into a report for the content manager. Previously, such products silently went live on the site.

The speedup in results wasn't only from resizing: image caching and correct caching headers eliminated repeated requests to the server when paging through the catalog. Server load during peak traffic dropped — pages are served from cache rather than rebuilt on every request.

A month after implementation, pages per session grew by 18%, and bounce rates on product pages nearly halved. Content managers no longer clean thumbnails by hand — the pipeline does it on every export.

How does batch processing differ from 1C synchronization?

Batch processing and 1C synchronization solve different tasks, although both are about product photos.

Batch processing is a one-time run over an existing catalog: the script takes source files from a folder or archive, brings them to a uniform look (cropping to proportions, converting to a white background, generating a set of sizes for the card, list, and detail page), compresses them, and arranges them into the structure that Bitrix expects.

Synchronization is a regular exchange: a photo is linked to a product by code or SKU and updated whenever the item changes in the accounting system.

The key difference lies in the source of truth and the trigger moment. With batch processing, the truth is the files on disk, and the run is manual or scheduled; with synchronization, the truth is the product card in 1C, and the exchange happens by events or on a schedule.

This leads to different requirements: batch processing needs a predictable folder structure and consistent names, while synchronization needs stable identifiers and protection against overwriting already uploaded images during a partial exchange.

Comparing the methods comes down to three parameters: volume, frequency of changes, and acceptable discrepancy.

If the catalog is uploaded once and then rarely edited, batch processing is cheaper and faster — it doesn't involve exchanging reference data and doesn't depend on the availability of the accounting system.

If the assortment changes daily and photos arrive together with descriptions, then without 1C synchronization the catalog quickly diverges from reality: products appear without images or with outdated ones.

In practice, the choice of approach is rarely either-or.

A workable scheme is an initial batch processing of the entire catalog to quickly get a storefront, followed by 1C synchronization for changes: it picks up new items and updates photos without going through the entire array.

Such a hybrid removes the main pain point — long full runs on every update — and leaves room for rollback: if the exchange delivered a wrong image, the previous version of the file is preserved and restored selectively.

We analyze a specific catalog and say where one-time processing is enough and where ongoing synchronization is needed — describe your task, and we'll come back with an estimate and a plan.

Common technical concerns about photo preparation

Before starting, people usually ask the same questions: will the catalog "break", will the server handle it, will quality be lost during recompression, and how long will it take. Below are answers to the point, without generalities.

Will the server load increase after uploading new photos?

On the contrary — properly prepared images reduce it. We bring files to a uniform size for the card and compress them without visible quality loss: the page serves less data, opens faster, and the server spends fewer resources on delivery. Additionally, we set up caching and lazy loading — heavy photos don't slow down the first screen.

Will image quality suffer during compression?

No, if compression is configured for the product type. For clothing and textiles, detail and color matter more; for electronics, clear contours; for small items, a close-up.

We select the compression level separately by category and check the result on real cards, not "by eye". On screen the difference isn't visible, while the file weight drops several times over.

How long does implementation take, and is it possible to roll back?

Timelines depend on the catalog size: a small storefront — just a few days; a large catalog with thousands of items — in stages, by category. Before uploading, we make a backup, so rolling back to the previous state is possible at any step. The work proceeds without stopping the site: customers see up-to-date cards throughout the process.

If your case isn't on the list — describe the task, we'll look at your specific configuration and come back with an estimate and a plan.

Let's discuss the task of preparing photos for your catalog

To come back with an estimate rather than general words, we need to understand three things: how many items are in the catalog, where the source files come from, and how the export from 1C is set up.

Then we look at what is already configured in the information blocks — property types, detail card templates, resize rules — and where the bottleneck is: in file preparation, in uploading, or in serving images to the visitor.

Describe the task in free form — we will clarify the details ourselves:

• catalog size and section structure: how many products, how many items already have photos, how many do not;
• data source: export from 1C, supplier price list, manual upload via the admin panel, or a mixed scheme;
• current state: how photos get into the information block now and what exactly is unsatisfactory — speed, quality, duplicates, manual labor;
• quality requirements: minimum resolution, uniform background, acceptable proportions, whether additional angles and watermarks are needed;
• constraints: access to the server and admin panel, publication regulations, windows when the catalog must not be touched;
• timelines and priorities: what needs to be closed first, and what can wait until the next stage.

Based on these inputs, we prepare a work plan: which steps we do on the 1C side, which on the Bitrix side, where we set up automatic processing, and where manual verification is needed.

In the estimate, we record the scope, stages, and points where you can verify the result before final delivery.

If technical questions come up during the review — about compatibility with current settings, about migrating already uploaded photos, about rolling back changes — our engineers will sort them out before the start.

Let's discuss the task: send us the inputs, and we will come back with a project estimate and work plan.