Your Booking Page LCP Is a Revenue Number, Not a Technical One

Most practice owners are told their website is "slow" and handed a list of technical fixes. That framing loses money, because it treats a booking page like a performance problem when it is a revenue problem with a performance cause.

The distinction matters because it changes who owns the decision. A performance problem gets queued behind other development work. A revenue problem gets scheduled.

Here is what the number actually means. Largest Contentful Paint is the moment the biggest thing on screen finishes rendering. On a booking page that is almost always the hero image or the first form field. Until it paints, the patient is looking at a blank rectangle and deciding whether you are worth the wait.

That patient is not browsing. They found you, read enough to be interested, and clicked the one button that leads to a booking. Whatever they experience next is applied to the highest-intent traffic your site receives.

Why the hero image is almost always the culprit

In the audits we run, the single largest contributor to a failing LCP is not the server and it is not the framework. It is one oversized image, uploaded at whatever resolution the camera produced, served at that size to every device.

A 6 MB photo does not become a 6 MB problem on desktop broadband. It becomes a 6 MB problem on a phone on 4G in a car park, which is exactly where someone books a dental appointment.

The reason it survives review is that nobody sees it. The practice owner opens the site on an office laptop over fast wifi with the image already cached. The designer checks it on a retina display. The one context nobody tests is a mid-range Android on mobile data with an empty cache, which is the context most bookings actually happen in.

There is a second-order effect worth knowing. A large hero does not only delay itself. It competes for bandwidth with the CSS and fonts the page needs before it can render anything at all, so an oversized image pushes back the paint time of text that had nothing to do with it.

The four fixes, in the order worth doing them

Ordering matters here. Teams routinely start with the hardest change and never reach the one that would have fixed it. We have watched practices commission a full redesign, keep the same hosting and the same images, and report no change in bookings, because neither of the two things actually causing the delay was touched.

Read that table as a sequence rather than a menu. The first two rows are usually a single afternoon of work and typically recover more than the bottom two combined. Hosting is last not because it never matters, but because it is the most expensive change and rarely the binding constraint.

There is one honest exception. If your Time to First Byte is above 800ms on mobile, the server is genuinely the floor and no amount of image work will get you under 2.5 seconds. Measure TTFB first; it tells you whether the rest of the list is worth starting.

How to measure it properly

Three mistakes make most self-audits useless.

Testing the homepage. The homepage is optimised first, cached hardest, and carries none of the booking widget's payload. It tells you almost nothing about the page where the money is. Test the booking URL specifically.

Reading the desktop tab. PageSpeed Insights opens on mobile by default now, but the desktop number is the one people quote because it is kinder. If your mobile and desktop LCP differ by more than two seconds, you have a mobile-specific rendering problem and the desktop score is actively misleading.

Trusting the lab score. The score at the top of PageSpeed Insights is a simulation. The Core Web Vitals panel below it, when present, is field data from real Chrome users on your site. When the two disagree, the field data is what Google uses.

What this is worth

A booking page is the last step before revenue. Every 100ms of delay on it is applied to the visitors closest to converting, which is why the arithmetic is worse than a general "site speed" number suggests.

Take a practice getting 400 booking-page visits a month, converting at 8%, with an average first-appointment value of GBP 120. That is GBP 3,840 a month. The research consensus puts conversion loss in the region of a few percent per additional second of load. On a page that is 1.6 seconds over the threshold, recovering even half of that is the difference between a page that pays for itself and one that does not.

We are deliberately not quoting a single headline percentage here, because the figure varies enormously by sector and the widely-shared ones are older than they look. Measure your own page, then measure it again after the hero fix.

The number that should worry you is not in your analytics at all. A session that ends before the booking interface renders looks identical to a visitor who changed their mind. It is recorded as a bounce, attributed to nothing, and disappears into an average.

What good looks like

• Largest Contentful Paint under 2.5 seconds on mobile, closer to 2 on the

booking page specifically

• Time to First Byte under 600ms, so the rest of the budget is spendable
• The hero image served in AVIF or WebP at the size it actually renders
• No lazy-loading attribute anywhere near the largest above-the-fold element
• A booking widget that is not waiting on chat, reviews and analytics to

finish first

None of this is visible to a patient as a metric. It is visible as the page appearing when they expected it to.