Where do the numbers on this page come from?

From the run at the top and the counted band under it. Each one names its command or its file — a live Server-Timing header, a recorded run written down in text/speed-lifecycle-run.md, or a dated Lighthouse baseline in text/perf-baseline.json. The register that reconciles all three is at /speed-metrics.

Can I check them myself?

Yes, and that is the point. The line under the run is a curl against this host and it answers in one round trip. The Lighthouse commands, with the exact flags they were run with, are on /speed.

Why is a tenant page slower than this one?

This page is prerendered and does no server work. A tenant page on a custom domain resolves a domain row, a session and an authority walk before it renders a byte. That is the auth phase in the run at the top, and we count it as a loss — see Limits.

What about cold starts?

Cloudflare Workers do not cold start. Every request is served by an already-warm worker at the nearest edge location.

What actually limits speed?

The model. Inference runs in seconds on the provider’s clock, not ours. Fallback chains route around a provider that has gone slow, configurable per agent — they do not make a slow provider fast.

Are these numbers current?

Each carries the date it was taken and the machine it was taken on, because a figure from a local build and a figure from production are not the same claim. When one goes stale the honest answer is the date, not a fresh estimate.

Do you guarantee a deploy time?

No. The pipeline is deterministic — build, deploy, health check — but we do not sell a stopwatch as a service level. What we publish instead is the timing header on every response, so you can measure us rather than take our word.

A real run, timed

a person opens a tenant page

1 edge CF edge → worker boot, TLS ~5–15ms est
2 auth domain row → authority walk → descendants → billing 256.0ms prod
3 render template + islands — with the data waterfall folded in 746.0ms prod

Two phases, and one of them is 74% of it

The same page on our prerendered host does no server work at all. This one does 1,005ms of it — down from 3,220ms before the waterfall was collapsed — and until the trace shipped nobody could see which part.

0ms

step 1 of 3summed from the measured steps

1.77–2.00sTTFB, ten runs

det~5–15ms1 step · not summeddispatch, routing, D1, KV, render — the only part engineering can fix

chain0.0ms0 steps · consensusfaucet and Sui finality — the price of enforceable, not ours to optimise

llm0.0ms0 steps · the model’sinference — seconds, not milliseconds. not fixable, only avoidable

Server-Timing, mover.chat, live production · text/speed-results.md

generatenever called

llm = 0.0ms · 0 of 3 stepsthe contract is published, so understanding it takes no understanding

edge — inferred from structure and never timed, so it carries a tilde and contributes nothing to the clock

and the part we are not hiding

On the prerendered primary host the identical trace reads auth;dur=0.0, render;dur=0.0, det;dur=0.0 — no server work at all, TTFB 0.30–0.66s, Lighthouse 98 on live production with an LCP of 933ms. The gap between the two is not the code; it is that one of them runs the tenant preamble and the other returns bytes. Collapsing the round-trip waterfall took this page from 3,220ms of server work to 1,005ms; it did not take it to zero, and nothing short of answering from work already done at publish will. On a dev server that preamble measures 2–5ms, which is 50–150× off, and is exactly why this plan reversed its own conclusion twice.

primary host~~det 0.0ms~~det 0.0ms · TTFB 0.30–0.66s

tenant host, server work~~det 3,220ms~~det 1,005ms

tenant host, TTFB~~3.2–4.2s~~1.77–2.00s

the preamble, in production~~224–655ms~~222–274ms

the preamble, local~~2–5ms~~still 2–5ms — it never transfers

what the gate sees~~localhost only~~a tenant host, proven red-able

curl -sI https://one.ie/ | grep -i server-timingauth;dur=0.0, render;dur=0.0, det;dur=0.0check it yourself — every phase on this page ships in a standard header

four serial round trips. on a laptop they cost microseconds, which is how this got called cheap twice.

the preamble barely moved — 501ms to 256ms is the tail going, not the walk getting cheaper. it is the next thing to attack.

render and data are STILL one number here. the split shipped for /u/[slug] and not for this entry path, so this row remains unattributed.

this phase went 2,719ms to 746ms by asking for its data all at once instead of one hop at a time

a gate now sends a real Host: and reads the auth phase — this path is measured, and the gate is proven to go red

Summing the steps gives 1002.0ms; the run printed 1005.0ms — the 3ms difference is untimed overhead between steps, and is not reconciled away.

That was one page load, end to end

Three phases off a live production response. Two carry a measured number, the first carries a tilde because no instrument reaches it, and the line underneath is a command you can run against this host right now.

What just happened

the chip that says est on the first row

No instrument reaches the edge boot, so that step carries a tilde and a range instead of a number, and it adds nothing to the total. Every other chip says prod: read off a live production response.
the row marked auth

Four database round trips, one after another, before the first line of page code runs: the domain row, the authority walk, the descendants, the billing record. That is the tenant tax, and it is the next thing to cut.
the row marked render

On this entry path, render still has the data reads folded into it — so it cannot be read as "rendering is slow". The split shipped for /u/[slug] and not for a custom-domain root, and until it does, that number is two things at once.
the line under the run

