How to Improve Your Website's Loading Speed

To improve your website's loading speed, first measure the pages your visitors use, identify what delays their content or interactions, and check each change under the same conditions. Reducing images, avoiding unnecessary JavaScript work and reviewing server response are common starting points, but priorities depend on what the measurements reveal.

This guide focuses on how to measure and act. For context, you can read our article on the importance of website speed. A technical improvement can make a page easier to use, but it does not guarantee better Google rankings or more sales.

1. Choose which pages and actions to measure

Do not review only the homepage. Include a service page, an article and, if you have a store, a category and a product page. Also test important actions: opening the menu, applying a filter, submitting a form or adding to the basket.

Record the URL, device, tool and page state for each test. A signed-in session, a cookie notice or a third-party application can change what loads. Use comparable conditions so you do not attribute differences caused by the network or browser to a change.

• Select representative pages, not just the fastest one.
• Check mobile and desktop separately.
• Repeat tests to detect variation and avoid deciding based on a single result.
• Save the initial report and any functional problems you observe.

2. Use PageSpeed Insights without confusing scores with real experience

Enter a public URL in PageSpeed Insights and review the mobile and desktop views. The tool may show real-user data and a Lighthouse lab test. These are different measurements and should not be interpreted as the same result.

Field data: what real users experience

When enough data exists, information from the Chrome User Experience Report lets you observe how the website performs during real visits. Check whether the report covers the specific URL or the whole origin. Missing data does not mean the website is fast or slow: there may not be enough information to display.

Lab data: a test for diagnosis

Lighthouse runs a test under controlled conditions and highlights opportunities for improvement. Its score can vary between runs. Use it to investigate resources and tasks delaying the page, not as an isolated goal or a ranking guarantee.

You can consult the official explanation of how PageSpeed Insights works. If you do not have field data, combine lab tests with checks on real devices and follow-up monitoring.

3. Identify which part of the experience is failing

Not all speed problems involve downloading files. Main content may appear late, an interaction may be blocked, or the page may shift while you read. Core Web Vitals help distinguish these situations.

• LCP: measures when the largest visible content element appears. Investigate which element it is and what delays its appearance.
• INP: reflects responsiveness to interactions. If the page is slow to react, review JavaScript tasks and the work needed to update the screen.
• CLS: measures unexpected changes in content position. Reserve space for images, advertisements and elements that arrive later.

Lighthouse's loading test does not, on its own, reproduce all the interactions needed to assess INP. Its long-task warnings can guide diagnosis but do not replace that measurement. Consult the Core Web Vitals documentation to interpret the indicators and their current criteria.

4. Optimise images without delaying the main content

Review which images are downloaded and the sizes at which they are displayed. A photograph prepared for print usually needs a different version for a screen. Reduce its dimensions to match actual use and adjust compression without losing details visitors need.

• Use formats such as WebP or AVIF where appropriate and check the visual result.
• Offer different-sized versions to avoid downloading the same large image on every device.
• Declare dimensions or a stable aspect ratio to prevent content moving as it loads.
• Apply lazy loading to images outside the initial view where appropriate.
• Do not delay the main image that needs to appear when the page opens by lazy-loading it.

If the main image is the LCP element, check that the browser can discover it early. Preloading or higher download priority can help in particular cases, but should not be applied indiscriminately to every image: they compete for the same resources.

Also review videos and animations. Avoid loading a heavy player before the user needs it, and provide a lightweight initial presentation where possible, without hiding necessary information.

5. Reduce JavaScript and review third-party services

Every chat, player, measurement tool or extension can add downloads and browser work. List what loads and distinguish what is essential for using the page from what can wait.

• Remove duplicate extensions or those without a necessary function after checking their dependencies.
• Load functionality only on pages that use it where the platform allows.
• Split long tasks if an interaction is blocked.
• Review whether a service can load later or after a user action.
• Maintain required consent: speeding up the website does not justify activating tracking before obtaining it.

Do not mark every script as deferred or delete code because a tool flags it as unused during a single visit. It may be needed when opening a menu or completing a purchase. After each adjustment, check forms, the basket and other important journeys.

6. Check the server, caching and resource delivery

If the browser waits a long time before receiving the initial response, investigate hosting, queries, redirects and the processes that generate the page. Compressing images does not fix a slow server response.

Review compression of text files and caching rules for reusable resources. A content delivery network can help delivery, but it does not automatically fix a slow application or an incorrect configuration.

• Avoid unnecessary redirect chains without breaking existing URLs.
• Configure caching for images, styles and scripts with their update process in mind.
• Do not apply public caching to personal data, sessions, baskets or orders.
• Check how the cache is invalidated when content changes or a version is published.

If you do not manage these settings, share the reports with whoever maintains the website and request a specific check of server response and caching. Changing hosting without a diagnosis can move the same problem to another provider.

7. Review styles, fonts and content shifts

Styles and fonts also affect when content appears and its stability. Limit unused font variants and check how text is displayed while the chosen font arrives.

Avoid hiding all text until a download finishes. If you use a fallback font during loading, check that the change does not uncomfortably move headings, buttons or paragraphs. Reserve space for banners and modules inserted later.

Reducing unnecessary styles can help, but automatically deleting rules without testing other pages can break the design. Make these adjustments on a working copy and check different screen sizes before applying them to the public website.

8. Prioritise changes and verify the result

Start with the problem affecting the main content or action. If the initial image arrives late, investigate its download and the server response. If the page is visible but does not react, review the browser's work. If buttons move around, correct content stability.

1. Save the initial measurement and describe the observed problem.
2. Apply a specific change or a small related group of changes.
3. Repeat the test on the same pages and under the same conditions.
4. Check the main functions and appearance on mobile and desktop.
5. Document what changed and how to revert it if a fault appears.
6. Review real-user data afterwards when available.

Field data reflects accumulated visits, so it does not necessarily show a change as soon as you publish it. Do not confuse an immediate lab improvement with an improvement already confirmed for all your visitors.

What not to do to achieve a higher score

• Remove necessary content or useful functions simply to simplify the test.
• Delay the page's main image or preload every resource.
• Install several optimisation tools that apply incompatible changes.
• Enable caching without checking sessions and private data.
• Consider the problem resolved after a single favourable run.
• Promise Google rankings based on a performance score.

The aim is for the website to display useful content, respond to actions and maintain a stable presentation. Google explains the context of these signals in its documentation on Core Web Vitals and search results. Improving them does not guarantee a particular position.

Start with a diagnosis, not a list of tricks

Choose your main pages, measure their loading and interactions, and record what makes them difficult to use. That information will help you decide whether to optimise images, review code or work on the server, without changing what already works.

If you need help interpreting the results and prioritising the work, explore our website optimisation service or send us your website's URL and the problem you observe.