Every Page Here Was Finished Before You Asked for It
We build sites where the page already exists as a file by the time you click. Here is what that means, why we do it, and what it changes for the person reading.
You are reading this on Fractera, and this page was not made for you. It was made before you arrived — written, checked and turned into a finished document days ago. When you clicked, nothing had to be assembled: the server looked up a file and handed it over. This post is about why we build almost every page that way, and what you get out of it that has nothing to do with our convenience.
Two ways to answer a visitor
A website can answer a request in one of two ways, and the difference is the whole story. It can assemble the page while you wait — wake up, ask the database, decide what your version looks like, render it, then send it. Or it can have the page ready and simply send it. Both look identical when everything goes well, on a fast phone, on a good network, at a quiet hour. They stop looking identical the moment something goes wrong.
| When you open a page | Assembled on request | Finished in advance |
|---|---|---|
| What happens at that moment | The server wakes, queries the database, renders the HTML, then replies | The server finds a finished file and sends it |
| A hundred people arrive at once | That work is done a hundred times | The same file is sent a hundred times |
| Scripts fail to load on a bad connection | Often a blank screen — the text was going to be drawn in your browser | The words are already in the document you received |
| The database is having a bad day | The page cannot be produced at all | The page is unaffected; only genuinely live parts are |
| A search engine or an AI assistant reads it | Whatever happened to be finished in time | The whole page, the same as a person sees |
What the waiting actually costs
Speed is easy to dismiss as vanity, so it is worth looking at what has been measured. Google’s own guidance puts the bar for the main content of a page appearing at 2.5 seconds or less, measured at the 75th percentile of loads — not for your best visitor, but for the unlucky quarter on a tired phone in a lift. And a study commissioned by Google and prepared by Deloitte, which watched four weeks of mobile traffic across retail, travel, luxury and lead-generation brands in Europe and the US, put a price on a single tenth of a second.
- +8.4%
retail conversions after a 0.1 s speed-up
- +9.2%
average order value in retail
- +10.1%
travel conversions, same study
- 4
weeks of mobile traffic observed
A tenth of a second is not a redesign. It is roughly the difference between handing over a file and building the answer first — which is the entire subject of this post. And the benefit is not only commercial: the same speed decides whether a person on a train, on a rural connection, or on a five-year-old phone sees your business at all, or sees a white rectangle and goes back.
It is also how you are found“Core Web Vitals are used by our ranking systems.”
Google is careful to say this is one signal among many and that good numbers alone do not lift you up the results. We are equally careful: we do not promise rankings. What we can promise is that the page will not be the reason you lose them.
What a visitor gets, in plain terms
- The words arrive with the page. The text you are reading is inside the document your browser downloaded, not painted in afterwards by a script. Turn JavaScript off and this article still reads perfectly — that is a deliberate property, tested on every build, not a happy accident.
- A busy day does not slow it down. Handing out the same finished file a thousand times costs almost nothing. Sites that build each page on demand get slower exactly when they are most popular, which is exactly when it matters.
- Less can break. A page that needs no database at the moment you open it cannot be broken by a database. Fewer moving parts between your click and your screen means fewer ways for the answer to go missing.
- Machines read the same page you do. Search engines and AI assistants get the complete text, not a shell that would have filled itself in a browser they do not run. Everything published here also has a plain-text twin written for exactly that audience.
How we actually build one
From a folder of words to a file on a server
Four steps, and a page is only published if it survives all four.
The words live in a folder
Each page is a folder with its own text inside — one file per language, sitting beside the page it belongs to. Nothing is stitched together from a database at the moment you open it, and deleting the folder removes the page completely, translations included.
A build turns them into finished documents
Before anything goes live, the whole site is rendered once into ready HTML. That is the step that moves the waiting off your visit and onto our clock, where it belongs.
Machine checks refuse the broken ones
A picture referenced but never committed, a language that lost its translation, a page that quietly stopped being static — each of those fails the build instead of reaching you. Every check exists because that exact mistake shipped once.
Your browser receives a file
Nothing is computed for you, because there is nothing left to compute. The server’s only job is to find the right document and send it.
Where we stop being static, on purpose
Anything that belongs to you alone cannot be prepared in advance, and we do not pretend otherwise. Your order history, your account, a basket, a signed-in dashboard — those are drawn after you sign in, because a page prepared for everybody is by definition not private. The rule we hold to is simply this: the public part of a site, the part a stranger and a search engine meet first, has no excuse to be assembled on demand.
There is a second, quieter cost, and it is ours: building in advance means we have to know what a page says before anyone asks. That is more discipline for us and less improvisation. We think that trade is obviously worth it, and we would rather say it out loud than let you discover it in a proposal. Who “we” are is on the About us page in the footer.
Speed is not decoration. It is the first thing a site says to a stranger, and it is said before a single word has been read.
Sources
- Largest Contentful Paint (LCP) — web.dev, Google. The “good” threshold is 2.5 seconds or less, assessed at the 75th percentile of page loads across mobile and desktop.
- “Understanding page experience in Google Search results” — Google Search Central. The sentence quoted above appears there verbatim, alongside the caveat that there is more to page experience than these scores alone.
- “Milliseconds Make Millions” — commissioned by Google and prepared by Deloitte Ireland LLP on data from Fifty-Five. Four weeks of mobile site data from retail, travel, luxury and lead-generation brands across Europe and the US. A 0.1 s improvement in mobile site speed produced +8.4% retail conversions, +9.2% average order value and +10.1% travel conversions.
The three numbers above are quoted from those published studies and were checked against the originals. Everything else in this article is our own practice, and we are happy to be argued with about it.
Frequently asked questions
- Does “static” mean my site can never change?
- No. It means the page is finished before a visitor asks for it, not that it is finished forever. Text, images, prices and languages are edited in a control panel and apply without rebuilding the site. Pages that carry changing information are refreshed in the background on a schedule, and everyone keeps getting a ready copy while that happens.
- Will this make my site rank higher on Google?
- Nobody can honestly promise that, and we do not. Google states that Core Web Vitals are used by its ranking systems, while also saying that good scores alone do not lift a site up the results. What a fast, complete page does guarantee is that a search engine and an AI assistant receive the whole of your content rather than a shell — and that speed is not the reason a visitor leaves.
- What about a shop, a login, an account page?
- Those are drawn for the individual person after they sign in, because a page prepared for everybody cannot be private. The split is deliberate: everything public — the home page, the articles, the catalogue, the pages in the footer — is finished in advance, and only the parts that genuinely belong to one person are produced on request.