Your site feels fast on your phone because your phone has visited it a hundred times. Your customers arrive cold, on a train, on a three-year-old phone, mid-checkout. Speed for them is a different number entirely, and that number has a revenue line under it.
So we ran the experiment on ourselves first. Our own site is the test subject, its source code is public, and you can check every claim on this page in about ten minutes without asking our permission.
What we changed
A Next.js site (Next.js is the framework our site and our client work are built on) can serve pages two ways: build each page fresh for every visitor, or build it once ahead of time and hand out the finished page. Fresh-for-every-visitor is flexible and slow under load. Built-ahead is fast everywhere and risks going stale.
The middle path is what we shipped. Each page is built ahead of time and handed out finished, and the parts that change get rebuilt on a timer: at most every 300 seconds, five minutes. The setting lives in one line per page, revalidate = 300, in our public repository (github.com/Anito-Systems-Solution/anito-main-web). A visitor never waits for the machinery. The machinery updates itself while nobody is looking.
The experiment that matters more: unplug the CMS
Our content lives in a separate CMS (the admin system where articles get written and stored, like a newsroom database) on its own server. The obvious failure mode: that server goes down, and every page that reads from it goes down with it.
So we built the reads to degrade instead of die. Every time the site reads from the CMS, the read can fall back to a copy built into the site itself. Unplug the CMS and the site stays up: same pages, same articles, same links. The source code shows the fallback, and we test it by doing exactly that.
The site surviving its own CMS being unreachable is worth more to a business than any speed score, because the outage you get warned about costs you a bad afternoon, and the one that silently eats your checkout costs you customers you never counted.
Why this pays out to you
Two moves here, and both transfer to any build you pay for:
- Finished pages beat fresh pages. When a developer proposes building every page on every visit “so content is always current”, ask what a five-minute rebuild timer would cost instead. Usually nothing.
- Degrade, do not die. Any system that reads from another system should answer the question: what happens to my revenue pages when that other system is down? If the answer is a shrug, the shrug is the finding.
The same pattern runs on Milyon Digital, the client site we designed and built with a decoupled CMS, and it is the reason we did not have to think hard about the answer for our own site: the pattern was already proven on work a customer can open and click through right now (milyondigital.com).
What this does not fix
Honest limits: pre-built pages do not fix a heavy image habit, a pile of third-party tracking scripts, or a theme that loads a design framework to render a paragraph. Those slow a page no matter how it is delivered, which is why a speed score reads as a list of fixes, never a single switch. When we test our own pages we read the score’s detail list, because the detail is where the work items live. A developer who quotes “performance optimization” as a line item without naming what is on the list is quoting a mood. The list is the deliverable; the score is the receipt.
Run the check yourself
Ten minutes, no permission needed:
- Go to pagespeed.web.dev and test our site (anito.ai). Then test the portfolio page of any developer you are quoting with: their own site is their shop window. Look at their score, not their claims.
- Ask any developer: “if the CMS goes down, what do visitors see?” A specific answer means they have thought about it. A pause means they have not.
- Ask: “how long after I publish does the change appear, and what runs in between?” Our answer is five minutes, and the line of code is public.
If that list made you want a second opinion on a build you are weighing, discuss your project with us. You will get a straight answer, including the answer that you do not need us yet.
Common questions
Does the five-minute rebuild mean my published changes take five minutes to appear?
Up to five minutes for pages served from the pre-built copy, and the interval exists so a change never forces a visitor to wait for a fresh build. For most business content that delay is invisible. If a page truly cannot wait (a price change during a promotion, for example), that page gets a shorter timer or an on-publish trigger, and that is a per-page decision worth making deliberately.
Is a separate CMS not just another thing that can break?
It is another thing, which is exactly why the fallback exists. The alternative is editing pages in code, which puts publishing in the hands of whoever has developer access. Separating where content lives from how it renders keeps publishing with your team, and the fallback keeps the site alive when the content server has a bad day. Two systems with a designed relationship beat one system with a single point of failure.
What speed number should I actually care about?
The ones measured on a cold device on a mobile connection: Largest Contentful Paint (how long until the main content appears) under about 2.5 seconds, and Interaction to Next Paint (how fast the page responds when tapped) under about 200 milliseconds. PageSpeed Insights reports both. Care with lab scores produced on warm machines; the cold number is the one your customers get.