Three seconds. That's all you get.
Studies consistently show that if a page takes more than 3 seconds to load, over half of visitors leave. They don't wait. They don't come back. They go to the next result.
Google knows this. That's why page speed has been a ranking factor since 2010, and Core Web Vitals became a ranking signal in 2021.
Response time vs. page load time — what's the difference?
Response time (TTFB) — Time To First Byte. How long it takes your server to start sending data after receiving a request. This measures server performance.
Page load time — How long it takes for the complete page to be usable. This includes downloading HTML, CSS, JavaScript, images, and rendering everything.
Both matter, but TTFB is the foundation. If your server takes 2 seconds to respond, nothing else you optimize will make the page feel fast.
What causes slow response times
| Cause | Typical impact |
|---|---|
| Shared hosting under load | TTFB spikes during traffic peaks |
| Database queries not optimized | Server waits for slow queries to finish |
| No caching layer | Every request rebuilds the page from scratch |
| Server located far from users | Physical distance adds latency |
| Too many server-side redirects | Each redirect adds a full round trip |
| Unoptimized images | Massive files that take forever to transfer |
| Render-blocking JavaScript | Browser can't show content until scripts finish |
The Core Web Vitals connection
Google's Core Web Vitals include three metrics:
- LCP (Largest Contentful Paint) — When the main content becomes visible. Slow TTFB directly hurts LCP.
- INP (Interaction to Next Paint) — How fast the page responds to user input. Heavy JavaScript hurts this.
- CLS (Cumulative Layout Shift) — How much the page jumps around while loading. Images without dimensions cause this.
Failing Core Web Vitals doesn't tank your rankings overnight, but it's a tiebreaker. Between two similar pages, the faster one wins.
Quick wins for faster pages
Use a CDN. Serve content from a server close to the user instead of from one central location.
Enable caching. Don't rebuild the page for every visitor. Cache static and semi-static content.
Optimize images. Use modern formats (WebP, AVIF), compress them, serve the right size for each device, and lazy-load below-the-fold images.
Minimize render-blocking resources. Inline critical CSS, defer non-essential JavaScript.
Reduce server-side processing. Optimize database queries, use a faster runtime, or pre-render pages at build time.
Measuring response time across your site
A single page might be fast, but what about the other 500? You need a crawler that:
- Records the response time of every page
- Flags pages with high TTFB (above 600ms)
- Identifies patterns — is an entire section slow, or just specific pages?
- Tracks response time over multiple audits to spot degradation
Kaitico measures the response time of every crawled page and flags slow pages in your audit report, helping you spot performance bottlenecks across your entire site.