Bookaway, a digital travel booking platform connecting travelers with transport providers across more than 30 countries, relies heavily on organic search traffic. The team set out to align their landing pages with Google's Core Web Vitals standards, a set of metrics that evaluate user experience through the lens of page performance. For a business whose profitability is tied to organic discovery, getting these metrics right is not optional.

The Three Core Web Vitals

Google's Core Web Vitals measure distinct aspects of the loading experience:

  • Largest Contentful Paint (LCP): The time it takes for the main content of a page to load.
  • First Input Delay (FID): The time it takes for a page to become interactive. Google plans to replace this with Interaction to Next Paint (INP) beginning in 2024.
  • Cumulative Layout Shift (CLS): A measure of a page's visual stability.

While FID and CLS were relatively simple to fix, LCP proved the most challenging. It is also the most critical metric for content-heavy landing pages, as a low LCP ensures visitors see primary content sooner, reducing bounce rates.

Breaking Down LCP

LCP represents the moment when the largest piece of content—an image, a text block, or a video—is fully rendered. Achieving a good score involves optimizing several stages, each with its own risks.

  • Time To First Byte (TTFB): Slow server responses due to overload or unoptimized logic lengthen this phase.
  • Download Time of HTML: Large files or slow connections delay the fetch.
  • HTML Processing: When the browser encounters a <script> or <style> tag without an async or deferred attribute, rendering halts while those resources are fetched and parsed.
  • Fetching And Decoding Images: The time to download and process image files is a common bottleneck for the largest contentful element.
  • First Contentful Paint (FCP): Render-blocking JavaScript or CSS and slow server responses hurt this initial paint.
  • Rendering the Largest Contentful Element: Complex design elements and large media can delay the final stage.

How Bookaway Monitors Performance

To identify and react to issues, the team built a data pipeline around their Next.js application. They use the reportWebVitals function to capture metrics for each page load in real time, forwarding them to a custom analytics service.

This data lands in BigQuery, Google Cloud’s serverless data warehouse. Alongside the Web Vitals values, they record page route, device type, and language settings. This allows them to analyze performance from specific contexts. For example, fetching LCP values for visits to three different route landing pages—Bangkok to Chiang Mai, Hvar to Split, and Bol, Brac Island to Split—shows how quickly key content appears for those specific users.

They visualize this data in Google's Looker Studio, which connects directly to BigQuery. The tool's intuitive interface and customizable reports let the team filter data by page groups, such as their "Route Landing Page" group, which draws over one million visits per week. They track LCP for the 75th percentile of users on these pages and can segment results by mobile versus desktop traffic to see where optimizations matter most.

What the Performance Data Revealed

Bookaway’s performance metrics pointed to two distinct challenges tied to its role as a global transportation booking platform. The first was the inherent diversity of its audience. Users in different regions connect under very different network conditions and with different device capabilities. The second was seasonality: traffic surged from warmer destinations like Thailand and Vietnam during winter months, while European users dominated during the northern summer. These geographic shifts in the user base correlated with measurable variations in performance, making it clear that a one-size-fits-all approach to content delivery was insufficient.

The second challenge was rooted in the site’s architecture. Bookaway relied on dynamic content serving, where every request triggered database lookups and page rendering on the back end. That server-side work inflated Time to First Byte (TTFB) — the delay between a user's request and the arrival of the first byte of data. Dynamic serving is simple to implement, but it is costly in both computational resources and network latency, particularly for users far from the origin servers.

Pre-generated HTML, as used in a Jamstack-style approach, offered a clear alternative. Serving static files eliminates on-the-fly rendering, reducing TTFB and opening the door to more aggressive caching. The anticipated result was better Largest Contentful Paint (LCP) scores and a more consistent experience across all regions and seasons. A Content Delivery Network (CDN) was seen as the key to unlocking those benefits.

The CDN Strategy

A CDN is a network of edge servers distributed in data centers worldwide. These servers cache copies of content — HTML, JavaScript, images — and deliver them based on the user’s geographic location. When a request is made, DNS routes it to the nearest edge server, reducing the physical distance data must travel and cutting latency. For a site that already hosted its infrastructure on Amazon Web Services, Amazon CloudFront was the logical choice. Its global edge network and scalability made it a natural fit.

Configuring CloudFront involved setting a max-age value to control how long a cached page remains fresh. Bookaway set this to three days. During that window, visitors received the cached HTML directly from the nearest edge location, bypassing the origin server entirely. Once the period expired, the next request would trigger the CDN to fetch a fresh copy from the origin — a slower experience for the user making that request.

This setup performed well for popular pages. The problems started with the long tail. Bookaway operates over 100,000 landing pages in seven languages, roughly 700,000 URLs in total. Many of these pages are visited only occasionally. With a three-day freshness window, these pages frequently expired out of the cache before anyone requested them. The next visitor would then face the full latency of an origin fetch.

The solution was the stale-while-revalidate strategy. Under this approach, the CDN serves the expired (stale) copy of a page to the visitor immediately, while it checks the origin server for a newer version in the background. If a fresh version exists, the cache is updated. This eliminated the latency penalty for long-tail pages, ensuring a fast experience no matter how rarely a page was consulted.

Measured Gains

The impact of these changes was immediate and quantifiable. The CDN rollout alone cut LCP from 3.5 seconds to 2 seconds. Adding stale-while-revalidate brought it down further to 1.7 seconds.

TTFB showed an even more dramatic improvement. With static content served from edge locations, the time from request to first byte dropped from 2 seconds to 1.24 seconds. This was the result of eliminating back-end processing for each request and reducing network distance through CloudFront’s global footprint. TTFB is a critical factor in the overall LCP calculation, and this reduction was a primary driver of the speed gains. Overall, the stale-while-revalidate strategy contributed an additional 15% improvement in LCP at the 75th percentile.

Validating the Improvements

Beyond internal metrics, the changes were reflected in Google Search Console’s “Page Experience” report, which tracks load times, interactivity, content stability, mobile usability, and security. The data from that report confirmed the site’s improved performance after the implementation.

Practical Lessons from the Project

The experience at Bookaway offers several takeaways that apply beyond this specific case. Performance optimization starts with a detailed look at each stage of the loading and rendering process — from TTFB and HTML download speed to image decoding, JavaScript and CSS parsing, and the rendering of the largest contentful element. Each step presents opportunities for delay that need to be addressed.

Monitoring is equally important. Real-time tools like Next.js can provide ongoing visibility, while storing data in BigQuery and visualizing it with Looker Studio enables data-driven decisions. Finally, the architectural shift matters. Moving from dynamic rendering to static content delivery, supported by a CDN, can dramatically reduce TTFB and improve loading times by serving pre-built pages from locations close to the user. The specific priorities will differ from project to project — LCP was the critical metric here — but the underlying principles of measuring, monitoring, and rethinking content delivery apply broadly.