Skip to main content
.com domains from $2.99 — free WHOIS privacy on every name

Benchmark bench · Beginner · 20 min

How to test your website speed — Measuring Site Speed: Which Number, Which Tool

You want a number you can act on and re-measure, not a score that moves every time you press the button and tells you nothing about why.

View Business Hosting plansBrowse more How-To Library

The short answer

Take the field reading first, because that is what you are actually judged on: Core Web Vitals from real Chrome users, with the published thresholds of 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS.

Then use lab tools to explain it. PageSpeed Insights gives you the vitals breakdown and the specific opportunities, WebPageTest gives you the request-by-request waterfall, and curl isolates TTFB so you can separate the server's thinking time from the page's weight. Three tools, three questions, and one rule: change one thing, then measure again.

By the HostingFast team · Reviewed 24 August 2026

Beginner

Assumed level

5

Stages to done

Free

Support cost

Proven

Verified on production

Twenty minutes gets you a baseline you can defend: three runs per template, the field reading from Search Console, and a TTFB figure taken logged out.

Keep the results somewhere. A short table of date, change, TTFB and LCP is the difference between optimising and guessing, and it costs one line per edit.

Field data first, lab data second

Field data is collected from real Chrome users on real connections and real devices, aggregated over a rolling window, and reported in Search Console's Core Web Vitals section. The published thresholds are LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, measured at the 75th percentile of your visitors. That percentile is why one fast laptop test proves nothing.

Lab data is a single synthetic run on a defined connection and device profile. It cannot tell you what your visitors experience, and it is not meant to — it is a diagnostic instrument. A lab score of 60 alongside green field vitals is a better position than a lab 95 with amber field data, and treating the score as the objective is how people end up optimising for a robot.

Separate the server from the page

TTFB covers everything before your HTML starts arriving: DNS resolution, TCP connect, the TLS handshake, and the server's own thinking time. curl reports each part separately, which is what makes it useful: curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer} total %{time_total}\n' https://example.com.

That one command usually settles the argument. If TTFB is 90 milliseconds and LCP is 4 seconds, the hosting is not your problem and the page is. If TTFB is 1.2 seconds, nothing you do to the images will save you, and the work belongs in caching, PHP and queries.

The runs that mislead, and how to stop them

Four common ways to measure something you did not mean to. Testing once, when single-run variance on shared infrastructure is real — take three and use the median. Testing only the homepage, which is frequently the least typical template you own. Testing while logged in, which bypasses the page cache entirely and shows you a number no visitor experiences. And testing immediately after a deploy or a purge, when the cache is cold by definition.

Fix all four by writing the protocol down: three runs, logged out, per template, warm cache, same time of day. Boring, repeatable, and the only way two measurements a month apart are comparable.

Attribution is the whole point

One change, one measurement. Batch five optimisations together and you may well end up with a faster site, but you will not know which of the five did it, which means you cannot repeat it on the next site and you cannot undo the one that quietly broke something.

Keep the log. Date, what you changed, TTFB, LCP. After a month it is the most valuable performance document you own, because it converts opinions about what works into a record of what worked here, on this site, with this stack.

A performance-test needle sweeping hard to the right

The stack these baselines were taken on

The numbers in this guide were taken against our own platform: LiteSpeed Enterprise in front of NVMe storage, per-site PHP switching, and a London datacentre with multiple upstream carriers.

How a platform is engineered — NVMe disks, LiteSpeed, restrained account density per machine — matters far more to your response time than the datacentre's position on a map.

  • Published Core Web Vitals thresholds quoted, not paraphrased
  • The full curl format string, ready to paste
  • Four ways a measurement misleads, each with its fix
  • Engineers who will compare your numbers with you

Why HostingFast

Standard on every plan

The right number first

Field data at the 75th percentile is what you are judged on, so the guide starts there rather than with a lab score.

Server split from page

One curl command separates DNS, TLS and server time from everything that happens after the first byte.

Thresholds stated exactly

