The short answer
Measure before you change anything: run your home page and a key service page through PageSpeed Insights on mobile and note which Core Web Vital fails. Then fix the usual causes in this order: an oversized hero image or autoplay video, third-party scripts such as chat and review widgets, images without set dimensions that make the page jump, and slow server response. Google uses Core Web Vitals in ranking, but it does not promise top positions for good scores, so the goal is a page that loads quickly for patients on a phone.
How speed fits into Google Search
Google's page experience documentation says Core Web Vitals are used by its ranking systems, alongside many other signals. The same page is careful about limits: good results in Search Console or other tools do not guarantee a top position, and Google still shows the most relevant page even when its page experience is weaker. Where several practices have equally helpful pages, a better experience can help.
So speed work pays off twice. It removes a reason for Google to prefer a competitor's page, and it keeps a patient who tapped your result from giving up before the page appears. For what each metric measures, see our guide to Core Web Vitals for practice websites.
Measure first
PageSpeed Insights gives two kinds of results, and they answer different questions:
- •Field data comes from real Chrome visits over the last 28 days and is reported at the 75th percentile, so most of your visitors had that experience or better. This is the data behind the Core Web Vitals assessment.
- •Lab data comes from a Lighthouse test that simulates a mid-range phone on a mobile network. It changes from run to run, but its audits point to the files and scripts causing the delay.
| Metric | Good | Poor |
|---|---|---|
| Largest Contentful Paint (loading) | 2.5 s or less | Over 4 s |
| Interaction to Next Paint (response to taps) | 200 ms or less | Over 500 ms |
| Cumulative Layout Shift (page jumping) | 0.1 or less | Over 0.25 |
| Time to First Byte (server, experimental) | 800 ms or less | Over 1.8 s |
Source: Google, About PageSpeed Insights. Values between Good and Poor count as Needs Improvement.
Write down the field values and the top lab audits for your home page and your two or three most important service pages. That is your baseline. Search Console's Core Web Vitals report then shows which groups of pages share the same problem.
Fix the biggest causes in order
- The hero image or video. On most practice sites the largest element at the top of the page is a photo or a background video, and it decides Largest Contentful Paint. Resize the photo to the size it is shown at, save it as WebP (web.dev reports files usually 25 to 35 percent smaller than JPEG or PNG), and let it load normally rather than lazy-loading it. Replace an autoplay background video with a still image and let visitors press play if you want the video.
- Images further down the page. Add
loading="lazy"to images below the first screen, and give every image width and height attributes so the browser reserves space and the layout does not jump. - Third-party scripts. Chat widgets, review carousels, booking pop-ups, social feeds and several tracking pixels each add code that runs on every visit and can slow taps and scrolling. List them, remove what nobody uses, and ask your vendors whether the rest can load after the page.
- Layout shifts. Cookie banners, late-loading fonts and ads or widgets that push content down are common causes. Reserve space for anything that appears after the page loads.
- Server response. If Time to First Byte is slow on every page, look at caching, the hosting plan and whether a content delivery network serves your files. On WordPress, a caching setup and a plugin cleanup are usually the first steps.
Change one thing at a time and rerun the lab test after each change, so you know what helped. Field data takes up to 28 days to reflect a fix because it covers a rolling window of visits.
Test the phone version
Google uses the mobile version of a site's content for indexing and ranking, which it calls mobile-first indexing. Always read the mobile tab in PageSpeed Insights first, and open your pages on an actual phone over cellular data, not only on office Wi-Fi.
Phones have less processing power than desktop computers, so heavy JavaScript hurts them most. If the desktop score is fine and mobile is not, scripts and oversized images are the usual reasons. Our guide to optimizing your website for mobile patients covers layout, tap targets and forms.
Keep it fast
- •Set a speed budget. Agree on a limit for page weight and for the number of third-party scripts, based on your own baseline. When someone wants a new widget or pixel, it has to fit the budget or replace something.
- •Retest after every change. A new plugin, theme update, gallery or tracking tag is the most common reason a fast site slows down again.
- •Check Search Console monthly. The Core Web Vitals report shows when a group of pages moves from Good to Needs Improvement.
- •Watch bookings, not only scores. Compare form submissions and calls from the website before and after speed work in your reporting dashboard.
If the fixes reach the theme or hosting, our SEO team can audit the site and handle the technical changes.
Sources
Google updates its documentation, so check it for current wording.
- •Google Search Central: Understanding page experience in Google Search results
- •Google Search Central: Understanding Core Web Vitals and Google search results
- •Google for Developers: About PageSpeed Insights
- •Google Search Central: Mobile site and mobile-first indexing best practices
- •web.dev: Browser-level image lazy loading for the web
- •web.dev: Use WebP images
Frequently Asked Questions
Does website speed affect Google rankings?
Yes, but as one signal among many. Google says Core Web Vitals are used by its ranking systems, and it also says good scores do not guarantee top rankings and that it still shows the most relevant page even when page experience is weaker. Treat speed as something that helps a relevant page compete and keeps patients from leaving, not as a shortcut to page one.
What is a good speed score?
Look at the field data first. A page passes the Core Web Vitals assessment in PageSpeed Insights when its 75th percentile visit has a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less. The Lighthouse lab score counts as good at 90 or above, but it changes from run to run and is a debugging tool, not the score Google uses.
Why does PageSpeed Insights show no field data for my site?
Field data comes from the Chrome User Experience Report, which needs enough real visits from Chrome users to a public, indexable page. Newer or low-traffic pages often fall back to data for the whole site, or show none at all. In that case, use the lab results to find problems and check the Core Web Vitals report in Search Console as traffic grows.
Should I lazy-load every image?
No. Lazy-load only images below the first screen. The main image at the top of the page, often the hero photo, should load normally, because delaying it makes Largest Contentful Paint worse. Give every image width and height attributes so the page does not jump as images load.
Is WebP safe to use?
Yes for current browsers, and web.dev reports WebP files are usually 25 to 35 percent smaller than comparable JPEG and PNG files. If you need to support older browsers, serve WebP inside a picture element with a JPEG or PNG fallback.
Do I need a developer to speed up my site?
Not for the first steps. Resizing and compressing photos, removing unused plugins and widgets, and replacing an autoplay background video with a still image are things an office manager can often do. Slow server response, heavy JavaScript and layout shifts from the theme usually need a developer.