Response time is how long your server takes to start returning a page after a request. Slow responses delay everything the user sees, increase bounce rates and drag down Core Web Vitals. Aim for a fast, consistent response.
Response time measures server speed before any rendering happens. It is the foundation of perceived performance: no amount of front-end optimisation can hide a slow server.
Check your website
See how your site handles website response time: why speed builds trust — free, no account needed.
For business owners
Speed is trust. Visitors judge a slow site as less professional and less reliable, and they leave — abandonment climbs sharply with every extra second. A fast, consistent response makes the whole experience feel dependable and directly improves conversions and search performance.
How it works (technical)
Response time is dominated by Time To First Byte (TTFB) — DNS, connection and TLS setup plus server processing. Slow responses usually come from unoptimised database queries, lack of caching, under-resourced hosting, or distant servers. Fixes include caching (page, object and CDN), query optimisation, faster hosting and putting a CDN close to users.
Real-world example
A booking site's homepage took three seconds just to respond because every visit ran uncached database queries. Adding full-page caching cut the server response to under 200ms, and bounce rate on mobile fell significantly.
Why it matters
Response time underpins Core Web Vitals and user experience. Scanners measure it because it is a direct, comparable indicator of site health and trust.
How to fix it
Add caching — page, object and CDN — so repeat work is not redone per request.
Optimise slow database queries and add indexes.
Use a CDN to serve users from a nearby location.
Upgrade under-powered hosting if the server is the bottleneck.
Monitor response time over time to catch regressions.
Best practices
Cache aggressively but invalidate correctly.
Measure from multiple regions, not just your office.
Track trends so gradual slowdowns are caught early.
Common mistakes
Blaming the front end when the server response is the real delay.
No caching on dynamic pages.
Only testing speed once instead of monitoring it.
Frequently asked questions
What is a good response time?
Aim for a server response (TTFB) under about 200ms; under 500ms is acceptable. Above ~1s starts to noticeably hurt experience.
Put this into practice
See how your site scores with Plexa Trust — start with a free scan, then unlock the complete audit on Pro.
Scan your website free