Core Web Vitals for a Global Tourism Site

A national tourism organisation relies on its website to inspire travellers in more than 20 international markets. Most of those visitors arrive on their phones, often from a Google search, so how quickly and smoothly the site loads directly affects both their first impression and where the site appears in search results.

Our job was to make the site noticeably faster and more stable without changing how it looked or worked.

On mobile, visitors were left waiting for the page to appear, and once it did, the content shifted around as it finished loading. Google measures exactly this (in what it calls Core Web Vitals), and the site was falling short.

• Slow to appear: the main image took up to 4 seconds to show.

• Unstable while loading: content jumped about 15 times more than Google's limit.

• The cause: the site waited for all its code to load before showing anything, and downloaded far more than it needed.

Rather than redesigning anything, we changed the order and amount of work the site does as it loads. We put what visitors see first ahead of everything else, and removed anything that wasn't needed.

• Show the important part first: the main image and heading now appear straight away.

• Stop the jumping: space for images and banners is reserved in advance, so nothing moves.

• Download less: images are sized to the screen, and repeat visits no longer download the same files twice.

• Measure what Google measures: we tracked real-visitor data, not just test scores.

The difference is visible to every visitor. Pages appear in about half the time and stay still while they load, and the site now meets Google's standards where it matters most.

• About twice as fast: mobile homepages now show their main image in 1.6–2.1 seconds, down from up to 4.

• Pages hold still: layout jumping fell by over 99%.

• Every market homepage now passes Google's mobile thresholds for speed and stability.

• Clear next step: third-party marketing scripts are now the main thing slowing how quickly pages respond to taps, and we gave the client a plan to fix that.

Speed work is as much about knowing where to look as about the fixes themselves. A few lessons from this project now shape how I approach every performance job:

• Real users matter more than test scores. Real-visitor data caught issues the lab tests missed.

• Fast and stable have to go together. A page that appears sooner but then jumps around isn't a better experience.

• The biggest slowdown isn't always your own code. Once ours was lean, third-party scripts were the main remaining cost.