Site responding slowly

Your site is loading, but it's taking too long. DomainDash recorded a slow response and marked the site Needs attention. It responded, but not within the acceptable time window.

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 consistently above the slow threshold (1000ms by default)
• The site loads in the browser but feels sluggish
• Running curl -w "%{time_total}" -o /dev/null -s https://example.com returns a high number (above ~1–2s)

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 slow it is, 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. Knowing which phase is slow tells you exactly what to fix — so you can tighten up the page your visitors feel, not chase the wrong thing.

The threshold for a slow response is 1000ms (one second) for the full response time by default. A reply slower than that counts as slow, and DomainDash marks the site Needs attention until response time drops back below the threshold.

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. Check the timing breakdown in DomainDash's most recent check for the site. 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 is real and holding, not a one-off good reading:

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 tab. It should be trending down.
3. Once response time falls consistently below the threshold, DomainDash automatically returns the site from Needs attention back to Healthy at the next check cycle.

Related

• Connection timeout — if the site stops responding altogether rather than just slowing down
• 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