Why a slow website costs you bookings in 2026

Core Web Vitals — the speed and stability scores Google uses as a lightweight but real ranking signal — have been stable since INP replaced FID in March 2024 (LCP ≤2.5s, INP ≤200ms, CLS ≤0.1 at the 75th percentile). What changed isn't the bar; it's that INP, the responsiveness metric, now exposes interaction lag the old FID metric never measured. Many small tourism sites that looked "good" on 2023 lab data now score "needs improvement" on real-user field data — without changing a line of code, and most operators don't know it.

The effect is quiet: not a cliff, but a steady drift down the rankings, invisible unless you're tracking it. Here's what this means for Irish tourism sites specifically, and the small set of fixes that make the difference.

What actually changed

Core Web Vitals measures three things:

• LCP (Largest Contentful Paint) — how long before the main content appears
• INP (Interaction to Next Paint) — how long before the site responds to a tap
• CLS (Cumulative Layout Shift) — how much the page jumps around as it loads

Where the 2024–2025 ground actually shifted:

• LCP "good" threshold remains 2.5 seconds (75th percentile, mobile field data) — Google has not tightened it
• INP replaced FID as the responsiveness Core Web Vital in March 2024 and is now the primary tap-latency metric
• CLS uses a session-window measurement (the largest 5-second burst of unstable shifts) — unchanged at 0.1, but real-world sessions surface shifts the older single-load measurement would have hidden

What this means in practice: a site that scored "good" across the board on lab data in 2024 can now score "needs improvement" on real-user field data without changing a line of code, because INP exposes interaction latency that FID never measured.

Why Irish tourism sites are hit hardest

Three overlapping factors make this a tourism-specific problem:

1. Large hero images

Tourism websites live and die by visual impact. A typical tourism hero is a 1920×1080 JPEG at 400-800KB, often loaded at full quality on mobile, where it's rendered at 375×211. The rendering gap is wasted bandwidth, and the file size directly increases LCP on mobile.

2. Third-party widgets

Small operators commonly embed: a booking widget, Google Maps, a reviews widget, a social feed, a cookie banner, a live-chat widget. Each one adds JavaScript to the page — and each additional JS file adds INP cost and delays LCP.

3. Real users on real connections

Your visitors are disproportionately on mobile, often on rural networks or travelling on patchy data. Ireland's rural 4G coverage remains uneven — 3G fallback happens. The site that loads in 1.2 seconds on fibre in Dublin may take 8 seconds in the Gaeltacht.

The effect adds up: a visitor in rural Connemara, on 3G, loads a 3MB hero image on a site with five third-party widgets, and sees a white screen for 6 seconds. They close the tab. You never knew they existed.

The five fixes that actually move the numbers

Fix 1: Serve hero images as WebP or AVIF

Converting hero images from JPEG to WebP typically cuts file size by 25-34% at the same visual quality, per Google's own comparison study. AVIF often does better again, though browser support is still catching up. Modern frameworks serve the right format per browser automatically; WordPress themes often don't.

If you are on WordPress, a plugin like ShortPixel or EWWW Image Optimizer configured properly (not default settings — configured) will cut your image payload dramatically. This is the single highest-ROI change for most tourism sites in 2026.

Fix 2: Lazy-load everything below the fold

Images, videos, iframes, widgets — anything not visible on initial load should be deferred. Lazy-loading is a browser standard in 2026 (loading="lazy" attribute on images and iframes), but many older tourism sites don't use it.

Fix 3: Move third-party widgets to "load on interaction"

A booking widget doesn't need to be running in the background on your homepage. It needs to be there when the user clicks "Book Now". A technique called facade loading replaces widgets with static previews that swap to the real widget on user interaction. Cuts INP measurably.

Fix 4: Remove unused plugins and scripts

Audit your third-party scripts. Most tourism sites have 10-20 scripts loaded on every page, many of which were added for a single experiment and never removed. Every unused script is free latency.

Chrome DevTools' Coverage tab shows exactly which JS is used vs. loaded on each page. The gap is often startling.

Fix 5: Upgrade the hosting setup

Hosting matters more in 2026 than it did five years ago. A tourism site on shared WordPress hosting at €5/month is meaningfully slower than the same site on modern edge hosting — Vercel, Netlify, Cloudflare Pages, or a properly configured managed WordPress host like WP Engine or Kinsta.

The difference is real: modern edge and managed hosting serve assets from locations close to the visitor, which meaningfully cuts load time for international traffic on variable connections — with no other changes. For a tourism site serving overseas visitors, this is exactly where the gap hurts most.

How to measure where you are

Three free tools, in order of usefulness:

1. PageSpeed Insights (pagespeed.web.dev) — paste your URL, scan on mobile, look at the Core Web Vitals section. Green is good; amber is the usual starting state for small tourism sites.
2. Google Search Console → Experience → Core Web Vitals — shows real-user field data for your site, broken down by URL.
3. Chrome Lighthouse (built into Chrome DevTools) — runs a full audit with specific remediation suggestions.

Focus on PageSpeed Insights mobile score and the Core Web Vitals report in Search Console. Desktop scores are a distraction — your traffic isn't on desktop.

A realistic 2026 target

Aim for:

• LCP under 2.5s on mobile in the 75th percentile (what PageSpeed Insights calls "good")
• INP under 200ms in the 75th percentile
• CLS under 0.1 over the full session

Hitting all three on mobile is achievable for a well-built small tourism site. It is difficult for a site built on an old theme with a long list of plugins layered in over five years.

When to rebuild vs. when to patch

The honest answer: if your site is on WordPress and more than four years old, it's almost always cheaper and better to rebuild than to patch. If it was built cleanly within the last two years on a modern framework (Next.js, Astro, Nuxt, SvelteKit), it's almost always worth patching.

The tipping point is usually how much content exists. A site with 50+ pages of valuable content is worth migrating carefully. A site with 8 pages and a booking widget is often faster to rebuild from scratch.

The hidden cost

Every second of extra load time costs conversions. Public web-performance research puts the impact in the single-digit-to-low-double-digit percent range: a Deloitte/Google study of mobile sites found a 0.1-second speed improvement lifted travel conversions by 10.1% (web.dev — "Milliseconds make millions"), and the WPO Stats index collects many comparable results (Renault saw +13% conversions per one-second LCP improvement). For a small operator doing €500k in direct bookings per year, even a low-single-digit shift is a meaningful slice of annual revenue. (Speed is only half the conversion picture — the booking flow itself is the other half: mobile booking conversion benchmarks.)

That is the real number behind a Core Web Vitals "needs improvement" score.

Sources

The performance numbers and conversion impact ranges above are drawn from public web-performance research. For background on Core Web Vitals and travel-performance case studies:

• web.dev — Milliseconds make millions — the Deloitte/Google study quantifying mobile speed's effect on conversions across retail and travel.
• web.dev — Web Vitals — the canonical Core Web Vitals reference (LCP, INP, CLS).
• web.dev — Case studies — Google's published performance case studies, including travel sites.
• WPO Stats — community-curated index of web-performance case studies and research.