A Lighthouse score is the 0–100 number Google's free testing tool gives a web page for performance, accessibility, best practices and SEO. Agencies and vendors love to send screenshots of it. This page explains what the score measures, why it moves every time you test, how it differs from the real-visitor data Google uses, and which fixes actually raise it on a practice website.
In short: Lighthouse is a lab test of one page load on a simulated phone or desktop. Its performance score is a weighted mix of five speed metrics, and it varies between runs. Use it to find problems, test on mobile three to five times and take the median, and judge success by real-visitor Core Web Vitals, not a perfect 100.
"lighthouse score" draws 880 searches a month in the US and 140 in Canada (CPC $15.99, keyword difficulty 46; Google Ads Keyword Planner data via DataForSEO, 12-month average to Sep 2026).
What a Lighthouse score measures
Lighthouse (opens in a new tab) is an open-source, automated tool from Google. You can run it in Chrome's DevTools, through PageSpeed Insights, or from the command line. Each run loads the page once in a controlled, simulated environment and reports what it saw.
That makes it a lab test. It doesn't record what real patients experienced; it records what one simulated visit looked like. That's why it's so useful for diagnosing problems and so easy to over-read.
Performance, accessibility, best practices and SEO categories
Lighthouse reports four main categories, each scored 0–100.
Performance is a weighted average of five metrics. As of October 22, 2026, Chrome for Developers lists the Lighthouse 10 weights (opens in a new tab) as current. Weights change between versions, so check the version your report shows.
| Metric | Weight (Lighthouse 10) | What it means on a practice site |
|---|---|---|
| Total Blocking Time | 30% | How long scripts (chat, reviews, ad tags) lock up the page |
| Largest Contentful Paint | 25% | When the hero photo or main headline appears |
| Cumulative Layout Shift | 25% | Whether buttons and text jump while loading |
| First Contentful Paint | 10% | When anything at all first appears |
| Speed Index | 10% | How quickly the visible page fills in |
The bands: 90–100 good, 50–89 needs improvement, 0–49 poor.
Accessibility is a weighted average of automated pass/fail checks (opens in a new tab), weighted by user impact. Manual checks don't affect it. A 100 doesn't mean the site is accessible; the W3C notes that evaluation tools "can not determine accessibility" (opens in a new tab), only assist. See our accessibility checks guide for what to test by hand.
Best practices covers general good practice, security and deprecated technologies. SEO checks basics such as page titles, descriptions and crawlability. Both are useful checklists; neither is a ranking forecast.
Why your score changes every time you test
Lighthouse's maintainers list the sources of variation in their variability documentation (opens in a new tab): page content that changes between loads (ads, A/B tests, rotating sliders), local network conditions, the testing computer's hardware, other programs and browser extensions competing for resources, and the browser itself. Their headline finding: "The median Lighthouse score of 5 runs is twice as stable as 1 run."
On practice sites, the biggest swings usually come from third-party widgets. A chat or review widget that loads quickly on one run and slowly on the next can move the score noticeably.
Testing method: how to get a fair number
- Use mobile emulation. In PageSpeed Insights, read the Mobile tab. In Chrome DevTools, choose Mobile before running.
- Run three times at minimum; five is better. Report the median, not the best run.
- Test the same pages each time: your home page and one service page.
- Use the same setup: one browser, extensions off, nothing else heavy running.
- Write down the date and Lighthouse version shown in the report, so later comparisons are like for like.
Lighthouse vs real-user Core Web Vitals
| Item | Lighthouse (lab) | Core Web Vitals (field) |
|---|---|---|
| Source | One simulated page load | Real Chrome visitors |
| Time window | Right now | The previous 28 days (opens in a new tab) |
| Responsiveness metric | Total Blocking Time, a stand-in | Interaction to Next Paint, measured on real taps |
| Best for | Finding causes, checking a fix | Knowing what patients experienced |
| Available for small sites | Always | Only with enough Chrome traffic |
Web.dev calls Core Web Vitals "first and foremost, field metrics" (opens in a new tab) and says lab measurement "is not a substitute for field measurement". Lighthouse can't measure Interaction to Next Paint because nobody taps anything during the test, so it reports Total Blocking Time as a proxy. Google's documentation says Core Web Vitals are used by its ranking systems (opens in a new tab); it doesn't describe the Lighthouse number that way. See Core Web Vitals for where to find your field data.
What a good score looks like for a practice website
A practice site should aim for the green band, 90 or above, for mobile performance on its home page and its most important service pages. Lighthouse's documentation says a perfect 100 is "extremely challenging to achieve and not expected", and that going from 99 to 100 takes about as much improvement as going from 90 to 94.
Beyond that, a higher score isn't a goal by itself. What matters is whether patients can see your services, tap to call and request an appointment quickly on a real phone, and whether your field Core Web Vitals pass. For reference, the medfy.ai home page reports a 98/100 mobile speed score: the Google Lighthouse score of Medfy's newest website template, tested on a phone.
Templates and page builders often score lower out of the box because they load features you don't use. Our comparison of templates vs custom builds covers that trade-off.
Fixes that move the score on practice sites
- Resize and compress the hero and provider photos. Improves Largest Contentful Paint. Web.dev's LCP guide (opens in a new tab) also warns never to lazy-load the main image.
- Delay chat and review widgets until tapped. Improves Total Blocking Time. A facade (opens in a new tab) loads a lightweight placeholder first.
- Remove the home page slider. Improves LCP and layout stability.
- Lazy-load maps and videos below the fold. Improves LCP and Speed Index.
- Reserve space for banners and badges. Improves Cumulative Layout Shift.
- Remove unused scripts and old ad tags. Improves Total Blocking Time, and keeps pixels away from patient forms.
Test again with the same method after each change, so you know which fix did what. Our website grader (free tool) gives a quick read, and the free marketing audit scores your site's speed on phones alongside SEO, your Google listing and AI visibility. For the full picture, see our guide to website speed optimization.
Frequently asked questions
What is a good Lighthouse score?
For performance, Lighthouse labels 90 to 100 as good, 50 to 89 as needs improvement and 0 to 49 as poor. Aim for the green band on your home page and a service page, tested on the mobile setting. Lighthouse's own documentation says a perfect 100 is extremely hard and not expected, so a practice site in the 90s has better things to work on than the last few points.
Why is my Lighthouse score different every time I test?
Lighthouse runs in a simulated environment that is sensitive to the network, the testing computer, browser extensions, other programs running, and anything on your page that changes between loads, such as ads, chat widgets or rotating sliders. Its maintainers say the median of five runs is about twice as stable as one run. Test the same page several times and report the middle score.
Does a Lighthouse score affect Google rankings?
Not as a number. Google's documentation says Core Web Vitals are used by its ranking systems, and those are field metrics gathered from real Chrome visitors over 28 days. A Lighthouse score is a lab diagnostic run once on a simulated device. Improving what Lighthouse flags often improves the real-visitor numbers too, but Google's documentation points to the real-visitor numbers, not the lab score.