We measured one Punta Cana hotel's homepage five times with Google's own PageSpeed Insights.

It scored 7. Then the test errored out. Then it scored 100. Then 19. Then 19 again.

Nothing about the website changed between those runs. If you had tested it once and got the 7, you would have concluded your site was among the worst in the country. If you had got the 100, you would have concluded it was perfect. Both would have been wrong.

This post is about reading that report properly, because the panic it causes is mostly avoidable and the useful parts are not the ones people look at.

What the score actually is

The number in the coloured circle is not a measurement of your website. It is a weighted composite of several lab metrics, produced by running Google's Lighthouse tool once, on Google's servers, against a simulated mid-range phone on a throttled network.

Three words in that sentence do the damage.

Simulated. It is not your customer's phone on Claro in Bávaro. It is a model of a mid-tier device on a slow connection.

Once. A single run, with all the variance that implies.

Composite. The score blends several metrics by weight. Two sites with identical real-world experience can score differently, and a change that improves your score may not improve anything a visitor feels.

The score is a useful rough signal and a terrible target.

The four numbers worth your attention instead

Scroll past the circle. Google's own Core Web Vitals documentation names three metrics with specific thresholds, and there is a fourth figure on the report that explains most problems.

Largest Contentful Paint. How long until the main thing on the page appears. Google's target is within 2.5 seconds. This is the single most informative number on the report.

Cumulative Layout Shift. Whether the page jumps around while loading. Target is below 0.1. Usually caused by images without declared dimensions, or ads and banners inserted after the page draws.

Interaction to Next Paint. How long the page takes to respond when someone taps. Target is under 200 milliseconds. Note that PageSpeed's lab run cannot measure this directly — it reports Total Blocking Time as a proxy, and INP comes from real-user data when Google has enough of it for your site.

Total page weight. Not a Core Web Vital, but it sits in the report and it explains the other three more often than anything else.

If LCP is under 2.5 seconds and CLS is under 0.1, your site is fine. The score in the circle is then a curiosity.

Why your score moves, with real numbers

Here is what we actually recorded across 36 Dominican hotel websites and a set of verification re-runs.

One large resort: 7 on the first run, then a Lighthouse error, then 100, then 19, then 19. We treat roughly 19 as the real value. The 7 was a low outlier and the 100 was not real at all — more on that below.

Another property: 20 on the first run with an LCP of 55.5 seconds and 11.26 MB downloaded, then 50 on the re-run with an LCP of 37.2 seconds and 8.3 MB. Both were genuine page loads. That site is simply unstable, which is itself the finding.

Two others were rock solid. One scored 34 twice, with page weights of 28.69 MB and 28.70 MB — the heaviest site in our sample, and perfectly reproducible. Another scored 84 then 82.

So variance is not uniform. Some sites give you the same answer every time. Others swing by thirty points. You cannot know which kind you have from one run.

The trap nobody warns you about

The 100 in that sequence is the most important thing in this post.

That run returned a performance score of 100, an LCP of 0.8 seconds and a total page weight of 0.0 MB. There was no real page load. The server returned essentially nothing, and PageSpeed scored the emptiness as though it were a very fast page.

It does this silently. There is no warning on the report.

So: any run showing a near-zero page weight should be discarded, not celebrated. If your score suddenly jumps to the high nineties with no deployment behind it, check the page weight and the screenshot filmstrip before you tell anyone.

How to use the report without being misled

Six rules, in order.

1. Run it three times and take the median. Not the best, not the worst. This single habit removes most of the noise.

2. Discard degenerate runs. Near-zero bytes, a blank filmstrip, or an error means no result, not a good one.

3. Read LCP first, score last. LCP against 2.5 seconds tells you more than the composite.

4. Check the field data if it exists. When Google has enough real-user traffic for your site, the report shows real-world data above the lab results. That is your actual customers. It beats the simulation every time.

5. Test the pages that matter. PageSpeed defaults to one URL. We only measured homepages in our study and said so — your booking page or menu page may be far worse.

6. Test mobile, not desktop. In the Dominican Republic this is not a preference. The Oficina Nacional de Estadística's ENHOGAR-MICS 2025 survey found 89.4% of households own a smartphone against 32.3% owning any computer, laptop or tablet.

What a normal score looks like here

This is the part that should actually reduce the panic.

Across our 36-site sample of Punta Cana and Bayahibe hotel websites, the median PageSpeed score was 29. Thirty-one of the 36 scored under 50. Not one site scored 90 or above. The median LCP was 17.1 seconds, and exactly one site in 36 got its main content on screen in under four seconds. Zero reached Google's 2.5-second threshold.

If you just tested your site and got 34, you are above the median for Dominican tourism websites. That is not an excuse to stop — it means the whole market is slow and there is room to win on it — but it does mean a score in the thirties is not a crisis unique to you.

The opportunities list is not a to-do list

Under the metrics, PageSpeed gives you a list of suggestions with estimated savings. People print this and hand it to a developer as a work order. That is usually a mistake.

The list is generated mechanically and does not know your business. Three common items worth understanding before acting:

"Eliminate render-blocking resources" often means your fonts and stylesheet. Fixing it properly is real work. Fixing it carelessly produces a page that flashes unstyled text before snapping into place, which looks broken.

"Reduce unused JavaScript" is frequently your booking engine, your chat widget or your analytics. Some of that is genuinely waste. Some of it is the thing that takes your reservations. The report cannot tell the difference and will happily suggest you remove revenue.

"Serve images in next-gen formats" is almost always correct and almost always worth doing. On our sample, images were a median 27% of page weight, so this is a real but partial win.

Read the estimated savings in seconds, not in score points. An item promising 0.1 seconds is not worth a deployment. One promising 4 seconds is.

What not to do

Do not chase 100. The effort required to go from 85 to 100 is usually larger than the effort to go from 29 to 85, and the visitor cannot feel the difference.

Do not let anyone sell you a service priced against a score. A score is a one-run lab composite that can be moved by deferring scripts your business actually needs. Ask what the LCP is and what it will be afterwards.

And do not compare your score to a competitor's from one run each. You would be comparing two coin flips.

We have put a number on the overall state of Dominican business websites in a separate post, and published why we release the research including the inconvenient parts. If you want someone to run the test properly and tell you which of the numbers actually matters for your business, DR Web Studio works with businesses across the Dominican Republic — contact us for a free consultation.