Your website gained weight this year: 8 fixes that pay for themselves
Sep 22, 2026
Your website is heavier than it was last year. Not by a little.
The median mobile home page now ships 2.6 MB, up 8.4% in twelve months, according to the 2025 Web Almanac from HTTP Archive. Desktop reached 2.9 MB. Nobody sat in a meeting and approved that. It arrived a component at a time, a tag manager at a time, a hero video at a time.
Meanwhile the bill for getting someone onto that page keeps climbing. Paid clicks cost more than they did, organic clicks are harder to win, and every visitor who bounces before your page finishes painting was a visitor you already paid for. That is the arithmetic that makes performance a commercial problem rather than an engineering one.
The Deloitte figures are from 2019, which is worth saying plainly. The relationship they measured has not been overturned since, but treat the exact percentages as a well-evidenced direction rather than a promise about your particular funnel.
Open PageSpeed Insights and read the top section only, the one labelled as real user data. If your site has enough traffic, that is your actual score. The lab section below it is a diagnostic tool, not a verdict. Teams that optimise for the lab number often ship changes that do nothing for the field number.
Identify it, then clear its path. Preload it. Never lazy-load it, which is the most common own goal in the category. Serve it in a modern format at the size it actually displays, not the 3000 pixel original. Give the font a fallback so text paints immediately instead of waiting.
List them. Put a name and a purpose next to each. Delete anything nobody claims. Load the rest after your content, not before it. This single exercise usually recovers more time than a month of code optimisation, and it costs nothing but the argument.
Convert to AVIF or WebP with a fallback. Serve responsive sources so a phone never downloads a desktop asset. Set explicit width and height on every image so the layout stops jumping, which fixes CLS as a side effect. Lazy-load everything below the fold and nothing above it.
Measure it on its own. Strip it back to what a purchase requires. Baymard's data shows 17% of abandoners cite a complicated checkout and 17% cite errors or crashes, and those two often describe the same page on a bad connection. A checkout that works on a strong connection and fails on a weak one is a checkout that fails for a meaningful share of your buyers.
The question is not whether the framework is good. It is whether your page needs to ship an entire client-side application to display content that does not change. If most of your site is content, server rendering or static generation gives you the same authoring experience at a fraction of the runtime cost. If your site is genuinely an application, keep the framework and spend the effort on splitting the bundle instead.
Pick a number your team can hold. A total JavaScript budget per page, an LCP target, a cap on third-party requests. Then run a check in continuous integration and fail the build when a change exceeds it. Reporting on a regression after it ships is how most teams discover it in the next quarterly review instead.
Before you start, record conversion rate by device, bounce rate on your top landing pages, and revenue per session. Make your changes. Compare. If the speed numbers improve and the commercial numbers do not, you optimised the wrong page, and that is useful information rather than a failure.
None of that requires budget approval. What it produces is a short list of specific, measurable defects, which is a much better brief than make the site faster.
The median mobile home page now ships 2.6 MB, up 8.4% in twelve months, according to the 2025 Web Almanac from HTTP Archive. Desktop reached 2.9 MB. Nobody sat in a meeting and approved that. It arrived a component at a time, a tag manager at a time, a hero video at a time.
Meanwhile the bill for getting someone onto that page keeps climbing. Paid clicks cost more than they did, organic clicks are harder to win, and every visitor who bounces before your page finishes painting was a visitor you already paid for. That is the arithmetic that makes performance a commercial problem rather than an engineering one.
What the current data actually says
Most performance advice floats free of numbers. Here are the ones worth knowing.Fewer than half of mobile sites pass Core Web Vitals.
The Web Almanac performance chapter puts 48% of origins in the good bucket on mobile, against 56% on desktop. Mobile improved four points in a year, which is progress, and still leaves the majority failing.Largest Contentful Paint is the metric holding everyone back.
On mobile, 62% of origins pass LCP, against 77% for INP and 81% for CLS. Your slow metric is almost certainly how long the main thing takes to appear.The median mobile page carries 632 KB of JavaScript and 911 KB of images.
Images are usually the cheaper fix, and almost nobody starts there.A tenth of a second is worth measurable money.
Deloitte's Milliseconds Make Millions study, run across 37 brands and more than 30 million sessions, found a 0.1 second mobile speed improvement lifted retail conversion 8.4% and average order value 9.2%. Travel conversion rose 10.1%. Lead generation saw form progression improve 21.6%.Roughly seven in ten carts are abandoned.
Baymard Institute puts the documented average at 70.22% across 50 studies. Among the stated reasons, 17% cite a lengthy or complicated checkout and another 17% cite site errors or crashes.
The Deloitte figures are from 2019, which is worth saying plainly. The relationship they measured has not been overturned since, but treat the exact percentages as a well-evidenced direction rather than a promise about your particular funnel.
1. Measure field data, not your laptop
Lighthouse on a wired connection in a quiet browser tells you about your laptop. Core Web Vitals are scored on what real Chrome users experienced, which includes mid-range Android phones on congested networks.Open PageSpeed Insights and read the top section only, the one labelled as real user data. If your site has enough traffic, that is your actual score. The lab section below it is a diagnostic tool, not a verdict. Teams that optimise for the lab number often ship changes that do nothing for the field number.
2. Find your largest contentful element and defend it
LCP is the single element that takes longest to render in the initial viewport. Usually a hero image, sometimes a headline blocked by a web font, occasionally a banner injected by a testing tool.Identify it, then clear its path. Preload it. Never lazy-load it, which is the most common own goal in the category. Serve it in a modern format at the size it actually displays, not the 3000 pixel original. Give the font a fallback so text paints immediately instead of waiting.
3. Audit your third-party scripts by name and by cost
Every tag was added by someone with a reason. The chat widget, the heatmap recorder, the consent layer, the review embed, the two analytics tools nobody has opened in a year, the abandoned A/B testing snippet still loading on every page.List them. Put a name and a purpose next to each. Delete anything nobody claims. Load the rest after your content, not before it. This single exercise usually recovers more time than a month of code optimisation, and it costs nothing but the argument.
4. Fix images before you touch JavaScript
At 911 KB median on mobile, images are the largest single category of page weight and the easiest to reduce without a rebuild.Convert to AVIF or WebP with a fallback. Serve responsive sources so a phone never downloads a desktop asset. Set explicit width and height on every image so the layout stops jumping, which fixes CLS as a side effect. Lazy-load everything below the fold and nothing above it.
5. Treat the checkout as a separate performance product
Your homepage gets the attention because it is the page leadership looks at. Your checkout is where the money is, and it is usually the heaviest page you own, because that is where the payment scripts, fraud tools, address validators and analytics all collect.Measure it on its own. Strip it back to what a purchase requires. Baymard's data shows 17% of abandoners cite a complicated checkout and 17% cite errors or crashes, and those two often describe the same page on a bad connection. A checkout that works on a strong connection and fails on a weak one is a checkout that fails for a meaningful share of your buyers.
6. Question the framework, carefully
Modern JavaScript frameworks solve real problems. They make complex interfaces maintainable by teams, and dismissing them because a brochure site does not need one misses why people reach for them.The question is not whether the framework is good. It is whether your page needs to ship an entire client-side application to display content that does not change. If most of your site is content, server rendering or static generation gives you the same authoring experience at a fraction of the runtime cost. If your site is genuinely an application, keep the framework and spend the effort on splitting the bundle instead.
7. Set a performance budget and enforce it in the build
Speed work that is not defended gets undone. Someone adds a tag, a new hero video ships, a dependency grows, and in three months you are back where you started.Pick a number your team can hold. A total JavaScript budget per page, an LCP target, a cap on third-party requests. Then run a check in continuous integration and fail the build when a change exceeds it. Reporting on a regression after it ships is how most teams discover it in the next quarterly review instead.
8. Watch the metric that actually pays you
Page speed is a means. The number that matters is whether more people completed the thing you wanted them to complete.Before you start, record conversion rate by device, bounce rate on your top landing pages, and revenue per session. Make your changes. Compare. If the speed numbers improve and the commercial numbers do not, you optimised the wrong page, and that is useful information rather than a failure.
Why this keeps happening
Web bloat is not a knowledge problem. Every developer reading this already knows that images should be compressed and that a page should not ship half a megabyte of unused JavaScript. The reason the median keeps climbing anyway is that nothing in the normal workflow of a business pushes back.
Marketing needs a tag to prove a campaign worked. Sales needs a chat widget. Someone senior wants a video on the homepage. Each request is individually reasonable, individually small, and lands on a page nobody owns the weight of. Performance degrades the way a garage fills, which is to say nobody notices until the car does not fit.
There is also a harder truth about AI-assisted development. The tools are genuinely good, and we use them. They also generate more markup to achieve the same visual result, because they reach for wrappers and utility classes rather than the minimum structure. WebAIM's 2026 analysis of the top million home pages found the average page grew to 1,437 elements, a 22.5% jump in one year, and attributed the trend partly to automated coding practices. Faster authoring produces heavier output unless somebody is explicitly watching the weight.
Which is the actual recommendation here. Not a tool, not a framework, not a plugin. Someone whose job includes the number, and a build that refuses changes which break it.
Three tests to run this week
Run your homepage, your top landing page and your checkout through PageSpeed Insights.
Read only the real user data section. Ten minutes for all three, and the checkout result is usually the one that surprises people.Open your site on a throttled connection.
Chrome DevTools, Network tab, select Slow 4G, then reload and try to buy something or submit a form. This is the experience a real share of your traffic has every day.Count your third-party scripts.
DevTools, Network tab, sort by domain. Anything not on your own domain is a dependency someone chose. Write the list down and ask who still needs each one.
None of that requires budget approval. What it produces is a short list of specific, measurable defects, which is a much better brief than make the site faster.
