// build
Websites Built to Rank, Load Fast and Convert
Changing a headline means filing a ticket. The phone score has been red since somebody installed the third analytics tag. The page builder that made it easy to launch now makes every fix a fight. Nobody can say which pages actually produce enquiries. That is the site this service is for. We rebuild the public surface as static HTML, with the smallest amount of JavaScript the design can survive on. Then we hold it to the published Core Web Vitals thresholds. LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, at the 75th percentile of real visits.
That surface is all this page covers. The application behind your login is a different engagement, and it belongs to the software build. Continuous testing of the pages once they exist belongs to CRO.
We build the public surface. We do not drift into becoming your product team on a marketing budget.
Why static, and what it actually costs you
Every page is rendered at build time and served as a file. No server renders a template per request. No database query sits in the path of a visitor. No client-side framework has to boot before the words appear.
Three things follow from that. Time to first byte stops depending on your traffic. That matters because TTFB should be no more than roughly the first 40% of the LCP budget. It is the recommended share and not a law. A slow origin under load will happily spend most of the 2.5 seconds before a byte arrives. Crawlers that fetch but do not execute JavaScript see the same content a browser sees. That includes most of the AI crawlers now reading the web for answer engines. And the site gets cheap enough to host that nobody argues about caching.
The cost is real and worth stating. Publishing goes through a build, so a content change is live in a minute or two instead of instantly. Anything that genuinely needs a server has to be designed as its own endpoint. A live search index, a logged-in area, a pricing calculator hitting your API. None of those come free with the static build.
Where JavaScript earns its place
We are not against JavaScript. We are against shipping a framework runtime to render a paragraph. Interactive pieces load as isolated components on the pages that need them, so a calculator on one page does not slow down the other forty.
This site is the working example. The build enforces a critical-path budget of 40KB of gzipped JavaScript per page and fails if a page exceeds it. Most of these pages come in far under that, because almost nothing here needs to be interactive to be useful.
Built to convert, without pretending we tested it
A new site cannot claim a conversion rate it has never had. What a build can do is remove the reasons a page fails to convert and make the outcome measurable from day one.
So: forms that work on a phone keyboard and do not lose input on a failed submit. The site itself writes a server-side event for every enquiry. That is part of the build and never a tag bolted on afterwards. Client-side analytics is blocked often enough that it cannot be the record of truth. Every tracking call is wrapped, so an analytics failure never takes a real submission with it.
Under all of it, a page that is fast. The cheapest conversion improvement still available to a slow page is the one where it appears before the visitor gives up.
Turning that instrumented baseline into a testing programme is a different service and a different KPI. We will hand you a site where tests are possible. Running them is not part of this line.
Migrations: the part that loses rankings
Rebuilds rarely lose traffic because the new site is worse. They lose it because old URLs stop resolving, or resolve through three redirects, or all land on the homepage. Before launch, every existing path is mapped to its destination and checked to resolve in a single hop. The pages that currently earn traffic keep their paths, unless there is a reason strong enough to move them.
What you will not get from us
A single-page app to render a brochure is off the table, as is any builder that only we can operate. If leaving us costs you more than a handover call, the build was wrong. Nor will you get a few hundred near-identical location pages to inflate the page count. Scaled thin content is a site-wide risk and not a per-page one. The penalty lands on the pages that were earning.
You will also not get a Lighthouse number quoted at you as if it were a ranking factor. Field data from real visits is what we report, because that is what Google measures.
One more, and it is a habit more than a refusal. If you ask us to rebuild the marketing site when the thing costing you money is the product behind the login, we will say so. Even though it means turning down the job in front of us.
What you get
- A statically rendered site in your repository, built and deployed by your own CI
- Field Core Web Vitals reported against the 2.5s LCP, 200ms INP and 0.1 CLS thresholds at the 75th percentile
- A section and page component library, so the next landing page is assembled instead of designed from nothing
- Editing you keep control of, either content as files in the repo or a headless CMS whose account is in your name
- A redirect map covering every existing URL, verified to resolve in a single hop before launch
- Forms that write a server-side event at submit, shipped in this build, with every tracking call wrapped so a failed tag cannot swallow the enquiry
- Metadata and structured data generated from the content, so no page can ship with a missing or duplicated title
- A performance budget enforced by the build, so the site cannot quietly get slower after we hand it over
How it runs
- 01
Measure the site you already have
We pull field performance data, crawl the current site, and record which pages actually produce enquiries. Without that, a rebuild is a redesign with no way to tell whether it helped or quietly cost you traffic.
- 02
Set the JavaScript budget before the design
How much script a page may ship is decided at the start, because it constrains the framework, the animation and the third-party tags. Retrofitting a budget onto a finished build is a second build.
- 03
Render static, add interaction as islands
Every page is HTML at build time, and the few genuinely interactive parts load as isolated components. A crawler, a cheap Android phone and a screen reader all get the content without waiting for a runtime.
- 04
Map every URL, then launch
Old paths are mapped to new ones and checked for single-hop resolution before the switch. Rebuilds lose rankings through redirect chains and forgotten pages far more often than through anything on the new site.
- 05
Verify in the field and hand over the repository
We watch real-user vitals and the conversion path for the weeks after launch, then hand you the code, the accounts and the deployment. A site you cannot deploy without us is a liability, not an asset.
Questions we get asked
- How is this different from the software you build?
- This is the public surface, the pages anyone can reach without logging in, plus the forms that feed your pipeline. The application behind the login, its API and its data model are a separate engagement. The two are built by the same team, and they are scoped, priced and measured apart. We will say which one your request actually is before quoting.
- Can we keep WordPress or our page builder?
- Sometimes, and we will tell you when the honest answer is yes. If your team publishes daily and the site is fast enough, replacing a working CMS buys you very little. We propose a rebuild when the builder is what makes the site slow and fragile. In that case every performance fix is a fight with the tool.
- Will we get a perfect Lighthouse score?
- We do not sell that number. Lighthouse is a lab test on simulated hardware. Google ranks on field data from real visits, and the two disagree regularly. We report the 75th percentile of your actual traffic against the published thresholds, which is the measurement that counts and is harder to flatter.
- Our marketers need to edit pages without a developer. Does a static site break that?
- No. Editors work in a headless CMS or in plain content files, and publishing triggers a rebuild. A change is live in a minute or two, and not instantly. That delay is the only real cost, and in exchange there is no database or plugin stack on the critical path of a visitor request.
- Will a rebuild cost us our rankings?
- It can, and the honest answer is that some short-term movement is normal even when the migration is clean. What we control is the avoidable part. Redirects resolve in one hop, and content is preserved instead of rewritten wholesale on launch day. The pages that earn traffic keep their existing paths wherever possible.
- Who owns everything when the engagement ends?
- You do. The code sits in your repository, the hosting and CMS accounts are in your name, and nothing is licensed back to you. There is no proprietary builder in the stack, so leaving us costs you a handover call. Nothing has to be rebuilt.