iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Web client quality tends to slip when it is treated as an engineering matter alone. Pages can pass lab checks while real customers wait for content, tap controls that respond late, or abandon a checkout, and the cost never reaches the people who set priorities. Two Google-published case studies, one on Farfetch and one on T-Mobile, show a workable alternative: measure what users actually experience, connect those measurements to business outcomes, and share ownership across product, engineering, and the business.
The broader claim in the title, that major companies neglect web client quality, is a plausible hypothesis, but these sources do not prove it. The two case studies describe recognized performance problems and organized improvement work at two companies. They do not show how common neglect is across large organizations. Treat the strategies below as documented practice in those two cases, and test them against your own users.
Why client quality slips
The two cases point to three recurring patterns. Each is worth checking against your own organization.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match- Lab scores stand in for user experience. A passing lab run says little about a customer on an older phone or a congested mobile network.
- Performance numbers never reach business reviews. When speed is reported only as a technical score, it competes poorly with features that carry visible revenue targets.
- Ownership sits with one team. When frontend engineers hold the metric, no product owner is accountable for how fast a journey feels to a customer.
Measure the experience users actually have
Core Web Vitals are a compact starting point, not a full definition of product quality. Google’s Web Vitals guidance states that “Optimizing for quality of user experience is key to the long-term success of any site on the web,” and the initiative aims to simplify a crowded set of performance measures around the ones Google considers most important. The table below lists the metrics that matter for this topic. Confirm thresholds against the current guidance before setting targets, because definitions and thresholds change.
#1 Best Overall
- HTML CSS Design and Build Web Sites
- Comes with secure packaging
- It can be a gift option
| Metric | What it measures | “Good” threshold (75th percentile of page loads) | Notes |
|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading: when the largest visible content renders | 2.5 seconds or less | Cited as the good-experience threshold in the Farfetch case study |
| Interaction to Next Paint (INP) | Responsiveness to user input | 200 milliseconds or less | Replaced First Input Delay as a Core Web Vital in March 2024 |
| Cumulative Layout Shift (CLS) | Visual stability: unexpected layout movement | 0.1 or less | Core Web Vital |
| Time to Interactive (TTI) | When a page is reliably interactive | Not a Core Web Vital | The Farfetch case study notes it is no longer recommended for field measurement, because user interaction can affect the result |
Lab data for debugging, field data for reality
Lab runs such as Lighthouse use fixed device and network settings. That makes them repeatable and useful for finding the cause of a regression. Field data reflects the mix of devices, networks, locations, and behavior your customers actually have. Field results for many public sites are available through the Chrome UX Report, which tools such as PageSpeed Insights draw on, but those aggregates cannot show your own checkout steps. T-Mobile reported that Lighthouse and Chrome UX Report data offered only a partial picture, and it added direct field measurement with the web-vitals JavaScript library.
Instrument real users with web-vitals
A minimal setup sends each metric to your own analytics endpoint. The path below is an example.
import { onCLS, onINP, onLCP } from 'web-vitals';
function sendToAnalytics(metric) {
const body = JSON.stringify({
name: metric.name,
value: metric.value,
rating: metric.rating,
page: location.pathname
});
navigator.sendBeacon('/analytics/web-vitals', body);
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);Replace location.pathname with your own page-group or journey-step label if you want results segmented by template or funnel step.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When lab and field results disagree
- Field is worse than lab: compare the device and connection mix in your field data with the settings your lab runs use, then rerun the lab test under those conditions.
- Pages load quickly but feel slow: look at INP and the event handlers behind it. Load metrics alone will not show a slow tap or a laggy filter.
- One page group is worse: segment by template, country, and signed-in state before changing shared code.
Connect the experience to outcomes
A metric changes decisions only when it is tied to what a user was trying to do. Choose the journeys that carry business weight, such as landing, search, product detail, checkout, account access, and support. For each one, compare performance with task completion, errors, complaints, abandonment, and conversion. Start with correlations, and use controlled experiments before claiming that speed caused a change.
Rank #3
Farfetch: statistics first, then A/B tests
Farfetch joined performance events to session and conversion data and used statistical analysis to find where to act. It then A/B tested changes to how product images load, and it built a business case calculator and dashboards. Rui Santos, Farfetch’s Web Channels Senior Principal Product Manager, described the effect this way: “Connecting performance metrics with business metrics was surprisingly effective to pass the message across very, very quickly.”
T-Mobile: putting revenue against LCP intervals
T-Mobile estimated the revenue impact across LCP intervals to win leadership attention. Each result below is the case study’s own figure for that company’s site when it was published, so the Farfetch numbers reflect its 2022 case study and the T-Mobile numbers its March 2025 case study.
Rank #4
- Brand: Wiley
- Set of 2 Volumes
- A handy two-book set that uniquely combines related technologies Highly visual format and accessible language makes these books highly effective learning tools Perfect for beginning web designers and front-end developers
| Company and metric | Reported result | Conditions and caveats |
|---|---|---|
| Farfetch: conversion rate | 1.3% average decrease for each additional 100 ms of LCP above the threshold cited | A statistical association in Farfetch’s own data |
| Farfetch: exit rate | 3.1% decrease for each 0.01 reduction in CLS | A statistical association reported in Farfetch’s analysis |
| Farfetch: conversion rate | 2.8% increase for each one-second reduction in TTI | TTI is no longer recommended for field measurement, because user interaction can affect it |
| Farfetch: product-page loading and conversion | More than 600 milliseconds shaved from loading; conversion uplift of 1–5% | The uplift was A/B tested, and the range is reported at the company’s defined confidence level |
| T-Mobile: overall LCP | 42% decrease | Reported as the outcome of its performance work |
| T-Mobile: overall website complaints | 20% reduction | Reported in the same case study |
| T-Mobile: complaints about slow loading | 34% reduction | Reported in the same case study |
| T-Mobile: prospect visit-with-shopping-intent to order rate | 60% improvement over the same period | Associated with a more efficient purchase flow; the case study does not present it as a universal effect of speed |
Build ownership across functions
Ownership is where many programs succeed or stall. Farfetch framed its goal this way:
“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.”
Rui Santos said this in the Farfetch case study. Its core team included engineering, infrastructure, architecture, and product. T-Mobile described similar cross-functional work, with SEO and Product teams involved alongside engineering.
Farfetch: budgets, breach governance, and CI checks
- Time-based performance budgets set by metric and by journey page.
- A defined process for handling budget breaches.
- Checks in the CI pipeline that catch regressions before release.
T-Mobile: shared dashboards, alerts, and release requirements
- Shared dashboards and a performance wiki that teams can use as a common reference.
- Alerts by page group, so the owners of each area see their own regressions.
- Education sessions for cross-functional teams.
- Lighthouse requirements that work must meet before launch.
Prioritize fixes by user impact and risk
Choose fixes from field evidence and from the journeys where users drop off, not from a generic checklist. The two cases document these options:
- API work: caching and refactoring APIs, and reducing API errors (T-Mobile).
- Caching: CDN caching and static asset caching.
- Images: smaller modern formats, responsive images, and lazy-loading of non-critical images. Farfetch moved product images to a native loading implementation, prioritized critical images, and lazy-loaded the rest.
- Load order: prioritizing critical content, preloading critical resources, preconnecting to important domains, and reducing payloads.
- Frontend structure: migrating frontend components (T-Mobile).
Test each change on the actual page, across the browsers your users run, and check functional behavior. A faster page that breaks a filter, a form, or a keyboard path is a regression, not a gain.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Compare options on six criteria
When two approaches compete, score them on the following points. This is editorial guidance for structuring a comparison, not a benchmarked ranking.
- Real-user outcomes on the critical journey: speed, stability, responsiveness, and task completion.
- Evidence quality: field data, lab repeatability, and controlled experiments.
- Functional correctness and error rates.
- Accessibility and compatibility across users and devices.
- Implementation cost, operational complexity, and maintainability.
- Whether teams can monitor regressions continuously.
Treat accessibility as its own quality dimension
Accessibility is part of a usable web client and should be assessed separately from speed. The WCAG 2.2 Recommendation is the reference standard. The two case studies do not report accessibility outcomes, and a performance gain does not show that a page conforms to WCAG. When you change images or scripts, check at least these criteria:
Quick Recap
- 1.1.1 Non-text Content: responsive and lazy-loaded images still have appropriate text alternatives.
- 2.1.1 Keyboard: components injected or re-rendered by scripts remain operable from the keyboard.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
