FID/INP Optimization for 1C-Bitrix: Accelerating Site Response

Optimizing FID (First Input Delay) for 1C-Bitrix We've encountered projects where INP reached 1500 ms on a typical Bitrix store. A click on the "Buy" button — and the user waits more than a second. Every 100 ms of delay reduces conversion by 7%. That's direct lost revenue. Our experience shows: a

Our competencies:

Frequently Asked Questions

Optimizing FID (First Input Delay) for 1C-Bitrix

We've encountered projects where INP reached 1500 ms on a typical Bitrix store. A click on the "Buy" button — and the user waits more than a second. Every 100 ms of delay reduces conversion by 7%. That's direct lost revenue. Our experience shows: a properly configured FID/INP optimization yields INP < 200 ms in 5–10 days turnkey. We'll evaluate your project for free.

FID (First Input Delay) — the time from the first interaction to the browser's response, described in web performance standards (see Wikipedia). Google replaced FID with INP (Interaction to Next Paint), which measures all interactions. Thresholds: FID < 100 ms, INP < 200 ms. On heavy Bitrix sites, INP can reach 500–1500 ms. Optimization reduces latency by 2.5x when implementing code splitting.

Why INP Matters for Business

Every extra millisecond of delay means losing a customer. Google research shows if INP exceeds 200 ms, bounce probability increases by 32%. For an e-commerce store on Bitrix, this means dozens of lost orders per day. On one of our projects, we reduced INP from 800 to 150 ms — conversion increased by 15%. Investment in optimization pays off in 2-3 months.

Why the Browser Doesn't Respond to Clicks

The browser is single-threaded: while the main thread is busy executing JavaScript, it can't process input events. The user clicks a button — the click is queued and waits for JS to finish the current task. Long Tasks with duration > 50 ms are the main cause of high INP.

Sources of Long Tasks in Bitrix:

  • Loading and parsing large JS bundles: jQuery + plugins + components = 500 KB – 1 MB
  • Initialization of sliders, mask fields, maps, widgets on DOMContentLoaded
  • Heavy event handlers: catalog filter, cart recalculation
  • Synchronous AJAX requests (block the thread)

How to Diagnose Long Tasks: Step-by-Step Guide

  1. Open Chrome DevTools (F12) and go to the Performance tab.
  2. Click the Record button (circle icon).
  3. Interact with the page: scroll, click a button.
  4. Stop recording and look for red bars above the timeline — these are Long Tasks > 50 ms.
  5. Click a task to see the call stack: which script occupied the main thread.

For INP, enable 'Web Vitals' in DevTools and repeat the interaction. You can also use console monitoring:

const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { if (entry.duration > 50) { console.warn('Long task:', entry.duration.toFixed(1) + 'ms', entry); } } }); observer.observe({ type: 'longtask', buffered: true }); // Example of lazy loading a slider if (document.querySelector('.main-slider')) { import('./swiper.min.js').then(({ default: Swiper }) => { new Swiper('.main-slider', { /* ... */ }); }); } 

What is Code Splitting and How It Helps

Standard Bitrix loads all JS on every page: jQuery, catalog plugins, cart scripts, sliders, maps — everything at once. A page with 1 MB JS executes it all on load. Code splitting reduces INP to 200 ms compared to 500+ ms without it — that's 2.5x faster.

In Bitrix context — via \Bitrix\Main\Page\Asset::addJs() in specific component templates, not in header.php.

Defer and Async for Scripts

<!-- Synchronous — blocks HTML parsing --> <script src="/bitrix/js/plugin.js"></script> <!-- defer — loaded in parallel, executed after HTML parsing --> <script src="/bitrix/js/plugin.js" defer></script> <!-- async — loaded and executed as soon as possible --> <script src="/bitrix/js/analytics.js" async></script> 

defer — for scripts that need the DOM (component initialization). async — for independent scripts (analytics, ad tags). In Bitrix, JS files added via \Bitrix\Main\Page\Asset::addJs() are output without defer. To add the attribute — custom implementation via the OnEndBufferContent hook or overriding the script output template.

Heavy Event Handlers

A click handler that does synchronous DOM recalculations on 200 elements blocks the thread for the duration. INP will equal the handler time. Debounce can reduce latency by up to 300 ms.

Improvement patterns: Debounce for frequent events (search input, filter change):

let debounceTimer; searchInput.addEventListener('input', function() { clearTimeout(debounceTimer); debounceTimer = setTimeout(() => { doSearch(this.value); }, 300); }); 

Breaking heavy operations via setTimeout or scheduler.postTask:

async function processLargeList(items) { for (let i = 0; i < items.length; i += 50) { const chunk = items.slice(i, i + 50); processChunk(chunk); await new Promise(resolve => setTimeout(resolve, 0)); } } 

Web Workers for computations: if an event handler requires heavy computations (sorting, filtering large arrays) — move to a Web Worker. Runs in a separate thread, does not block the UI.

Third-Party Scripts

JivoSite, MetrikaTag, Google Analytics, social media pixels — each adds JS that executes on the main thread. With 5–10 third-party scripts, the total startup load can be 200–500 ms of Long Tasks.

Strategy:

  1. Load third-party scripts with async or after the load event
  2. Use requestIdleCallback for non-critical scripts
  3. Check if all connected widgets are needed — often there are unused ones
// Load analytics after idle window.addEventListener('load', () => { requestIdleCallback(() => { const script = document.createElement('script'); script.src = 'https://analytics-provider.com/tag.js'; script.async = true; document.head.appendChild(script); }); }); 
Typical Mistakes in INP Optimization
  • Implementing code splitting but leaving synchronous template scripts — the effect is lost.
  • Loading all scripts with async — execution order is not guaranteed, potential bugs.
  • Not verifying after optimization: INP may increase due to new widgets.
  • Forgetting server-side rendering (TTFB) — if the server is slow, JS optimization won't help.

What's Included in the Optimization Work

Deliverable Description
Long Tasks Audit Full Performance analysis, list of culprits
Code Splitting Bundle splitting, lazy loading
Defer/Async Migration Configure attributes for all scripts
Debounce/Refactoring Optimize event handlers
Defer Third-Party Postpone non-critical scripts
Documentation & Training Maintenance guide

Optimization Timelines

Task Duration Effect
Long Tasks Audit via DevTools 0.5 day Understanding the problem
Migrate scripts to defer 1 day INP down 50–200 ms
Defer third-party scripts 0.5 day INP down 100–300 ms
Debounce search and filters 1 day Filter INP down 200–500 ms
Code splitting for heavy components 3–5 days Catalog page INP down 200–500 ms
Refactor heavy event handlers 2–5 days INP < 200 ms

A good result for a Bitrix store is INP < 200 ms. This is achieved when the total JS bundle < 200 KB (after parse) and there are no Long Tasks > 100 ms on interaction.

We are a team with 10+ years of Bitrix experience, certified specialists. We've completed 50+ speed optimization projects. We guarantee achieving INP < 200 ms or further refinement at our expense. We provide a checklist and monitoring after implementation.

Contact us for a free evaluation of your project. Order a performance audit today and get a consultation on FID/INP optimization for your Bitrix site.