Website speed: how to decide whether to optimise it

To improve website speed, start by identifying which page is slow, which action it hinders and which resources or dependencies are involved. This review helps you decide whether to optimise a specific journey or first address a content, design or sales-process issue.

The useful decision is not about chasing an isolated score. It is about determining whether slowness affects an action that matters to your business, understanding what causes it and choosing a proportionate scope. By the end, you will be able to assess whether to act now, limit the improvement to a specific review or postpone it until another priority has been resolved.

Business decision: what actually needs to change

The goal is not for the website to appear fast in a one-off test. It is for a person to reach the information, navigate and complete the expected action without a wait that disrupts the journey.

Before discussing optimisation, separate three layers:

This distinction helps prevent commissioning a generic improvement when the issue is concentrated, for example, on a services page with heavy images or in a form that depends on external tools.

Signs that it is worth addressing website speed

Optimisation becomes a priority when a relevant action and observable friction occur together. These signs justify reviewing it:

• Delays are noticeable when opening pages that present services, products or contact options.
• Navigation becomes uncomfortable on mobile, especially before an important action.
• Content, image or functionality changes have made the website respond worse than before.
• Some pages contain many visual resources, scripts or integrations whose purpose is unclear.
• Slowness affects internal tasks, such as updating content, managing enquiries or accessing information through the website.
• You are about to redesign, migrate or add features and need to avoid carrying performance issues into the new scope.

There is no need to assume that every sign has a single cause. A website may be slow because of the weight of its resources, the way a page was built, hosting configuration or third-party services. Several dependencies may also be involved at the same time.

A hypothetical example: a company adds videos, maps, forms and tracking tools to several pages. If one of those pages is used to receive enquiries, it would make sense to review which elements are necessary before replacing or expanding the entire website.

Signs against it: when not to start there

Improving speed can be useful, but it should not displace a more urgent need or become an intervention without a purpose. You may postpone or narrow it down if any of these situations apply:

• You do not know which page or journey is affected.
• The website has a more basic issue with messaging, structure, outdated content or unclear contact options.
• The delay occurs only in an external tool you do not control, and you have not yet assessed alternatives or consequences.
• You are about to replace the website and a temporary improvement would duplicate work without protecting an immediate need.
• The team has not defined who will maintain the changes, licences or integrations after the intervention.
• The priority is based solely on a metric, without connecting it to a customer action or an operational task.

Postponing does not mean ignoring the issue. It may mean documenting it, identifying the affected journey and first resolving what prevents the website from explaining your proposition clearly or handling enquiries properly.

Costs and dependencies: what can change the scope

There is no single cost for improving website speed because the work depends on what needs to be analysed, modified and maintained. A localised review does not require the same effort as reviewing a website with many templates, languages, a catalogue, integrations or legacy content.

The areas that may form part of an intervention include:

• analysis of priority pages and journeys;
• review of images, videos, fonts and other downloaded resources;
• adjustments to templates, components or code;
• review of plugins, modules or equivalent dependencies;
• configuration of hosting, caching and file delivery;
• review of forms, maps, analytics tools or other external services;
• testing on the agreed devices and in the agreed contexts;
• documentation of changes and maintenance responsibilities.

It is also advisable to separate the initial work from recurring costs. Hosting, licences, certain external services, maintenance and future updates may affect the solution chosen.

The most sensitive dependency is often one that provides a visible function but delays the journey. The criterion should not be to remove it as a matter of principle, but to ask what function it serves, who needs it, whether an alternative exists and what happens if it fails or loads late.

Decision matrix for prioritising improvements

Use this matrix as guidance when deciding the next step. It does not replace a technical review when several possible causes are involved.

Conditional recommendation

Prioritise website speed if you can link slowness to an important page or task and there is a reasonable hypothesis about the elements involved. In that case, request a review focused on the affected journey, rather than a generic promise to “make the website faster”.

If the slowness is not localised or coexists with structure, content or maintenance issues, define those priorities first. The appropriate solution may range from simplifying specific resources to rethinking a template, an integration or the website architecture. The choice requires technical validation and a business decision about which functions must be retained.

If you need to clarify what is slowing down an important journey and what scope would be needed to resolve it, you can tell AVSISTEC about your web development project so the context, dependencies and priorities can be assessed before deciding on changes.