2.5 seconds, 200 milliseconds, 0.1 — the published targets, so you know when you are done rather than chasing 100.

A written protocol

Three runs, logged out, per template, warm cache. Repeatable measurement is what makes month-on-month comparison possible.

Attribution enforced

One change per measurement, because a batch of five leaves you faster and none the wiser.

A log worth keeping

Date, change, TTFB, LCP. After a month it is the most useful performance artefact you own.

Quick Start

From order to online

  1. 1

    Record the baseline before you touch anything

    Three runs per template, median taken, logged out, warm cache. Homepage plus a product or service page plus a content page. Without this row in the table, every later claim is unverifiable.

  2. 2

    Take the field reading from Search Console

    The Core Web Vitals report shows LCP, INP and CLS at the 75th percentile of your real visitors, grouped by URL pattern. This is the reading that reflects what people actually get.

  3. 3

    Use lab tools for the explanation

    PageSpeed Insights for the vitals breakdown and named opportunities; WebPageTest for the waterfall, where a single blocking request is obvious. Neither replaces the field reading; both explain it.

  4. 4

    Isolate TTFB with curl, logged out

    curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer} total %{time_total}\n' https://example.com. Three runs. This tells you whether the problem is before or after the first byte.

  5. 5

    Change one thing, re-measure, write it down

    One edit, one measurement, one line in the log. It feels slower than batching and it is the only method that leaves you knowing why your site is fast.

Built In

Loaded onto every plan

  • NVMe SSD storage behind a LiteSpeed cache on every tier
  • LiteSpeed caching built into the server rather than bolted on by plugin
  • Per-site PHP version switching from the control panel
  • Full SSH access with Git and Composer for curl and CLI measurement
  • Resource Usage graphs in cPanel for CPU and entry-process peaks
  • PHP X-Ray on CloudLinux Pro on the Nitro tier for slow-request attribution
  • Built-in WebP image optimisation at no extra cost
  • 99.9% uptime as the target, monitored around the clock
  • Money-back cover: 30 days on hosting plans, 7 on reseller
  • Human support on duty every hour of every day

Frequently Asked

What people ask us most often

Which number should I report, field or lab?

Field, every time, with lab data as the supporting explanation. Field data is what real visitors experienced and what search engines act on; lab data is a synthetic run on a fixed device profile. A useful report reads: field LCP is 2.1 seconds at the 75th percentile, and the lab waterfall shows the hero image is the LCP element. One is the outcome, the other is the reason.

Does a score of 100 mean visitors experience a fast site?

Not necessarily. A perfect lab score is achievable on a page with green synthetic metrics and amber field vitals, because the lab run uses one device profile and one connection while your visitors use hundreds. It also works the other way: a lab score in the sixties with green field data is a site your visitors find fast. Optimise the field numbers; use the score to find candidates.

How do I measure a logged-in page without the cache in the way?

Deliberately, and separately. Logged-in requests bypass the page cache by design, so they measure your uncacheable path — PHP, queries, object cache. Take that reading with curl using a session cookie, and treat it as a different metric from your public TTFB rather than as a worse version of it. Both matter; conflating them is how people conclude their cache is broken.

Where does TTFB end and page weight begin?

At the first byte of HTML, which is exactly what makes the split useful. Everything before it — DNS, connect, TLS, server compute — is TTFB and points at hosting, caching, PHP and queries. Everything after it — render-blocking CSS, the LCP image, JavaScript execution — is the page and points at your templates and assets. Measure TTFB with curl, measure the rest with a lab run, and you always know which half to work on.

Keep reading

Changing hosts? Run through our checklist first.

A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.

You'll get the checklist email, then occasional pointers on keeping a site running fast. Unsubscribe the moment you want out — the privacy policy covers the rest.

Hosting that survives being measured.

LiteSpeed in front of NVMe on every tier, per-site PHP switching, PHP X-Ray on Nitro, and engineers who will read your waterfall with you.

View Business Hosting plans