Test on a real phone with a stopwatch, then use a tool to find causes. Scores are diagnostic rather than a verdict, and lab tests and real-visitor data answer different questions.

Why the numbers disagree

Run three speed tests and you get three results, sometimes wildly different, on the same page in the same minute.

None of them is broken. They are measuring different things under different conditions and reporting them in different units.

One simulates a mid-range phone on a slow connection. Another tests from a server with a fast one. A third reports what actual visitors experienced over the past month.

Comparing them is like comparing a stopwatch, a weather forecast and a survey. All useful, none interchangeable.

Lab against field

The distinction that explains most of the confusion.

Lab data is a controlled test, run on demand, under simulated conditions. It is repeatable, immediate, and not what anybody actually experienced.

Field data is gathered from real visitors over a period, usually weeks. It reflects reality and it lags badly, because it is an average over time.

Which means a fix applied today shows instantly in lab data and takes a month or more to move field data.

Businesses regularly conclude a fix did not work because they checked the wrong number the following week.

What to use each for

The first is the one people skip, and it is the only one that answers the question a customer would ask.

The stopwatch test

Crude and more reliable than any score for deciding whether there is a problem.

A real phone, mobile data, private browsing window so nothing is cached. Tap the link and count until you can read the thing you came for.

Under three seconds is fine. Three to five is acceptable. Above eight is losing people.

Do it on the pages people actually land on, which is usually a service page rather than the homepage.

If that test passes, the score does not matter. A page that feels fast is fast, whatever a tool says about it.

A worked example

A supplier who had spent several weeks and a developer's time chasing a score from the low forties into the seventies.

The work was real: deferred scripts, compressed assets, a caching layer.

Measured with a stopwatch before and after, the page went from about 2.4 seconds to about 2.1.

Nobody could perceive the difference, and no visitor behaviour changed, because the page had never been slow.

The same effort applied to a different page on the same site, which took nine seconds because of an uncompressed background image, would have produced a change everybody noticed.

The score had directed attention to the page that was easiest to measure rather than the page that was actually a problem.

Reading a lab report usefully

The parts worth attention, and the parts to ignore.

Worth attention: the list of what took longest, the largest files, and anything flagged as blocking the page from rendering.

Worth ignoring for a small business site: recommendations requiring a rebuild, suggestions about serving formats your platform does not support, and anything whose stated saving is a few hundredths of a second.

The report is a list of everything imperfect, not a list of what matters. Most of it is technically correct and irrelevant at this scale.

The useful discipline is reading the top three items and stopping.

The counter-case

Where scores genuinely matter more than the stopwatch.

Where somebody else is being paid to improve performance and a number is how the work is specified and verified. A stopwatch is a poor contractual term.

Where a client or a tender requires a stated score, which happens in public sector work.

And at large scale, where fractions of a second across millions of visits genuinely aggregate into something.

For a local business with a few thousand visits a month, none of those applies, and the stopwatch is the better instrument.

Testing the right pages

A mistake that wastes effort.

Most speed work is done on the homepage, because that is what a tool tests by default and what the owner thinks of as the site.

Most visitors arrive on a service page or an article from a search, and never see the homepage at all.

Check which pages people actually enter through, and test those. The homepage may be the fastest page on the site and the least visited.

Testing from where customers are

An option most tools offer and few people set.

Testing from a server in another country adds distance that your actual visitors do not experience, or hides distance that they do.

Set the test location to somewhere near your customers. For a Vancouver business that means the west coast rather than a default that might be anywhere.

It changes the result meaningfully and it is a dropdown in the tool rather than a project.

What a score does not tell you

Worth stating, because a number invites over-interpretation.

It does not tell you whether visitors are leaving, which is a question for your analytics rather than a speed tool.

It does not tell you whether the page is any good, whether it answers the question, or whether the enquiry form works.

And it does not tell you whether improving it would produce any business result, which is the question you actually care about.

A page scoring poorly and producing steady enquiries is doing its job. A page scoring perfectly and producing nothing has a different problem entirely, and no amount of optimisation addresses it.

A routine that is proportionate

  1. Stopwatch test your two busiest pages, twice a year.
  2. If either fails, run a lab test to find the cause.
  3. Fix the top three items and stopwatch again.
  4. Check field data a month later to confirm.
  5. Otherwise leave it alone.

The fifth is the one that saves the most time. A site that passes the stopwatch does not need optimising, however much a testing tool would like it to.

What the metrics behind those tools are measuring is covered in Google named the numbers it cares about.

Frequently asked questions

Why do speed tools disagree?

They measure different things under different conditions. One simulates a slow phone, another tests from a fast server, a third reports real visits over weeks.

What is the difference between lab and field data?

Lab is a controlled test, immediate and repeatable. Field is gathered from real visitors over weeks, reflects reality, and lags badly behind any fix.

Why does my fix look like it did not work?

Because field data averages over a month. A change shows instantly in a lab test and takes weeks to move the real-visitor numbers.

What is the stopwatch test?

A real phone, mobile data, private window, counting until you can read what you came for. Under three seconds is fine, above eight is losing people.

How should I read a lab report?

The top three items and stop. It lists everything imperfect rather than everything that matters, and most of it is irrelevant at small-business scale.

Which pages should I test?

The ones people actually enter through, usually a service page rather than the homepage. The homepage may be your fastest and least visited page.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Chasing a score that will not move?

Check with a stopwatch first. Plenty of low-scoring pages are perfectly fast in practice.

Start a Conversation