Dental Website Slow Loading? How Booking Page LCP Costs You Patients

If your dental website is slow loading on mobile, you lose patients before they see your treatments, your prices or the booking button. Nothing crashes. The page just takes long enough that a patient on a phone gives up and tries the next practice on the list.

The number that measures this is Largest Contentful Paint, or LCP. This guide explains what it means on a booking page, what usually causes it, and the five fixes in the order worth doing them.

What booking page LCP measures

Largest Contentful Paint is the moment the biggest thing on screen finishes appearing. On a dental booking page that is usually the hero image, a large heading or the booking widget itself. Until it appears, the patient is looking at a blank or half-built page and deciding whether you’re worth the wait.

Google rates an LCP of 2.5 seconds or less as good, 2.5 to 4 seconds as needing improvement, and over 4 seconds as poor. It judges this on real visits, at the 75th percentile, so a page that feels quick on your office laptop can still fail for most of your patients.

The patient on your booking page isn’t browsing. They found you, read enough to be interested, and pressed the one button that leads to an appointment. Whatever happens next happens to your most valuable visitors.

Why your dental website looks fine on desktop but loads slowly on mobile

Most practice websites are signed off by the owner, the practice manager and the agency on a laptop, over fast office broadband, with the images already cached. The hero looks sharp. The booking button is in the right place.

Patients aren’t sitting at that desk. They search at lunch, in the car park, on the sofa at 9pm, on a mid-range Android or an older iPhone, often on a weak signal. On that phone the same site can feel sluggish: the main image takes a few seconds to appear, a pop-up jumps in late, the booking button doesn’t respond on the first tap.

The patient doesn’t think “this site has an LCP problem”. They think the practice feels disorganised, and they leave.

What causes slow loading on a dental website

It is rarely one thing. Usually three or four smaller problems add up on a mobile connection.

An oversized hero image

In the audits we run, the biggest single cause of a failing LCP is one image: a photo uploaded at whatever size the camera produced and served at that size to every phone. A multi-megabyte photo that loads instantly on office broadband takes seconds on 4G, and it also competes for bandwidth with the text and styles the page needs first.

Too many third-party scripts

Practice websites collect scripts over the years: a chat widget, a reviews feed, a booking embed, a Facebook pixel, Google tags, a heatmap, a cookie banner. Each was added by someone different, for a good reason, and nobody measured the total. The booking widget, the one thing the patient came for, often loads last.

Slow server response

Before anything appears, the server has to answer. That wait is called Time to First Byte (TTFB), and Google treats 0.8 seconds or less as good. Cheap shared hosting can push it well past that, and no amount of image work will get you under 2.5 seconds if the server is slow to start with.

Layout shift on the booking step

A banner that loads late, a cookie notice or an embed that resizes can push the booking form down just as the patient goes to tap it. Google measures this as Cumulative Layout Shift (CLS); 0.1 or less is good. On a treatment page it’s annoying. On a booking page it costs appointments.

Five fixes for booking page LCP, in the order worth doing them

Order matters. We have seen practices pay for a full redesign, keep the same images and hosting, and see no change in bookings, because neither of the two things causing the delay was touched.

Read the table as a sequence, not a menu. The first two rows are usually an afternoon of work. Hosting comes last not because it never matters, but because it is the most expensive change and rarely the main cause.

The one exception: if your TTFB is above 0.8 seconds on mobile, the server is the floor, and you should fix hosting first. Measure it before you start; it tells you whether the rest of the list is worth doing. For the image side in more detail, see how we set up an image pipeline.

How to check your own booking page

Three mistakes make most self-checks useless:

• Testing the homepage. It’s usually optimised first and carries none of the booking widget’s weight. Put the booking page’s address into PageSpeed Insights instead.
• Reading the desktop tab. People quote it because it’s kinder. Your patients are on the mobile tab.
• Trusting the lab score. The big score at the top is a simulation. The Core Web Vitals section above it, when there is one, comes from real Chrome users on your site, and that is what Google uses.

“Core Web Vitals assessment: failed”

If PageSpeed Insights shows this, real visitors over the last 28 days missed Google’s “good” mark on at least one of the three measures: LCP, INP (how quickly the page responds to taps) or CLS. Because it is a rolling 28-day figure, a fix takes a few weeks to show as a pass.

If LCP passes but taps still feel slow, the problem is responsiveness, not loading; see INP above 200ms on booking flows.

What a slow booking page costs the practice

A worked example, with numbers you should swap for your own. A practice gets 400 visits a month to its booking page, converts 8% of them, and a first appointment is worth £120 on average. That page brings in about £3,840 a month. Even recovering a small share of the patients who give up while a slow page loads is worth real money.

We’re deliberately not quoting a headline percentage for “each second costs X%”. The figures that get shared are older than they look and vary by sector. Measure your own page before and after the hero fix.

Paid traffic makes it worse. Google Ads charges for the click whether or not the page loads in time, and landing page experience is part of how Google rates your ads. We wrote up one practice where we paused a Google Ads request until the website was fixed.

What good dental website speed looks like

• LCP under 2.5 seconds on mobile, closer to 2 seconds on the booking page
• TTFB under 0.8 seconds, so the rest of the budget is usable
• The hero image served as AVIF or WebP, at the size it actually displays
• No lazy-loading on the hero image, and lazy-loading on everything below it
• INP under 200 milliseconds, so taps feel immediate
• CLS close to zero on the booking and pricing pages
• A booking widget that isn’t waiting for chat, reviews and analytics to finish

None of this shows to a patient as a number. It shows as the page appearing when they expected it to, and the button working the first time. If your contact form is the slow part rather than the page, see why website form submissions are slow.

For practices, the speed of the website is one part of a bigger picture; see marketing for dental practices for the rest.