How We Cut Page Weight by 46%

When SimpleTire's lead engineer reached out, their Lighthouse performance score was 34 on mobile. A product listing page was loading 4.8MB of assets on a clean cache. Their bounce rate had climbed 22% over the previous year, tracking almost exactly with their steady growth in asset weight.

Here is what we did, and more importantly, why each change worked.

Start with measurement, not guesswork

Before touching anything, we set up proper measurement: Lighthouse CI in the build pipeline so regressions surface immediately, real user monitoring with p75 and p99 load times broken down by page type, and WebPageTest runs from three geographic regions to catch CDN coverage gaps.

Without this baseline, you are optimizing on instinct. With it, you can prove that changes matter, you can catch regressions before they ship, and you can explain the results to stakeholders in language that connects to the business outcomes they care about.

Images were 71% of the problem

Three things were making images expensive.

There were no responsive images. A 4000-pixel product photo was being served to every device, including a 375-pixel mobile screen. Adding proper srcset and sizes attributes to every product image dropped image transfer by 58% for mobile users immediately.

The site was serving JPEG everywhere. Switching to WebP with a JPEG fallback for older browsers cut average image size by another 30%. AVIF where browser support allows cuts it further still, and browser support is now broad enough that it is worth using.

Below-the-fold images were loading on page load. Adding native lazy loading to any image that starts below the fold cut initial page weight by a further 40% without any impact on perceived performance for users.

Together these three changes saved 2.1MB per page load with about two days of engineering work.

JavaScript was the second problem

Their JS bundle was 1.2MB uncompressed. An afternoon with source-map-explorer showed why: a date formatting library adding 67KB for features used in exactly two components, a full icon library imported globally at 340KB rather than as tree-shaken individual imports, and three overlapping analytics scripts two of which were serving identical purposes.

Replacing the date library with native Intl formatting, fixing the icon imports, and removing the redundant analytics scripts took the better part of a day and removed 420KB from the main bundle.

Third-party scripts: the dark matter

Third-party scripts load asynchronously so they do not block the initial render, but they still compete for CPU and network bandwidth on the client. SimpleTire had 11 third-party script tags. After a proper audit: four were duplicates or features nobody was using, three could reasonably be deferred until after user interaction, and two could be replaced with lighter alternatives that served the same business purpose.

Deferring the live chat widget and moving analytics to a first-party edge function removed 310KB of third-party script weight and improved time-to-interactive on mobile by 2.3 seconds.

The results after eight weeks

Page weight went from 4.8MB to 2.6MB, a 46% reduction. Lighthouse mobile score went from 34 to 71. The p75 load time on a 4G connection went from 8.2 seconds to 3.1 seconds. Bounce rate dropped 14% in the same period.

The estimated conversion impact, measured through a holdback test, was a 4.1% lift on mobile. At SimpleTire's traffic volumes, that number pays for several engineers for a year.

Performance work pays for itself quickly on sites where load time correlates with conversion. If you can instrument the measurement, it almost always turns out to be worth doing.