What Is a Good Website Response Time? (2026 Standards)

A good website response time is 0.8 seconds or less, measured as time to first byte (TTFB). That is Google’s current benchmark, and most websites miss it: HTTP Archive’s Web Almanac 2025 found that only 55% of desktop sites and 44% of mobile sites achieve a good TTFB.

If your site is one of the misses, the cause is rarely mysterious. It’s usually missing caching, plugin bloat, or a database nobody has cleaned in years.

This guide covers the current response time standards (including why Google appears to publish three different numbers), how to check where your site stands, and the fixes that actually move the needle.

What is a good website response time?

A good website response time is 0.8 seconds or less, measured as TTFB (time to first byte). Google’s current guidance (web.dev, updated November 2025) sets three bands, measured at the 75th percentile of visits:

• 0.8 seconds or less: good.
• 0.8–1.8 seconds: needs improvement.
• Over 1.8 seconds: poor.

That’s the server-side benchmark. From the visitor’s side, what matters is how fast the page feels, and the perception thresholds have been stable for decades. Nielsen Norman Group’s response-time research puts one second as the limit for keeping a user’s flow of thought uninterrupted:

• Under 1 second: feels instant to the visitor.
• 1 to 2 seconds: still feels fast and smooth.
• 2 to 3 seconds: acceptable, but the delay is noticeable.
• 3 seconds or more: feels slow and starts costing you visitors.

You’ll often hear “keep the whole experience under 2 seconds” as the target. That’s a reasonable rule of thumb, but it’s an industry convention, not a published standard, so treat it as a guide rather than a pass mark.

One note on Core Web Vitals: TTFB isn’t one of them, but response time still feeds them (more on that below), and Core Web Vitals are used by Google’s ranking systems. Google is careful to add that good scores don’t guarantee top rankings; relevance still comes first.

For the full picture, read our guide on how Core Web Vitals affect SEO.

What is TTFB (time to first byte)?

TTFB (time to first byte) is the time between a visitor requesting your page and the first byte of the response arriving in their browser. It includes redirect time, DNS lookup, the connection and TLS handshake, and the wait while your server processes the request and starts responding.

When people say “server response time,” they almost always mean TTFB. The two terms are used interchangeably in Google’s tooling and in most performance documentation, and this article treats them as the same measurement.

Google’s thresholds for TTFB are the ones above: good at 0.8 seconds or less, poor above 1.8 seconds, measured at the 75th percentile of visits. Google itself calls these a “rough guide” rather than a hard standard, because architecture changes the math. A single-page app that builds everything in the browser needs a faster TTFB than a server-rendered page that arrives ready to read.

TTFB is not a Core Web Vitals metric, but it caps everything downstream. Your Largest Contentful Paint can never be faster than your TTFB, because the browser can’t render what it hasn’t received. A slow first byte makes every other speed target harder to hit.

Server response time vs website response time vs page load time

These three terms get used interchangeably, but they measure different slices of the same journey, and each has its own benchmark.

Metric	Definition	What it includes	Good	Needs improvement	Slow
Server response time (TTFB)	Time for the server to process a request and send the first byte of data	Redirects, DNS lookup, connection and TLS setup, server processing, database queries	0.8s or less	0.8–1.8s	Over 1.8s
Website response time	Time for the site to start responding and showing content	Server response time plus network delays and first visual elements appearing	Under 1 second (feels instant)	1–2 seconds (fast, but perceptible)	3 seconds or more
Page load time	Total time for the page to fully load and become interactive	Website response time plus rendering, scripts, images, and third-party resources	Under about 3 seconds (UX convention)	Past 3 seconds, delays are obvious	Well past 3 seconds

Sources: TTFB bands from Google’s web.dev guidance (updated November 2025, at the 75th percentile); perception tiers from Nielsen Norman Group’s response-time limits; the 3-second page load figure is a UX convention, with the abandonment stat from Google/SOASTA’s 2016 mobile research.

Where do real sites stand? HTTP Archive’s Web Almanac 2025 found that only 55% of desktop sites and 44% of mobile sites achieve a good TTFB, and just 56% (desktop) and 48% (mobile) pass all three Core Web Vitals. Hitting 0.8 seconds puts you ahead of roughly half the web.

Why Google gives three different numbers (200ms, 600ms, and 800ms)

If you’ve researched server response time before, you’ve probably run into three different “Google recommends” figures. All three are real. They come from different places, and only one is current:

• 200ms comes from a deprecated PageSpeed Insights API doc (v4, shut down in 2019). It’s historical only, and any article still citing it is working from retired guidance.
• 600ms is the threshold that trips the “Reduce initial server response time” warning in PageSpeed Insights reports, the one your clients see flagged. It comes from a Lighthouse audit that has since been folded into the “document request latency” insight in Lighthouse 13.
• 800ms is Google’s current TTFB guidance on web.dev, updated November 2025.

When you need one number, use 800ms. It’s the current, maintained threshold, and it’s the one this article uses throughout.

Why does website response time matter?

Slow server responses cost you in three places: visitor behavior, search visibility, and how often Google even looks at your site.

Visitors leave before the page makes its case. Once a response takes more than a second, Nielsen Norman Group’s research shows the visitor’s flow of thought breaks, and every extra second after that erodes trust in the page. The business impact is measurable: in 2020, Deloitte and Google’s “Milliseconds Make Millions” study analyzed 37 brand websites across more than 30 million sessions and found that a 0.1-second improvement in mobile site speed increased retail conversions by 8.4%.

Speed feeds Google’s ranking systems. Google’s page experience documentation (updated December 2025) states that Core Web Vitals are used by its ranking systems, with the caveat that good scores don’t guarantee top positions. Since TTFB caps Largest Contentful Paint, a slow server response makes good Core Web Vitals scores harder to achieve in the first place.

