Site responding slowly

Your site is loading, but it's taking too long. DomainDash recorded a slow response and marked the site Needs attention.

Symptom

• DomainDash records a slow response rather than marking the site Down, and the per-check rows show Slow response
• The site shows Needs attention rather than Healthy
• Response time is at or over the slow threshold (1000ms)
• The site loads in the browser but feels sluggish
• Running curl -w "%{time_total}" -o /dev/null -s https://example.com returns a number of 1 second or more

What it means

A slow response means DomainDash received a valid reply, but it arrived too slowly. This is different from a connection timeout (where no response arrived at all). The site is working (visitors aren't blocked) but the experience is poor, and depending on how slowly it responds, search engines may penalise your rankings.

Every request to a site passes through several distinct phases before the browser sees any content: a DNS lookup, a TCP connection, a TLS (Transport Layer Security) handshake, server processing time (often called Time to First Byte, or TTFB), and finally the content download. Any one of these phases can become the bottleneck. The slow phase tells you what to fix.

The threshold for a slow response is 1000ms (one second) for the full response time, and it's the same for every site and plan. One reply at or over the threshold records that check as Slow response and shows the site as Needs attention straight away. An incident for a site responding slowly opens only after 12 slow checks in a row, and the site's card on the dashboard then shows Alert.

Common causes

• Slow TTFB — the application takes a long time to generate the response. Usually slow database queries, missing caches, or expensive computations running on every request.
• Slow DNS — the DNS provider is slow to resolve, or the record's Time to Live (TTL) is so short that every visitor triggers a fresh lookup.
• High TCP/TLS latency — the server is geographically distant from the check location (or your users), adding network round-trip time to every connection. No CDN in place.
• Large response / no compression — the server sends a large uncompressed response, and the download phase takes most of the time.
• N+1 database queries — an application pattern where one page load triggers dozens of database queries instead of one efficient query with joins.

How to fix

1. Find which phase is slow. In DomainDash, open the site's Uptime page and find the Check history card. When the latest check got a successful response, slow ones included, its row shows a timing breakdown of how long each phase took: DNS, TCP, TLS, Server (TTFB), Download, and Total. It doesn't show for an error response or a failed connection, and only on the first page of the history. You can also get this locally:

   curl -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
     -o /dev/null -s https://example.com

   The biggest number points to the bottleneck.

2. If TTFB is slow, the application itself is the bottleneck. The usual culprit is slow database queries, so use your framework's query analysis tools to find the slowest ones and speed them up. Add caching for expensive operations, and look for N+1 patterns: a page that makes dozens of small queries instead of one efficient query. Many frameworks have query logging or developer toolbars that surface these.

3. If DNS is slow, check your DNS provider's average response time. Cloudflare and AWS Route 53 are consistently fast globally. Raise the TTL on your records to at least 300 seconds (5 minutes) to let resolvers cache the result rather than looking it up on every visit.

4. If TCP or TLS is slow, the server is far from the request origin. A CDN (Content Delivery Network) like Cloudflare terminates connections close to your visitors worldwide, cutting the round-trip to your origin for cached content.

5. If the download phase is slow, the response is too large. Turn on compression on your web server (most can do this with a single setting), and check the current response size:

   curl -v -o /dev/null https://example.com 2>&1 | grep -i "content-length"

   HTML pages should generally be under 50KB uncompressed. Look at what's in the response: unused CSS, large inline scripts, and embedded images all inflate page size.

How to verify

Check that the speed-up holds over several checks:

1. Re-run the curl timing command and compare each phase against the baseline.
2. In DomainDash, look at the response time trend on the site's Uptime page. It should be trending down.
3. If no incident for a site responding slowly has opened, the site reads Healthy as soon as a check comes back under 1000ms. If one is open, the first passing check shows Recovering and the next shows Healthy. The incident itself closes after 12 passing checks.

Related

• Connection timeout — if the site stops responding altogether rather than responding slowly
• HTTP 5xx response — if the server is returning error codes along with slow responses
• Uptime — how DomainDash measures response time and what the thresholds mean