Web Performance Starts Before the First Byte: DNS, Domains and TTFB

by

Most performance guides start at the browser: minify your JavaScript, compress your images, cut your render-blocking CSS. All of that matters — but by the time the browser gets to render anything, a whole chain of events has already happened. And if that chain is slow, no amount of front-end optimization will save your Time To First Byte.

Today we’re looking at the very first links in that chain: your domain and its DNS.

1. Every page load starts with a DNS lookup

Before a single HTTP request is sent, the browser has to resolve your domain name to an IP address. On a cold lookup this can take anywhere from 20 to 300+ milliseconds depending on where your authoritative nameservers live and how they’re built.

That cost is paid before TCP, before TLS, before your server even knows anyone is visiting. It’s pure dead time — and it’s entirely determined by choices you made when you registered the domain.

2. Your registrar’s DNS is part of your stack

Many sites simply use the nameservers their registrar assigned at signup and never think about it again. That’s fine if the registrar runs a serious DNS infrastructure — and a problem if it doesn’t.

What to look for:

  • Anycast DNS. The same nameserver IP announced from many locations worldwide, so the lookup is answered close to the visitor instead of crossing an ocean. This alone can cut 100+ ms for international users.
  • Low, sane TTLs where you need them. Long TTLs (hours) for stable records mean most visitors hit a cached answer and pay ~0 ms. Short TTLs only where you actually plan to fail over.
  • DNSSEC support. Not a speed feature, but a trust one — and increasingly expected.
  • An API. If you manage more than a couple of domains, being able to script record changes (and automate ACME DNS-01 challenges for TLS certificates) is the difference between a five-minute deploy and a support ticket.

European registrars have quietly become very good at this. INWX, for example, bundles anycast nameservers, DNSSEC and a full JSON-RPC API with every domain — the kind of setup you’d otherwise assemble yourself from a registrar plus a separate managed-DNS provider.

3. Practical checklist

  1. Measure it. Run your domain through a DNS performance tester from several regions. If cold lookups exceed ~100 ms from your main markets, your nameservers are costing you real TTFB.
  2. Cut CNAME chains. Every extra CNAME hop is another lookup. Point records as directly as you can, and use ALIAS/ANAME (CNAME flattening) at the apex.
  3. Preconnect for third parties, not for yourself. dns-prefetch and preconnect hints help with external origins; your own domain’s lookup happens before HTML exists, so only fast authoritative DNS fixes that.
  4. Raise TTLs on stable records. If your A record hasn’t changed in a year, a 300-second TTL is just donating latency to your visitors.
  5. Consolidate. Domains scattered across registrars with mixed nameserver quality are impossible to audit. One provider, one API, one DNS story.

The takeaway

Front-end performance work has the best tooling and the loudest advocates, but the waterfall doesn’t start at the first byte of HTML — it starts at the resolver. Treat your domain’s DNS as part of your performance budget, measure it like you measure LCP, and choose infrastructure (registrar included) accordingly.

Your users will never know why the site feels fast. That’s the point.

Leave a Comment