How fast could your site be?

Enter your address. We measure it as it is and through WebSpeed, side by side.

No signup. See your before/after PageSpeed score in about a minute. What the report shows

Speed up Bitrix without a developer or a redeploy

No release to plan and no developer to book: traffic routes through WebSpeed with a DNS change, and nothing is installed, enabled or patched inside the platform. Bitrix sites are usually slow for structural reasons rather than neglected ones — the head serves the whole product, and every component you enabled brings its assets to it. We ran 97 Bitrix sites through WebSpeed to measure which of those costs actually land on the critical path.

No signup. See your before/after PageSpeed score in about a minute. What the report shows

  • Nothing to install
  • Your site stays where it is
  • Any optimization can be switched off
Screen filled · mobile

How fast 1,134 sites fill the screen

Speed Index of the original sites, as they are, without our optimization.

Fastest quarter: 4.3 s or less

Where does yours land? The free check puts your site on this chart.

Across every platform we’ve measured — not enough Bitrix sites yet for a chart of their own. Updated 24 Sep 2026.

What WebSpeed does on Bitrix

Each one is independent and can be switched off for your domain — nothing here is all-or-nothing.

The first paint stops waiting on CSS

The styles the first screen needs are inlined; the rest stop blocking. The browser paints on the first response instead of waiting out a chain of stylesheets.

Critical CSS Render-blocking resources FCP

Scripts stop blocking the parse

Blocking scripts are deferred and inline body scripts are held until rendering is done, then run in order. Same behaviour, out of the way of the first paint.

TBT TTI

Analytics and chat load after the page is usable

Counters, pixels and live-chat load once the page is usable, not in the middle of it rendering.

TBT INP

Unsized images get their real dimensions

We read each image's true aspect ratio server-side and write it into the markup, so the browser reserves the right box before the file arrives.

CLS

The first screen gets priority

The hero image — or the CSS background standing in for one — is preloaded at high priority, so the content that defines the page arrives first.

LCP SI

Your controls

What stays under your control

An optimization you cannot undo is a risk, not a feature. Each of these is a decision you keep after the site is live on WebSpeed.

  • Switch any optimization off

    Each one is independent. If something doesn't suit your Bitrix theme, it can be disabled for your domain alone and everything else keeps working.

  • Keep only what measurably helps

    On a tuned profile we measure each optimization against your own pages and drop the ones that do not earn their place there.

  • Re-check whenever you want

    Your audit page re-runs both measurements on demand, so "did it help" stays a number you can pull rather than a claim you have to take.

  • Turn it off entirely

    WebSpeed sits in front of your site, not inside it. Revert the DNS record and your original site serves again, unchanged — nothing to uninstall.

In progress: a dashboard where you flip these yourself and follow each page's scores over time. Today it is a message to us and we apply it to your domain.

Why Bitrix sites are slow

What our filter logs recorded across the Bitrix sites we have audited. Each card carries its own count: how many sites had the problem, or how many fixes it took.

Measured across 97 Bitrix audits · snapshot 2026-10-19

92%of sites

Stylesheets block the first paint

Nearly every site we audited. Each enabled component queues its own stylesheet into the head, and the browser must fetch and parse the whole set before it can paint a single pixel.

65%of sites

Third-party scripts load eagerly

Analytics, pixels, chat widgets and callback services start loading with the page instead of after it, competing for bandwidth and main thread with the content the visitor actually came for.

607fixes on 64 sites

Inline scripts run while the page draws

Component initialisation sits inline in the body and executes as the browser works through the markup, so rendering stops each time one runs. On a catalogue page there are a lot of them.

1162fixes on 66 sites

Images arrive without dimensions

Our highest-volume correction here. Components output images without width and height, so the browser cannot reserve space and the text jumps as each file lands.

The research behind these numbers

Real results

Measured on real Bitrix pages

Stored audits — the original page against the same page served through WebSpeed, on mobile and desktop. Not a demo build: these are the sites as they ship.

Bitrix avtomir.ru
Measured with WebSpeed on
Screen filled · mobile
2.7s
was 4.3 s−1.6 s
Page weight
798KB
was 6.7 MB−88%
Desktop · PageSpeed
100
was 78+22
Main content (LCP) · desktop
0.6s
was 1.3 s−0.7 s
Forecast · if your visitors get this speed

Projections, not measurements: this run's measured LCP improvement scaled by published studies, and CO₂ from the measured bytes at ≈0.15 g/MB. Sources under the grid.

Google traffic ≤ +22%Conversion +4%Bounce −6%CO₂ −88%
0 optimizations applied
  • Gave unsized images their real aspect-ratio (anti-CLS)
  • Preloaded the LCP image (fetchpriority: high)
  • Preloaded the hero background image
  • Made non-critical CSS load without blocking
