I have a confession that is going to annoy anyone who has ever screenshotted a green “98” from PageSpeed Insights and sent it to their boss as proof the website is fine: that number is mostly theater. I have watched hotel sites with a glorious green lab score lose direct bookings on mobile all day long, and I have watched ugly amber-scored sites convert like crazy. The lab score and reality are two different things, and the gap between them is where I do some of my favorite diagnostic work.
So let me walk you through how I actually read Core Web Vitals field data — the real-user CrUX stuff — to figure out which pages on a hotel site are quietly costing it money. Not the lab fantasy. The field truth.
Lab data vs field data, and why the lab lies to you
When you run PageSpeed Insights, you get two sections, and most people only look at one of them.
The top section, the giant colored number, is lab data. It is Lighthouse running one simulated page load on a throttled fake phone in a Google data center. It is a controlled experiment. It is repeatable. And it has almost nothing to do with your actual guests on actual phones on actual hotel-lobby-grade wifi.
The section underneath — the one labeled something like “Discover what your real users are experiencing” — is field data, pulled from CrUX, the Chrome User Experience Report. This is a rolling 28-day window of real Chrome visits to your URL. Real devices, real networks, real distances from the server, real ad blockers, real everything.
Here is the punchline: Google ranks on the field data. Not the lab number. So when you celebrate a 95 lab score while your CrUX INP sits in the red, you are celebrating the wrong scoreboard.
The lab score is a flight simulator. CrUX is the black box recorder from the actual flights. Only one of them tells you why guests are bouncing off your booking page at 11pm on a Sunday on a three-year-old Android.
The three metrics that make up Core Web Vitals as of now:
- LCP (Largest Contentful Paint) — how long until the biggest thing on screen (usually your hero image) actually shows up. Good is under 2.5 seconds.
- INP (Interaction to Next Paint) — when a guest taps “Check availability,” how long until the page visibly responds. Good is under 200 milliseconds. This one replaced the old FID metric and it is far less forgiving.
- CLS (Cumulative Layout Shift) — how much the page jumps around as it loads. Good is under 0.1. This is the metric that makes someone tap the wrong date because the calendar shifted under their thumb.
Why hotel sites get wrecked by field data specifically
Two page types on nearly every independent hotel site I audit are structurally built to fail these metrics, and they happen to be the two page types that matter most: the booking/availability page and the photo gallery.
The booking page is where you bleed INP and CLS. You drop in a booking-engine widget — SynXis, Cloudbeds, Mews, a Little Hotelier embed, whatever — and it loads a pile of third-party JavaScript, often inside an iframe, often after the rest of the page. A guest lands, taps a date before the widget’s own script has finished waking up, and nothing happens for 400ms. That is a bad INP, recorded in CrUX, attributed to your URL, and it is invisible in a clean lab run because the lab robot does not impatiently jab at a half-loaded calendar.
The gallery page is where you bleed LCP and CLS. Twenty 4MB images of your suites, none of them sized with width and height attributes, all lazy-loading and reflowing as they arrive. The lab test on fast simulated wifi shrugs. Your guest on hotel-district LTE watches the page heave and shudder for four seconds.
This is exactly why I refuse to diagnose a hotel site from a single homepage PageSpeed run. The homepage is usually the most optimized, most cached, most loved page on the whole site. It is the page that makes the lab score look great while the money pages quietly rot.
Reading CrUX by page group, not by single URL
The mistake I see constantly: someone tests one URL, sees green, declares victory. CrUX data is available per-URL but only for URLs with enough traffic to be statistically meaningful. Your homepage almost always has it. Your “Garden Suite” room page might not. So you have to think in page groups, not individual URLs.
The way I structure a hotel audit is by template type, because pages built from the same template share the same performance DNA:
| Page group | Primary CWV risk | What’s usually causing it |
|---|---|---|
| Homepage | LCP | Oversized hero video or image |
| Room/suite pages | LCP + CLS | Heavy unsized photos, lazy-load reflow |
| Photo gallery | LCP + CLS | Many large images, no dimensions set |
| Booking/availability | INP + CLS | Third-party booking widget JS |
| Blog/content | Usually fine | Occasional ad or embed script |
| Local/area guide | LCP | Embedded maps, unoptimized images |
I pull CrUX at the origin level first (the whole domain’s aggregate, which CrUX always has) to see the overall shape, then drill into the individual high-traffic URLs that do have their own data — usually the homepage and the booking page. For the room and gallery templates that lack per-URL data, I run lab tests across several example URLs of the same template and treat the pattern as a proxy, while leaning on real-user monitoring to fill the gap.
How to actually get the data
You do not need a fancy tool to start:
- PageSpeed Insights — paste a URL, read the field-data section (ignore the big number for now). If it says no field data, that URL lacks the traffic; go up to origin.
- Search Console’s Core Web Vitals report — this is the underrated one. Google groups your URLs by similar behavior and tells you which groups are “Poor” or “Need improvement” on mobile vs desktop. That grouping is your page-group map, handed to you for free.
- The CrUX dashboard or BigQuery — if you want the 28-day trend lines and the full histogram, this is where it lives. Overkill for most independents, gold for the curious.
The 75th-percentile rule is the part people miss: Google judges you by your 75th-percentile user, not the average. So three quarters of your visits can be lovely and you still fail if the slowest 25% are bad. On a hotel site, that slow quarter is disproportionately your mobile, far-from-the-server, last-minute-booking guests — the exact people you want to convert.
Walking through a diagnosis the way I do it
Let me make this concrete with an illustrative example (numbers below are made up to show the method, not a real client result).
Say I pull a boutique inn’s data. Origin-level CrUX: LCP fine, INP borderline, CLS fine. Looks okay-ish. If I stopped there I would tell them “you’re basically fine.” But I don’t stop there.
I open Search Console’s CWV report and see two URL groups flagged amber on mobile. One group is the room-detail template. One is the booking page. The homepage is green. The aggregate looked okay only because the homepage gets the most traffic and dilutes the average.
I drill into the booking URL specifically — it has its own CrUX data because it gets enough visits — and INP is sitting in the red on mobile. Now I know: the booking widget is the problem, the thing standing directly between my guest and a direct reservation. That is the single most expensive 300ms on the entire website.
Then I do the same for a couple of room URLs via lab + my RUM script, confirm the unsized-image CLS pattern, and now I have a prioritized list that is about money, not vanity:
- Booking page INP — touches every direct conversion.
- Room-page CLS and LCP — touches the page guests read right before they decide.
- Everything else — later.
That ordering is the whole game. Fixing the homepage hero to go from a 92 to a 98 lab score feels productive and changes nothing. Shaving 250ms off booking-widget interaction touches every single person trying to give you money instead of giving it to an OTA.
A green lab score on your homepage is like a spotless lobby with a broken elevator. Guests don’t experience the average of your building. They experience the specific path they’re standing on — and on a hotel site that path runs straight through the booking widget.
What I actually do about each one
A quick field guide once you’ve found the culprit page group:
- Bad LCP on galleries and room pages — serve modern formats (WebP/AVIF), size images to their display size, set explicit
widthandheight, and make sure the hero image is not lazy-loaded. Preload the LCP image if it’s critical. - Bad CLS — every image and embed gets reserved dimensions so nothing reflows. Reserve space for the booking widget’s iframe so the page doesn’t jump when it arrives.
- Bad INP on booking pages — this is the hard one because you often don’t control the third-party widget’s code. Options: defer the widget until interaction, load it in a way that doesn’t block the main thread, lean on the booking engine’s own performance settings, or push your provider to ship a lighter embed. Sometimes the honest answer is that the engine is the bottleneck and the fix is a conversation with the vendor.
This is the connective tissue between technical SEO and revenue, which is why I treat Core Web Vitals work as part of both our hotel SEO and book-direct CRO work rather than a standalone checkbox. A faster, steadier booking page does two things at once: it removes a small ranking drag, and — far more importantly — it stops scaring guests off the exact page where they decide between booking with you directly and bouncing back to an OTA.
Setting expectations honestly
Two things I always say out loud so nobody gets oversold.
First: Core Web Vitals are a real but modest ranking signal. Fixing them will not magically vault you above the OTAs for a competitive term — that takes content, links, reputation, and the rest of the stack. Anyone promising a #1 from a speed fix is selling you something. What good vitals do is remove a handicap and stop you losing on the tiebreakers. They maximize your odds; they don’t guarantee an outcome.
Second: this is one lever among many in the larger fight to win back more direct bookings and build a healthier OTA mix. You will never fully escape the OTAs, and you shouldn’t try to — they’re a discovery channel. But every guest who lands on a fast, stable booking page and completes a direct reservation is a guest you didn’t pay 15-25% commission on. That math, compounded across a year, is the whole reason this technical-weeds stuff matters. I dig into that exact math over in the book-direct commission breakdown, and into the structural reasons OTAs keep out-ranking you in how OTAs steal search.
And remember the timing quirk: CrUX is a trailing 28-day window. You can ship a perfect fix today and the field data won’t fully catch up for about four weeks. So instrument your own real-user monitoring to see the immediate improvement, and treat the CrUX dashboard as the slow, official confirmation that lands a month later. Don’t panic-revert a good fix just because the green hasn’t shown up yet.
The short version
Stop trusting the big lab number. Pull the field data, group it by page template, find the 75th-percentile user on your booking and gallery pages, and fix those first because that’s where the bookings live. The homepage will be fine. It’s always fine. It’s the money pages that are quietly bleeding.
If you’d rather not spend your weekend in BigQuery histograms, this is exactly the kind of diagnosis we run as part of a technical audit — pulling your real-user data, mapping it to your page groups, and handing you a fix list ordered by revenue impact instead of vanity. Book a call and I’ll tell you which of your pages are actually hurting you, and which green scores are lying to your face.