Website performance is often treated as something to address near the end of a project.
Build the site. Add the content. Connect the integrations. Install the analytics. Then, shortly before launch, run a performance test and start looking for ways to make the numbers better.
That approach gets things backwards.
Performance is not a final optimisation task. It is the result of decisions made throughout a project — from architecture and content modelling to image handling, frontend implementation and the number of third-party services a page depends on.
If performance matters, it needs to be scoped from the beginning.
Performance starts with architecture
Some performance problems can be fixed relatively easily. An oversized image can be compressed. A cache can be configured. An unnecessary script can be removed.
Others are consequences of much earlier decisions.
A page that depends on several external services before it can render useful content will behave differently from one that does not. A component system that routinely ships large amounts of unused JavaScript creates a different performance profile from one designed around progressive enhancement.
Likewise, an application that has to perform multiple expensive queries to assemble every page cannot necessarily be made fast simply by adding another caching layer.
Architecture establishes the conditions within which later optimisation has to work.
That is why performance conversations should happen while the system is being designed, not once it is already built.
Content has a performance cost
Content decisions matter too.
Large images, video, embedded tools, interactive components and complex page-building options all have consequences.
This does not mean editors should be prevented from creating rich content. It means the platform should establish sensible constraints.
Images can be resized automatically. Appropriate formats can be generated. Components can have defined behaviours at different breakpoints. Video can be loaded intelligently rather than immediately.
Good performance is often less about asking editors to remember technical rules and more about designing those rules into the CMS.
Third parties need to be treated as dependencies
Analytics, consent platforms, advertising tools, personalisation services, chat widgets, social embeds and marketing automation can all be legitimate requirements.
They are also external dependencies.
Each one can introduce additional requests, JavaScript execution and network latency. Some may be outside the development team's direct control.
This makes third-party services an architectural consideration.
Before adding one, it is useful to understand what it does, when it needs to load, whether it can fail safely and what impact it has on the user experience.
The question should not simply be:
“Can we add this script?”
It should also be:
“What does adding it cost?”
Define performance before development starts
“Make the website fast” is not a particularly useful requirement.
A better approach is to agree what good performance means for the project.
That might include target Core Web Vitals, maximum page weights, limits on JavaScript, image strategies or expectations for important journeys such as search, product pages and checkout.
Those expectations can then influence technical decisions throughout development.
They also give teams something meaningful to test against.
Test realistic pages
Performance testing can become misleading when it focuses exclusively on an ideal page with carefully selected content.
Real websites are rarely ideal.
Editors add images. Marketing teams add campaign tracking. Products accumulate options. Consent platforms appear. Personalisation gets introduced.
Performance testing should therefore include representative pages and realistic content.
For ecommerce in particular, testing should also include dynamic journeys where caching is less useful: account areas, baskets, checkout and other personalised interactions.
Plugins still have a role
None of this means performance plugins, caching systems or CDNs are unnecessary.
They can be extremely useful.
The problem is expecting them to compensate for every decision that came before them.
A caching plugin cannot make a poorly designed integration reliable. A CDN cannot remove unnecessary application logic. Minifying JavaScript does not answer whether that JavaScript needed to be shipped in the first place.
The strongest performance work happens earlier.
It begins by treating performance as a project requirement — something that informs architecture, design, content and implementation from the start.
Because by the time a website reaches its final performance audit, the biggest decisions affecting its speed have usually already been made.