← Back to Blog

How to Trace Why a Page Takes So Long to Start Loading

Split the blank-tab pause into DNS, connection and server stages, and fix the stage that is actually slow.

You click a link and nothing happens. Not an error, just a blank tab and a spinning indicator. Then, after a long pause, the page suddenly appears. If the page never appears at all, rather than appearing late, the fault is different: check first whether the site is down for everyone with our Uptime Monitor. That pause is the clue. A page that is slow to start is not the same problem as a page that is slow to finish, and fixing the wrong one wastes a whole afternoon.

This post shows you how to split that opening pause into its parts and fix the part that is actually slow. You need only a browser and our Website Speed Test for the overall picture, plus your browser's developer tools for the breakdown.

First, name what "slow to start" means

A page has two kinds of slowness. The first is the wait before anything arrives. The second is everything after that first piece arrives: images, stylesheets, scripts and fonts loading in turn.

If the screen stays blank for several seconds and then fills in quickly, your problem is the first kind. If the page appears straight away but takes ages to finish, your problem is the second kind, and this post is not the fix for it. A fix for heavy images will do nothing for a slow start, so the distinction matters.

Run the page through our Website Speed Test twice. If the second run is much faster, the first run may have been a cold cache, which is normal and not a fault to chase. If both runs are slow to start, you have a real problem to trace.

Read the waterfall in order

Open the page in Chrome or Edge, press F12, go to the Network tab, and reload. Click the first request, usually the page address itself, and open its Timing tab. You will see the opening pause broken into stages, in the order the browser performs them.

The stages are these. Redirects: the browser is sent from one address to another before the real page is requested. DNS lookup: the browser turns the domain name into an IP address. Connection and TLS: the browser connects and agrees a secure connection. Waiting, or server response time: the server builds the page and sends the first byte back.

Work through the stages from left to right and stop at the first one that is large. That is your culprit, or at least your first culprit. Do not skip ahead to the server because servers feel like the obvious suspect. A fast server can sit behind a slow redirect chain or a slow DNS lookup, and no server tuning will fix either one.

If the DNS stage is the slow one

DNS lookup is usually quick, often tens of milliseconds to around 200 milliseconds on a first visit, because the answer is cached after that. If DNS takes far longer than the other early stages, or the delay only happens on a first visit and vanishes on reload, check DNS properly.

Start with our DNS Records Lookup and confirm the domain resolves to the address you expect, with no stray records pointing at an old host. Nameservers that answer slowly make every first-time visitor wait before anything else can happen. Also check whether the problem follows the visitor or the domain: slow for visitors in one country but fine elsewhere points to the DNS provider's coverage there, not to your server.

Two traps are common. Redirects across different domains force a fresh lookup for each new domain, so cut the chain. A very low TTL forces resolvers to ask again far more often than needed, so raise it once the records are stable. If you have just changed DNS, our DNS Propagation Checker shows whether resolvers around the world have the new record yet.

If the connection or TLS stage is the slow one

After DNS, the browser connects and negotiates HTTPS. This stage should be a small fraction of the total wait. If it is large, look at two things.

First, distance. A server far from your visitors will always take longer to connect to, because each round trip takes longer. That is geography, not code, and the usual answer is a content delivery network with a node near the visitor, or a host in the region most visitors come from.

Second, the certificate setup. A misconfigured TLS setup can stretch the handshake, and a certificate problem can produce warnings that look like slowness to a visitor who hesitates. Run the domain through our SSL Checker to confirm the certificate is valid and covers the exact address visitors use. Fix any problem it reports before tuning anything else.

If the waiting stage is the slow one

This is the most common culprit. A long waiting time means the browser connected fine and then waited while the server built the page: running code, asking a database, calling another service, or waiting for a cache that missed.

Compare pages on the same site. If a plain static page starts fast but a database-driven page starts slowly, the difference is the work that page does, not the host. If every page starts slowly, the host itself, or a shared server under load, is a stronger suspect. If the site is fast logged out but slow logged in, the likely cause is uncached, personalised content built fresh for each logged-in visit.

On a WordPress site, the usual suspects are a page cache that is not actually caching the page you tested, a plugin making slow database queries, or an external call, such as a feed or licence check, that blocks the page until it answers. Change one candidate at a time and retest after each change. Changing three things at once tells you nothing about which one worked.

What to do first

Run the Website Speed Test twice and confirm the slow start repeats. If the whole page is slow, not just the start, work through How to Fix a Slow Website, which runs the checks in order. Then open the Timing tab, read the stages from left to right, and stop at the first large one. If it is DNS, check the records with the DNS Records Lookup and cut any redirect chain. If it is connection or TLS, check the certificate with the SSL Checker and think about distance to your visitors. If it is waiting, compare a simple page with a complex one and test one change at a time. Fix the stage the trace points to, retest, and only then move to the next stage. A slow start is a sequence, and once you read it in order, it stops being a mystery.

A new post lands here every day. If there is a topic you want covered, email ask@websmartstudios.com.