What a 731 KB homepage costs you, measured on our own site

It is easy to write this article about somebody else’s website. We are going to write it about ours, because until very recently the slowest site we had ever measured belonged to us.

The numbers

Here is what the old 99-mph.com homepage actually sent, measured from a cold request:

	Old site	Ramp	Now
HTML document	731,021 bytes	47,114 bytes	27,260 bytes
— of which inline CSS	543,494 bytes	—	—
— of which inline JS	48,048 bytes	—	—
Separate stylesheets	17	0	1
Separate scripts	44	0	1
Time to first byte	5.5s	0.6s	—

That first column is not a typo. Three quarters of the page was a stylesheet pasted directly into the document.

Why inline CSS is worse than it sounds

A normal stylesheet is a separate file. Your browser downloads it once, keeps it, and reuses it on every other page of the site. That is the entire point.

When a page builder inlines the stylesheet into the HTML instead, the browser cannot keep it, because it is not a file any more — it is part of that one page. So it downloads all 543 KB again on the About page. And again on Contact. And again on every single page, forever.

The tooling usually does this in the name of speed. The idea — “critical CSS” — is real and sound: work out the handful of rules needed to paint the top of the page, inline just those, and load the rest normally. The failure mode is inlining everything and calling it critical, which is what happened here. It is a plugin default, not a decision anybody made.

Why 44 scripts is the number that actually hurts

Bytes are only half of it. Each of those 44 scripts is a separate request, and scripts block. The browser has to fetch, parse and run them before it can finish drawing the page.

Most of them were there because a plugin needed them on some page, so it loaded them on every page. A contact form’s validation script on a page with no form. A gallery lightbox on a page with no gallery. Nobody chose that either.

What 5.5 seconds means in practice

Time to first byte is how long the server takes to start answering. Ours was 5.5 seconds — before any of the above had even begun downloading.

Some of that was a redirect. The apex domain sent every visitor to the www version first, so each person paid for two round trips instead of one, and the redirect was issued by WordPress — meaning PHP had to boot up just to say “go somewhere else.”

The honest framing is this: on a phone, on a normal connection, a large share of people will not wait. They do not send you an angry email about it. They go back and tap the next result. You never learn it happened, which is exactly what makes this the most under-diagnosed problem in small-business websites.

How to measure your own, in about two minutes

You do not need a tool or an account.

The page weight. Open your homepage in Chrome or Firefox, press F12 for developer tools, click the Network tab, and reload. Sort by Size. The first row is your HTML document. If that number is above about 100 KB, look at why — a normal HTML document is 15–50 KB. Then look at the total at the bottom of the panel, and the request count.

The inline CSS specifically. Right-click the page, choose View page source, and use your browser’s find (Ctrl-F or Cmd-F) for <style. If you get a handful of small blocks, that is normal. If you find one that scrolls for thousands of lines, that is the problem described above.

The redirect. In the same Network tab, look at the very first request. If its status is 301 or 302 and it points at your own site, every visitor is paying for an extra trip.

A second opinion. Google’s PageSpeed Insights is free and needs no login. Put your URL in and read the field data section at the top if it appears — that is measured from real visitors on real phones, not a simulation, and it is the closest thing to the truth you will get for free.

What we would fix first, in order

If you are looking at bad numbers on your own site, the order matters more than people think, because the first two are usually free.

1. The redirect. Handle apex-to-www at your DNS or CDN layer instead of in the site itself. Often a five-minute change, and it helps every page.
2. Scripts you are not using. Most page builders have a setting to load assets only where needed. Turning it on frequently removes half the requests without touching how the site looks.
3. Image formats and dimensions. Fifteen of our thirty-five images had no width or height set, which makes the page visibly jump around as it loads. Setting those two attributes costs nothing. Converting to WebP or AVIF is a bigger win still.
4. The stylesheet. This is the hardest one, because on most page builders you cannot fix it without leaving the page builder.

That last point is the uncomfortable one, and we are not going to dress it up: we could not fix our own stylesheet problem inside the tool that caused it. We rebuilt the site without a page builder instead. That is not advice we would give to everyone — if your site is loading in a couple of seconds and bringing you work, leave it alone. Page weight is worth your attention when it is costing you visitors, and not before.

The part where we do not pretend

There is a version of this article that ends by telling you that this is complicated and you should hire somebody. We are not going to write that, because the four steps above are genuinely most of the value, and three of them are settings rather than skills.

What is fair to say is that we published our own bad numbers rather than quietly fixing them, and you can check every figure in the table yourself. If you would rather hand the whole thing over than work through it, that is what we sell. But the guide works whether or not you do.