You type your address in, and the page takes an age. You click to another page and back, and now it is instant. You reload, still instant. So is the site slow or not? You ask a colleague to try it and they get the long wait too, then the same quick loads afterwards.
That pattern, a website slow on first load but quick after that, is telling you something specific: there is work being done, or files being fetched, only on the first visit, and that work is being saved for later. The saving is a good thing. The problem is that a large share of the people who matter to a small business, such as someone arriving from a search result or an ad, are first-time visitors. They only ever see the slow version.
What happens on a first visit that does not happen again
It helps to follow one visit step by step. Here is roughly what a browser does the first time it meets your site, and what it can skip on the second.
- Finding the server. The browser has to look up your domain to get the server’s address. That lookup (DNS) is cached by the browser and the operating system, so the next request skips it.
- Opening a secure connection. It connects to the server and negotiates encryption for HTTPS. This takes several back-and-forth trips. Once the connection is open, later requests reuse it, and returning visitors can often resume the secure session more quickly.
- Getting the page itself. The server either has a ready-made copy of the page in its cache, or it builds the page from scratch with PHP and database queries. Built from scratch is much slower.
- Downloading everything the page needs. Styles, scripts, fonts and images. On the first visit all of them are new. On the second, the browser uses copies it saved, if the server told it that it could.
On a repeat view, steps one and two are mostly skipped, step three is likely to hit a warm cache, and step four shrinks to whatever has changed. No wonder it feels like a different site.
Three kinds of “first” that get confused
When someone says “slow first visit fast after”, they might mean any of three quite different things. Working out which one you have saves a lot of trial and error.
First visit by this person
The browser has nothing saved. Every file has to be downloaded and the connection set up from scratch. This is unavoidable to some degree, but it should not be dramatic. If it is, the page is probably carrying too many or too large files, or the server is not telling browsers they can keep them.
First visit to this page since the cache was cleared
Here the visitor does not matter; the page does. If the server’s page cache has no copy, the first person to ask for it waits while it is built, and everyone after them gets the saved copy. This is why sites often feel slow right after an update or after someone clicks “clear cache”: every page is cold again.
First visit after a quiet period
On a low-traffic site, cached pages can expire before anyone asks for them again. Some hosts also free up memory on idle sites, so the first request of the morning wakes things up. The site then seems fine in the afternoon, when you test it, and slow at the time your first customer of the day arrives.
Our explainer on the different types of website cache sets out which cache lives where, which helps when you are trying to work out which one went cold.
Website slow on first load? How to tell which kind
You can do these checks with an ordinary browser in a few minutes.
- Normal window, then private window. Load a page normally, then open the same page in a private window. If the private window is much slower, the difference is the browser’s own saved files. The server is doing its job; the page is just heavy for a newcomer.
- Two people, one after the other. Ask someone on a different device and network to load a page you have not visited today, then you load it straight after in a private window. If they waited and you did not, the server’s page cache was cold for them and warm for you.
- Check the response headers. In your browser’s developer tools, click the first request for the page and look at the response headers. Many caching plugins and hosts add a header that says whether the page came from the cache, often with words like HIT or MISS. A MISS on the first load and a HIT on the second confirms a server cache miss.
- Look at the server wait. In the same panel, the timing for that first request shows how long the browser waited for the server. A long wait on the first load that disappears on the second points to the page being built from scratch.
- Look at the connection steps. The timing breakdown also lists DNS lookup, initial connection and SSL. If those are large on the first load, the slowness is in setting up the connection rather than in your site.
When the slow part is the server cache
If the page cache is the issue, the usual causes are that pages expire too quickly, that the cache is being cleared far more often than needed (some setups clear the whole site cache every time any post is saved), or that the cache only fills when a visitor triggers it.
That last one has a standard remedy: having the cache filled in advance, so the first real visitor is not the one who pays for it. How that works, and when it causes more trouble than it saves, is covered in warming up the cache before visitors arrive. Setting up the caching plugin itself belongs in the caching section of our guide to website performance.
When the slow part is the browser cache
If the server answers quickly but a new visitor still waits a long time, the page is simply heavy for someone who has none of its files yet. Two things to check.
First, whether the server is telling browsers to keep files at all. If your images, styles and scripts are sent with very short or missing cache instructions, even returning visitors may download them again. The post on cache-control headers and browser caching explains what those instructions look like.
Second, how much a new visitor has to download. Browser caching helps repeat visitors; it does nothing for someone arriving for the first time. Reducing what the page carries is the only way to make a first visit lighter. If you are not sure what that involves, start from the triage in why a website is slow and which part is to blame.
When the slow part is the connection
Sometimes the DNS lookup or the secure connection takes a surprising amount of time. Causes include a slow DNS provider, a chain of redirects (for example from the bare domain to www and then from http to https, each needing its own trip), and pages that pull files from many different domains, each needing its own lookup and connection.
Redirect chains are easy to spot: type your address the way a customer might, without www or https, and watch the network panel. Every redirect before the real page is a wasted round trip. DNS itself is covered in how DNS affects page load time.
Why it matters more than it seems
It is tempting to shrug off a slow first load because the site is quick once you are in. But think about who sees the first load. Someone who found you on Google. Someone who clicked your ad. Someone who received a link on WhatsApp. They have not been to your site before, and they will judge it on that first impression.
Your own experience is almost the opposite. You visit the site many times a day, so your browser has everything saved and your pages are always warm. You are the visitor least likely to notice the problem.
Mistakes to avoid
- Testing your own site only in a normal browser window and concluding it is fine.
- Running a speed test once, then again, and reporting the faster second result.
- Setting the page cache to clear on every small change across the whole site.
- Assuming a CDN will fix a slow server response when the page is not being cached at all.
- Ignoring redirects because each one “only takes a moment”.
Frequently asked questions
Why is my site fast in the afternoon but slow first thing in the morning?
Cached pages often expire overnight, or the cache is cleared by a scheduled task, so the first visitors of the day trigger fresh page builds. On some hosting the server also frees memory on quiet sites. Checking cache lifetimes and preloading important pages usually smooths this out.
Is it normal for a first visit to be a little slower?
Yes. A new visitor must look up the domain, open a secure connection and download every file for the first time, so some difference is expected. It becomes a problem when the first visit is several times slower than the second, which usually means the server cache is missing or the page is very heavy.
Will a CDN make first visits faster?
It can help with static files such as images, styles and scripts, because they are served from a location nearer the visitor. It will not help much if the HTML page itself is built slowly on your server every time, unless the CDN is also set up to cache pages, which needs care on dynamic sites.
Why does a speed test give a better result when I run it twice?
The first run may have filled the server’s page cache, so the second run gets a ready-made copy. When you compare before and after results, make sure the cache was in the same state each time, or you will be comparing a cold load with a warm one.
Caching setup is one of the things our website speed optimisation service covers, along with image work and a review of server response time. You see the audit findings and a prioritised list first, and nothing is changed without your say-so.
Next in this series: Website Slow at Peak Times? Why Busy Hours Hurt
