What we measure before we call a site fast

Fast is not a feeling and it is not a single score. A marketing site can look instant on a developer laptop and still fail on a mid-range phone in Belgrade on 4G. We measure the things users actually wait on, then we cut the work that does not need to run in the browser.

The numbers that matter

Largest Contentful Paint tells you when the hero is real. Cumulative Layout Shift tells you whether the page jumps while fonts and images settle. Total Blocking Time tells you whether the main thread is too busy to take a click. We treat those as a budget, not as a screenshot for a case study.

• LCP under 2.0s on a throttled lab profile is the floor, not the brag.
• CLS under 0.1 - reserved image space, no late-loading webfonts that restack the heading.
• TBT under 200ms. If a widget needs a click, load it on that click.

Hydration is the tax most sites forget

A page that is "React" is not automatically interactive-heavy. If a section has no state, it should not be a client component. We keep the landing page as server HTML and hydrate the islands that earn it: the form, the mobile menu, the booking embed. Cal.com does not get to download on first paint. It loads when someone asks to book.

Images get real dimensions, modern formats, and a blur placeholder so the layout does not jump. Fonts are self-hosted. Third-party scripts are guilty until they prove they belong in the critical path.

Lab scores still lie without a field check

Lighthouse on desktop is the easy mode. We still run it because a regression there is a cheap catch. The number we trust more is a mobile profile and, once the site is live, real-user timing. If the field data disagrees with the lab, the field data wins.

That is what we mean by built for speed. Not a theme with a performance toggle. A stack where the default path does less work.