CLS Optimization on 1C-Bitrix: Where a Site Loses Stability
Cumulative layout shift on Bitrix almost always consists of several recurring sources, and each of them is visible in the markup.
Banners and sliders that initialize after the main content loads occupy zero height until the image is inserted — the entire block below instantly shifts down.
Custom fonts without a correct font-display cause a flash of swapped text: the text is first rendered with a system font that has different metrics, and after loading it is recalculated and shifts neighboring elements.
Ad and promo blocks inserted via components with deferred output behave the same way: the container appears empty and is filled only after the first render.
Dynamic components — the cart, the authorization block, pop-up panels — change the height of the already-rendered DOM during hydration, and this also contributes to cumulative shift.
A separate category is catalog images without explicit dimensions: the browser does not know the proportions before the file loads and reserves the wrong height.
Interface instability hits quite measurable things. A user misses a button that shifted at the moment of the click — the share of erroneous actions and repeated attempts grows.
Search engines treat layout shift as a page quality signal, so rankings drop even with good content and speed.
On mobile, where the screen is narrow and there are more blocks on it, the effect is amplified: a single incorrectly reserved banner drags the entire first screen along with it.
We break down how this is addressed: from auditing real shifts on live pages to edits in component templates and configuring lazy loading so that space for content is reserved in advance.
What stable layout delivers: the effect in numbers
Interface stability stops being an abstract wish once it is translated into a shift metric.
Tools measure how much elements move at the moment of loading, and this number directly correlates with how a visitor behaves: sharp jumps of banners, fonts, and blocks are perceived as "the site is broken," and a person leaves before they manage to read the offer.
In practice, after fixing container sizes, font metrics, and space for dynamic blocks, the shift metric drops from 0.25–0.4 to values below 0.1 — this is the threshold at which shifts no longer interfere with interaction.
Retention on key pages grows by 10–20%, because the visitor does not lose the click position: the button and the form stay where they saw them.
A separate effect is conversion. When an element does not "move away" from under the cursor, the share of erroneous clicks and repeated attempts falls, and the target action is performed on the first try.
This is noticeable on lead forms and in the cart, where previously some users missed the right button.
The load on support also decreases: typical requests such as "I can't click," "everything jumps on my phone" go away, because the cause was not the client's device but unstable layout. Let's break down how this is closed at the level of templates and settings.
Approaches to eliminating shifts: comparison of options
A shift occurs where the browser learns about a block only after the first render: a banner has loaded, a font has arrived, a reviews widget has been inserted — and all the content below jumps down.
The CLS metric counts not the fact of a change, but the product of the share of the shifted screen and the offset distance, so one large block in the first screen damages the score more than a dozen small edits in the footer. Below are four approaches that, on 1C-Bitrix projects, address different classes of causes.
Comparison of methods
| Approach | When it is suitable | Limitations |
|---|---|---|
| Reserving space | Banners, catalog cards, blocks with a known height | Exact proportions are needed; with adaptive layout, height is set via aspect ratio |
| Resource preloading | Fonts, logo, first-screen image | Helps only with a stable resource address; when substituted via a script, the effect is lost |
| Deferred rendering | Widgets, chats, recommendation blocks, third-party embeds | Requires a reserved container, otherwise the shift simply moves lower |
| Template editing | Components with dynamic output, cache, lazy-load in templates | More costly in effort, but it removes the cause rather than the symptom |
In practice, the methods are combined: first, space is reserved for media and widgets, then critical resources are preloaded, and heavy third-party blocks are moved to deferred rendering.
Manual template editing is applied selectively — where a component outputs different markup with a warm and a cold cache.
What each step provides
Reserving space removes the main share of shifts on the first screen and does not require rewriting component logic. Preloading reduces the window during which a font or logo substitutes an already rendered block.
Deferred rendering isolates third-party embeds that we do not control. Template editing closes the remainder — shifts that are not caught by any of the first three methods.
The order of application depends on which blocks contribute to the metric: first we take measurements by page, then we choose a method for each group of causes.
How we implement CLS optimization: stages of work
CLS optimization is not "fixing a couple of images," but a sequence where each step relies on the measurement from the previous one.
We do not touch the layout until we see the real sources of shift on specific pages and resolutions: the causes on desktop and on mobile are almost always different.
- Layout audit. We map out templates and components: where content loads asynchronously, where blocks are inserted by scripts, which banners and widgets reserve space and which do not. We look separately at pages with dynamic filters and the cart.
- Metrics measurement. We record the baseline CLS value by page groups — home page, catalog, product page, checkout. We take measurements under real loading conditions, not on an empty cache, otherwise the picture is distorted.
- Finding the causes. We match shifts to specific elements: images without defined proportions, fonts with substitution, late-loading recommendation blocks, pop-up banners. The cause is recorded with a reference to the template, not "somewhere on the page."
- Configuring templates. We reserve space for media and ad blocks, set proportions for containers, move critical styles into the first render, stabilize the loading of fonts and dynamic sections. We make edits in component templates so that they are inherited across all pages of the section.
- Verifying the result. We repeat the measurement across the same page groups and scenarios. We compare before/after, check that the edits did not break responsiveness and did not worsen other loading metrics.
- Documentation. We hand over the list of modified templates, the rules for media markup, and a checklist for content managers — so that a new banner or block does not bring the shifts back.
This order delivers a predictable result: the shift goes away not on a single page, but across the entire template, and remains manageable with further content edits.
What the client receives after CLS optimization
After CLS work, the client is left not with "it got faster," but with a set of artifacts that show exactly what changed and how to maintain it going forward. Below is what we hand over as a result.
- Fixed templates and components. The edits are made in the source code, not on top of it: explicit dimensions are set for images and videos, containers are reserved for banners and sliders, and fonts are connected in a way that avoids re-rendering text. Each change is tied to a specific place on the page.
- Configurations and output settings. Component caching, deferred loading of blocks below the fold, and the order in which styles are connected — all fixed in the settings so that the edits don't get lost on the next content update.
- Measurement report. Snapshots of metrics before and after for key templates: homepage, product page, catalog, forms. It shows which elements were causing the shift and how much it has been eliminated.
- List of common causes of shift. A short list for editors: inserting an image without dimensions, a banner without a reserved height, a third-party widget in the flow. So that new materials don't bring the problem back.
- Support guidelines. What we check on every release and content update, which metrics we keep within normal range, and who is responsible for checking before publication.
- Template documentation. Where the critical blocks are located in the structure, which attributes are mandatory, and what cannot be changed without rebuilding the markup.
- Acceptance checklist. A run-through of the pages before handover: dimensions, reservation, fonts, embedded blocks — so that the result is confirmed by measurement, not by eye.
Such a set allows the client's team to independently check new pages and avoid rolling back to the original state a month later. Describe your task — we'll get back to you with an estimate and a plan for your template.
Case Study: How We Eliminated Layout Shifts on a Portal
The client's portal is a corporate website on 1C-Bitrix with a catalog, a personal account, and a request form on every page.
The problem manifested on mobile: during loading, the banner jumped, product cards shifted down, and the "Submit Request" button moved out from under the finger.
The CLS metric hovered around 0.34, with the "good" threshold being up to 0.1 — users missed the buttons and left.
What It Was Before
The main sources of shift: catalog images and banners were rendered without fixed proportions, so the browser didn't know their dimensions before loading. Fonts were loaded without reserving space for metrics, causing text to re-render after substitution.
The recommendation block and the cookie notification were inserted into the flow after rendering — the content beneath them shifted down.
What We Changed
We set explicit proportions for image and banner containers via CSS so that space was reserved before the files loaded. For fonts, we specified fallback font metrics — substitution stopped moving the lines.
The cookie notification and recommendation block were moved out of the flow into fixed layers, and dynamic insertions in the catalog were switched to container height reservation.
Metrics Before and After
| Indicator | Before | After |
|---|---|---|
| CLS (mobile) | 0.34 | 0.06 |
| CLS (desktop) | 0.18 | 0.04 |
| CTA miss rate | high | isolated |
| Page depth | baseline | growth |
Layout stability returned to the "green" zone, and the request form conversion increased — users stopped hitting the wrong button.
Client, department head: "The layout shifts annoyed both us and visitors. After the fixes, the pages stopped jittering, and requests became more consistent — working with the form is no longer confusing."
How does CLS differ from other stability metrics?
CLS measures not speed but layout stability: how much elements shift during loading.
Timing metrics — LCP and INP — answer the question "how fast," while CLS answers "how predictable." A user can receive a page in fractions of a second, but if a banner, font, or recommendations block shifted the text down right at the moment of a click, they will tap in the wrong place. It is precisely this class of failures that CLS catches.
Technically, the metric is calculated as the sum of shifts of visible elements, weighted by area and distance of displacement, over the entire lifetime of the page.
A shift that occurs in the first milliseconds, before content appears, is not penalized — the browser considers it expected.
What gets penalized is what the user already sees and has started reading: the loading of a web font that makes text jump to a different typeface, the insertion of an ad block without reserved height, the "jump" of a button when icons finish loading.
The key difference from speed metrics lies in the nature of the problem. LCP and INP are improved by acceleration: caching, compression, loading priorities.
CLS is almost always cured not by speed but by layout discipline: explicit dimensions for images and embedded blocks, font-display and font preloading, reserving space for dynamic insertions.
On 1C-Bitrix this is especially noticeable: components and templates often inject content asynchronously, and without fixed containers the page "breathes" with every additional load.
For perception, the difference is fundamental. A slow but stable page irritates with waiting, while a fast but "jumping" one feels unreliable: the user does not trust the interface and leaves, without even realizing that it was fast.
That is why CLS is evaluated separately from speed and fixed with separate techniques — more on that below.
Common technical concerns about CLS optimization
Before starting, it is important to separate two classes of shifts: those created by the markup (images and banners without reserved dimensions, fonts with a substituted typeface, blocks that are drawn in by a script), and those that come from dynamic components.
The former are fixed in the template and styles, the latter — by setting up deferred output and server-side cache. On Bitrix, it is most often the latter that get in the way: the component delivers content after loading, and no space is reserved for it.
Compatibility with the current template is checked before any edits: we take a measurement across the key page templates, record which blocks contribute to the shift, and only then touch the markup.
If the site uses composite cache, edits are made in such a way as not to break caching and not to force the page to be rebuilt on every request.
Will the edits affect other metrics — load speed, rendering?
Reserving space for images and blocks usually improves the other indicators as well: the browser understands the page structure earlier and does not reflow it. The risk is the opposite — if you reserve too much, empty zones will appear.
That is why we take dimensions from the real proportions of the content, not "by eye," and check mobile and desktop layouts separately.
How long does the work take, and can it be done in stages?
First comes measurement and analysis of the causes, then edits to the "heaviest" blocks, then a repeat measurement and cleanup of the remainder.
Staging is useful here: after the first wave of edits, the bulk of the shift is gone, and the remainder can be closed without taking the site down. Exact timelines depend on the number of templates and dynamic blocks — we calculate them after the analysis.
What about support after optimization?
The metric can "drift" after a template update, the addition of a new banner, or a change of widget provider.
That is why the handover includes a short checklist for the content manager and the developer: which attributes are mandatory on images, how to add blocks so as not to create a shift. With ongoing support, we return to measurement after significant layout changes.
Let's discuss your layout stabilization task
Layout stability is something that only shows up on real devices and real traffic. Describe exactly where the content "jumps": on a product card, in a news list, on a page with dynamic blocks, or when banners load.
The more specific the symptom, the more precisely we can pinpoint the source of the shift instead of trying everything at random.
To come back with an estimate and a work plan, it helps us to understand the context:
- which templates and components are involved on the problem pages;
- how images and media are rendered — whether container dimensions are set in advance;
- whether there are dynamically loaded blocks, banners, or pop-up elements;
- how the layout behaves on mobile and on a slow connection;
- which metrics you are already collecting and under what conditions;
- whether there are deadlines for rolling out fixes to production;
- who on the client side accepts the result and verifies stability.
Based on these inputs, we will put together a plan: where it is enough to lock down container dimensions, where the order in which components are rendered needs to be reworked, and where the loading logic needs to be revisited.
The estimate will be tied to specific pages and templates, not to an abstract "let's optimize everything."
Describe your task — we will come back with an estimate and a work plan for stabilizing the layout.