How to check website speed
To check how fast a website really loads, run it through a test that opens the page in a real browser from a known location and read three numbers: time to first byte, largest contentful paint, and total load time. A single number from a single place is a snapshot, not a score. The useful comparison is always the same page tested from the same location before and after a change.
The quick way: run a real browser test
Enter the URL into a page speed test and let it load the page in an actual browser rather than estimating. A good report gives you a screenshot of what rendered, the overall timings, and a per-request breakdown showing which image, script or third-party call was slow. That breakdown is what turns "the page is slow" into "this one font file blocks rendering for 1.8 seconds".
Run it right after a deploy, after a plugin or theme update, and before committing to a hosting or CDN change. Those are the moments when speed changes and nobody notices.
Measuring it yourself from the command line
For the server side of the story you do not need a browser at all. curl can print its own timing breakdown:
curl -o /dev/null -sS -w "dns:%{time_namelookup}s connect:%{time_connect}s tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n" https://example.com/This measures one request for the HTML document only, so it will always look faster than the real page. That is exactly why it is useful: it isolates the server from the browser. If ttfb is high here, no amount of image optimization will help. If ttfb is low and the page still feels slow, the problem is in what the browser has to do after the HTML arrives.
What TTFB, LCP and full load mean
- Time to first byte (TTFB). How long the server took to start answering, including DNS, connection setup, TLS and the server's own processing. A high TTFB points at hosting, database queries or backend code, not at the page's assets.
- Largest contentful paint (LCP). When the largest visible element in the viewport finished rendering, usually a hero image, a video poster or a big block of text. This is the number closest to what a visitor calls "when the page appeared". Google treats 2.5 seconds or less as good.
- Load / full load time. When the browser finished loading the document and its blocking resources. Everything the visitor can see is normally done well before this.
- Total time to settle. Load time plus anything still running afterwards, such as scripts that fetch data once the page appears done. A page can look finished and still be busy, and that work competes with the visitor's first scroll or click.
- Requests and transferred bytes. How many files the page pulled and how much was downloaded. These are the levers behind almost every number above.
Read them together. Low TTFB with a high LCP means the browser is doing too much: too many requests, render-blocking scripts, or an enormous hero image. High TTFB with everything else normal means the server is the bottleneck, before the browser is even involved.
Why one test from one place misleads
It is normal to test the same URL twice and get two different results, and neither is wrong. Three things drive most of the spread:
- Distance. A test run near the server has a shorter network path than one run on another continent. If your visitors are in Europe and you test from the same city as your server, you are measuring the best case, not the typical one.
- Device profile. A test can emulate a mobile device with a smaller viewport, a different user agent and a throttled connection. A desktop-tuned page scores very differently under mobile emulation, on purpose.
- Caching and warm-up. The first request may hit a cold cache at the CDN or the application; the second is served warm. Run a page two or three times and use the pattern, not the single fastest run.
A single test is still worth running. It just means a number carries meaning only alongside the conditions it was measured under.
How to read a waterfall
The waterfall is the per-request timeline, one bar per file, ordered by when it started. Four shapes come up again and again:
- A long first bar before anything else starts. That is TTFB on the HTML, and everything queues behind it.
- A staircase where each request begins only when the previous one ends. That is a dependency chain, usually a script that loads another script that loads the real content. Chains are the most expensive shape on the chart.
- A wide bar in the middle from a third-party domain. Ads, chat widgets, analytics and fonts sit here, and a slow third party delays your own page if it is loaded synchronously.
- A dense cluster of tiny bars. Dozens of small files, each with its own connection overhead. Fewer, larger, cached files usually beat many small ones.
Bars in red or with 4xx and 5xx codes deserve attention even when the page looks fine, because a failing request still costs time before it fails.
Catching a slowdown nobody went looking for
A single test tells you how the page performed once, from one place, on one device profile. That is what you want when debugging something specific. It is not what you want when the goal is to notice a slowdown at all: pages get heavier one update at a time, and nobody runs a manual test on a quiet Tuesday. Scheduled page speed monitoring runs the same test from the same locations on an interval, keeps the history, and alerts when the numbers cross a threshold. Run one now with the page speed test, and see server response time if the slow part turns out to be the server.