Slow servers get crawled less. Google’s crawl budget documentation (updated December 2025) says it directly: when a site responds quickly, Google raises its crawl limit; when it slows down or returns server errors, Google crawls less. The effect matters most on large sites, but a site-wide slowdown can delay how quickly your new and updated pages get picked up. Our guide on website crawlability covers how to find and fix the wider crawl issues.

How to check your server response time

Before fixing anything, get a number. Three free lab tools will give you one in a few minutes:

• PageSpeed Insights: run your URL and check the diagnostics for the “Reduce initial server response time” warning (in newer Lighthouse versions it appears under document request latency). This is the same report your clients see, so it’s the natural place to start.
• Chrome DevTools: open the Network panel, reload the page, and select the first document request. The Timing tab shows “Waiting for server response,” which is your TTFB.
• WebYes: a free website audit surfaces your Core Web Vitals and flags slow server delays on the same page, if you’d rather see both in one report.

Test a few page templates, not just the homepage. A product page with heavy database queries can have a TTFB several times worse than a cached homepage. For a full walkthrough of testing from different locations and connection speeds, read our guide on how to check website response time.

What causes slow server response times?

Most slow server response times trace back to six causes: underpowered or shared hosting, traffic spikes, plugin or page bloat, missing caching, slow database queries, and inefficient code.

• Underpowered or shared hosting. On cheap shared plans, your site competes for CPU and memory with every other site on the server. Response times swing with your neighbors’ traffic.
• Traffic spikes. A server sized for normal traffic queues requests during a spike, and queued requests are slow requests.
• Plugin and page bloat. Every active plugin and page builder layer adds work the server must do before it can respond.
• Missing caching. Without a page cache, the server rebuilds the same page from scratch for every single visitor.
• Slow database queries. Bloated tables, years of post revisions, and unindexed queries stretch the time it takes to assemble a page.
• Inefficient code. Heavy themes and unoptimized application code turn every request into more processing than it needs.

The good news: four of those six are fixable without touching the hosting contract. That’s what the next section is for.

How to improve server response time

The highest-impact fixes, in rough order: enable full-page caching, audit your plugins, clean up the database, and trim your code and assets. Hosting and CDN changes matter too, but if you manage sites for clients, those are usually recommendations, not tasks.

Google’s own “Optimize Time to First Byte” guide on web.dev covers the same territory from the engineering side; here’s the practical version.

Fixes you can make today

Enable full-page caching. For most CMS sites this is the single biggest TTFB win. Instead of rebuilding the page on every request (running code, querying the database), the server returns a stored HTML copy. On WordPress, that means a caching plugin or the host’s built-in page cache; server-level options like Varnish or Redis-backed object caching stack on top. On dynamic pages with no cache, this one change can cut TTFB from seconds to a few hundred milliseconds.

Audit your plugins instead of just pruning them. “Remove unnecessary plugins” is common advice; the useful version is to measure. On WordPress, a profiling tool like Query Monitor shows which plugins add database queries and server time to each request. Test on staging, find the two or three worst offenders, and replace or drop them. One slow plugin often costs more than ten lightweight ones.

Clean up the database. Post revisions, expired transients, and orphaned tables from long-deleted plugins all make queries slower. Schedule a cleanup (plugins can automate it), and flag repeatedly slow queries for a developer to index or rewrite.

Optimize code and assets. Bloated themes and script-heavy pages take longer to generate and send. Swap heavyweight page-builder templates for leaner ones where you can, and cut script weight; our guide on how to reduce JavaScript load time covers the six changes with the best effort-to-impact ratio.

Compress and resize images. Image weight mostly hurts page load time rather than TTFB, but oversized media still ties up server bandwidth and slows everything the server sends. Compress images, serve modern formats like WebP, and size them to their containers.

Eliminate redirect chains. Every redirect adds a full round trip before the browser even requests the real page, and redirect time counts toward TTFB. Update internal links that point at redirecting URLs, and collapse multi-hop chains to a single hop. Our guide to HTTP status codes and SEO explains how to find and fix them.

Modern protocols. The host should serve HTTP/2 at minimum, and HTTP/3 where available; both cut connection overhead. It’s usually a configuration change, or comes free with a decent host or CDN, rather than a project.

A better hosting tier. Shared hosting means sharing compute with strangers; a VPS, cloud, or managed plan buys dedicated resources and consistent response times. Weigh the site’s current TTFB against Google’s 0.8-second benchmark, plus the “Reduce initial server response time” warning in the PageSpeed report, to see if it’s worth the upgrade.

A CDN. A content delivery network serves content from locations closer to each visitor and can cache full pages at the edge, which cuts TTFB for everyone far from the origin server. Worth it once your audience is spread further than your server’s location covers well.

Fixes to recommend to the client

If you manage sites for clients, hosting and infrastructure usually aren’t yours to change. These belong in a recommendation with a business case attached:

Modern protocols. The host should serve HTTP/2 at minimum, and HTTP/3 where available; both cut connection overhead. This is host-controlled, and the talking point is that it’s usually a configuration change, or comes free with a decent host or CDN, rather than a project.

A better hosting tier. Shared hosting means sharing compute with strangers; a VPS, cloud, or managed plan buys dedicated resources and consistent response times. Talking point for the client: the site’s current TTFB against Google’s 0.8-second benchmark, plus the “Reduce initial server response time” warning sitting in the PageSpeed report they can see for themselves.

A CDN. A content delivery network serves content from locations closer to each visitor and can cache full pages at the edge, which cuts TTFB for everyone far from the origin server. Talking point: where the site’s actual audience is, versus where the server is.

FAQs on website response time