Check your server response time

SiteCurl measures Time to First Byte (TTFB): the time between sending a request and receiving the first byte of the response. This tells you how fast your server processes the request and starts sending the page back.

A TTFB under 600ms is considered good, based on web.dev guidance. Between 600ms and 1,500ms is a warning. Over 1,500ms is critical: visitors are waiting more than a full second before the page even starts to appear.

The check runs on every page in your scan. This is important because different pages can have very different response times. A static about page may respond in 100ms while a product listing page that queries a database may take 800ms. SiteCurl shows you which pages are slow so you can focus your effort.

TTFB is the starting gun for the rest of the page load. Before the browser can parse HTML, load CSS, render images, or run JavaScript, it has to wait for the server to start responding. A slow TTFB delays everything that comes after.

Think of it this way: if your TTFB is 1,200ms, the page cannot even begin to render until 1.2 seconds have passed. Then the browser still needs to download, parse, and display the content. On a mobile connection, you could be looking at 3 to 5 seconds of total load time.

The causes of slow TTFB are almost always on the server side. Unoptimized database queries, missing caching, an underpowered hosting plan, or a server located far from your visitors. These are infrastructure problems, not code problems. A developer can spend weeks optimizing front-end assets, but if the server takes a full second to respond, the page will still feel slow.

TTFB also varies by page. Your home page might be cached and respond in 80ms. Your search results page might run a database query on every request and respond in 900ms. Checking only the home page gives a false sense of how your site performs.

Google includes server response time in its page experience signals. A slow TTFB contributes to poor Core Web Vitals scores, which affect search rankings. The web.dev TTFB guidance recommends under 600ms as a target for the 75th percentile of page loads.

Visitors feel TTFB directly. A page that takes over a second to start loading feels broken. On mobile connections, the delay is even more noticeable because the network itself adds latency on top of the server time.

There is a compounding cost. Slow response times increase bounce rates. Higher bounce rates reduce the traffic your pages get from search. Less traffic means fewer customers. Fixing TTFB breaks this cycle at the earliest possible point.

E-commerce sites feel the impact in cart abandonment. A product page that takes two seconds to start loading loses buyers before they even see the price. Studies show each additional second of delay can reduce conversions by up to 7%.

SaaS companies with database-heavy dashboards often have fast marketing pages but slow application pages. If your pricing page is fast but your signup flow is slow, you lose prospects at the exact moment they decided to convert.

Agencies managing client sites need to spot slow servers early. A client's hosting plan may have been fine when the site launched, but traffic growth and plugin additions can push response times up over time. A monthly scan catches the trend before it becomes a crisis.

Step 1: Enable server-side caching. Most content management systems generate pages dynamically on every request. Enable page caching so the server stores the rendered HTML and serves it directly on repeat requests. In WordPress, use a caching plugin like WP Super Cache or W3 Total Cache. In Rails, use fragment or page caching.

Step 2: Use a CDN. A content delivery network serves your pages from servers close to your visitors. If your server is in New York and your visitor is in London, a CDN cuts the round-trip time dramatically. Cloudflare, Fastly, and most modern hosts offer CDN built in.

Step 3: Optimize database queries. Slow queries are the most common cause of high TTFB on dynamic sites. Check your database logs for queries taking over 100ms. Add indexes to frequently queried columns. Avoid loading data you do not need on the page.

Step 4: Upgrade your hosting plan. Shared hosting puts your site on the same server as hundreds of others. When another site on that server gets a traffic spike, your response time suffers. A VPS or dedicated plan gives you consistent performance.

Step 5: Check for slow third-party calls. If your server makes API calls to external services during page rendering (payment processors, CRM lookups, analytics), each call adds to TTFB. Move these to background jobs or client-side requests.

Mistake 1. Only testing the home page. The home page is often cached or static. Your slowest pages are usually the ones with database queries, search results, or dynamic content. Test across your whole site.

Mistake 2. Confusing TTFB with total page load time. TTFB is just the server response. Total load time includes downloading CSS, JavaScript, images, and rendering the page. Both matter, but they have different fixes.

Mistake 3. Adding a CDN without fixing the origin. A CDN caches your pages, but if the origin server is slow, the first request to each page still takes a long time. Fix the server first, then add a CDN on top.

Mistake 4. Ignoring time-of-day variation. Shared hosting is often fast at 3 AM and slow at noon. A single test may give a misleading result. Run scans at different times to get a realistic picture.

After making changes, run another SiteCurl scan and compare response times across your pages. SiteCurl tracks scores over time so you can see whether your changes made a difference. Focus on the slowest pages: those are where your effort has the biggest impact.

For a manual check, run curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s ' https://yoursite.com/page to see the response time for a specific URL. Run it a few times to get a consistent reading. The target is under 600ms (0.6 seconds).

Server response time is the foundation of page speed. No amount of front-end optimization can fix a slow server. Check your TTFB across all pages, not just the home page. Enable caching, use a CDN, and optimize database queries. Target under 600ms for every page.