Why Is My Website Slow? A Step-by-Step Diagnosis Flowchart

"The site is slow" is not a diagnosis. A page load is a chain of stages, and each stage has a different cause, a different owner and a different fix. If you tune images when the real problem is a 3-second server response, nothing improves. This guide gives you a decision flowchart in text: measure each stage in order, stop at the first one that is clearly too large, and fix that before moving on.

The stages of a page load

Every visit passes through the same sequence:

1. DNS lookup: turning the hostname into an IP address.
2. TCP connect: one round trip to reach the server (HTTP/3 uses QUIC instead, which merges this with the TLS step).
3. TLS handshake: negotiating encryption.
4. TTFB (time to first byte): the server receives the request, does its work and starts replying.
5. Download: the rest of the HTML plus every CSS, JavaScript, image and font file.
6. Render: the browser parses, runs scripts, lays out and paints.

Stages 1 to 4 happen before a single byte of content arrives. Stage 5 is about size and number of requests. Stage 6 happens on the visitor's device and is where JavaScript hurts most.

Step 0: Confirm it is slow for everyone

Before you dig in, rule out the visitor's side. Load the page from a different network, a different device and in a private window with extensions off. Run it through the website speed test to get a measurement from outside your own connection. If it is fast everywhere except one browser, you are looking at an extension, a cached bad script or a local network problem, not a site problem.

Also check whether the slowness is constant or intermittent. Constant slowness points to page weight or a slow application. Slowness that comes and goes points to server load, a noisy neighbor on shared hosting, or a cache that expires and gets rebuilt.

The flowchart

Run the measurement below from your own machine, then follow the decision points.

curl -o /dev/null -s -w \
'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} size=%{size_download}\n' \
https://example.com/

The values are cumulative: ttfb includes everything before it. Subtract neighbors to get the time spent in each stage. Run it three to five times, because a single sample can be an outlier.

START: total time is too high
|
+-- Is dns > ~100 ms (uncached)?
|     YES -> DNS stage. Go to "DNS" below.
|
+-- Is (connect - dns) larger than one network round trip to the server?
|     YES -> Distance or network path. Go to "Connect".
|
+-- Is (tls - connect) > ~2 round trips?
|     YES -> TLS stage. Go to "TLS".
|
+-- Is (ttfb - tls) > ~500 ms?
|     YES -> Server stage. Go to "TTFB".
|
+-- Is (total - ttfb) large, or size very big?
|     YES -> Download stage. Go to "Download".
|
+-- All of the above look fine, but the page still feels slow?
      -> Render stage. Go to "Render".

These thresholds are rules of thumb, not standards. What matters is which stage dominates the total. If one stage accounts for most of the time, start there.

DNS

DNS time is only meaningful on the first, uncached lookup. Repeat the curl command right away and the second run will show a near-zero value from your resolver's cache.

• टूल: the DNS checker to confirm all authoritative nameservers answer and agree.
• Common causes: a slow or distant DNS provider, a very long CNAME chain, a missing or very low TTL forcing constant re-resolution, or a nameserver that times out and falls back to another.
• Fix: use a reputable DNS provider with a global anycast network, shorten CNAME chains, and set sensible TTLs. See DNS explained for website owners और TTL explained.

Connect

If connect minus dns is high, the cost is the network distance between the visitor and your server, since TCP needs a full round trip to complete.

• टूल: website hosting checker और CDN detector to see where your server is and whether a CDN is in front.
• Common causes: a single origin on another continent, no CDN, packet loss on the route.
• Fix: put a CDN in front of static and cacheable content, or move the origin closer to most visitors. See CDN explained.

TLS

The handshake needs one or two round trips on top of connect time. A TLS 1.3 handshake takes one round trip; TLS 1.2 takes two.

• टूल: the TLS version checker और SSL checker.
• Common causes: TLS 1.2 only, an incomplete certificate chain forcing the client to fetch missing intermediates, no session resumption, or OCSP checks that block.
• Fix: enable TLS 1.3, serve the full chain, and consider HTTP/3 where supported. See HTTP/2 and HTTP/3 explained.

TTFB

This is the server stage. If ttfb minus tls is large, the visitor is waiting for your application, not your network.

• Tools: the speed test for a multi-location view, plus your own server logs and profiler.
• Common causes: uncached dynamic pages, slow database queries, a PHP or Node process pool that is exhausted so requests queue, a slow external API called during page generation, or an overloaded shared server.
• Fix: page caching or a CDN cache for anonymous traffic, query and index tuning, more workers, and moving slow third-party calls out of the request path. The full walkthrough is in how to reduce time to first byte. For WordPress specifically, see the WordPress slow site checklist.

Download

If TTFB is fine but the total is large, the page is too heavy or makes too many requests.

• टूल: the page weight analyzer for a breakdown by resource type, and your browser's Network tab sorted by size.
• Common causes: unoptimized images, large JavaScript bundles, web fonts loaded in many weights, uncompressed text responses.
• Fix: check compression first.

curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/ | grep -i content-encoding

If that prints nothing for an HTML, CSS or JS response, enable gzip or Brotli on your server or CDN. Then work on images (image optimization with WebP and AVIF) and remove assets you do not need. Also confirm the connection is HTTP/2 or HTTP/3 with the HTTP/2 and HTTP/3 checker, because HTTP/1.1 limits parallel downloads.

Render

If the network side looks healthy and the page still feels slow, the browser is the bottleneck. The browser spends time downloading, parsing and executing JavaScript, and scripts can block painting.

• Tools: the Core Web Vitals tool and the third-party script checker. In Chrome, the Performance panel and Lighthouse show long tasks and render-blocking resources.
• Common causes: large JavaScript bundles, render-blocking CSS and scripts in the head, tag managers loading many third-party scripts, layout shifts from images without dimensions, a hero image discovered late.
• Fix: defer non-critical scripts, remove unused third-party tags, set width and height on images, preload the one image that is your largest paint, and lazy-load the rest. See the Core Web Vitals guide.

Pick the tool for the stage

Slow some of the time

Intermittent slowness needs history, not a one-off test. A monitor that records response time on every check will show you whether slowness lines up with a time of day, a cron job, a backup or a traffic spike. If response time climbs before an outage, treat it as an early warning; many outages begin as slowness.

Fix one thing, then measure again

Change one variable at a time and repeat the same measurement under the same conditions. Otherwise you cannot tell what helped. Keep a short log: date, change, before and after numbers. When the largest stage is no longer the largest, move to the next one.

अगले कदम

• Run the website speed test and note which stage dominates.
• Check page composition with the page weight analyzer.
• Read how to reduce time to first byte if the server stage is your problem.
• Track response time over days with an uptime monitor.
• Review Core Web Vitals for the render side.

सामान्य प्रश्न

What is a good page load time?

There is no single number. Google's Core Web Vitals guidance treats a Largest Contentful Paint of 2.5 seconds or less as good, measured for real visitors, so use that as a practical target.

Why is my site fast for me but slow for visitors?

You are probably near the server, have the site cached in your browser, or are on a fast connection. Test from other locations and on a throttled mobile profile.

Should I fix TTFB or page weight first?

Fix whichever stage takes the most time in your measurement. TTFB comes first in the chain, so a slow TTFB delays everything after it.

Can a CDN fix a slow site?

It fixes distance and cacheable content. It will not speed up slow database queries on uncached pages, though it can hide them for repeat requests.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.