The canonical literature on web performance is, for the most part, written from the perspective of the engineering teams at the largest commerce platforms — teams operating with substantial caching infrastructure, with bespoke hosting environments, with engineering headcount that permits the optimisation of individual interventions to a level of sophistication that is, in the great majority of UK retail commerce, neither achievable nor commercially defensible. The literature’s recommendations are, considered abstractly, sound; the recommendations are also, in their typical formulation, calibrated to operating conditions that the great majority of retailers do not have access to, and the recommendations therefore fail to translate cleanly to the operational reality that the great majority of retailers face.
Easy Performance is the toolkit I have built, over the course of approximately three years of consulting on retail performance engagements, to consolidate the interventions that consistently produce measurable improvement on the hosting and tooling environments that UK retailers actually operate. The toolkit is not, in any sense, a competitor to the more sophisticated performance platforms; it is a deployable package of the interventions that the more sophisticated platforms typically present as advanced features, calibrated to the constraints under which most retailers are working. This post is an account of what the toolkit does, the constraints it is calibrated to, and the conversion data that justifies its inclusion in the procurement conversations I have with new clients.
The constraints that the toolkit is calibrated to
The hosting environment for the typical mid-market UK retailer in 2026 is, in my observation, substantially more constrained than the canonical performance literature assumes. The hosting is, in the great majority of cases, on a shared platform — Shopify, WooCommerce on managed WordPress hosting, BigCommerce, or one of the smaller platform competitors — with limited control over the underlying server configuration. The CDN is, in many cases, the platform’s default rather than a chosen configuration; the caching layer is similarly opaque. The development team responsible for the site is, in the great majority of cases, an external agency rather than an in-house engineering team; the agency’s engagement model is project-based rather than continuous, with the implication that performance optimisations must be implementable within discrete project windows rather than continuously refined over long horizons.
These constraints are not, individually, decisive obstacles to performance work; they are, however, decisive obstacles to the specific performance work that the canonical literature recommends. An intervention that requires custom CDN configuration is unavailable to a retailer whose CDN is the platform’s default; an intervention that depends on continuous tuning by an in-house engineering team is unavailable to a retailer whose engineering work is bought in chunks. The toolkit’s design is, accordingly, biased towards interventions that can be implemented through the configuration surfaces that retailers actually have access to and which produce sustained improvement once implemented rather than requiring continuous attention.
The interventions, in operational terms
The toolkit consolidates approximately fifteen distinct interventions into a single deployable package. The interventions are organised into three groups by the type of constraint they address.
The first group concerns the document head and the rendering-blocking resources that the head conventionally contains. The interventions in this group include the deferral of non-critical JavaScript via the defer attribute; the preconnect declarations for third-party origins that the document references; the explicit width and height attributes on every image to prevent layout shift; the lazy-loading attribute on every below-the-fold image; and the explicit fetchpriority hints on the hero image to bias the browser’s resource scheduler appropriately. None of these interventions is, individually, novel; the toolkit’s contribution is to apply them all consistently across every page of the site, which the manual application by a project-based agency frequently fails to achieve.
The second group concerns the third-party scripts and tags that the marketing team has accumulated on the site over time. The toolkit includes a tag-audit dashboard that surfaces, for each third-party script on the site, the script’s loading pattern, its impact on the Core Web Vitals scores, and the proportion of pageviews on which the script appears to produce a meaningful business outcome. The dashboard is not, in itself, a removal mechanism; the recommendation that follows from the dashboard is the responsibility of the retailer’s marketing team, who are typically the only stakeholders with the authority to remove a tag whose business owner is internal. The dashboard’s value is in surfacing the data that supports the conversation, which the retailer’s marketing team is, in my experience, frequently unaware of.
The third group concerns the database queries and template renderings that determine the server-side response time. The toolkit includes a query-audit module that, on managed WordPress and WooCommerce installations, surfaces the slowest queries on each request and identifies the specific plugins or theme code responsible for them. The audit produces, in essentially every deployment I have run it on, a small number of identifiable interventions that produce measurable response-time improvement — typically the removal of an unused plugin, the addition of a missing database index, or the replacement of an N+1 query pattern with a single batched query.
The conversion data and what it implies
The toolkit’s deployments have, on the conversion data I have collected, produced consistently measurable improvements in conversion rate. The magnitude of the improvement varies by deployment, with the principal predictor being the starting point: sites that had received no previous performance work typically showed conversion uplifts in the range of seven to twelve per cent following the toolkit’s deployment, while sites that had received some previous performance work typically showed uplifts in the range of two to five per cent. The mechanism is the well-documented relationship between page-load time and conversion rate, which on retail sites is approximately monotonic across the range of load times the toolkit affects.
The conversion uplift is, considered against the implementation cost of the toolkit, substantially greater than the cost in essentially every deployment. The cost is recovered, on the data I have available, within between two and six weeks of the deployment for the majority of retailers; for retailers with substantial traffic and significant previous neglect of the performance work, the cost is recovered within days. The procurement conversation, accordingly, is one of the more straightforward I have with new clients; the data is clear and the recovery period is short.
What the toolkit does not address
Two categories of performance work are deliberately outside the toolkit’s scope.
The first is the architectural performance work that requires substantial engineering investment to implement. The conversion of client-rendered listings to server-rendered listings, the construction of a custom CDN configuration, the introduction of an edge-cached personalisation layer — all of these are interventions that produce measurable improvement but which the toolkit does not provide, on the grounds that the implementation work is sufficiently substantial that it is more appropriately scoped as a bespoke engagement rather than as a packaged toolkit. (For a more detailed account of the architectural performance work and when it is worth the engineering investment, see A Core Web Vitals diary.)
The second is the application-specific performance work that requires bespoke understanding of the retailer’s specific commercial logic. A site whose performance bottleneck is in the calculation of personalised pricing, or in the rendering of a complex configurator, or in the integration with a slow third-party inventory system, has a performance problem that the toolkit’s general-purpose interventions cannot meaningfully address. The toolkit will identify that the bottleneck exists; it will not, in its current form, provide the specific intervention that would resolve it.
The annual review pattern
The toolkit’s deployment is, in operational terms, a single point-in-time intervention; the performance benefits it produces are real but are subject to gradual erosion as the site evolves. The marketing team adds new tags; the development team adds new plugins; the design team introduces new third-party widgets. The cumulative effect, over twelve months, is to recover approximately a third of the performance debt that the toolkit’s deployment had cleared, and the toolkit’s audit dashboards therefore include explicit mechanisms for surfacing this drift over time.
The recommendation that has emerged from the deployments is that the toolkit’s audits be re-run annually, with the recommendations from the audit acted upon as part of the retailer’s ongoing maintenance budget rather than as a discrete project. The annual cadence is, in my observation, the cadence at which the performance debt is identifiable but not yet decisive; quarterly reviews are unnecessarily frequent, and biennial reviews are insufficient to prevent the debt from accumulating to the point where the conversion impact is significant. The retailers who have adopted the annual-review pattern have, on the conversion data, sustained the performance benefits over multi-year horizons; the retailers who have treated the toolkit’s deployment as a one-off have observed the benefits gradually erode.
An advisory close
The performance work that produces measurable improvement on UK retail sites is, in 2026, a smaller and more focused set of interventions than the canonical literature implies, and is calibrated to a more constrained operating environment than the literature assumes. The retailer’s first task is to identify the interventions that are achievable within the operational constraints the retailer actually faces; the toolkit consolidates those interventions into a deployable package, with the documentation and audit infrastructure that supports their ongoing maintenance.
It is recommended that any retailer who has not conducted a performance audit within the previous twelve months conduct one, with whatever tooling is appropriate to the site’s hosting and architectural context; the audit is, in resource terms, modest, and the conversion gains that the audit’s recommendations produce, when implemented, are consistently in the range that justifies the audit cost many times over. (For a related account of how performance work has, over the previous decade, been consistently the most reliable source of conversion improvement available, see A Core Web Vitals diary: what actually moves the needle.)