1C-Bitrix serves its own homepage from a file cache, and a phone still waits 6.3 seconds for the first pixel

The server is not the problem

Start with the response headers of the homepage:

$ curl -s -D - -o /dev/null -H 'Accept-Encoding: br' https://www.1c-bitrix.ru/

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: no-cache
X-Bitrix-Composite: Nginx (files)
X-Accel-Expires: 7200
Content-Encoding: br

X-Bitrix-Composite: Nginx (files) means this HTML never reached PHP. Bitrix’s composite mode wrote the page to disk, and nginx handed the file over as if it were static. The lab trace agrees: time to first byte on the mobile run was 51 ms. The document is compressed with brotli, which is the right call and not one every platform makes.

The second thing is in the markup. All 33 external scripts on the page sit in the last 3% of the document, starting 194,405 bytes into a 200,048-byte file. The only scripts left in the head carry data-skip-moving="true", which is Bitrix’s opt-out from its own “move all JavaScript to the end of the page” setting. So that setting is on, and it shows: total blocking time on the mobile run was 40 ms.

Fast server, scripts out of the way, idle CPU. And then:

Metric (mobile)	Original
Time to first byte (lab trace)	51 ms
First Contentful Paint	6.3 s
Largest Contentful Paint	9.5 s
Total Blocking Time	40 ms

Six seconds pass between a document that arrived almost instantly and the first thing a phone can draw. Caching made the page arrive sooner. It did not change what has to arrive before anything is painted.

Fourteen stylesheets before the first pixel

The head links fourteen stylesheets, and the browser will not paint until it has every one. Bitrix appends a version string to each URL, and that string is more useful than it looks:

/bitrix/content_fonts/opensans/800/opensans.css?1562746550373

It is two numbers glued together: the file’s modification time as a Unix timestamp, then its size in bytes. We checked on this file. The server answers Content-Length: 373 and Last-Modified: Wed, 10 Jul 2019 08:15:50 GMT, which is timestamp 1562746550. Anyone can read the uncompressed weight of a Bitrix page’s assets straight from its source.

Read that way, the head looks like this:

Stylesheet	Bytes, uncompressed
app.min.css	228,615
bootstrap.min.css	162,023
main.css	33,748
GDPR banner, base.min.css	14,360
social login form, style.css	7,102
styles.css	4,551
owl.carousel.min.css	3,351
GDPR cookie settings, style.min.css	2,148
auth header form, style.min.css	1,968
opensans.css × 5 (weights 300 to 800)	349 to 373 each
14 files	459,659

Compressed, all fourteen come to 77,777 bytes on the wire, so the problem is not their size. It is that there are fourteen of them, each one a request the first paint must wait for, and that none of them comes from the merged bundle Bitrix can build itself: a merged template stylesheet lives under /bitrix/cache/css/, and no link on this page points there.

Five of the fourteen are the font files. Each holds exactly one rule:

@font-face {
	font-family: 'OpenSans';
	src: url('OpenSans-ExtraBold.eot');
	src: url('OpenSans-ExtraBold.eot?#iefix') format('embedded-opentype'),
	url('OpenSans-ExtraBold.woff2') format('woff2'),
	url('OpenSans-ExtraBold.woff') format('woff'),
	url('OpenSans-ExtraBold.svg#open_sansextrabold') format('svg');
	font-weight: 800;
	font-style: normal;
	font-display: swap;
}

Five render-blocking requests that move 4,615 bytes to deliver 1,793 bytes of CSS. And this one, the 800 weight, is never used: the measured run downloaded the 300, 400, 600 and 700 WOFF2 files and no ExtraBold. Note what is right in the same file, though: font-display: swap, so text does not hide while the fonts load.

Lighthouse’s own estimate for removing the render-blocking requests on this run is 2.75 s of first contentful paint. That is an estimate, not a measurement; our measured number is further down.

Half the page is two images

The mobile run moved 3,195,882 bytes (3.0 MB, counting a megabyte as 1,024²). Here is the composition:

Type	Requests	Bytes
Images	37	2,289,646
Scripts	38	542,444
Fonts	4	211,834
Stylesheets	14	77,777
Documents	2	57,291
Other	9	16,890
Total	104	3,195,882

Images are 72% of it, and two files are 1,562,608 bytes, 49% of the whole page.

The first is winners.jpg, 827,981 bytes, a CSS background:

.company-count-info_background{background-image:url(/images/content_ru/background/winners.jpg);
  background-size:cover;background-position:50%;background-repeat:no-repeat}

On desktop that section is the largest contentful element of the page. On mobile it is not, but the stylesheet applies the background anyway, so the phone downloads it too.

The second is a thumbnail in the press-release slider:

