Questions
Why is my website slow?
A slow website usually has one of four causes: the server takes too long to answer, the page downloads too much, rendering is blocked by scripts and stylesheets, or the visitor is far from the server. They produce the same complaint and need completely different fixes, so the first step is measuring which one applies — a single timing breakdown separates them in about a minute, and it is worth doing before changing anything.
Separate the four causes first
Run `curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer} total %{time_total}\n' <url>`.
If `ttfb` is high and `tls` is low, the server is slow: it received the request quickly and took time to answer.
If everything before `ttfb` is high, the network path is the problem — usually distance to a single origin.
If `ttfb` is low but the page still feels slow, the cost is in the browser: download size or render blocking. That is where the browser's own developer tools take over.
Cause 1 — the server answers slowly
The usual culprits are database queries that multiply with the number of items on the page, and pages rendered from scratch on every request when their content changes daily.
Check whether responses carry cache headers. A page that could be cached and is not is doing the same work thousands of times.
Measure the page types separately. The home page is usually cached and fast; search results and account pages often are not, and that is where visitors actually spend time.
Cause 2 — the page downloads too much
Images are almost always the largest component, and the most common single fault is serving a 2000-pixel-wide image into a 400-pixel slot.
JavaScript is the second: a framework bundle that grew feature by feature until it dominates the page.
Fonts, video embeds and third-party tags each add their own weight, and third parties add their own latency as well since each one is a separate connection.
Cause 3 — rendering is blocked
A stylesheet or a synchronous script in the `<head>` stops the browser from rendering until it has been fetched and executed. The page may have arrived quickly and still show nothing.
This is why a page can have a small total weight and still feel slow: the ordering matters as much as the size.
The browser's performance panel shows exactly what blocked and for how long.
Cause 4 — distance
A single origin serving a global audience pays the round trip on every request. If timings are good locally and poor from another continent, this is it.
A CDN in front of cacheable responses removes it for those responses. It does not help uncacheable ones, which still reach the origin.
How VeriFixScan helps
It measures response time across every page the crawler reaches rather than the home page alone, so the distribution is visible — which usually shows that the problem lives in one template.
`performance.page_weight`, `performance.javascript`, `performance.image_payload` and `performance.render_blocking` separate the download and rendering causes; `performance.ttfb` and `performance.static_cache` separate the server ones.
What it reports is measured from where the scan runs. It characterises the site, not the experience of a specific visitor, and field data from real users is a different and complementary thing.
What to change first, once you know the cause
The order below is roughly by benefit per hour of work, and the first three items resolve most complaints without anybody touching application code.
Size the images to the slot they occupy, and serve a modern format. A page carrying six photographs at full camera resolution is downloading several megabytes to display a few hundred kilobytes' worth of pixels, and this is the single most common cause of a heavy page.
Cache what can be cached. A page whose content changes daily and is rendered on every request is the cheapest fix available: one header, and the work happens once instead of thousands of times.
Move scripts out of the critical path. A tag manager or an analytics snippet loaded synchronously in the `<head>` delays rendering for every visitor, and almost none of them need to run before the page appears.
Audit the third parties. Each one is a separate connection, and a chat widget or a heat-mapping script can cost more than the entire rest of the page. The useful question for each is whether anyone has looked at its output in the last six months.
Then the application: the query patterns that multiply with page size, the work done per request that could be done once.
And last, the infrastructure. A bigger server makes slow code slightly less slow at permanent cost, which is why it is the step to take after the others rather than instead of them.
Frequently asked questions
- What is a good page load time?
- Google's Core Web Vitals define thresholds for what users perceive: Largest Contentful Paint under 2.5 seconds is considered good. Total load time is a weaker measure because it includes work the visitor never waits for.
- Will a CDN fix a slow site?
- It fixes distance and serves cacheable responses without reaching the origin. It does not make a slow database query fast, and an uncacheable page pays the full server cost regardless.
- Why is my site fast for me and slow for visitors?
- Your browser has warm caches, you are probably close to the server, and your connection is likely better than average. Measuring from another location and with the cache disabled removes all three advantages.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website