Time to First Byte, or TTFB, measures how long a browser waits before it receives the first byte of a response from the server after requesting a page. It captures DNS lookup, connection setup, and server processing time. A low TTFB means your site starts loading quickly, which sets the ceiling for every other speed metric.
Key takeaways
- TTFB measures the delay between requesting a page and receiving its first byte of data.
- It is the foundation metric, because every other loading metric starts only after the first byte arrives.
- A good TTFB is generally under 800 milliseconds, with under 200 milliseconds being excellent.
- The main contributors are DNS lookup, connection setup, server processing, and network distance.
- Hosting quality, caching, and a content delivery network are the biggest levers you can pull.
- Framer sites are served from a fast global infrastructure, so strong TTFB comes built in.
What TTFB actually measures
When a visitor’s browser requests your page, a sequence of events has to happen before any content can render. The browser resolves your domain to an IP address through a DNS lookup. It opens a connection and negotiates a secure TLS handshake. It sends the request, and the server processes it, which may involve running code, querying a database, and assembling HTML. Only then does the server send back the first byte. TTFB is the total time for all of that.
This matters because TTFB is the starting line for everything else. The browser cannot begin parsing HTML, cannot discover the stylesheet it needs, and cannot start painting pixels until the first byte arrives. If TTFB is slow, every downstream metric inherits that delay. You can optimize images and defer scripts all you want, but a slow first byte caps how fast your page can possibly feel.
For a deeper treatment of this specific metric, our standalone guide to Time to First Byte walks through the mechanics in more detail. The summary is that TTFB is the server-side foundation that the rest of your performance is built on.
What counts as a good TTFB
As a practical benchmark, a TTFB under 800 milliseconds is considered good, and tools like Google Lighthouse and PageSpeed Insights flag values above that as a problem. Under 200 milliseconds is excellent and typical of well-hosted, well-cached static sites. Anything over 1.5 seconds is a serious issue that will drag down the entire experience and your search rankings along with it.
It is worth understanding that TTFB varies by visitor. A user physically close to your server, with cached DNS, on a fast connection, will see a far lower TTFB than a user on the other side of the world hitting your origin cold. This is why measuring TTFB from a single location can mislead you, and why a global content delivery network is so effective. It moves your content physically closer to every visitor.
The four contributors to TTFB
Breaking TTFB into its parts shows you exactly where to optimize.
DNS lookup
Before anything else, the browser has to translate your domain into an IP address. A slow or distant DNS provider adds latency here. Using a fast, globally distributed DNS service removes this as a bottleneck, and the cost of doing so is usually nothing.
Connection and TLS setup
Establishing a connection and completing the secure handshake takes round trips between the browser and server. Modern protocols and properly configured servers reduce the number of round trips required, which directly trims TTFB. The farther the server, the more each round trip costs.
Server processing time
This is the time the server spends generating the response. For a dynamic site that runs code and queries a database on every request, this can be the largest component. For a static or pre-rendered site, the server simply hands back a ready file, which is dramatically faster. This single architectural choice often makes the biggest difference.
Network distance
Physical distance between the visitor and the server imposes a hard floor on latency, because data cannot travel faster than the speed of light through fiber. A visitor far from your origin server will always see a higher TTFB unless the content is served from somewhere closer, which is precisely what a content delivery network does.
How to improve TTFB
The highest-leverage improvements address the largest contributors first.
Serve static or pre-rendered content wherever possible. When the server can return a ready-made file instead of generating one per request, server processing time collapses toward zero. This is the single most effective structural change for most sites.
Use a content delivery network. A CDN caches your content at edge locations around the world, so visitors are served from a nearby node rather than a distant origin. This attacks both network distance and server processing in one move, and it is the standard way fast sites stay fast for a global audience.
Cache aggressively. Whether it is full-page caching, edge caching, or caching the expensive parts of a dynamic response, every cache hit avoids server work and shortens TTFB. The goal is for the common case to never touch slow origin processing.
Choose quality hosting. Cheap, oversold shared hosting produces inconsistent, often poor TTFB because your server is contending for resources. Hosting built for performance, with fast infrastructure and good caching defaults, removes a whole category of problems.
Optimize the back end. For genuinely dynamic pages, slow database queries and unoptimized code show up directly in server processing time. Profiling and tightening the slow paths pays off in TTFB.
TTFB does not exist in isolation. Once the first byte arrives quickly, you want the page to paint quickly too, which is the subject of our companion guide to First Contentful Paint. A fast TTFB makes a fast First Contentful Paint possible, but you still have to optimize what happens after the first byte.
TTFB, trust, and conversion
Speed is not a vanity metric. Slow-loading pages lose visitors before they ever see your offer, and the loss compounds at every second of delay. Because TTFB gates everything that follows, a poor TTFB is felt by every single visitor on every single page load. Improving it lifts the entire experience at once.
There is also a search dimension. Google uses page experience signals, including loading performance, as a ranking factor, and Core Web Vitals are influenced by how quickly your server responds. A slow TTFB can quietly suppress your rankings, which means fewer visitors reach your conversion-optimized pages in the first place. The fix at the server level protects both the visitors you have and the ones search sends you.
Mobile visitors feel slow servers most acutely, often on weaker connections and less powerful devices. Since so much traffic is now mobile, a fast first byte is essential to the mobile experience, a theme we explore further in our mobile-first design guide. A site that responds instantly on mobile keeps users engaged where the patience for delay is lowest.
A practical example
Imagine a marketing site built on a traditional dynamic platform with budget shared hosting. Every page request triggers code execution and several database queries, and the single server sits in one region. Visitors near that region see a TTFB around 600 milliseconds, while visitors across the world see well over a second, and during traffic spikes the shared server slows further.
Now imagine the same site rebuilt as a pre-rendered static site served through a global CDN. The server no longer generates pages per request, it hands back cached files from the edge location nearest each visitor. TTFB drops below 200 milliseconds almost everywhere, the difference between regions nearly disappears, and traffic spikes no longer degrade performance because the edge absorbs them. Nothing about the content changed. The delivery architecture did, and every visitor now starts loading the page faster.
Common TTFB mistakes
The first mistake is blaming front-end assets for a server-side problem. If your TTFB is high, optimizing images will not fix it, because the delay happens before any image is even requested. Diagnose where the time actually goes before optimizing the wrong layer.
The second is measuring from a single location and assuming it represents everyone. Your TTFB near the server tells you nothing about a visitor on another continent. Test from multiple regions to see the real picture.
The third is choosing hosting on price alone. Oversold shared hosting is a common, hidden cause of poor and inconsistent TTFB, and no amount of front-end work compensates for it.
The fourth is running fully dynamic pages when static would do. Many marketing and content pages do not need per-request generation. Pre-rendering them removes the largest TTFB contributor entirely.
The fifth is skipping a CDN. Without one, every visitor hits your origin directly, and distant visitors pay the full latency cost. A CDN is one of the cheapest, highest-impact TTFB improvements available.
How to measure TTFB accurately
Before optimizing TTFB, measure it properly, because a single misleading number leads to wasted effort. Tools like Google PageSpeed Insights and Lighthouse report server response time, and field data from real users shows you what visitors actually experience rather than a synthetic test from one fast connection. The two together give you the full picture, with lab tests for diagnosis and field data for reality.
Crucially, measure from more than one location. TTFB near your server tells you almost nothing about a visitor on another continent, and the gap between the two is often where your real problem lives. If your local TTFB looks fine but field data shows slow responses, the cause is usually network distance, which points straight to a CDN as the fix. If TTFB is slow everywhere, the cause is more likely server processing or hosting. Letting the measurement guide the diagnosis keeps you from optimizing the wrong layer and chasing improvements that visitors never feel.
How Framer helps
Framer sites are served from a fast, globally distributed infrastructure with content delivered from edge locations close to your visitors. Pages are optimized and cached by default, so the heavy server processing that slows traditional platforms is simply not part of the equation. The result is a strong TTFB without you having to configure caching layers, tune a server, or stand up a CDN yourself. The fast first byte comes built into how Framer serves your site.
Want a site that responds instantly?
Fast loading starts with a fast server response, and that is built into every Framer site we ship. Let us build you a site that loads fast for every visitor, everywhere.
Frequently Asked Questions
What is a good TTFB value?
Under 800 milliseconds is generally considered good, and tools like Lighthouse and PageSpeed Insights flag higher values. Under 200 milliseconds is excellent and common for well-hosted static sites served through a content delivery network.
Is TTFB the same as page load time?
No. TTFB measures only the wait for the first byte from the server. Total page load includes downloading and rendering all the assets that follow. TTFB is the starting point, and a fast one makes a fast overall load possible.
Does a CDN improve TTFB?
Yes, significantly. A content delivery network serves cached content from edge locations near each visitor, reducing both network distance and server processing. For a global audience, it is one of the most effective ways to lower TTFB everywhere.
Why is my TTFB high even though my site looks simple?
A simple-looking site can still run dynamic code and queries on every request, or sit on slow shared hosting in a single region. Those server-side factors drive TTFB, not how the page looks. Pre-rendering and quality hosting usually fix it.