Bitrix rusal.ru
Measured with WebSpeed on
Screen filled · mobile
1.8s
was 4.6 s−2.8 s
Page weight
4.4MB
was 16.3 MB−73%
Mobile · PageSpeed
91
was 53+38
Desktop · PageSpeed
44
was 20+24
Forecast · if your visitors get this speed

Projections, not measurements: this run's measured LCP improvement scaled by published studies, and CO₂ from the measured bytes at ≈0.15 g/MB. Sources under the grid.

Google traffic ≤ +40%Conversion +22%Bounce −20%CO₂ −73%
89 optimizations applied
  • Images — 57 changes
  • JavaScript — 16 changes
  • CSS delivery — 10 changes
  • Resource hints — 5 changes
  • Fonts — 1 change
Bitrix donstroy.moscow
Measured with WebSpeed on
Screen filled · mobile
11.7s
was 17.6 s−6.0 s
Page weight
7.8MB
was 13.8 MB−44%
Main content (LCP) · mobile
16.9s
was 33.2 s−16.3 s
Why only this

The rest stayed inside measurement noise.

Forecast · if your visitors get this speed

Projections, not measurements: this run's measured LCP improvement scaled by published studies, and CO₂ from the measured bytes at ≈0.15 g/MB. Sources under the grid.

Google traffic ≤ +40%Conversion +30%Bounce −20%CO₂ −44%
42 optimizations applied
  • Images — 24 changes
  • JavaScript — 9 changes
  • Resource hints — 6 changes
  • CSS delivery — 3 changes
Bitrix acron.ru
Measured with WebSpeed on
Page weight
1.6MB
was 2.3 MB−31%
Desktop · PageSpeed
96
was 78+18
Main content (LCP) · desktop
1.1s
was 2.9 s−1.8 s
Why only this

The rest stayed inside measurement noise.

Forecast · if your visitors get this speed

Projections, not measurements: this run's measured LCP improvement scaled by published studies, and CO₂ from the measured bytes at ≈0.15 g/MB. Sources under the grid.

Google traffic ≤ +40%Conversion +15%Bounce −20%CO₂ −31%
19 optimizations applied
  • JavaScript — 10 changes
  • Images — 3 changes
  • Resource hints — 3 changes
  • CSS delivery — 2 changes
  • Fonts — 1 change

Real Google Lighthouse audits, original vs. WebSpeed Fast. The filled tiles are measured: the score is shown per device only where it moved beyond the ±5 the audit counts as noise, “screen filled” is Speed Index, and page weight is transferred bytes. The outlined pills are projections from those measurements — not guarantees. Scores are per-page; yours will differ.

Google traffic Core Web Vitals are a Google ranking signal; the biggest lift is leaving the “Poor” zone (score < 50), scaled here by device search share.

Conversion Akamai / SOASTA (2017): a 100 ms delay cost 7% of conversions across ~10 billion retail visits; scaled here to the measured improvement.

Bounce Akamai / SOASTA (2017): a two-second delay raised bounce rate by 103%; scaled to the measured improvement, site-specific.

CO₂ The measured byte reduction at ≈0.15 g per MB per visit (Sustainable Web Design v4) — a model of the network and devices, not a measurement of them.

Why it's worth doing

What a faster Bitrix site is worth

SEO Rank ↑ out of the “Poor” band

Search sees a faster page

Core Web Vitals have been a confirmed Google ranking signal since 2021. The biggest win is leaving the "Poor" band, where faster competitors get preferred.

— Google Search Central
Conversion +7% per 100 ms you cut

More visitors finish what they started

Conversion tracks load time closely — on Akamai’s retail numbers a delay of just 100 ms cost 7% of conversions. Shaving seconds is the cheapest funnel work available.

— Akamai / SOASTA, 2017
Bounce ≈ ½ cutting a 2 s delay

Fewer people leave before it loads

Close a two-second gap and bounce rate roughly halves — Akamai measured those same two seconds raising it by 103%. A page that paints early keeps the visit a slow one loses outright.

— Akamai / SOASTA, 2017
CO₂ ≈ 0.15 g saved per MB you cut

Lighter pages, less energy

Transfer weight maps to emissions at roughly 0.15 g of CO₂ per MB. Cutting bytes is the one optimization that shows up on a sustainability report.

— Sustainable Web Design v4

Each figure links to the page that publishes it. The studies measure what delay costs; read here as what speed returns. Industry benchmarks, not a guarantee for a specific site — the per-site numbers are the audits above, and yours is a free check away.

Where the time actually goes on Bitrix

Bitrix has a reputation for being heavy, and the usual explanations are about hosting and about the size of the product. Our measurements point somewhere more specific and more fixable: the assets are not unusually large, they are unusually early.

The head is the main event. On 92% of the 97 sites we audited, stylesheets were blocking the first paint, which puts Bitrix above even WordPress (84%), where a render-blocking head is one of the two most common defects we find. Bitrix assembles the head from the components a site has enabled, and each one contributes whether or not the current page uses it. Nothing about that is a mistake anyone made; it falls out of a modular product doing what it was designed to do.

