Measured, not claimed: speed and accessibility checks on every release

Every website quote says the site will be fast and accessible. The words are free. A number with a date next to it is not. This post explains the tests a build has to pass before we release it, and shows you how to run the same tests yourself, on any site, in about two minutes. That includes this one and the site you have now.

The tool is free and it is Google’s

The test is called Lighthouse. In Google’s words, “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” You point it at a page and “it runs a series of audits against the page, and then it generates a report on how well the page performed”^[1]. It is built into Chrome, and it is the engine behind PageSpeed Insights, which “reports on the user experience of a page on both mobile and desktop devices, and provides suggestions on how that page may be improved”^[2].

PageSpeed Insights “uses Lighthouse to analyze the given URL in a simulated environment for the Performance, Accessibility, Best Practices, and SEO categories”^[2]. Each runs from 0 to 100, and the bands are fixed: “A score of 90 or above is considered good. 50 to 89 is a score that needs improvement, and below 50 is considered poor.”^[2]

What the four scores mean

Performance is the one people quote, and it is not a single timing. “The Performance score is a weighted average of the metric scores”^[3], and the weights favour three things: Total Blocking Time at 30%, Largest Contentful Paint at 25% and Cumulative Layout Shift at 25%, with First Contentful Paint and Speed Index at 10% each^[3]. “The scoring distribution is a log-normal distribution derived from the performance metrics of real website performance data on HTTP Archive.”^[3] So 100 does not mean “passed”. It means faster than almost every page Google has measured.

Accessibility works differently. “The Lighthouse Accessibility score is a weighted average of all accessibility audits”, and “Each accessibility audit is pass or fail. Unlike the Performance audits, a page doesn’t get points for partially passing an accessibility audit.”^[4] The report also lists manual checks the tool cannot score on its own, such as whether “The page has a logical tab order” and whether “Interactive controls are keyboard-focusable”^[4]. A 100 here is a floor, not a ceiling.

Best Practices is a checklist of things a well-made page does. The first audit, for example, checks that the page declares its document type, which “prevents the browser from switching to quirks mode”^[5]. “Each Best Practices audit is weighted equally in the Lighthouse Best Practices Score.”^[5]

SEO checks the basics search engines need, such as a meta description, which “provides a summary of a page’s content that search engines include in search results”^[6]. “Each SEO audit is weighted equally in the Lighthouse SEO Score, except for the manual Structured data is valid audit.”^[6]

The three Core Web Vitals

Underneath the Performance score sit three measurements Google treats as special. “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.”^[7] The table puts the four scores and the three vitals in one place, each with its threshold for “good”.

Score or metric	What it tells you, in one line	Good
Performance	Weighted average of five loading timings, scaled against the real web[3]	90 or above[2]
Accessibility	Weighted average of pass-or-fail checks on labels, contrast and structure[4]	90 or above[2]
Best Practices	Equal-weighted checklist of things a well-made page does[5]	90 or above[2]
SEO	Equal-weighted checklist of what search engines need to read the page[6]	90 or above[2]
Largest Contentful Paint (LCP)	“measures loading performance”: when the biggest thing on screen has appeared[7]	2.5 seconds or less[7]
Interaction to Next Paint (INP)	“measures interactivity”: how long a tap or click takes to show a response[7]	200 milliseconds or less[7]
Cumulative Layout Shift (CLS)	“measures visual stability”: how much the page jumps around while loading[7]	0.1 or less[7]

The thresholds are not judged on your best visitor. Google’s guidance is that “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices”^[7]. In plain words: three visitors in four have to get the good experience before the page counts as good.

Lab data and field data are different things

A Lighthouse run is lab data. “Lab data is determined by loading a web page in a controlled environment with a predefined set of network and device conditions.”^[8] One machine, one connection, one location, one visit with an empty cache. That makes the test repeatable, so you can change something and see whether the number moved.

Field data comes from real people. “Field data is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.”^[8] Google collects it through the Chrome UX Report, which “is a dataset that reflects how real-world Chrome users experience popular destinations on the web”^[9] and “is used by Google Search to inform the page experience ranking factor”^[9]. When PageSpeed Insights shows real-user figures at the top of a report, that is the Chrome UX Report, and it covers “the previous 28-day collection period”^[2].

The two disagree for ordinary reasons. “Lab tests typically load a page with a cold cache, but when real users visit that page they may already have some of its resources cached.”^[8] Google is direct about which to trust: “if you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts”^[8].

