Blog 7 min *

* Publication times use Tampa, Florida local time (Eastern Time).

An overhead flat-lay of compact objects stacked and accumulating on one side, fading into shadow on the other.

Page Weight Keeps Growing. Your Customer's Device Budget Doesn't.

By Gabriel Lopez-Seco

Your website got heavier this year. Not because you redesigned it, added a page, or made a deliberate choice to add content. It got heavier because the plugins updated, a tracking pixel loaded a new dependency, the booking widget’s vendor pushed a new version, and someone added a promotional banner with an uncompressed image.

That is the ordinary lifecycle of an SMB website. And the HTTP Archive Web Almanac 2024 confirmed that it is happening across the entire web: page weight is still growing “at almost the same rate” year on year through 2024 (HTTP Archive / Web Almanac 2024, Page Weight chapter, 2024).

The device your customer is holding has not kept pace.

The Load Budget Most SMB Sites Already Violate

Here is a concrete number that most business owners have never seen: on the 75th-percentile mobile device and network, a JavaScript-heavy site has a total page-weight budget of approximately 730 KB, of which no more than 365 KB should be JavaScript, to load interactively in 3 seconds (Alex Russell / Infrequently Noted, using Cloudflare Radar data, 2024).

That budget is derived from real-world measurements of what a P75 mobile device, not a brand-new flagship, but the kind of mid-tier Android phone that represents a typical real-world customer, can actually download, parse, and execute in 3 seconds on a P75 network connection (7.2 Mbps down, 94 ms RTT).

Let’s make that concrete. A standard WordPress site with:

  • A booking plugin (e.g., Calendly or a WordPress-native scheduler)
  • A live chat widget
  • Google Analytics (GA4)
  • A Meta Pixel for ad retargeting
  • A Google Ads conversion tag

…can clear 365 KB of JavaScript from those five integrations alone, before a single line of code specific to your business has loaded. The content your customer came to read, your services, your phone number, your pricing, has not appeared yet. The browser is still executing scripts from five third-party vendors.

Most SMB sites do not pass this budget. The Web Almanac 2024 Performance chapter, drawing on Chrome User Experience Report (CrUX) real-user data from millions of sites, confirmed that the performance inequality gap, the difference between what high-end and low-end devices experience, is widening, not closing (HTTP Archive / Web Almanac 2024 Performance chapter, 2024, citing Alex Russell’s performance inequality gap framework).

What “Page Weight” Actually Means in Practice

Page weight is the total size of everything your browser has to download to render a page: HTML structure, CSS styling, JavaScript logic, images, video, fonts, and third-party requests.

The categories are not equally expensive. Here is how they differ:

Images are typically the largest contributor to raw file size, a 2 MB hero image transfers 2 MB of data. But images are mostly passive: once downloaded, they display without additional processing.

JavaScript is the most CPU-expensive category. A 365 KB JavaScript file does not just consume 365 KB of bandwidth, after downloading, the browser has to parse the code, compile it, and execute it. On a mid-tier Android processor, that execution takes materially longer than on a desktop or a high-end iPhone. The browser’s main thread, the process responsible for all user interaction as well as JavaScript execution, cannot respond to taps or scrolls while executing scripts. A page that requires 600 ms of JavaScript execution time is a page where taps feel broken for 600 ms.

Third-party scripts are doubly expensive: they add to both the bandwidth load and the execution load, and they load from external servers with their own latency. A chat widget loading from a vendor’s CDN adds a DNS lookup, a TCP connection, and a TLS handshake before a single byte of that script arrives.

A Worked Example: The Plumbing Company

Take a plumbing company in Hillsborough County with a homepage at 3.2 MB, including a compressed hero video, a booking plugin, analytics, and a live chat script. That 3.2 MB total page weight is more than four times the 730 KB budget before the customer on a 4G LTE connection can read the phone number (Alex Russell / Infrequently Noted, 2024, C8-R9).

On a P75 mobile connection: 7.2 Mbps down, downloading 3.2 MB of content takes roughly 3.6 seconds of transfer time alone, before the browser has processed a line of JavaScript or rendered a pixel. Add execution time for three active scripts, and the page’s time-to-interactive stretches well past 6 seconds.