Images are the highest-volume defect. We recorded 1,162 individual images shipped without dimensions, spread across the 66 sites where the problem occurred at all, so roughly eighteen per affected site. That is the cheapest class of problem to fix and one of the most visible when it isn’t: the layout shifts under the reader as each file lands.

Component initialisation runs during rendering. Inline scripts in the body execute as the browser parses, which on a catalogue page happens many times over. Deferring them changes nothing about what runs — only when.

Why the usual advice runs out

Most Bitrix speed advice concerns the server: tune the cache, upgrade the plan, turn on compression. That advice is not wrong, and it addresses how quickly the first byte arrives. It does not touch what that byte stream contains — and a render-blocking head arrives just as blocking when it arrives quickly.

Changing the contents means editing what components emit. In practice that is template work, repeated for every component, and re-checked after every update — which is why it is usually scoped, costed and then postponed.

A reverse proxy changes where the work happens. Your site keeps serving the page it always did; WebSpeed receives that page, rewrites its critical path, and hands the result to the visitor. Nothing inside Bitrix changes, so there is nothing for an update to undo and nothing for your team to relearn.

What you get from the audit

It needs nothing but the URL:

  1. Your score, both devices — mobile and desktop, original vs the WebSpeed-served page.
  2. The individual metrics — LCP, CLS, TBT and the rest, side by side rather than rolled into one number.
  3. What actually changed — the itemised list of optimizations behind the result.
  4. A before/after video of your page loading, if the gain is big enough to see.

Bitrix speed — questions

Do I have to change anything in Bitrix?

No. WebSpeed runs in front of your existing site: traffic is routed through it with a DNS change, and nothing is installed, enabled or patched inside the platform. Your team keeps working exactly as before.

I already use Bitrix's own caching and compression. Is this redundant?

No — they work on different halves of the problem. Bitrix caching mainly improves how fast your server answers; it does not change what that answer contains. Our measurements are about the contents: 92% of the 97 sites we audited still shipped a render-blocking head, cache settings or not. The two stack.

We run a catalogue with a cart and personal accounts. Is that safe?

The admin panel under /bitrix/admin/, the sign-in pages under /auth/ and the personal section under /personal/ (the default cart lives there too) pass through unchanged and are never cached, as does any request with the saved Bitrix sign-in cookie BITRIX_SM_UIDH. A visitor with a session cookie still gets optimized pages, but none from the shared cache. Beyond that, test instead of assuming: strict-SameSite cookies used by carts and sessions behave differently through a proxy, so for transactional sections we would rather set this up with your developer and verify the flows than promise it works.

Our site has several language versions. Is that a problem?

No. In Bitrix a language version is usually a separate site in the same installation, under a folder such as /en/ or on its own domain. Each address is a separate page for us, optimized and cached on its own, so the Russian and English versions never share a cache entry. A language chosen through a cookie sends the request past the shared cache.

Will it change how the site looks?

It should not — every optimization here is about when and in what order things load, not about what they are. The audit shows you the before and after so you can check the result yourself before deciding anything.

Pricing

Pick how hands-off you want it

The before/after check is free to run; it isn’t one of these plans. Choose a plan when you’re ready to make the speed-up permanent — or buy the report once and apply it yourself.

SaaS subscription

Growth

from €79 · /mo
For several sites at once
14-day free trial
  • Everything in Fast, across multiple sites
  • Priority cache — your pages stay warm
  • Support with a named contact
  • One invoice for the whole portfolio
Request access
Agencies and multi-site owners.
SaaS + hands-on service

Custom

from €179 · /mo
Hand-tuned for your site
  • Everything in Growth
  • A config built by hand for your site
  • What only you can change, written up for your team
  • Set up, measured and maintained by us
Get a plan for my site
We look at your site by hand first, then keep it tuned. Six months minimum.

Subscriptions start with a 14-day free trial (Fast and Growth). After it, Fast is billed yearly, and Growth and Custom run for a minimum of 6 months — you commit only after the trial. Fast is priced by monthly visits; indicative launch pricing.

Downloadable report

Not ready for a subscription?

Buy the Audit once and apply it yourself — the same findings the pipeline acts on, written up as instructions.

  • One site, up to 5 pages you choose
  • Fast’s changes to your page code, written up as a guide you run yourself
  • Server settings, code changes and ready-to-paste head snippets
  • Before/after PageSpeed from the free check (PDF / HTML / MD)
  • Re-issued free for a year as your site changes
€149 · one-time
DIY: you apply it
Get the audit See an example report →
Not useful? Email us within 14 days and we refund it. A document, not a service — you apply it; Custom is the same work done for you.

See your own before / after

Paste your URL for a free PageSpeed comparison on mobile and desktop. No signup, about a minute.

No signup. See your before/after PageSpeed score in about a minute. What the report shows

Other platforms: WordPress Duda WooCommerce Divi Wix Tilda Squarespace