For a small business, field data often does not exist. “A page might not have sufficient data if it has been recently published or has too few samples from real users.”^[2] A new site, or one with modest traffic, shows lab data only. That is normal, and it is why we publish lab figures with the exact method, so anyone can reproduce them.

What “WCAG 2.2 AA” means

Accessibility has a written standard, and quotes should name it. The Web Content Accessibility Guidelines come from the W3C, the body that maintains the web’s standards: “The WCAG documents explain how to make web content more accessible to people with disabilities.”^[10] The current version, WCAG 2.2, “was published on 5 October 2023”^[10]. It covers “blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these”^[11].

The letters after the version are the level: “The success criteria are at three levels: A, AA, and AAA. The success criteria are what determine ‘conformance’ to WCAG.”^[10] Each level includes the one below: “For Level AA conformance, the web page satisfies all the Level A and Level AA success criteria, or a Level AA conforming alternate version is provided.”^[11] AAA is the top, and the W3C does not expect whole sites to reach it: “It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.”^[11]

AA is the level we build to, and the level to ask for in any quote. It is a floor. Lighthouse can check contrast ratios and missing labels, but it cannot tell whether a page makes sense to someone using a screen reader or a keyboard, which is why its report carries a list of manual checks^[4]. The score is the start of the job, not proof it is done.

Why it matters to a business

Google’s summary of the published evidence reports that “the BBC found they lost an additional 10% of users for every additional second their site took to load”^[12], and that Rakuten 24’s Core Web Vitals work “increased revenue per visitor by 53.37% and conversion rate by 33.13%”^[12]. The mechanism is the same for a Perth trade business: a slow page loses the call.

How to run it yourself

1. Open pagespeed.web.dev in any browser.
2. Paste the full address of a page, including https://, and press Analyze.
3. Look at the top of the report. It either shows real-user data or says there is not enough; that is the field-versus-lab question above^[2].
4. Read the four scores. Anything under 90 is amber or red by Google’s own bands^[2].
5. Find LCP, INP and CLS in the metrics and compare each to the table above.
6. Switch between the Mobile and Desktop tabs.
7. Run it two or three times; Google suggests thinking of performance “as a distribution of scores, rather than a single number”^[3].
8. In Chrome on a computer you can skip the website: open the page, press F12, click the Lighthouse tab, then “Analyze page load”^[1].

What we do on every release

After every release of this site we run Lighthouse on the home page with the same settings each time: Lighthouse 12, desktop preset, against the production build. The results, the method and the date are published on the home page, and they are replaced after each release rather than left to go stale.

The previous two posts explain how the site earns those figures: what React is and how islands keep its JavaScript small. If you have run the test on your current site and did not like the numbers, the brief builder takes about three minutes, and the reply comes back with a recommended approach and a fixed price.

Reference list

All sources accessed 19 May 2026.

1. Google (n.d.) Introduction to Lighthouse. Chrome for Developers. https://developer.chrome.com/docs/lighthouse/overview/
2. Google (n.d.) About PageSpeed Insights. Google for Developers. https://developers.google.com/speed/docs/insights/v5/about
3. Google (n.d.) Lighthouse performance scoring. Chrome for Developers. https://developer.chrome.com/docs/lighthouse/performance/performance-scoring/
4. Google (n.d.) Lighthouse accessibility score. Chrome for Developers. https://developer.chrome.com/docs/lighthouse/accessibility/scoring/
5. Google (n.d.) Page lacks the HTML doctype, thus triggering quirks mode. Lighthouse Best Practices audits, Chrome for Developers. https://developer.chrome.com/docs/lighthouse/best-practices/
6. Google (n.d.) Document does not have a meta description. Lighthouse SEO audits, Chrome for Developers. https://developer.chrome.com/docs/lighthouse/seo/
7. Google (n.d.) Web Vitals. web.dev. https://web.dev/articles/vitals
8. Google (n.d.) Why lab and field data can be different (and what to do about it). web.dev. https://web.dev/articles/lab-and-field-data-differences
9. Google (n.d.) Overview of CrUX. Chrome UX Report, Chrome for Developers. https://developer.chrome.com/docs/crux/
10. W3C Web Accessibility Initiative (n.d.) WCAG 2 Overview. W3C. https://www.w3.org/WAI/standards-guidelines/wcag/
11. W3C (2024) Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, 12 December 2024. https://www.w3.org/TR/WCAG22/
12. Google (n.d.) Why does speed matter? web.dev. https://web.dev/articles/why-speed-matters