Why your Wix site feels slow: 4.9 MB of HTML before a single image, and which half you can actually fix

A store owner posted that his Wix site took about six seconds before it responded to anything. He had already done the obvious: converted images to webp, shrunk them to size. It changed nothing. His question was the honest version of a question a lot of people have:

“Once you have already made those changes, and the site is still slow — is there anything else we can do? Or just suffer?”

Three days, no replies. And the replies he would eventually get were predictable: compress your images. Which, in his case, was both wrong and slightly insulting, because he’d done it.

The interesting thing is that this question is answerable — precisely, with a number — and almost nobody answers it, because doing so requires an experiment rather than an opinion.

First: the images really were fine

Before looking for a culprit I checked the thing he said he’d already fixed, because the worst outcome here is telling someone to keep digging in a hole that’s finished.

Of 108 media references on the home page, images were being requested at 147×147, 160×160 and 162×162 pixels, q_80, in webp — exactly the size of the slots they sit in, with no headroom. There was not one oversized image on the page. His image work was done and continuing it would have been a waste of his weekend.

(One exception: the og:image was requested at 2500×2500. That is a social-preview asset, not something a visitor waits on.)

So the images were a dead end, which meant the weight was somewhere people don’t usually look.

The HTML document is 4.9 MB

Not the page. The document — before a single image, font, or external script.

Over the wire it arrives compressed at 1,230 KB. Decompressed, the thing the browser has to parse is 4,888 KB.

I ran it cold three times, bypassing cache: 1,260,005 / 1,259,977 / 1,259,993 bytes. A spread of 28 bytes across three runs. That is not a measurement artefact; that number is real and stable, and you can build an argument on it.

What is inside those 4,888 KB:

part size share inline <script> 1,579 KB 32.3% inline <style> — 88 separate blocks 1,291 KB 26.4% the actual markup 2,017 KB 41.3%

And inside the scripts, two JSON blobs that the browser must parse on the main thread before the page becomes interactive:

• wix-warmup-data — 1,193 KB
• wix-viewer-model — 238 KB

Breaking down the first one by key:

key size what it is platform.ssrPropsUpdates 939.7 KB serialized props for every element on the page appsWarmupData.dataBinding 197.3 KB CMS collections bound to this page platform.ssrStyleUpdates 50.5 KB pages 15.4 KB

Nearly a megabyte of JSON describing the props of every component, shipped inline in the document, parsed synchronously before anything responds. That is where the six seconds went — not into his images.

The part that makes this usable: the control

Here is where most performance write-ups stop, and where they stay useless. Because the obvious response to everything above is:

“Fine — but that’s the platform. I didn’t write any of that. What am I supposed to do, rebuild the site?”

That response is reasonable and it deserves an actual answer, not a shrug. So I measured two more pages on the same platform, in the same account, on the same day. Same builder, same infrastructure, same everything — the only variable is how much is on the page.

page document warm-up blob ssrPropsUpdates <style> blocks home 4,888 KB 1,193 KB 940 KB 88 a gift-card page 2,642 KB 5.5 KB 0 31 a near-empty page 1,855 KB 40.7 KB 0 36

Two conclusions, and they point at different people:

1. About 1.9 MB is an irreducible platform tax. His own nearly-empty page — a page with essentially nothing on it — still ships 1,855 KB. He was right, and it’s proven by his own site rather than by my opinion. No optimisation he performs will remove that floor.

2. The home page adds roughly 3.0 MB on top of the floor, and that part is its own construction. The 940 KB ssrPropsUpdates block exists only on the home page — it is literally 0 KB on both of the others. It isn’t emitted by the platform as a constant; it’s generated in proportion to the number of components on that particular page.

So the answer to “or just suffer?” is both, in a ratio: about 40% of the weight is a floor he cannot touch, and about 60% is his page’s own composition, which he can. That is a completely different conversation from “your platform is bloated” and from “compress your images”, and neither of the usual answers gets anywhere near it.

The general form

The control experiment is the whole technique, and it generalises past no-code builders:

To separate the platform’s cost from yours, hold the platform constant and vary only your content.

Same account, same stack, same day. A near-empty page in the same system is the floor. Whatever your real page ships above that floor, you built — regardless of who wrote the code that emits it.

This works for a CMS theme, a component library, an analytics stack, a framework’s hydration payload. Every one of those arguments usually dead-ends in “well, that’s just what X does”. The empty-page control turns it into a number, and a number is something an owner can make a decision about.

Two things I measured and then threw away

This matters more than the findings, because a wrong claim about someone’s site costs you the entire conversation.

The search box. His actual complaint was that site search felt slow. I tried hitting the platform’s search endpoint directly and got 400 Bad Request three times in a row. It was tempting to write “your search endpoint is returning 400” — it would have looked like a sharp catch. It would also have been a lie. Three consecutive 400s from an undocumented endpoint mean I guessed the request format wrong, not that his search is broken. What went back to him instead was: I could not measure this from outside, and here is how you check it yourself in a minute.

Load time. The document arrived in 4,754 / 4,896 / 5,106 / 5,114 ms. Beautifully consistent numbers — and useless as an argument, because that is my connection to his server, not what his customer experiences on the other side of an ocean. Weight is a property of the page. Time is a property of the path between two machines. Only one of those belongs in a claim about someone else’s site.

There were also 21 platform apps installed. I mentioned it as a direction and gave no number, because I didn’t measure each one’s contribution and I’m not going to invent it.

Why bother being this careful

Because the whole value of an unsolicited measurement is that it’s true. The moment one number in it is wrong, the recipient is right to discard all of them — and they will, along with the person who sent it.

The discipline is cheap: reproduce cold three times, run a control that holds the platform constant, and delete anything you cannot separate from your own network, your own cache, or your own guess at an API. What survives is short, and it’s worth something.

I build browser tools where this kind of thing is the job — parametric product configurators and engineering calculators, where the geometry and the costing are computed from the same parameters so they can’t disagree. Work at smirnov-artur.github.io/webgl, reachable on Telegram at @smirnovarturr or at [email protected].

If you run this control on your own stack, I’d be curious what your floor turns out to be. Mine keeps coming in higher than anyone expects.