01 — Why it mattered
Mid-tier Android users in the UK were the majority of traffic — and the slowest path through the funnel.
A fast, mobile-optimised flight search site for UK customers, wired to live GDS fares.
02 — Problem
Search results took longer than the customer's patience. Filters re-rendered the world. Ad spend was leaking on bounces.
03 — Approach
Rebuilt the results page with a virtualised list, debounced filters, and a payload trimmed to what the device needs. Treated the slow Android as the design target, not the desktop.
04 — Build
Five weeks alongside the existing team. Most of the work was profiling, not coding.
05 — Outcome
The request graph came down to 25 — the tightest of any booking site here — and LCP lands at 820ms with layout shift at 0.004. Full load still takes 3.2s, and the reason is unambiguous: 9.8MB of images against 449KB of JavaScript. The rendering path was fixed. The asset pipeline was never mine to fix.
06 — Reflection
Performance is a feature. You ship it on purpose, with a budget and a graph that the team agrees to defend. Without the budget, the wins get spent.