Quick answer
Test your website’s response time by measuring time to first byte (TTFB): how long the server takes to start sending a page. Run Google’s free PageSpeed Insights, check the TTFB figure, then confirm it in your browser’s developer tools. Google’s guidance treats 0.8 seconds or less as good and over 1.8 seconds as poor.
When a website feels slow, most advice jumps straight to images, plugins and scores out of 100. But before any of that can load, the server has to answer. If it takes two seconds to reply, nothing else you optimise can make the page feel quick. Response time is the first link in the chain, and it is easy to test for free. This guide shows how, what the numbers mean and what usually fixes a slow one.
What response time actually measures
The figure that matters is time to first byte, or TTFB. It is the time from the moment a browser starts asking for your page until the first piece of the reply arrives. Google’s web.dev guide to time to first byte explains that it includes any redirects, looking up the domain, setting up the secure connection and the server’s own work to build the page. It says good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.
TTFB is not the same as the full page load. A site can have a quick TTFB and still be slow because of heavy images, or a slow TTFB with otherwise light pages. Testing it separately tells you which problem you have.
Step 1: run PageSpeed Insights
- Go to PageSpeed Insights and enter the full address of a page, such as your homepage.
- Look first at the section showing real-user data, if your site has enough visitors. It reports how quickly the server responded for actual people over recent weeks.
- In the diagnostics below, find the server response time audit, which shows how long your server took on Google’s test run.
- Run the test two or three times and on two or three different pages, because a single result can be affected by a busy moment.
Step 2: check it in your own browser
Every modern browser can show response time for each file. In Chrome, open the developer tools, choose the Network tab, reload the page and click the first item, which is the page itself. The Timing panel breaks the request into parts. Chrome’s documentation on network timing explains each one. The line usually labelled “Waiting for server response” is the server’s thinking time.
Test with the browser cache disabled (there is a tick box in the Network tab) and in a private window, so you see what a new visitor sees rather than a cached copy.
Step 3: read the results
| What you see | What it usually means | Where to look |
|---|---|---|
| TTFB 0.8 seconds or less | The server is responding well | Look at images, scripts and fonts instead |
| TTFB between 0.8 and 1.8 seconds | Room to improve | Caching and hosting |
| TTFB over 1.8 seconds | The server is struggling | Hosting, caching, heavy plugins or database |
| Fast on one page, slow on another | That page does heavy work | Search, filters, shop pages, big queries |
| Fast for you, slow on PageSpeed | You are seeing a cached or nearby copy | Test in a private window and from another location |
| Slow only sometimes | Busy shared server or traffic spikes | Hosting plan and caching |
Step 4: rule out redirects and DNS
Redirects count towards TTFB. If your address goes from http to https to www to a final page, each hop adds time. Type your domain without “www” and without “https” and watch the address bar; if it jumps several times, tidy the redirects so visitors land in one step. Slow DNS can add time too, especially if the domain uses a slow or distant DNS provider.
Step 5: test again after each change
Keep a short note of your results: date, page, TTFB from PageSpeed and from your browser. When you or your host change something, test the same pages again. Without a before and after, it is impossible to know whether a change helped.
A worked example
Take a typical case: a bike shop’s WordPress site feels sluggish. PageSpeed Insights shows a server response of around two seconds on the homepage and nearly three on the shop page. In the browser’s Network tab, the “waiting for server response” line matches. The owner checks the hosting plan, the cheapest shared tier, and finds no page caching is switched on. After caching is enabled, the homepage TTFB drops well under a second, but the shop page stays slow because a filtering plugin runs heavy database queries on every visit. Replacing that plugin brings the shop page into line. Each step was tested before and after, so the owner knows exactly which change fixed which page, and which ones made no difference.
What usually fixes a slow response
- Page caching. On WordPress and similar systems, the server builds each page from the database on every visit unless pages are cached. Caching serves a ready-made copy, often cutting TTFB dramatically.
- Better hosting. Cheap shared hosting can be slow when neighbouring sites are busy. A good host with modern PHP, enough memory and server-level caching makes a real difference; our website hosting cost guide explains the tiers.
- Fewer heavy plugins. Some plugins run slow database queries on every page. Removing or replacing them helps.
- A tidy database. Years of revisions, spam comments and leftover plugin data slow queries down.
- Up-to-date software. Newer PHP versions are typically faster. Our WordPress maintenance guide covers keeping it current.
- A content delivery network, which serves cached pages from locations close to visitors.
When to get help
If your TTFB is consistently over 1.8 seconds and caching is already on, the problem is usually hosting or something heavy in the site itself, and it needs someone who can see the server. Our website speed optimisation is £99 and covers caching, images and the common causes of slow responses. If the hosting itself is the bottleneck, our website management and hosting is £20 a month with UK hosting and daily backups. For the wider picture, read our guide to website speed for small businesses, or run our free SEO audit. Every Luxbranding price is on our pricing page.
Get the UK Website Project Brief Template (free)
A two-page template for briefing any UK web designer: sitemap, integrations, audience and deliverables. Cuts revision rounds in half.
No spam. UK GDPR compliant. We only use your email to send this resource, unless you tick the box to hear from us.
Frequently asked questions
What is a good website response time? +
Google's web.dev guidance says a good time to first byte is 0.8 seconds or less, and anything over 1.8 seconds is poor. That measures how long the server takes to start sending the page, including redirects, domain lookup and connection set-up. A fast response does not guarantee a fast page, but a slow one guarantees a slow page.
How do I check my server response time for free? +
Run your page through Google's PageSpeed Insights and look for the real-user data and the server response time audit. Then confirm it in your browser: in Chrome, open developer tools, choose the Network tab, reload and click the first request to see its timing. Test several pages, more than once, in a private window.
Why is my website slow to respond? +
The usual causes are no page caching, so the server builds every page from scratch, slow or overloaded shared hosting, heavy plugins running slow database queries, an old PHP version, a cluttered database and chains of redirects. Testing before and after each change shows which fix makes the difference.
Does response time affect Google rankings? +
Indirectly. Google uses page experience signals, including how quickly the main content appears, and a slow server response delays everything else. More directly, slow sites lose visitors who give up before the page loads. Fixing a poor response time helps both the people visiting and the loading measurements Google uses.