<img class="press-realise__img"
     src="/upload/iblock/94d/xhmzrjgyng2jcumybi3vxol8rp94iwqt/orig.png"
     alt="ИИ‑агенты: от хайпа к практике. …">

The file is a 1000×1000 truecolour PNG of 734,627 bytes (we read its header, not the whole file). The stylesheet puts it into a box 10.6666666667em tall. The seven other thumbnails in the same slider weigh between 18,560 and 100,874 bytes, so this is not a pattern of the template. It is one upload that went in at the size it was exported.

None of the 18 img tags on the page carries a loading attribute, and 17 of them have no width and height. The press slider, the client logos and the country flags all load with the first screen. On a phone that means the 41 KB product image that becomes the largest contentful element shares the throttled connection with 1.5 MB of images further down the page.

The platform has the tool for this. core.min.js, which this page downloads, lists /bitrix/js/main/lazyload/dist/lazyload.bundle.js among the modules it already contains. It is just not attached to these images.

A realtime client for a visitor it does not serve

Near the end of the document, Bitrix’s push-and-pull client loads with its dependencies:

<script src="/bitrix/js/pull/protobuf/protobuf.js?1703578952274055"></script>
<script src="/bitrix/js/pull/protobuf/model.min.js?170357895214190"></script>
<script src="/bitrix/js/rest/client/rest.client.min.js?16121731009240"></script>
<script src="/bitrix/js/pull/client/pull.client.min.js?176053918649849"></script>

Read the trailing digits again: 274,055 + 14,190 + 9,240 + 49,849 = 347,334 bytes of JavaScript, 35% of the 978,931 bytes of script source this page links. It is the infrastructure for live updates: notifications, chat, presence. Right above the tags, the page prints the client’s configuration for this visitor:

(window.BX||top.BX).message({"pull_server_enabled":"Y", … ,"pull_guest_mode":"N","pull_guest_user_id":0, …});

Guest mode off, user zero. A visitor arriving from search is a guest. In the measured run none of these scripts made a request of its own; the resource list has no call they could have made.

We want to be careful about what this proves. A logged-in partner on the same URL may well use the channel, and from outside we cannot see that. For the anonymous first visit that PageSpeed measures, and that a new customer makes, it is 70,936 bytes on the wire and 339 KB to parse for a feature the page has switched off for them. The cost on this run was mostly bandwidth: blocking time was 40 ms, so the parse did not jam the main thread.

What changed through the proxy

Metric	Mobile, original	Mobile, WebSpeed	Desktop, original	Desktop, WebSpeed
PageSpeed score	59	75	74	100
First Contentful Paint	6.3 s	2.6 s	0.6 s	0.3 s
Speed Index	6.6 s	4.6 s	1.7 s	0.6 s
Largest Contentful Paint	9.5 s	5.1 s	2.9 s	0.5 s
Total Blocking Time	40 ms	0 ms	2 ms	0 ms
Cumulative Layout Shift	0	0.002	0.168	0.003

The largest single change is first paint on mobile, 6.3 s to 2.6 s, and it comes from the head: the accelerated run requests 5 stylesheets instead of 14. Images went from 37 requests and 2,289,646 bytes to 20 requests and 214,288 bytes on mobile. The four product box PNGs (211,187 bytes) became WebP files of 40,739 bytes together, and winners.jpg became 111,959 bytes. The 1000×1000 thumbnail is below the first screen and was never requested.

Composition, since a score that rises because a page stopped loading is not a win: 65 of 104 requests and 0.8 of 3.0 MB. The gap is lazy-loaded images below the fold and third-party scripts that wait for interaction, both listed in the limits above. The original HTML was the same 54,053 bytes for the mobile and the desktop run, and the largest element on mobile was the same product image before and after, so the mobile run measured the mobile page.

Two things went the wrong way, and one matters. Our accelerated run gave that mobile product image loading="lazy", which is exactly the hint a first-screen image should not get, and mobile LCP stopped at 5.1 s instead of going further. The other is a mobile layout shift of 0.002 where the original had none.

What Bitrix already gets right on this page

The measurement does not say Bitrix is slow. It says the opposite about the parts Bitrix owns: the HTML came from a file cache in 51 ms, it was brotli-compressed, every script was moved out of the head by a platform setting, and the font file we fetched declares swap. A CMS that does those four things by default is ahead of most hand-built sites we audit.

What remains is what an editor and a template author decide: fourteen stylesheets where the platform could merge them, an image uploaded at 1000 pixels into a slot a fraction of that, a background JPEG nobody re-encoded, and a module attached to every visitor rather than to the ones it serves. Each of those is a one-line or one-file change. None of them is reached by a cache, because a cache makes the same bytes arrive sooner; it does not decide which bytes should be there.