How to Reduce Server Response Time and Fix Redirect Chains

What these checks test

SiteCurl measures two things that affect how quickly a visitor’s browser can start rendering your page. Response time (Time to First Byte, or TTFB) measures how long the server takes to send back the first byte of data. The redirect chain check counts how many redirects happen between the requested URL and the final page.

A slow TTFB means the server is taking too long to process the request. A long redirect chain means the browser has to make multiple round trips before it even starts downloading the page.

Why it matters

Every millisecond before the page starts rendering is dead time for the visitor. A 200ms TTFB is fast. A 2-second TTFB means 2 seconds of staring at a blank screen before anything happens. Redirect chains multiply this: each redirect adds a full round trip (100-500ms depending on the connection).

Google uses TTFB as a factor in page experience rankings. A site with a 3-second TTFB is at a disadvantage compared to one that responds in 200ms.

How to reduce server response time

Identify the bottleneck

Slow TTFB usually comes from one of three places:

1. Slow database queries: A page that runs 50 queries per request is going to be slow. Profile your queries and add indexes or caching for the most expensive ones.
2. No server-side caching: If your server rebuilds the same page from scratch for every request, add page caching or fragment caching. A cached page can be served in under 10ms.
3. Overloaded server: If the server is running out of CPU or memory, either optimize your application, add a CDN to offload static requests, or upgrade your hosting plan.

Add a CDN

A Content Delivery Network caches your pages on servers around the world. Instead of every request traveling to your origin server, visitors get the cached version from a nearby edge node. Cloudflare, Fastly, and AWS CloudFront all offer this.

For static marketing sites, a CDN can reduce TTFB from 500ms to under 50ms for most visitors.

Optimize your hosting

Shared hosting often has slow response times because you share resources with other sites. If your TTFB is consistently over 500ms, consider moving to a VPS, managed hosting, or a platform like Render, Vercel, or Netlify that optimizes for fast responses.

How to fix redirect chains

What causes redirect chains

The most common cause: your site redirects HTTP to HTTPS (good), then redirects non-www to www (also good), creating a chain: http://site.com -> https://site.com -> https://www.site.com. That is two redirects before reaching the final page.

Collapse the chain

Redirect directly to the final destination:

http://site.com -> https://www.site.com (one redirect)
http://www.site.com -> https://www.site.com (one redirect)
https://site.com -> https://www.site.com (one redirect)

In Nginx, handle all cases in one redirect:

server {
    listen 80;
    server_name site.com www.site.com;
    return 301 https://www.site.com$request_uri;
}

Internal redirect chains

Check for pages that redirect to other pages that redirect again. Common after site restructuring when old redirects are not cleaned up. Map each redirect to its final destination and update it to a single hop.

How to verify the fix

Check TTFB in Chrome DevTools: Network tab, click the HTML document request, look at “Waiting (TTFB)” in the Timing section. Check redirects by entering your URL and watching the Network tab for 301/302 responses. Run a SiteCurl scan to measure both automatically.

Related checks

Response time and redirects affect overall performance alongside compression and cache headers.

Start a free trial to measure response time and redirects across your site.