What a fast website actually looks like: two live demos at 99 on mobile

Two weeks ago a prospect stopped me mid-sentence. I had just said the thing every web person says, that I build fast sites, and she asked the only honest question there is: “Everyone says that. How would I actually know?”

I did not have a clean answer. I had a folder of old client sites I could not fully take credit for, and a lot of confident words. So I ended the call, and over the next few days I built two sites whose entire job is to answer that question for me. Then I put them on the internet so anyone can check.

A fast marketing website is a static site (no database, no plugin stack rebuilding the page on every request) that scores 95 or higher on mobile Lighthouse and shows its main content in under two seconds on a phone. I rebuilt two example sites, a skincare clinic and a B2B SaaS, on Astro and Cloudflare Pages. Both score 99 on mobile with sub-two-second loads at around 170 KB. You can run the test on them yourself.

The two sites live in one place: the Zivaro work gallery. One is Lumea, a med-aesthetics clinic with a calm, editorial look. The other is Cadence, a dark, technical B2B SaaS site. Different industries, different moods, same engineering underneath.

What makes a marketing website “fast”?#

Three numbers tell you almost everything, and they are all on the free PageSpeed report.

The first is the Lighthouse performance score, zero to one hundred. Treat the mobile score as the real one. Desktop scores look great on almost anything because the connection and processor are quick. Your visitors are on a phone on a normal mobile connection, so that is the number that reflects their experience.

The second is Largest Contentful Paint (LCP): how long until the biggest thing on screen, usually the hero image or headline, has actually rendered. Google considers anything under 2.5 seconds “good.” This is the metric that decides whether a visitor feels the page snap into place or waits and wonders.

The third is total page weight: how many kilobytes the browser has to download. A heavy page can still score acceptably on fast hardware and then fall apart on a mid-range phone. Lighter is almost always better, and it is the number most agency-built sites quietly fail. In South Africa, where mobile data is not cheap, weight is also a courtesy: a 3 MB page-builder homepage costs a visitor real money to open, while a 170 KB page costs almost nothing.

How fast are the two demos, and how do I check?#

Here are the numbers I publish on the gallery, measured on mobile:

• Lumea (clinic): performance 99, LCP 1.4s, around 169 KB.
• Cadence (SaaS): performance 99, LCP 1.9s, around 172 KB.

Those are deliberately the cautious end of what I measured. The live sites often test even better, because I would rather you run the check and be pleasantly surprised than read an inflated number and feel let down. A proof point only works if reality beats it.

So check it. Open pagespeed.web.dev, paste in lumea.zivaro.co.za or cadence.zivaro.co.za, and read the mobile result. Or just open either site on your own phone and notice that there is no spinner, no layout jumping around as things load, no wait. That feeling is the entire argument, and it is the one thing a screenshot of a score cannot give you.

Why does a static site beat WordPress for a marketing site?#

The common South African small business website runs on WordPress with a page builder like Elementor or Divi. That stack is popular for good reasons: it is familiar, it has a plugin for everything, and you can drag boxes around without touching code. The cost shows up in performance.

When someone visits a WordPress page, the server runs PHP, queries a database, loads whatever plugins are active, and assembles the HTML on the spot. The page builder then ships its own large bundle of CSS and JavaScript so the layout works, much of it unused on any given page. The result is a page that is doing a lot of work to show what is, in the end, mostly text and a few images.

A static site flips this. I build every page once, ahead of time, into plain HTML. Cloudflare serves those files from a data centre near the visitor, with no PHP, no database, and no per-request assembly. The demos use Astro to generate the pages, Tailwind for styling, automatic image optimisation, and self-hosted fonts that never block the first paint. There is simply far less for the browser to do.

To put numbers on it: a typical Elementor homepage I audit lands somewhere between 2 and 5 MB across sixty or more separate requests. The Cadence demo is one HTML file with a little inlined CSS and a few fonts, around 172 KB across a handful of requests. The same kind of content, an order of magnitude apart, and the gap is felt most on exactly the cheap phones and patchy connections a lot of your visitors are using.

The honest short version: ✓ a static site wins on speed, security, and hosting cost, and ✗ it loses on day-to-day editing convenience if you do not have a developer. Which brings up the fair question.

When is WordPress still the right call?#

I am not against WordPress. I am against using it by reflex.

WordPress still earns its place when a non-technical person needs to publish and edit content frequently and independently, when you are running a real content operation with many authors, or when you genuinely need a complex plugin ecosystem like a full WooCommerce store. In those cases the CMS convenience is worth the performance tax, and I will say so.

The decision rule I use is simple: how often does this site actually change, and who changes it? A marketing site that updates a handful of times a year does not need a database and a login screen. It needs to be fast, secure, and cheap to run, which is exactly what a static build gives you. A site that changes daily, edited by someone who does not want to call a developer, is a different job with a different answer.

I recently kept a client on WordPress for exactly that reason. Their team publishes a few articles a week and nobody on it writes code. Moving them to a static workflow would have shaved a second off load time and cost them hours every week in friction. That is the wrong trade, so I did not make it. The point is to pick the tool that fits the work, not to win an argument about stacks.

What do two demo sites prove about working with a studio of one?#

More than the speed numbers, honestly. One operator built both of these sites, in different visual styles, deployed them to their own domains, measured them, and wrote them up, in a few days. That is the studio of one model working in public: AI-assisted build, modern stack, no team to coordinate, no markup to justify.

It also sets the standard for what I hand over. When I build your web design project, this is the floor, not the ceiling: a fast static site you own outright, on infrastructure you control, with performance you can verify the same way you just verified mine.

If you have a site that feels slow and you are tired of taking your current provider’s word for it, the next step is small. Run PageSpeed on your own site, then run it on mine, and book a short call. No deck, no discovery-phase invoice. Just a look at the gap and an honest view on whether it is worth closing.

The prospect from two weeks ago, by the way, ran the test on the call. Then she ran it on her own site. We are building the replacement now.