Core Web Vitals for a medical website: does Google treat YMYL differently?

Every so often a clinic owner tells me the same thing, usually passed on by someone in marketing: "Google judges medical sites more harshly, so we need a 100 in PageSpeed or we'll drop." I understand where it comes from. There are two true things in that sentence and one that got stuck to them along the way.

True thing one: Google does treat health topics differently from cake recipes. True thing two: site speed matters. What got stuck to them is the belief that medical websites face stricter speed thresholds. They don't. The difference lies elsewhere, and for a clinic it is more interesting, because it is about trust, and trust decides whether a patient books at all.

In this piece I keep what Google says explicitly apart from what is my own reasoning. I also show how to measure a clinic website when the tools say "no data", and what usually slows it down.

Core Web Vitals are three metrics Google uses to describe how a page behaves for real users:

One important detail: what counts is the 75th percentile of visits, measured separately on phones and on desktops. A page passes when at least three out of four visits fall in the good range. One quick test in your office, on fibre and a new laptop, tells you almost nothing about that.

This is where it pays to read Google's documentation rather than summaries of summaries. In its page experience documentation Google says three things that set expectations well.

First, Core Web Vitals are used by its ranking systems. That part is not a myth.

Second, there is no single "page experience" signal. Google writes that its core ranking systems look at a variety of signals that add up to overall page experience: Core Web Vitals, HTTPS, displaying well on mobile, no intrusive interstitials, main content that ads do not get in the way of.

Third, and this is the sentence I would like every clinic owner to remember: Google always seeks to show the most relevant content, even if the page experience is sub-par. Good results in the Core Web Vitals report do not guarantee a top position.

The conclusion is simple. Speed is a condition your site should meet, not a lever for jumping ahead of competitors. A clinic with a perfect PageSpeed score and an empty service description will lose to a clinic with a slower site that answers the patient's question properly.

YMYL stands for "Your Money or Your Life". It is Google's name for topics that could significantly impact people's health, financial stability or safety, or the welfare of society. A clinic website, a procedure description, instructions on preparing for a test: these are all YMYL topics.

The term comes from the Search Quality Rater Guidelines, the document that people working for Google use when they assess samples of search results. Two things in it matter here.

Raters do not set rankings. The guidelines say plainly that no single rating can directly affect how a page appears in Google Search. Google uses the ratings to check whether its systems are working well. Nobody at Google sits down and rates your clinic's website by hand.

For YMYL the bar is higher, but it is about quality and trust. The guidelines say that pages on clear YMYL topics are held to very high page quality standards, because a poor page on such a topic could harm someone. In its guidance for content creators, Google adds that its systems give even more weight to content that shows strong E-E-A-T on topics affecting health, finances and safety.

E-E-A-T stands for Experience, Expertise, Authoritativeness and Trust. Google stresses that trust matters most and the other three contribute to it. It also notes that E-E-A-T itself is not a specific ranking factor, rather a description of what a mix of other signals is meant to pick up.

I searched the current version of the guidelines, from September 2025, for loading speed and Core Web Vitals. There is no section on them and no page quality criterion based on them. For YMYL, the guidelines talk about who is behind the content, whether you can contact them and whether the content is consistent with medical consensus.

Now my own reasoning, not a quote from Google. If trust weighs the most on health topics, and the Core Web Vitals thresholds are the same for every website, then the speed of a clinic website matters first to the patient and only second to the search engine.

Picture a typical moment. A patient on the bus is looking for an orthopaedist for tomorrow. She opens a page from the results, sees a white screen for three seconds, then a large slider, and when she tries to tap "Book an appointment", a cookie banner appears and pushes the button down. She taps something else. She goes back to the results and opens the next clinic.

No algorithm had to "penalise" anything here. The patient decided for herself whether to trust this clinic with her health, and she did it in a few seconds. A page that jumps and stutters looks neglected, and in healthcare people read neglect as a warning sign. The same goes for a booking calendar that loads more slowly than the rest of the page.

That is why I think of a clinic site's speed the way I think of hygiene in a practice. Nobody picks a doctor because the waiting room is clean, but a dirty waiting room can put people off before the doctor has a chance to say hello.

