← All practical guides

SEO and performance

How to speed up a website: measure, fix, verify

Establish where visitors wait before choosing a fix. HTML response time, a lab score and real-user experience measure different things.

Differline · Updated 2026-10-11

Choose several important pages

Check the home page, a service or product page, and the enquiry or cart journey. Run mobile and desktop PageSpeed Insights tests and record dates and results. Network, server load and third parties can make a single result fluctuate. Compare repeated tests under similar conditions. Do not start with a plugin promising to fix everything in one click.

Separate lab data from real-user data

Lighthouse lab results help reproduce problems, while CrUX field data describes eligible real-user experiences over a rolling period. A small site may not have enough samples for field data. Missing data indicates neither failure nor success. Core Web Vitals are LCP, INP and CLS; lab TBT can help diagnose interaction issues but is not the same as INP.

Identify the LCP element

LCP often concerns a large image or text block near the top of the page. Check whether the main image is unnecessarily large and whether dimensions suit the screen. Use suitable WebP or AVIF variants and responsive srcset where supported. Do not lazy-load the immediately visible main image; below-the-fold images can load later. Review quality, transparency and browser compatibility before accepting an optimisation.

Reduce unnecessary browser work

Review chat widgets, videos, advertising tags and plugins. Remove unused capabilities and load nonessential scripts at appropriate times. Long JavaScript tasks can delay interactions. Reserve image dimensions and space for banners or dynamic content to reduce layout shifts. After each change, test menus, forms, checkout and analytics.

Check servers and caching

A slow first response warrants checking server load, database queries and caching. Cache static files in the browser or CDN using a clear update strategy. Accounts, carts and private responses must not enter shared public caches. Test different users, prices and logout before enabling store caching. More server capacity does not automatically fix inefficient queries.

Accept changes through visitor experience

Repeat the same measurements and functional scenarios. Record changed transfer sizes or waits for main content. Field data reflects the new version gradually. Do not chase a score at the expense of functionality or accessibility: working checkout matters more than disabling a payment module to reach 100. Combine performance work with content, SEO and enquiry-path reviews.

Quick checklist

  • Several key pages measured
  • Lab and field metrics distinguished
  • Images, scripts and server investigated
  • Forms and checkout work after changes

Apply this to your needs

Sources and further instructions

Apply this to your project.

Send your website URL or describe your needs. We can establish the problem and an appropriate scope first.

Explore independently

Less guesswork before your next decision.

Automation assessment, website checks, software selection and project planning — without registration.

Free tools