The timed phases sum to 1,002.0ms and the header printed 1,005.0ms. The 3.0ms difference is overhead between the phases that the timers cannot see. It is left in rather than reconciled away.
the curl under the run

That is the same header, on this host. This page is prerendered, so there is no server work to time and it answers zero. The run above is the expensive case; this line is the cheap one, and both are real.

How the header gets there

Five steps, and a page never writes the header itself.

Step 1 of 5

The request arrives

Cloudflare Workers, at the nearest edge location. No cold start to pay.
Step 2 of 5

The clock starts

A middleware wrapper starts the request timer and attaches the header on the way out.

src/lib/perf-middleware.ts
Step 3 of 5

Authority resolves

Domain row, session, workspace. The auth phase closes the instant the walk hands off.

src/middleware.ts
Step 4 of 5

The page marks its own phases

From a closed set of names. A page never builds the header itself.

Astro.locals.perf?.mark('data')
Step 5 of 5

The header ships

On every response, in a standard format your browser already parses.

Server-Timing: auth;dur=…, render;dur=…, det;dur=…

These paths are real. Open the repo.

The timing you just watched is six files, and the runs behind it are four more.

one.ie/web/src
- middleware.ts
- lib
  - perf.ts
  - perf-middleware.ts
- components
  - speed
    - speed-run.ts
    - SpeedLine.tsx
    - speed-line.css
text
- speed-results.md
- speed-lifecycle-run.md
- speed-metrics.md
- perf-baseline.json

src/lib/perf-middleware.ts starts the clock and attaches the header. src/components/speed/speed-run.ts holds the recorded runs — every step in it carries the command it was read from and the machine it was read on.

SpeedLine

src/components/speed/SpeedLine.tsx

Props of SpeedLine
Prop	Type	Default	Notes
journey	'page' \| 'chat' \| 'agent'	'chat'	Which recorded run this instance replays. The fold above is set to page. src/components/speed/SpeedLine.tsx:105
proof	boolean	true	Renders the falsify-it-yourself line — the curl and what it answers. src/components/speed/SpeedLine.tsx:112
still	boolean	false	Start paused on the final frame. Reduced motion already does this on its own. src/components/speed/SpeedLine.tsx:103
speed	number	1	Multiplier on every dwell. src/components/speed/SpeedLine.tsx:107

The component at the top of this page is the same one on /speed-metrics, with one prop changed. There is no screenshot of it anywhere on this page.

Counted, with the command that counted it

A phase with no measurement gets no millisecond. That rule is why one of these is a gap rather than a win.

0.0ms

server work behind the prerendered host

curl -sI https://one.ie/ | grep -i server-timing

1,005.0ms

server work behind one tenant page, in production

Server-Timing det;dur on mover.chat, ten hits, 2026-08-20 — text/speed-results.md

0 of 30

steps in the recorded machine run that woke a model

text/speed-lifecycle-run.md — RECORD in src/components/speed/speed-run.ts

3.0ms

gap between the printed total and the steps that make it up

untimedGapOf(page) — printed header minus summed phases, left in

Run it yourself

From an empty folder to a provisioned workspace, on the same runtime the run above was measured on. These are the commands the CLI prints, and that middle line is what it prints back.

bash

$ npx oneie create my-nodeNode created — free plan, no credit card.$ cd my-node$ bun install$ one setup

Limits

Three of these rows go against us. They are the ones worth reading first.

Feature	Typical chatbot platform	In-house build
Every response carries a phase-by-phase timing header		you build it
No cold starts	varies	varies
Streaming inference from the edge	varies	you build it
Ships in one command, no build pipeline to configure	varies	you build it
A dated performance baseline in the repo you can re-run	rarely published	rarely published
Sub-second first byte on a tenant custom domainConceded. The run at the top of this page is real, and it spends 1,005.0ms in the worker before a byte leaves. Our prerendered host spends none. A tenant page on a custom domain is not there yet, and the auth phase is why.	varies	varies
Model response timeConceded. Inference is measured in seconds and it runs on the provider’s clock. Fallback chains route around a slow provider; nothing routes around slow.
Total control of infrastructure and costDedicated in-house infrastructure can match these deploy times. It costs meaningfully more to build and to run.

Speed is the architecture, not a tier

Every plan gets the same edge and the same runtime.

Starter

Same edge, same runtime, every plan.

$500/mo

Full Cloudflare edge runtime

Streaming inference

Single-command deploy

Server-Timing header on every response

Email support

Start my trial

Agency

Priority routing · faster reports

$5,000/mo

Priority edge routing

Faster report generation

Priority support

Start my agency

Scale

Dedicated edge region

$50,000

Dedicated Cloudflare edge region

Reserved Groq capacity

Uptime SLA

Latency percentile dashboard

Talk to us

Questions about speed

You watched a real page load at the top. Now read the header yourself.

Every number here names where it was measured, and the one step nobody has timed says so out loud.

Start my free trial The three runs, step by step

No credit card · every number names its source

That was one page load, end to end

What just happened

the chip that says est on the first row

the row marked auth

the row marked render

the line under the run

the curl under the run

How the header gets there

The request arrives

The clock starts

Authority resolves

The page marks its own phases

The header ships