The Hotel Study Findings That Didn't Make the Article

When we published our measurements of 36 Dominican hotel websites, we led with the numbers that made the argument: a median PageSpeed score of 29, a median 17 seconds to show the main content, and the finding that small independent hotels outperformed the big resort chains by more than two to one. A study has to have a spine, so a lot of what we measured didn't make it in.

Some of what we left out is more useful than what we published — including one finding that contradicts the advice every web developer gives, and one measurement that quietly lied to us. Here's the rest of the data.

Images are not the problem

This is the finding that surprised us most, and it undermines the standard advice.

Ask anyone why a website is slow and you'll be told to compress the images. It's the first thing everyone reaches for, including us. But in this dataset it is mostly wrong:

• Images accounted for a median of 27% of total page weight

• On 28 of 36 sites, images were less than half the total weight

Which means that on the typical hotel site we measured, roughly three-quarters of what the visitor downloads is not photographs. It's code — JavaScript, tracking scripts, chat widgets, booking engines, tag managers, personalization tools, analytics.

That changes the fix entirely. You cannot compress your way out of a problem that isn't images. Optimizing photography still matters and we'd still do it, but on these sites it addresses a quarter of the weight while leaving the other three-quarters untouched. The real work is removal, and removal is an organizational problem: every one of those scripts was added deliberately, by someone, for a reason that made sense at the time. Nobody's job is to take them out again.

Fourteen seconds of frozen browser

Total Blocking Time measures how long a page is unresponsive while the browser processes JavaScript — the period where taps do nothing and the page appears stuck.

• Median: 1.67 seconds

• Mean: 3.05 seconds

• Worst measured: 14.55 seconds

Nine of 36 sites blocked for more than three seconds. Six blocked for more than five.

Fourteen and a half seconds is worth pausing on. That is a visitor tapping a menu button and getting nothing, repeatedly, on a site belonging to a hotel with real revenue and a real marketing department. Nobody at that hotel knows, because on an office desktop over good Wi-Fi the problem is nearly invisible. It only exists on the phone your customer is actually holding.

Things moving around while you read

Cumulative Layout Shift measures how much a page jumps as it loads — the effect where you go to tap something and it moves out from under your finger.

Google's threshold for "good" is 0.1. Fourteen of 36 sites exceeded it, and one scored 1.000, which is roughly the worst possible result — a page where the content is still rearranging itself as you try to use it.

This is the least-discussed of the performance metrics and one of the most user-hostile. It's also often cheap to fix: most layout shift comes from images and ads loading without reserved space, and telling the browser how big things will be before they arrive is a small technical change.

Accessibility: the quiet failure

We ran accessibility scores alongside performance and then didn't use them, because the speed story was stronger. They deserve their own mention.

• Mean: 81 out of 100

• 29 of 36 scored under 90

• 17 of 36 scored under 80

• Only two sites scored a perfect 100

These aren't exotic failures. They're unlabeled buttons, insufficient colour contrast, missing alt text, form fields with no associated labels — the ordinary stuff. It matters for the obvious reason, which is that people with visual impairments, motor difficulties or screen readers are customers too. It also matters for a less obvious one: many accessibility signals are the same signals search engines use to understand a page. Alt text describes an image to a blind visitor and to Google. Proper heading structure helps a screen reader and a crawler.

Small hotels scored best here too — 84.5 against 80.9 for large resorts — which is the same pattern the performance data showed.

Every direct booking engine was on somebody else's domain

We detected booking engines on seven sites: three running Hotetec, two SynXis, one Paraty, one Beds24. All are legitimate hospitality booking platforms.

Here's the part worth noting: all seven were hosted on the vendor's domain, not the hotel's. Zero out of seven ran the booking flow on their own site.

In practice that means a guest who finds a hotel, browses its rooms and clicks "Book now" is handed off to a different web address to complete the transaction — a moment where the branding changes, the URL changes, and trust is tested. It's normal in the industry and it works. But combined with our published finding that only a third of these hotels offer direct booking at all, the picture is that even the hotels doing it right are doing it on rented infrastructure.

Fifteen hotels are shipping markup that no longer does anything

Structured data was widespread — 86% of sites carried JSON-LD. But 15 of 36 sites still ship FAQPage markup, which Google retired in 2026. It produces no search feature. It is not penalised and it does no harm; it simply does nothing.

We're not raising it because it's costing anyone rankings. We're raising it because it's a clean proxy for something harder to measure: how long has it been since anyone looked at this site? Markup for a feature that was withdrawn is a fossil layer. It tells you the site was configured once, correctly, by someone competent — and then never revisited.

The measurement that lied to us

This is the most important thing in this article, and it's a caution about the method rather than a finding about hotels.

We re-measured the four most extreme results before publishing. One large resort had scored 7 on the first run. On re-runs it scored 19, twice. So the 7 was excluded and no poor performer was named in the published article.

But one of those re-runs did something worse than being wrong. It returned a performance score of 100, a Largest Contentful Paint of 0.8 seconds, and a total page weight of 0.0 MB. No page had loaded at all. The tool had measured an empty response and scored it as though it were the fastest website in the world.

If we had run that test once, on that attempt, we would have published that this hotel had a perfect score. Nothing in the output says "this is wrong." It looks like a great result.

The lesson generalises well beyond our study. Any measurement showing near-zero page weight should be discarded rather than believed. And no single automated run is a fair basis for a public claim about a specific business — which is why our published article named only the one hotel whose top score we verified twice, and described every poor performer anonymously.

We're publishing this because studies that only show their clean results are less trustworthy than studies that show where the instrument wobbled.

What we'd do differently next time

Three things, said plainly:

Measure three times, report the median. We did this only for the extreme values. It should be standard for every site, and it would have caught the instability we found in one property that ranged from 20 to 50 across two runs.

Include field data where it exists. Everything here is lab measurement — Lighthouse on simulated hardware. Where a site has enough traffic, Google also publishes real-user data, which is closer to what customers actually experience.

Measure more than the homepage. We tested homepages only. The room pages and the booking flow are where a hotel actually makes money, and they may be considerably better or considerably worse.

The thread running through all of it

Every finding here points at the same thing the main article found: these sites were built competently and then left alone. The structured data is correct but includes a retired type. The accessibility failures are the routine ones any audit would flag. The scripts accumulate because adding is somebody's job and removing is nobody's.

That's not a design problem, and a redesign wouldn't fix it — a new site left alone for three years ends up in exactly the same state. It's a maintenance problem, which is far less interesting and considerably cheaper to solve.

If you'd like to know what your own site is carrying — the scripts nobody removed, the markup that stopped working, the blocking time your customers feel and you don't — contact us for a free consultation. We'll measure it properly, more than once, and tell you what we find.