Make it feel instant on a phone.

Fast enough that the main element renders inside 2.5 seconds and taps answer inside 200 milliseconds for three quarters of your real visitors — that is what Google's thresholds describe, and the 75th percentile matters because averages hide the worst experiences. The commercial answer is more interesting than the threshold, though. Deloitte Digital and Google measured an 8.4% retail conversion lift from a single 0.1 second improvement, which means there is no point at which further gains stop paying. We aim at the threshold first because it is a floor, then keep going where the revenue maths justifies it.

Because a lab tool measures one simulated device on one simulated network and your visitors are not that device. Real-user records aggregate every visit across old phones, patchy cellular connections, cold caches and geographies far from your origin. A page can score in the nineties in a lab and fail its real-user metrics because a personalisation script blocks rendering for the logged-in half of the audience, or because the hero element is discovered late on a cold cache. We use both: field data to decide what to fix and in what order, lab traces to work out exactly why.

In our experience, three things in rotation: the hero element, the fonts and the vendor tags. Pictures are the most common because they are the largest element on the page and the easiest to get wrong — the wrong format, no dimensions, or lazily fetched by a global rule. The Web Almanac found roughly 16% of pages lazy-load the very element that defines their LCP, which is a one-attribute fix worth whole seconds. After that it is usually the origin: no amount of front-end craft rescues a server that thinks for a second before replying.

It helps, and it is worth being precise about how much. Page experience is a real but modest ranking input: it rarely outranks better content, and it frequently decides between pages of similar quality. The larger effect is behavioural — more visitors reach the page, fewer leave before it renders, more pages get crawled per session because the crawler is not waiting either. We treat search gains as a welcome consequence and judge the work on conversion and enquiry volume, which is the number your board actually asks about. Where ranking is the goal we pair this with SEO rather than pretending speed alone does it.

Almost always, yes, and that is usually the brief. The great majority of the work is in the order things arrive, not the way they look: which assets the browser discovers first, which scripts block the main thread, how the origin caches, what the CDN serves. Visitors see the same layout arriving sooner. Where the design itself is the constraint — a hero video, a carousel that loads five variants, a font family with nine weights — we say so, quantify the cost in milliseconds and let you decide, rather than quietly changing your brand to win a metric.

We split them into three groups. Ones nobody uses get removed with sign-off, which is more of them than teams expect. Ones that matter but not immediately get deferred, consent-gated or loaded on interaction, so they no longer compete with the first paint. The rest — consent tooling, some payment and fraud scripts — are genuinely required early, so we move what we can server-side through tag management and budget the remainder honestly. Every tag keeps a documented owner and a cost, which is what stops the collection growing again.

Sometimes, and we will tell you when. Optimisation wins when the platform is sound and the problem is discipline: media, caching, tags, render order. A rebuild is the honest answer when the stack fights you at every turn — a theme with fifteen plugins layered on it, a page builder emitting megabytes of markup, an origin that cannot cache because everything is personalised. In that case we scope it as a redesign or a custom build with the metric baked into the brief, and we still start with the audit so the decision has numbers behind it.

With budgets and alerts rather than good intentions. Each template gets a written allowance in kilobytes and milliseconds; the pipeline checks it on every build; a regression triggers an alert to a named owner instead of being discovered next quarter. Editors get an asset pipeline that resizes and converts uploads automatically, because a 5MB hero uploaded in a hurry is the most common regression there is. New vendor scripts have to pass a written rule. That governance is deliberately boring, and it is the difference between a project and a durable standard.

The first engagement is a fixed-price audit and quick-win phase, so you approve a number rather than an open retainer: field measurement, traces, a ranked plan with an estimate in milliseconds per item, then the fixes that ship without a refactor. Deeper engineering is scoped from that plan, priced per phase, and sequenced so the highest revenue-per-hour items go first. Ongoing monitoring is a small monthly fee. We do not price this against media spend, and we will happily tell you when the remaining wins are too small to bill for.

Yes, and it is often the fastest arrangement. We tend to own the measurement, the diagnosis and the plan, then either implement inside your repository against your review process or hand your team specified tickets with acceptance criteria in milliseconds. Everything is documented and version-controlled, and we run a weekly session with the engineers doing the work so knowledge transfers as we go. Where there is no in-house engineering capacity, we do the whole job and train whoever will inherit it.