Luxury retailer Farfetch sees higher conversion rates for better Core Web Vitals

Most Core Web Vitals case studies tell you what a team fixed. This one, written up on web.dev by Manuel Garcia, Dikla Cohen, Patricia Couto Neto and Rui Santos, is more useful than that, because the interesting work happened before any code changed. Farfetch's problem was not that their pages were slow. It was that nobody outside engineering had any reason to care, so performance lost every prioritisation argument it entered.

The fix was to stop describing performance in milliseconds and start describing it in revenue. Everything else followed from that.

Step 1: make the data joinable

Farfetch already had a multi channel tracking system called Omnitracking, which recorded pageviews, user actions and system actions and fed a data model used for funnel and conversion analysis. The decisive move was to add performance data for each pageview into that same data layer.

Field measurements were captured in the browser using the web-vitals.js library, supplemented with custom JavaScript for Time to First Byte, First Contentful Paint, First Paint and Time to Interactive, collected through the Performance API, the Long Tasks API and Google's polyfills.

// the shape of the join that makes everything else possible
import {onLCP, onCLS, onINP} from "web-vitals";

function report({name, value, id}) {
  dataLayer.push({
    event: "web_vitals",
    metric_name: name,          // LCP | CLS | INP
    metric_value: Math.round(value),
    metric_id: id,
    session_id: analytics.getSessionId(),  // the critical field
    page_type: window.PAGE_TYPE            // pdp | plp | home
  });
}

onLCP(report); onCLS(report); onINP(report);

That session_id is the whole trick. Without it, your performance data sits in one tool and your revenue data in another, and no amount of dashboarding will let you regress one against the other. With it, the analytics team can ask whether the sessions that converted were measurably faster than the sessions that did not.

Farfetch also set time based performance budgets for each metric across the main journey pages, added a governance process for budget breaches, and began enforcing budgets in CI pipelines so regressions surface during development rather than in the field weeks later.

Step 2: what the correlation analysis found

Google recommends LCP stay below 2.5 seconds. Farfetch studied that threshold against their own data and found that beyond it, conversion rate starts to drop and exit rate rises.

Correlations derived from Farfetch's own field data joined to their Omnitracking conversion data. Treat the coefficients as directional evidence for building your own model, not as figures to quote for your site.

The fourth row deserves as much attention as the first three. The analysis also showed that some metrics had no significant impact on business KPIs, and that others mattered only at particular stages of the journey. Knowing which metrics do not pay is what stops a performance programme from becoming an infinite backlog.

One caveat the source itself raises: web.dev now cautions that measuring TTI in the field is no longer recommended, because user interaction introduces variance into the reading. Farfetch's TTI finding stands as reported, but anyone rebuilding this model today should substitute Interaction to Next Paint, which became a Core Web Vital in March 2024 and is designed for exactly this kind of field measurement.

Step 3: turn the coefficients into a self service tool

Rather than keep the model inside the analytics team, Farfetch built what they called the Site Speed Business Case Calculator, taking inspiration from Google's Speed Impact Calculator. Any product manager can use it to generate a business case for a performance improvement on the fly, adapted to different devices, product scopes and journey touchpoints.

They paired it with self service dashboards giving business wide visibility of real time performance indicators, and, because the performance data lives in the shared data layer, performance metrics also became available inside their A/B testing tooling. That last detail matters: it means any experiment can be checked for whether it accidentally regressed LCP.

Rui Santos, Farfetch's Web Channels Senior Principal Product Manager, is quoted in the case study on why this worked: "We wanted to break the cycle of performance being a tech-only concern, something owned only by the engineering team to deal with and fix. Connecting performance metrics with business metrics was surprisingly effective to pass the message across very, very quickly."

Step 4: the engineering work the business case paid for

The main opportunity identified in 2021 was LCP on the two page types that carry the revenue: product pages and product listing pages. The changes were unglamorous and entirely transferable:

1. Move the product image component off a JavaScript based loader
   and onto native browser markup.

2. Classify every image as critical or non critical.

3. Critical images: source already inline in the HTML, plus a preload.
            href="/product/hero-1000.avif"
         imagesrcset="hero-400.avif 400w, hero-1000.avif 1000w"
         imagesizes="(max-width: 999px) 100vw, 640px">

4. Non critical images: 
   with an IntersectionObserver polyfill for browsers such as
   Safari that did not support the attribute at the time.

Note what is absent: no framework migration, no CDN change, no rewrite. The single largest structural change was deleting a JavaScript image loader, which is the same lesson as the Shopify and Wikipedia case studies in this collection. JavaScript that stands between the browser and a resource it could have fetched from static markup is almost always a net loss.

Distribution figures read from the stacked bar charts in the source. Note that web.dev labels both charts as listing pages in their alt text, while the surrounding copy describes work on two page types, product pages and product listing pages. We have flagged that rather than resolve it.

How to replicate this without a data engineering team

You do not need Omnitracking. A minimum viable version of the Farfetch model takes a few days:

• Instrument. Add web-vitals.js and send LCP, CLS and INP to GA4 as custom events with the page type as a parameter. Google publish a reference implementation for this.
• Segment. In GA4 Explorations, build a comparison of sessions with good LCP against sessions with poor LCP, and put conversion rate and engagement rate side by side.
• Control for the obvious confounders. Slow sessions skew towards older devices, cheaper networks and different countries, all of which independently affect conversion. Segment by device category and country before you claim a causal number, or your model will simply rediscover that rich users buy more.
• Prove it with a test. Correlation funds the hypothesis; an A/B test on one template confirms it. Farfetch did exactly this, and their reported uplift range of 1% to 5% is stated with the confidence level attached, which is the honest way to report a result.

That last point separates a credible internal case from a discredited one. Anyone can produce a chart showing fast sessions convert better. The Farfetch programme survived scrutiny because the correlation was followed by a controlled test.

Where to start on your own site

Find out which templates fail in the field first, using our Core Web Vitals checker, then isolate whether the problem is load delay or render delay with the page speed analyzer. For the boardroom version of this argument, our Vodafone page speed case study is the shortest available proof that speed moves sales, and technical SEO versus content SEO covers how to weigh this work against everything else competing for the same sprint.

FAQ

Source: https://web.dev/farfetch/