The medical practice websites we look at share a recurring set of problems. For each one I note which metric it usually hurts.

A large slider or video at the top of the page (LCP). Three rotating photos of the reception desk or drone footage of the building. The browser has to download a heavy file before the patient sees anything useful. Sliders also often load every image at once, including ones nobody will see. One well-prepared image, or simply a clear headline with a booking button, almost always does better.

A third-party booking widget in an iframe (LCP, CLS, INP). A calendar from a booking portal embedded as an iframe loads its own scripts, fonts and styles. If no space is reserved for it, it pushes the page around when it arrives. If it sits right at the top, it delays everything else. Whether such a widget is the right choice at all is something I covered in the piece on booking portals versus your own system.

A chat that loads on every page (INP, LCP). Chat widgets can weigh more than the rest of the page and keep the browser busy just when the patient is trying to tap something. A good pattern is a lightweight facade: an icon that looks like the chat, with the real widget downloaded only after a click.

A cookie banner that shifts content (CLS). A banner inserted at the top of the page that pushes everything down is a classic source of layout shifts. A banner shown as an overlay that does not move content avoids the problem. The banner itself is needed if you use tracking tools, which I wrote about in the piece on what the GDPR requires from a clinic website.

Doctor photos straight from the camera (LCP, CLS). A team photo at print resolution with no dimensions set. It weighs several times more than it needs to, and when it finally loads, it pushes the text below it.

Fonts from several sources (LCP, CLS). Three typefaces in five weights, fetched from elsewhere. The text first appears in a fallback font, then swaps to the final one and changes width.

Tracking and advertising scripts (INP). A pixel from one ad platform, another from a second, a heatmap, a session recorder. Each is small on its own, together they keep the browser busy for a long time. In a clinic there is also the question of what data about patients these scripts send at all, and that is a matter for your data protection officer, not only for performance.

Start with PageSpeed Insights, Google's free tool. You paste in an address and get two quite different kinds of results that are often confused.

Field data are measurements from real Chrome users over the last 28 days, taken from the Chrome User Experience Report (CrUX). The Core Web Vitals report in Google Search Console is based on them, and they answer the question of how the site works for your patients.

Lab data is a simulation of a single page load on one device, emulating a mid-range phone on a mobile network. The 0 to 100 score refers to that simulation. It is useful for finding causes, but it is not Google's verdict. It is also worth knowing that a lab test does not measure INP, because nobody clicks anything in it.

The second place to look is Google Search Console, in the Core Web Vitals report. It shows groups of similar URLs and their status, separately for phones and desktops. A group's status is set by its worst metric.

This is the most common situation for small and mid-sized practices, so it deserves its own section. CrUX only collects data for pages with enough visits. Google does not publish the threshold. If a single page does not reach it, PageSpeed Insights shows data for the whole origin. If the origin does not reach it either, there is simply no field data.

That does not mean the site is bad or that Google cannot see it. It only means you cannot measure it from your patients' point of view with this particular tool. What to do then:

If I had to set the order for a typical clinic website, it would look like this.

Notice that the first point is not about milliseconds. It is about whether the patient manages to book. Our approach goes the same way: on clinic websites, online booking, SMS reminders and Google reviews come first, while GDPR and accessibility are the foundation that simply has to work.

Since credibility matters most on health topics, it is worth showing it on the page directly. These elements help patients and match what Google's guidelines look for on medical pages.

The same content is also read by AI search engines when a patient asks them about a clinic nearby. I wrote about that in the piece on clinic websites in AI search.

We deliver online booking, SMS reminders and Google reviews for medical practices in Medova, with GDPR and accessibility done properly in the background. The details are on medova.health. If you are wondering what such a site costs and where that figure comes from, I explained it in the piece on what a clinic website really costs.

If your site jumps around on a phone, or PageSpeed says "no data" and you are not sure what to do with that, write to me and we will suggest where to start. I lead the conversation about scope myself, and the measurements and fixes are done by the team the practice then works with directly. Sometimes it is enough to change three things at the top of the homepage, with no need to rebuild anything.