Sub-second, on a phone, on a bad connection

Website speed is measured by three published numbers: how long until the main content appears (target: under 2.5 seconds), how fast the page reacts when you tap (under 200 milliseconds), and how much it jumps around while loading (as near zero as possible). They're measured on real visitors' phones, not on a fast laptop on office wifi.

Why does the third one matter so much?

Because you've experienced it. You go to tap a link, an image finishes loading above it, the page shifts, and you tap an advert instead. That's a measurable defect with a name, and it's the one nobody thinks to ask for and everybody has suffered.

It's caused by content arriving without reserved space. The fix is unglamorous — every image gets its dimensions declared up front, so the space is held before the picture arrives.

What actually makes a site fast?

• Real HTML, delivered ready. Not a blank page that assembles itself once scripts load.
• Images in modern formats, sized properly. A 4000-pixel photo scaled down in the browser still downloaded at 4000 pixels.
• Load order that respects the reader. The image at the top loads immediately; things below the fold wait until you scroll near them. Heavy pieces come after your text is already readable.
• Fonts that don't hide your text. The default behaviour on many sites is invisible text for the first second.
• Nothing bloated in the way. Page-builder plugins are the usual culprit, and the usual reason a "fast host" didn't help.

What about tablets?

Tablet is where responsive layouts usually break, and it's the width nobody tests. Portrait and landscape behave differently enough to count as two cases. We check them as their own thing rather than assuming that something working at phone and desktop size works in between.

Where does accessibility come into this?

Same job, mostly the same work. Text large enough to read — at least 16 pixels on mobile. Tap targets big enough to hit, around 48 pixels. Colour contrast meeting the 4.5:1 minimum. Form fields properly labelled. A visible outline when navigating by keyboard. Correct document structure so a screen reader can move through it.

We build to WCAG 2.2 AA, which is a published standard we can test against with real tooling. We deliberately do not say "ADA compliant" — that's a legal determination, not a technical test, and any vendor selling it is selling you a sentence. We also don't install accessibility overlay widgets: they have a poor record with the users they claim to help, and they've been named in lawsuits rather than preventing them.

One honest note about our own site: when we published a WCAG claim, an audit found contrast failures on every page. We fixed the site rather than softening the claim. That's the rule — if an audit fails, either the site gets fixed or the claim comes off the page.

Common questions

My host says they're fast. Isn't that enough?

Hosting is one contributor and rarely the binding one. A fast server delivering a bloated page is still a slow website.

Is a perfect score the goal?

No. Lab scores are a diagnostic tool. What counts is the numbers from real visitors on real phones, which is what we monitor after launch.

Can any site be made sub-second?

No, and the ceiling is set by your content. If you need a 40-megabyte video on the homepage, we'll make it as fast as it can be and tell you honestly what it costs you.