Bundling performance work into a redesign

Storefront performance problems divide cleanly, and the division is the whole argument. One half is markup-shaped: how the hero image is delivered and sized, how many fonts load and how they swap, whether the above-the-fold content waits on JavaScript, whether elements reserve their space before they paint, how much is rendered that nobody scrolls to. These are decisions made when a template is built, and changing them later means rewriting the template.

The other half is stack-shaped: apps injecting scripts, tag managers loading vendors, review widgets, chat, personalisation, consent tooling, analytics loaded three times by three different teams. None of these are design decisions. A redesign moves them from the old theme to the new one, usually with a spreadsheet and a request to "make sure nothing breaks", and they arrive in the new store weighing exactly what they weighed in the old one.

Once you have seen that division, the answer to "should performance be part of the redesign?" stops being a yes or a no. The markup half belongs in the redesign, because the redesign is rewriting the markup anyway and doing it well costs almost nothing extra. The stack half is a separate piece of work with a separate list of stakeholders, and pretending it is part of the design project is how it gets deferred.

The structural mistake is scheduling performance as a stage — design, build, then optimise. By the time you reach the third stage the budget is spent, the launch date is fixed, and "optimise" becomes a list of things that did not get done.

The version that works puts the numbers in the brief. Google documents the Core Web Vitals thresholds precisely: LCP within 2.5 seconds, INP of 200 milliseconds or less, CLS of 0.1 or less, assessed at the 75th percentile of page loads and segmented across mobile and desktop. Those are not aspirations to revisit later; they are the definition of done for a template, alongside "it matches the design" and "it works on a phone".

Written that way, performance starts influencing decisions at the point where influencing them is free. A hero video, a full-bleed carousel, four font weights, an above-the-fold section that needs a product recommendation API call — each of these is a conversation worth having at design review, when the cost is a different design, rather than at launch, when the cost is a rebuild.

It also gives the build team somewhere to stand. "We cannot ship this" is a hard thing to say to a design that has been approved. "This template does not meet the acceptance criteria we agreed in the brief" is a normal project conversation.

Running a speed project just before a redesign is the more common and the more wasteful error. A team spends six weeks restructuring the product template, deferring scripts, rewriting image markup and fixing layout shift, and then nine months later that template is replaced by a new one built by different people who did not inherit any of those decisions. The app work survives. Almost none of the template work does.

If a redesign is genuinely committed and within a year, the honest advice is to do the app audit, fix image delivery at the source, and leave the templates alone until the rebuild — then hold the rebuild to a budget. That is a smaller invoice than the speed project, and we would rather say so.

Waiting for a redesign to fix performance is the opposite error and it is just as expensive, because it usually means waiting for a redesign that has no date. A store that is eighteen months from a rebuild and slow today is losing eighteen months of revenue to an event that may not happen. There is no reason to hold an app audit hostage to a design project.

The discriminator is simply whether the rebuild has a funded date. If it does, sequence around it. If it does not, stop treating it as a reason to wait.

There is a real price to putting both changes in one launch, and it is worth naming because nobody mentions it in the proposal.

When a redesign and a performance programme land together, the conversion rate moves, and nobody can say why. The design might have earned it. The two seconds might have earned it. The two might have cancelled each other out, with a better-converting design offset by a heavier page, or a faster page carrying a worse layout. You will have one number and two explanations, and the argument about which one to fund next time is unwinnable.

This matters most where the redesign is commercially contentious — where somebody was against it, or where the next phase depends on proving it worked. If that describes your situation, split the launches: ship the performance work to the existing theme, let it sit for a few weeks, then ship the design. You lose some efficiency and you buy a clean measurement.

If the redesign is uncontroversial and the brief is simply "make the site good", bundle it and do not spend money on attribution nobody will act on.

Two practical things to expect, both of which cause unnecessary panic in the fortnight after a launch.

Lab scores and field data are different instruments. A synthetic test on a fast connection tells you whether the template is well built. Field data tells you what real users on real devices experienced, and it is collected over a trailing window, so it does not move on launch day. A perfect lab score on Monday and unchanged field metrics on Friday is not a contradiction; it is the measurement working as designed. Plan the reporting conversation around that before the launch rather than after it.

Take a baseline first, at template level. Not a single site-wide number — home, collection, product and cart separately, on mobile, before anything changes. A redesign that improves the product template and regresses the collection template will average out to "no change", which is the least useful finding available and the most common one reported.

Then re-measure the same four templates the same way. If a template regressed, you want to know while the build team still remembers the code.

A redesign is not a performance strategy and performance is not a reason to redesign. We have turned down speed work on stores that were about to be rebuilt, because the honest answer was to spend the money on the rebuild brief instead. We have also told clients to stop waiting for a rebuild that had been eighteen months away for three years and just do the app audit.

The practical shape, if you are about to commission a redesign: put the Core Web Vitals thresholds in the brief as acceptance criteria per template, run the app audit as separate work before the build starts so the new theme does not inherit a stack nobody has questioned, baseline your four key templates on mobile, and agree in advance who is allowed to reject a design for being too expensive to render. That last one sounds like a formality. It is the only part of this that requires anyone to change their behaviour.

• Shopify speed optimisation
• The app audit
• Theme migration without a redesign