What a 4MB homepage actually costs you

We were getting ready to launch this site when we ran a check on our own files. The homepage was 4MB.

Not the whole site. One page.

For context, a well built marketing homepage usually lands somewhere between 500KB and 1.5MB including images. Ours was several times that, and we were about to put it in front of the exact audience most likely to check.

Here is what we found, and what we did about it.

The problem was invisible in the browser

This is the part worth paying attention to. The page looked fine. It loaded on our machines, the animations were smooth, nothing was obviously broken. On a fast connection in Toronto, you would never have known.

That is precisely why this kind of problem survives to launch. Page weight does not announce itself. It shows up as a slightly slower load for someone on mobile data, a slightly higher bounce rate, and a Core Web Vitals score you only look at when something has already gone wrong.

What was actually in there

We measured the file rather than guessing. Across the whole site, 92 percent of the HTML was base64 data.

Base64 is a way of encoding a file, an image or a video, as plain text so it can be pasted directly into an HTML file rather than sitting alongside it as a separate asset. It has legitimate uses, mostly for tiny icons where saving a network request is worth it.

It was being used here for two MP4 videos.

Both background videos on the homepage had been encoded into the HTML itself. One of them was a single line of text 2.5MB long. That was the 4MB.

Three things make this worse than it first appears:

1. Base64 inflates the file. Encoding a binary file as text makes it roughly a third larger than the original. You are paying a size penalty for the privilege.
2. Nothing can be cached separately. A real video file gets downloaded once and reused. A video baked into the HTML is re-downloaded in full every single time the page is requested.
3. It blocks the parser. The browser has to read through megabytes of text before it can finish building the page.

There was a fourth problem we only noticed once we started looking. The site logo was also base64 encoded, and because every page carries its own copy, the same image was embedded 26 times across the site. As a real file it would be downloaded once and cached for every page after that.

The fix

The fix is not clever. We extracted every embedded asset into a real file, gave each one a sensible name, and pointed the HTML at it.

The results:

• The homepage went from 4,037,627 bytes to 69,073 bytes. A 98.3 percent reduction.
• All 26 pages together went from 7.9MB to 579KB.
• The videos and images still exist, still load, and the page looks identical. They are now separate files that the browser caches properly.

We also set the videos to load their poster frame first rather than competing with the rest of the page for bandwidth, so the first thing a visitor sees paints immediately.

Total time: under an hour. No design changes. Nothing removed.

The uncomfortable part

We found this on our own website.

We do this work for clients. We audit sites, we fix technical SEO, we care about load times, and this still got most of the way to launch before anyone measured it. It got in because the site was built as a design mockup, where inlining assets is convenient, and nobody re-checked the assumption before it became the real thing.

We are writing it up rather than quietly fixing it because the lesson generalises: the problems that reach production are usually the ones nobody thought to measure, not the ones nobody knew how to fix. Everything above is a well understood problem with a well understood solution. It survived because for months, no one ran the check.

What to check on your own site

If you want to know whether you have a version of this, three things worth doing today:

• Look at your actual page weight. Open your site, press F12, go to the Network tab, reload, and read the total transferred at the bottom. If your homepage is over 2MB, something in there deserves a closer look.
• Run PageSpeed Insights on your homepage and read the opportunities section rather than fixating on the score.
• Check whether your images are the right size. A 4000 pixel wide photo displayed in a 400 pixel wide slot is the most common version of this problem, and it is usually a one line fix.

None of that requires a developer. It requires twenty minutes and a willingness to look.

If you would rather someone else looked, that is what we do.