Website speed test for dental practices: what the scores mean
Speed test tools give you a score out of 100 and a page of red warnings. Most of it does not matter for a dental practice website. Here is how to test properly, which numbers Google actually uses, and the handful of fixes that usually make the difference.
Practice Radar shows a dental practice where it ranks against every practice nearby, and does the work to move up.
Thirty days free. No card, and nothing starts automatically when it ends.
A website speed test for dental practices should answer one question: does your site load quickly for a patient on a phone? The free tools give you far more than that, including a score that changes every time you run it. This guide explains which website speed test to use, how to read the results without being misled, and what usually slows a practice website down.
The short answer: which website speed test to use
Use Google PageSpeed Insights first. It is free, it is Google's own, and it shows both a simulated test and real-world data from Chrome users who visited your site. Google explains the two in its About PageSpeed Insights page.
Then check the Core Web Vitals report in Google Search Console, which groups your pages by the same real-world measures across your whole site.
Other free testers such as WebPageTest and GTmetrix are useful for digging into why a page is slow, because they show a waterfall of every file the page loads in order. They are diagnostic tools. For judging whether you have a problem, Google's field data is the reference, because it is what Google says it uses.
See this for your own town.
Every practice competing with yours on one map, sized by the share of local search each one holds, re-checked every week. The sample town shows the whole thing now, with no sign-up.
Run on our own practice first: ninth of the 14 practices measured in its town in May, first of 18 in September, on UK-wide search value. Page-one keywords: 6 in May, 194 in September.
Thirty days free. No card, and nothing starts automatically when it ends.
Does website loading speed affect Google rankings?
Yes, a little, and less than most speed test reports suggest. Google's page experience guidance says Core Web Vitals are used by its ranking systems. In the same breath it says Google always seeks to show the most relevant content, even if the page experience is sub-par, and that good results in Core Web Vitals reports do not guarantee your pages will rank at the top.
Google also warns that chasing a perfect score just for SEO reasons may not be the best use of your time. For a dental practice, that is the right way to think about it. A slow site will not stop you ranking if everything else is strong, and a fast site will not rescue weak content or a thin Business Profile. Speed matters mainly because patients leave slow pages, and every patient who leaves is a booking you paid to attract and then lost.
Lab data and field data: why your score keeps changing
PageSpeed Insights shows two kinds of result, and confusing them is the most common mistake.
| Field data | Lab data | |
|---|---|---|
| Where it comes from | Real Chrome users visiting your site, from the Chrome User Experience Report | One simulated load of the page by Lighthouse |
| Time covered | The trailing 28 days | The moment you ran the test |
| Where it appears | The top section of the report | The lower section with the score out of 100 |
| What it is for | Judging whether real patients get a fast site | Diagnosing what to fix |
The score out of 100 is the lab result. Google's Lighthouse scoring documentation says much of the variability in the score is not caused by Lighthouse itself, and lists causes such as changes in the ads being served, internet routing and the testing device. Run the same page three times and you can get three different scores. Do not judge a change, or a web designer, on a single run.
What if there is no field data?
Many practice websites see "no data" in the field section. Field data comes from real Chrome visits, and Google only shows it when there is enough of it. Search Console's Core Web Vitals report help says the same thing: "No data available" means there is not enough data in the Chrome UX Report for that device type. In that case the lab result is all you have, so run it several times and look at the typical figure.
The three numbers Google actually uses
Core Web Vitals are three measures of real visits. Google judges each at the 75th percentile, which means three in four visits need to meet the "good" threshold.
| Measure | What it means for a patient | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | How long until the main image or heading appears | 2.5 seconds or less | Over 4 seconds |
| Interaction to Next Paint (INP) | How quickly the page responds when they tap a button or open a menu | 200 milliseconds or less | Over 500 milliseconds |
| Cumulative Layout Shift (CLS) | Whether the page jumps around as it loads, so they tap the wrong thing | 0.1 or less | Over 0.25 |
Those thresholds are from Google's PageSpeed Insights documentation. Anything between good and poor is "needs improvement".
The lab score uses different measures, weighted together. Google's scoring documentation gives the most weight to Total Blocking Time, then Largest Contentful Paint and Cumulative Layout Shift. A score of 90 or more is green, 50 to 89 is orange and below 50 is red.
How to run a mobile website speed test properly
- Test the pages patients land on. Your homepage, your most visited treatment page and your contact or booking page. Search Console's Performance report shows which pages get the most clicks.
- Use the Mobile tab. Make sure you are reading the Mobile results. Mobile is the harder test and the one to pass.
- Read field data first. If it shows all three Core Web Vitals as good, you do not have a speed problem worth spending money on, whatever the lab score says.
- Run the lab test three times. Note the middle score, not the best or worst.
- Write it down with the date. Speed tends to drift downwards as plugins, widgets and images are added. A record lets you spot when it changed.
What usually slows a dental practice website
Practice websites tend to slow down for a familiar handful of reasons.
Large images and sliders
A full-width photo slider on the homepage can easily be the single heaviest thing on the page. Google's guide to optimising Largest Contentful Paint recommends modern image formats such as WebP and AVIF, and warns never to lazy-load the main image at the top of the page because it delays it. One well-compressed photo usually loads faster and reads better than a five-slide carousel.
Third-party widgets
Review widgets, live chat, online booking pop-ups, finance calculators, social feeds and multiple tracking tags all load code from other companies' servers. Each one adds weight and can slow the page's response to taps. List every widget on your site and ask whether it earns its place. If a review widget can be replaced with a few reviews written into the page, that is often faster.
Hosting
Cheap shared hosting, or a server on another continent, makes every page start slowly before any of your content has even begun to load. PageSpeed Insights reports this as Time to First Byte. A UK practice serving UK patients is usually best served by a host with UK or European servers and a content delivery network for images.
Too many plugins and a heavy theme
Many practice sites run on WordPress with a multipurpose theme and a page builder. These can carry code for features you never use. A caching plugin set up properly helps, but adding plugins to fix speed is a common way to make it worse.
Embedded video and maps
An embedded YouTube video or Google Map loads a lot of code before anyone presses play or scrolls to it. A still image that loads the video or map when tapped keeps the page light.
Website speed optimisation: what to ask your web developer
You do not need to fix any of this yourself. You need to ask the right questions:
- What do our Core Web Vitals look like in Search Console on mobile, and which group of pages is worst?
- What is the largest element on the homepage on mobile, and how big is the file?
- Which third-party scripts does the site load, and which could we remove or delay?
- Where is the site hosted, and what is the Time to First Byte for UK visitors?
- Once you have made changes, can you start validation in Search Console? Google tracks the fix over a 28-day window.
Be wary of any proposal that promises a score of 100 or that measures success only by the lab score. Google's own documentation says a perfect score is not necessary, and the lab score varies between runs anyway.
When speed is not the problem
If your field data is good and patients still are not finding you, speed is not what is holding you back. Look instead at your Google Business Profile, your reviews, and whether you have a proper page for each treatment you want to grow. Our guide to SEO for dental practices covers those in order, and the free search audit shows where your practice stands in your area without needing an email.
Catch slow pages before patients do
On the Growth plan, Practice Radar runs site health checks on your practice website and flags problems as part of your monthly brief of three actions.
Run on our own practice first: ninth of the 14 practices measured in its town in May, first of 18 in September, on UK-wide search value. Page-one keywords: 6 in May, 194 in September.
Thirty days free. No card, and nothing starts automatically when it ends.