A website can look fast on an office laptop and still feel slow to someone opening it on a mobile connection. Improving performance starts with finding what delays the visitor's task: receiving the page, seeing its main content, opening a menu or completing an enquiry.
Measure first, change the bottleneck, then retest. Optimise the resources and code responsible for the delay instead of enabling every speed setting at once. Keep a backup and verify that forms, navigation and tracking still work after each release.
Why website speed matters, without the exaggerated promises
Waiting for content or an unresponsive button makes a website harder to use. Performance work should reduce that friction, but it cannot guarantee a particular increase in sales, enquiries or rankings. Those outcomes require separate measurement.
Google's page experience guidance confirms that Core Web Vitals are used by its ranking systems, while good scores alone do not guarantee top positions. Useful content and a working customer journey remain essential. Our Core Web Vitals guide explains LCP, INP and CLS; this article focuses on the practical work behind improving a website.
1. Establish a repeatable performance baseline
Choose representative URLs: a homepage, a service page, a content page and, where relevant, a product or checkout journey. Record the URL, date, device setting and test conditions. Keep the original reports so that a later comparison is meaningful.
PageSpeed Insights provides a Lighthouse lab test alongside real-user data where available. The field data covers a trailing 28-day window and may describe the URL or the wider origin. A missing field report is not a pass or a failure. Mobile and desktop results should be assessed separately.
Repeat lab tests rather than choosing the best single score. Use the browser's Network and Performance panels to inspect requests and interactions. Then try a normal visit on a phone: open navigation, scroll, expand content and use the enquiry form. A loading test alone does not cover the entire journey.
2. Match the symptom to the likely investigation
| What visitors notice | What to inspect | What not to assume |
|---|---|---|
| The page takes time to start appearing. | Document response time, redirect chain and backend processing. | A more expensive hosting plan will automatically fix it. |
| Text appears, but the main image arrives late. | Image discovery, dimensions, transfer size and rendering delay. | Compressing every image fixes the main delay. |
| The page looks ready, but buttons respond slowly. | JavaScript execution and the specific interaction. | A good initial load score means every action is fast. |
| Content moves while the page loads. | Image and embed space, font changes and inserted content. | A static screenshot proves the layout is stable. |
| Only some templates are slow. | Resources, widgets and queries specific to those pages. | Every page needs the same change. |
Use this as a triage checklist, not a diagnosis of your site. Our SEO audit guide explains why a useful recommendation needs evidence of the actual problem.
3. Optimise images without sacrificing the design
Compare the displayed image size with the delivered file. A thumbnail should not unnecessarily download a full-resolution original. Test appropriate dimensions and formats, including WebP or AVIF where suitable, and inspect the result for blurred text, lost detail or colour changes before replacing it.
Identify the actual largest-content element. Google's LCP optimisation guide separates server response, resource discovery, download and rendering delays. A smaller image will not solve a delay caused by JavaScript hiding it. Keep the important image discoverable early; do not lazy-load it. Use priority hints selectively rather than marking every image as urgent.
For images below the initial viewport, native lazy loading can avoid unnecessary early downloads. Supply width and height, or an appropriate stable aspect ratio, so space is reserved. Google's image lazy-loading guidance distinguishes these offscreen assets from images visitors need immediately.
4. Separate browser caching from page caching
Browser caching can reuse downloaded resources. Server or edge page caching can reuse a generated response. They solve different problems and need different rules. Inspect actual response headers rather than assuming a plugin or CDN is caching everything correctly.
Long-lived caching suits versioned static assets when updates produce a new URL. Personalised responses need deliberate handling: do not accidentally share cached account details, carts or private content between visitors. The MDN HTTP caching guide explains private and shared caches, validation and Cache-Control directives. In particular, no-cache requires validation before reuse; it does not mean the same thing as no-store.
Test both a first visit and a repeat visit. After a release, check that visitors receive current assets and that logged-in and logged-out experiences behave correctly. Keep a clear purge or rollback procedure for the cache layer you actually use.
5. Reduce unnecessary CSS and JavaScript carefully
Start with files that the page does not need. The Chrome DevTools Coverage panel helps identify unused CSS and JavaScript during a recording. Exercise menus, forms and responsive states before drawing conclusions: code unused during the initial load may be essential later.
Do not combine every file simply to lower the request count. Evaluate transfer size, execution work, caching and which pages require each bundle. Make one controlled change at a time. Retest different templates and screen sizes before removing shared styles or changing script order.
6. Audit third-party widgets and font loading
List analytics tags, chat tools, maps, video embeds and other integrations with a named purpose and owner. Remove duplicates or unused integrations only after checking dependencies. Consider loading a non-essential embed when it is needed instead of at initial page load.
For classic scripts, async does not preserve execution order, while defer runs after parsing and preserves document order. Neither is a universal switch for every integration. Follow vendor requirements and test consent, analytics and forms after changes. Google's third-party JavaScript guidance describes the trade-offs.
Review font families, weights and language subsets actually required. Fewer unnecessary downloads can help, but a fallback font must remain readable. Font swapping can change line breaks and shift content, so check headings and buttons while fonts load. Use Google's font guidance to choose a loading strategy suited to the design rather than preloading every font file.
7. Investigate delivery and hosting before buying an upgrade
Check whether slow responses affect every page or only particular requests. Review application work, database queries, cache behaviour and resource usage with the developer or host. A large frontend script and an expensive backend query require different fixes.
For compressible text resources such as HTML, CSS and JavaScript, check whether the response uses an appropriate supported compression method such as Brotli or gzip. Compare transferred bytes, not just the source file size. Already compressed media needs a different approach. See MDN's HTTP compression explanation.
A CDN is an option to evaluate against audience location and cacheable content, not a substitute for fixing application work. Keep necessary canonical redirects, but update internal links that unnecessarily pass through redirect chains. Test changes on a small, known set of URLs before altering shared configuration.
A safe release checklist for performance changes
- Define the problem: record the slow URL, action and supporting measurement.
- Back up and isolate: use staging where possible and keep the previous version available.
- Change one cause: avoid simultaneous hosting, plugin and theme changes that obscure the result.
- Test the experience: check mobile navigation, keyboard access, forms, consent and checkout where applicable.
- Repeat the measurement: use comparable device and network settings, including first and repeat visits.
- Monitor after release: review errors and real-user trends; the field-data window will not instantly represent only the new version.
A useful handover records the affected templates, what changed, before-and-after evidence and the rollback steps. Report improvements in measured performance separately from traffic or enquiries. Do not present an assumed commercial uplift as a measured result.
Keep performance work part of website maintenance
Recheck important journeys after adding a plugin, campaign widget, new template or large media collection. Agree practical limits for assets and integrations with the team, based on your own baseline rather than a universal file-size target.
For development support, explore Brainvative's website design and development services. For wider content, crawlability and search work, see our SEO services. Bring the affected URLs and test reports so the work can begin with a specific problem and a clear way to verify the fix.
