Conversion Rate Optimization
Speed and conversion
This is the narrowest useful unit of Conversion Rate Optimization: treat performance as a conversion problem, which is where its value is easiest to show.
What is meant by speed and conversion?
Treat performance as a conversion problem, which is where its value is easiest to show. In practice that means measuring speed on the pages that carry revenue, in field data, and then the harder half: correlating performance with conversion rate by segment and device.
Why this work exists
It rarely appears in a post-mortem, and it is often the answer.
It belongs to Conversion Rate Optimization and is described here because it is the piece clients recognise and ask for.
The nearest piece of work to it is making the mobile tap targets survive a thumb rather than a mouse. Where that is already handled, this moves faster than the estimate; where it is not, the two get done together or neither of them holds.
What good looks like
Working well means the decisions downstream get made faster, because the argument about what is true has already been had.
The gap between that and where most accounts start is why this is scoped as speed and conversion rather than as a line inside something larger. Finding what the best salesperson says and putting it on the page is the usual second step once it is in place.
When this is the right work
The diagnostic signs:
- Speed work is discussed as a technical score with no business case
- The checkout is the slowest part of the site
- Mobile conversion is a fraction of desktop and nobody has looked at load time
If none of those is true, something else is probably the constraint, and the Conversion Rate Optimization overview maps the alternatives. The usual neighbours are running a test long enough to cover a full weekly cycle and knowing when the honest answer is that the offer needs changing, not the button.
What the work covers
The scope, stated plainly:
- Measuring speed on the pages that carry revenue, in field data, scoped against what the business can actually act on rather than what is possible.
- Correlating performance with conversion rate by segment and device. Skipped more often than any other part of this, and regretted more often too.
- Prioritising the fixes by revenue impact rather than by lab score gain, done before anything downstream is committed to.
- Verifying the conversion effect after each change rather than assuming it. Usually scoped at half the size it turns out to be.
How it runs
It runs in three passes. The order is not interchangeable.
The second look
A fortnight after the first pass, the same ground gets covered again with fresh eyes. The second pass finds a different class of problem from the first.
Bringing in whoever owns the system
Developers, agency partners or whoever actually controls the platform get involved before recommendations are written, not after they are rejected.
Proving it in one place first
Changes get made to a small, representative slice and measured there before being applied everywhere. It is slower for three weeks and faster for the rest of the year.
What each part runs into
Each piece has its own friction:
- Measuring speed on the pages that carry revenue, in field data, which in Singapore runs into a language mix the content has to match rather than assume
- Correlating performance with conversion rate by segment and device: the Delhi NCR version of this has to deal with an enquiry path that runs through a messaging app rather than a form
- Prioritising the fixes by revenue impact rather than by lab score gain, where a Bengaluru engagement contends with a catchment smaller than the ambition on the website
- Verifying the conversion effect after each change rather than assuming it – working in Surat this means accounting for an incumbent whose position comes from presence rather than effort
The avoidable version of this
Chasing a perfect lab score on the homepage while the checkout stays slow. The revenue is downstream.
The damage is less in the wasted work than in the conclusion it leads to.
How it is measured
Field performance and conversion rate on the revenue path, by device. Agreed up front and reported every period, with the raw data available rather than only a summary.
Where the figure is estimated rather than counted, it says so on the report.
What you end up with
The thing you are left holding is Performance improvements on the revenue-carrying pages, with the conversion effect measured.
Given with the raw working attached, so the conclusion can be re-derived.
How it differs by sector
What this becomes in practice depends on who it is for:
- Automotive: Local inventory, model-level demand, and a buyer who arrives having already decided. so this work has to account for that before anything else.
- Healthcare and clinics, where content that affects health decisions is held to a higher standard, and advertising is restricted. which moves this work earlier in the plan.
- In Manufacturing and industrial the binding constraint is that low volume, high value, and a specification sheet that decides the deal.
The industry pages carry the rest of that detail. Automotive and Healthcare and clinics are the two where this piece of work most often decides the outcome.
Common questions
How much does page speed affect conversion?
Enough to matter and not by a universal ratio, whatever the frequently-quoted figures suggest. The effect depends on the baseline, the audience’s devices and connections, and how much the page asks of the user. The way to know for your site is to measure the conversion rate by load-time bucket, which usually shows the relationship clearly.
Which pages should be optimised first?
The ones on the revenue path, starting with the slowest. A fast homepage and a slow checkout is a common and expensive pattern, because the homepage visitor has no commitment yet and the checkout visitor was about to buy.
Is there a minimum worth doing?
There is a point below which the measurement cannot detect a change, and we would rather say so than take the work. Field performance and conversion rate on the revenue path, by device has to be able to move for the engagement to mean anything.
Does this have to be bought separately from Conversion Rate Optimization?
No. It is usually part of a wider Conversion Rate Optimization engagement, and it is described separately because it is the piece clients most often ask about by name. It can also be scoped on its own where that is genuinely what is needed, and we will say which applies after looking. If the brief is still open, Faceted navigation control and Marketplace optimisation are the two that change it most often.
What is a realistic timeline?
Two to three weeks to establish what is true, then a phase sized to the finding. Quoting the whole thing before the diagnosis would be guessing, and the guess is usually wrong in the expensive direction. New York has the worked example. Noida has the version that went wrong.
Ask about speed and conversion
A sentence about the problem beats a filled-in form. We read every one of these ourselves.
Start with an honest read on the gaps
Give us the context and we will give you the order of work, including the parts you can do yourself.