At the same time, a competitor’s site with a 580 KB page weight loads interactively in under 2 seconds on the same connection. Both sites appear in the same Google search results. The customer on a Verizon LTE connection from a job site, searching for an emergency plumber, opens both and goes with the first one that responds.

The plumbing company owner checks their analytics and sees a bounce. The audit trail stops there. The cause, page weight four times over budget, is not visible in the analytics dashboard.

One-Time Optimization Is Not the Answer

“We optimized our images last year” is one of the most common responses in a page-weight conversation. It is also an answer to a different problem than the one that keeps growing.

Image optimization is a one-time fix for a point-in-time snapshot of your site. It does not prevent:

  • Plugin version updates that bundle additional JavaScript dependencies
  • New third-party integrations (a new scheduling tool, a new ad pixel, a new chat vendor)
  • CMS framework updates that ship heavier core scripts
  • New banner images added by whoever manages marketing content

The Web Almanac 2024 confirmed that the page-weight trend line is continuing upward at “almost the same rate” year on year (HTTP Archive / Web Almanac 2024, 2024). That is not a warning about individual sites, it is a measurement of the whole web’s trajectory. The default trajectory for a maintained website is heavier over time, not lighter.

Optimization last year means the baseline was lower last year. Every update since then has added to it.

The Performance Inequality Gap: Who Gets Left Behind

The Web Almanac 2024 Performance chapter raised a specific concern that goes beyond page weight alone: the gap between high-end device performance and low-end device performance is growing (HTTP Archive / Web Almanac 2024, 2024).

A new iPhone 16 Pro executing 600 KB of JavaScript does so in a fraction of the time a mid-tier 2022 Android phone manages. The iPhone owner barely notices the script execution overhead. The Android user on a 4G connection at a medical facility waits. Both show up as “mobile sessions” in your analytics.

INP: Interaction to Next Paint, is the metric that captures this. It measures how long a page takes to respond to a tap or click. Google defines “good” INP as under 200 milliseconds. The Web Almanac 2024 confirmed that mobile INP performance significantly lags desktop across the web (HTTP Archive / Web Almanac 2024 Performance chapter, 2024). The INP gap is not a network problem, it is a device processing problem compounded by JavaScript weight.

A site that “felt fine” on the average device two years ago does not feel fine on the same device category today, because the site has gained 18 months of accumulated plugin updates while the device’s processor has not changed. The performance gap grows even when neither the device nor the site changes in a major way, through accumulated small additions.

What a Page-Weight Audit Actually Reveals

A page-weight audit is not an optimization exercise. It is a revenue diagnostic. It answers:

  • How much JavaScript is loading that your customer never interacts with?
  • Which third-party scripts are executing before your content appears?
  • Where is the mobile-desktop gap widest, is it bandwidth, CPU execution, or round-trip count?
  • Which specific elements are blowing the P75 mobile budget?

The answers determine where the behavioral cost is highest. For a service business where the conversion event is a phone call or a form submission, a slow-responding contact form (high INP from JavaScript overhead) costs more than a slow-loading image (slower LCP from image weight). For an ecommerce business, page weight on the product page costs more than on the about page.

The diagnostic step determines which fix matters most. Reducing image size on a page where JavaScript execution is the actual bottleneck produces a fraction of the business result.

iServU’s free assessment includes a page-weight and script audit mapped against the P75 mobile budget, not a Lighthouse score in a simulated environment, but an analysis of what your real visitors experienced. Gabriel Lopez-Seco runs it directly. No account manager. No handoff to a junior analyst.

Schedule a free assessment at iServU.

Sources

  1. HTTP Archive / Web Almanac (2024). Page Weight chapter: HTTP Archive crawl data, millions of URLs. https://almanac.httparchive.org/en/2024/page-weight
  2. Alex Russell / Infrequently Noted (2024). “The Performance Inequality Gap, 2024.” https://infrequently.org/2024/01/performance-inequality-gap-2024/
  3. HTTP Archive / Web Almanac (2024). Performance chapter: CrUX real-user data, millions of origins. https://almanac.httparchive.org/en/2024/performance