The 200 KB rule I use on every site
Most small business sites ship a megabyte before the first word renders. Here is the budget I use instead, and what it actually changes.
Every site I build starts with a number before it starts with a design: 200 kilobytes for the whole first screen, images and fonts included.
That is not a technical limit. It is a design constraint, and constraints make better decisions. When you know the hero has 60 KB left after fonts, you stop reaching for a 1.2 MB background photograph and start asking what the page is actually for.
Speed is a design decision, not a plugin
The usual answer to a slow site is to install a caching plugin. That helps, but it treats a symptom. A page that weighs four megabytes because someone exported every image at 4000px will still be slow on a phone in a lift, no matter how aggressively you cache it.
The decisions that matter happen earlier:
- What is above the fold, and does it need to be an image at all
- How many fonts the page loads, and whether they block the first paint
- How many third-party scripts run before the page is usable — chat widgets, pixels, tag managers, review badges
By the time a site reaches a caching plugin, those decisions are already made.
What actually eats the budget
In my experience, three things account for most of the weight on a typical small business site.
Hero images. A full-width photograph exported at 3000px and saved at 90% quality is routinely 800 KB to 1.5 MB. The same image served at 1600px wide in WebP or AVIF, at a quality setting you cannot see the difference on, is usually under 150 KB. Same picture, one eighth of the weight.
Web fonts. Each weight of each family is a file, and each one can delay text rendering. Two families at four weights each is eight requests before your headline appears. Most sites need one display face and one text face, at two weights, with font-display: swap.
Third-party scripts. Analytics, chat, heatmaps, ad pixels, consent managers. Each one is a request to another domain, often slower than your own server, and they frequently load before your content does. A page with eight of them is not really your page any more — it is a queue.
What matters less than people think
Minification and image compression plugins do almost nothing if the source material is wrong. A CDN is worth having, but for an audience entirely in Singapore, a well-configured server in Singapore is already most of the benefit — the round trip is 15ms, not 250ms.
And "Lighthouse score" is not the goal. A 99 can still feel slow if the first meaningful thing on screen arrives late. Judge the page by what a person sees in the first second, on a mid-range Android over 4G.
The test I run
Before a site goes live, I load it on a throttled connection — 4G, mid-tier phone — three times, and watch the first second:
- Does anything readable appear before the fonts finish?
- Does the layout jump when the images land?
- Does anything shift or pop after the page looks settled?
If the answer to those is yes, no, no, the numbers on a report matter much less.
Why 200 KB
Because it is achievable, and because it forces the conversation early. It rules out autoplaying video, carousels of stock photography and four-font brand systems before anyone has grown attached to them. What is left is usually a page that says one thing clearly — which is also the better design.
The constraint is not about being frugal for its own sake. It is about deciding, on purpose, what the page is for.