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