How to improve website speed without making the design worse

Test a first visit and a repeat visit separately. Include a representative phone-sized view and an ordinary inner page, not only the homepage on your own broadband connection. Keep the conditions in your notes so a later comparison means something.

The Core Web Vitals distinguish loading, responsiveness and visual stability. They answer different questions. A score improvement is useful only when you understand which part of the customer's experience changed.

Find the request that holds the page back

Look at the network waterfall and the work the browser performs before the main content appears. A large hero image may be the issue. It might also be discovered late because a script has to run before the image URL exists.

Google's LCP optimisation guidance breaks down those delays. Compressing an image won't solve all of them. If the real delay is discovery or rendering, work on that part of the path.

For images, serve appropriate dimensions and compare any new encoding with the original at the sizes people actually see. Keep important texture, text and product detail intact. Below-the-fold media can usually wait until it's needed; the image that introduces the page needs different treatment.

Use lossless savings first

Text, fonts and some model files can become smaller without changing the decoded content. During Hexcore's 15 October 2026 optimisation, the robot model transferred at about 604 KB with Brotli instead of 1.64 MB uncompressed. Its decoded SHA256 matched the original. That saved transfer bytes; it wasn't evidence that the whole site became 63% faster.

This distinction matters. An asset reduction is a measurement you can repeat. A loading-time claim needs its own controlled test.

Stop building things nobody has opened

A hidden gallery can still create elements, observers and downloads. A video can fetch data even when it isn't playing. Inspect the behaviour instead of assuming that hidden means free.

Load optional experiences when a visitor asks for them, and preserve a usable fallback if that download fails. Keep browser audio rules and keyboard navigation in the acceptance checks; a faster entrance isn't a success if the next action stops working.

Compare the rendered result

Review the same pages at the same widths before and after the change. Check lighting, typography, image detail and motion preferences. Then follow the contact or purchase route.

Keep before-and-after byte counts beside the decoded SHA-256 when testing lossless transport compression. For visual derivatives, compare the actual displayed detail separately. These checks answer different questions.