Site responding slowly

Your site is loading, but it's taking too long. DomainDash shows the site as Slow — it responded, but not within the acceptable time window.

Symptom

• DomainDash marks the uptime check as Slow (not Down)
• Response time is consistently above the slow threshold (typically 800ms+)
• 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 status means DomainDash received a valid response, 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 website 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.

The threshold for "slow" is configurable per site in DomainDash settings — the default is 800ms for the full response time. If your site's baseline is legitimately higher (for example, a complex server-rendered app), you can raise the threshold in site settings to avoid false Slow alerts.

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. Find slow database queries:

   -- PostgreSQL: find the slowest recent queries
   SELECT query, mean_exec_time, calls
   FROM pg_stat_statements
   ORDER BY mean_exec_time DESC
   LIMIT 10;

   Add caching for expensive operations (Redis is a good choice). Look for N+1 patterns — a page that makes 40 small queries instead of one joined 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 at edge locations close to users worldwide, eliminating the round-trip to your origin for cached content. Ensure TLS session resumption is enabled in your web server config to speed up repeat connections:

   ssl_session_cache shared:SSL:10m;
   ssl_session_timeout 10m;
   ssl_session_tickets on;

5. If the download phase is slow — the response is too large. Enable compression:

   gzip on;
   gzip_vary on;
   gzip_types text/plain text/html text/css application/json application/javascript;
   gzip_min_length 1024;

   Check 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. Audit what's in the response — unused CSS, large inline scripts, and embedded images all inflate page size.

How to verify

After fixing:

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 will automatically change the status from Slow 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
• Site settings — where to adjust the slow response threshold for your site