Setting up scroll maps on 1C-Bitrix: what breaks
Scroll maps on 1C-Bitrix are almost always assembled according to one scheme: scroll scenarios are tied to block positions calculated once — at the moment the document is ready.
While the page is static, everything is predictable: the animation step matches the actual position of the section, anchors lead where intended.
As soon as the platform changes the markup after rendering, the previous calculation no longer matches the page, and setting up scroll maps on Bitrix begins to behave unpredictably.
Then failures of scrolling scenarios begin. The composite cache returns markup before event handlers are connected, some elements arrive after the calculation.
Loading blocks and redrawing dynamic components change heights, and scrolling breaks after loading blocks: anchors shift by hundreds of pixels, animations trigger intermittently, and state (active section, progress, menu position) resets at the slightest shift.
The cost of such behavior is not cosmetic. Some buttons stop responding because handlers are attached to elements that are not yet in the document at the time of attachment, and debugging 'screen by screen' does not show the connection between load events and scroll layers.
Below we analyze how this is closed: from diagnosing the initialization order to recalculating maps on every markup change, so that scroll scenarios on 1C-Bitrix work the same on a static page and after loading.
What correct binding of scenarios to scrolling gives
Binding scenarios to scrolling in 1C-Bitrix is not 'so it moves beautifully', but predictability of page behavior: handlers are attached to specific sections and trigger once when a block enters the viewport, not on every document event.
The effect of setting up scrolling is noticeable on long pages with sticky menus, loading sections, and appearance animation — where small errors accumulate into problems.
Interface responsiveness and page weight
If the handler listens to the entire document, the browser recalculates the position of blocks on every shift — scrolling starts to 'stick', especially on phones.
Binding to sections and a visibility threshold removes unnecessary recalculations: interface responsiveness increases, movement becomes smooth. Duplicate animation libraries also go away — page weight decreases, first render happens earlier.
Fewer support requests about animations
A typical flow of complaints looks the same: a block did not appear, a button moved under the header, on a phone a section 'jumps' when the screen rotates.
Stability of scroll scenarios is exactly about this: one binding map, a unified trigger threshold, separate handling of orientation change.
After setup, the share of failures drops to isolated cases, and support requests about animations become several times fewer — edits stop being manual work for each block.
«We take measurements before edits and repeat after — otherwise talk about "it became smoother" says nothing».
Implementation options: custom scenario, library, ready-made module
Scrolling is assembled in several ways, and the choice here is a compromise between expressiveness and predictability of page behavior. Below are the options that are actually chosen between, and the cost of each.
| Option | When it fits | Limitations |
|---|---|---|
| Native browser tools | Appearance of blocks, header fixation, simple effects on scroll | Different behavior in older browsers, complex scene bundles are inconvenient to assemble |
| Pluggable animation library | Many scenes, precise timings, synchronous animation of dozens of elements | Library weight, dependence on its updates, careful restart when returning to the page |
| Solution from the extension catalog | Typical request, tight deadlines, setup from admin panel without editing the template | Limited flexibility, extra code on all pages, updates depend on the author |
| Static states with progressive enhancement | Basic appearance is mandatory for all, animation is an addition | Less spectacular, we design two states: with and without effect |
When native browser tools are enough
The appearance of blocks on scroll, smooth opacity change, panel fixation are covered by the browser's own tools. There are no external dependencies: the page remains light, and behavior does not break when third-party solutions are updated.
Limitations of ready-made solutions from the catalog
The module installs quickly and is configured from the admin panel, but it brings its own markup and scripts on all pages. If the solution stops updating or a non-standard scroll scenario is needed, the output will have to be rewritten — we plan for this in advance.
Implementation stages: markup audit, threshold scheme, assembly, acceptance
Before setting events, we fix what is considered 'read' on this particular page: feed, landing page, and product card behave differently. Scrolling in 1C-Bitrix is almost always distorted by composite cache and lazy loading, so the order of work begins with markup, not code.
Audit of markup and current handlers
We look at which containers actually scroll — sometimes it is an inner block with overflow, not the window. Separately, we check which listeners are already on scrolling and whether events are duplicated when redrawing dynamic elements.
- Inventory of containers and handlers: where scrolling is listened to, what already goes to analytics, where double counting is possible.
- Marking targets: significant blocks get identifiers, service and "sticky" elements are excluded from counting.
- Scheme of trigger thresholds: what depth shares count as an event, step between them, deduplication when returning to top.
- Setting up initialization for cache and loading: binding to container appearance, recalculating document height, restarting without accumulating listeners.
- Testing on real devices: mobile browsers with dynamic address bar, inertial scrolling, slow and fast runs.
- Verification with manual run: we analyze discrepancies in measurements down to the cause.
- Acceptance of work and handover: depth report, threshold scheme, instructions for new blocks.
Threshold scheme and testing on real devices
We select thresholds for the page length, not by template: on a short one, two marks are enough; on a long one, we add a step and describe behavior when document height changes.
Acceptance takes place on live devices and with cleared cache — a single run on desktop will not show either event loss during loading or false triggers from inertial scroll.
Configuration of scenarios, trigger thresholds, documentation
As a result, the client receives not only working scrolling, but also a set of artifacts by which it can be changed without us. Below is exactly what we hand over and why each item is needed.
Configuration of scenarios and comments in code
- Scenario configuration file: for each block, the selector, trigger threshold as a percentage of screen height, step, and animation curve are specified.
- Map of thresholds and bindings — one table "block → scenario → threshold → disable condition": it shows what and when will trigger, without reading code.
- Initialization scheme for loading and caching: where handlers are attached, how they are re-bound to blocks that arrive after loading, and what is taken into account with browser cache.
- Rules for disabling animation for weak devices: checking the system setting "reduce motion", performance margin, and a static fallback.
- Comments in code for each threshold and condition: why this particular value was chosen and what will break if it is shifted.
Edit regulations and knowledge transfer
- Scrolling documentation: entry point, procedure for adding a new block, list of places that must not be touched.
- Edit regulations: who makes changes, on which staging environment we test, which checks are mandatory before deployment, and how to roll back to the previous version.
- Knowledge transfer to the team: a session with your developer and content manager, meeting recording, and a checklist for typical changes — so that editing a threshold does not turn into contacting us.
Case study: catalog with dynamic loading of blocks
The store catalog was assembled from blocks: products were loaded on scroll, filters worked without page reload, cards were added to markup on the fly. Scrolling was configured separately for each template, so editing a template broke already debugged scenarios.
What it was before: failures after loading blocks
Added products appeared on the page, but handlers were not attached to them: the "add to cart" button on the third screen did not work, the gallery did not open.
On mobile, scrolling was jerky — the block height was recalculated after insertion, and the page jumped back to the previous product.
For the buyer, it looked like a non-working store; for support, like a stream of repeated requests for the same scenario. The share of stable triggers did not exceed seven scrolls out of ten, and analyzing each case took hours.
What it became after: metrics and observations
We separated initialization and state: the observer for block appearance subscribes only new cards, and filter and cart data are stored separately from markup.
Jerkiness was eliminated by fixing the container height for the loaded portion and calculating position before insertion.
Over a month of observations, the share of stable triggers reached 99%, list response decreased from several seconds to fractions of a second, and scroll-related requests became isolated — previously they accounted for a quarter of support requests.
«After the release, for the first time in a long time we did not receive a single complaint about scrolling — the scenario stopped being fragile», — comments the work the client's department head.
What to do if scrolling is already built on another library?
The first step is not to rewrite the markup, but to analyze what the library does with the page content.
If it only reads the scroll position and writes an offset to the block wrapper, the page structure remains the same, and replacement comes down to transferring settings: distances, trigger points, acceleration curves.
Rewriting begins where the animation engine itself assembles elements or requires its own nesting of containers.
To evaluate current handlers, we look at which elements listen to scroll events and what they write after them.
Two animation libraries simultaneously calculate position and recalculate styles of the same blocks — resulting in jerks, double recalculations per frame, and desynchronization with sticky headers. From the layer of changes, it is clear who is the leader and who is subject to removal.
What is described by data is transferred without edits: binding a block to the start of a section, delays, appearance order, reverse playback.
Logic based on manual calculations of window heights, frame counters, and handlers that themselves manage positioning has to be reassembled.
Order of conflict removal: the new connection is placed next to the old one, but disabled; we enable it page by page — starting with one section or template, check behavior at different widths, and only then disable the previous set.
The old connection is removed last, so rollback is possible at any stage, and the page does not go into downtime.
The result is a handler map, a transition plan with preserved layout, and an understanding of what changes by configuration and what is rewritten. Describe the task — we will return with an estimate and work order.
Compatibility, rollback, and updates: technical doubts
The scroll map on 1C-Bitrix lives on top of the template: it is tied to section markup and theme classes. Updating the template or modules changes this markup — the scenario stops finding targets.
Therefore, we keep settings in a separate connected file, not in the template body: theme updates do not affect them.
What happens when the template or modules are updated?
We bind the scenario to stable features of blocks, not to ordinal numbers. After the update, we run a check on reference pages — a missing binding point is immediately visible.
What will users with disabled animation see?
We take the system preference "reduce motion" into account with a separate media query. Scrolling becomes instant, parallax and offsets are disabled, content remains readable.
Can the previous behavior be restored?
The configuration is versioned separately from page code. Rollback is returning the previous settings file; we do not touch the core and template, so the previous behavior returns without side effects.
How does it work on mobile?
On narrow screens, a lightweight mode is enabled: heavy effects are off, scrolling is given to the system, section height is calculated by content.
«The page should remain readable without scripts», — an engineer of our team.
Let's discuss the task: what to send for evaluation and work plan
To ensure the evaluation and work plan are based on facts, not guesses, a minimum of input is needed — otherwise the first analysis goes into information gathering, not solving.
Scroll maps almost always break at the junction of template, extensions, and block markup, so it is important to see the whole picture. What to send to the contractor so that we return with specifics:
- addresses of pages where the scroll effect works incorrectly, and a short description: does not start at all, triggers once, jerks during fast scrolling, or triggers on the wrong block;
- access to the closed part of the site or to a test stand — to reproduce behavior without risk to the production environment;
- list of connected extensions, third-party modules, and the template used: conflict between them causes most failures;
- on which devices and in which browsers the problem reproduces, and where everything works normally;
- what edits have already been tried — in the template, scripts, module settings, so as not to go in circles;
- date of the last stable state or a backup: if edits affect the template, a predictable rollback path is needed;
- contact of the person who accepts the result — we will agree with them on the check before start and acceptance criteria.
Having received this, we return with an estimate and work plan: list of edits, rollout order, checkpoints, and how we will make sure that scrolling works on all target pages. Describe the task — we will discuss it substantively and propose the next step.