It's tempting to assume that faster networks and bigger phone storage made app and page size a solved problem. They didn't. In 2026, the bottleneck that actually determines whether an app or a website feels fast has shifted — from how long something takes to download, to how long a device's CPU takes to parse and execute it once it arrives. That distinction changes what "optimization" actually means, and it's worth understanding for anyone shipping a mobile app or a JavaScript-heavy website.
Mobile: what App Bundles and App Thinning actually do
Both major app stores now handle a large share of size optimization automatically, provided developers package their app correctly. The Android App Bundle is a publishing format that contains all of an app's resources and code in one package, and Google Play uses it server-side to generate and deliver multiple device-specific APKs rather than one universal file everyone downloads regardless of their phone's screen density, CPU architecture, or language settings.
The measured impact of this is substantial. Because the store generates and delivers only the slice of code, resources, and assets that actually match a given device, download sizes drop by 30-70% compared to a universal APK. Since the Android App Bundle became the mandatory publishing format, the median Android app's download size dropped 15%, and aggregate Play Store data showed install completion rates improving specifically in emerging markets — exactly where data costs and slower connections make every extra megabyte a real barrier to someone actually finishing an install.
Apple's equivalent mechanism is App Thinning, which creates device-specific app variants rather than shipping one binary with every possible asset baked in. Paired with On-Demand Resources, larger assets — a tutorial video, bonus content, rarely-used feature assets — can stay on Apple's servers and download only when the specific feature that needs them is actually opened, rather than bloating the initial install for every user whether they'll ever touch that feature or not.
The optimization work still left to developers
Automatic store-level thinning handles device-variant slicing, but it doesn't fix a bloated app from the inside. The common, still-manual techniques developer guides point to are removing unused frameworks entirely rather than just disabling them, compressing images and other assets before they ever enter the build, stripping unused CPU architectures from compiled binaries, and — often the biggest and most overlooked source of bloat — auditing third-party SDK size. A single analytics or ad SDK can add several megabytes on its own, and teams frequently accumulate two or three overlapping SDKs doing similar jobs without realizing it until a size audit turns it up.
The web has the same problem, with a twist
Website performance in 2026 tells a similar story to mobile, but with an important twist: raw page weight is still climbing, and JavaScript is the specific culprit that matters most. Current benchmarks put the average webpage at over 500KB of JavaScript, with median home pages weighing roughly 2.86 MB on desktop and 2.56 MB on mobile overall. Images remain the single largest contributor to total page weight at around 37%, but JavaScript, while smaller in raw kilobytes, is the heaviest contributor to actual performance cost — because unlike an image, JavaScript has to be parsed and executed by the device's CPU before a page becomes usable, not just downloaded and painted.
That parse-and-execute cost is the twist that faster mobile networks never solved. The often-repeated assumption was that 5G would fix mobile web performance the way 4G improved on 3G — but the bottleneck has shifted from network to CPU. A 500KB JavaScript bundle downloads in roughly 250 milliseconds on a typical 4G connection, but can take 3 to 5 seconds to actually parse and execute on a mid-range Android phone from a few years back. Faster downloads don't help if the phone's processor is still the thing standing between a visitor and a usable page. The rule of thumb some performance engineers use: every additional 100KB of JavaScript costs roughly one second of added interaction delay on median mobile hardware.
What's actually worth cutting
The practical guidance converging across 2026 web performance writing lands on a few concrete techniques:
- Code splitting and dynamic imports. Heavy components that aren't needed on first load — a rich text editor, a charting library, an embedded map — are strong candidates for
import()-based dynamic loading, so their weight only hits a visitor's device when that specific feature is actually used, not on every page load. - Tree shaking and dead code elimination. A typical mid-sized web app often carries 60–90KB of minified, gzipped JavaScript doing work the browser can now do natively — polyfills and utility functions for capabilities that shipped in browsers years ago but never got removed from the bundle.
- Auditing single-purpose library imports. The recurring lesson in current guidance is blunt: never import an entire library for one function. A date-formatting utility or a small array helper pulled in wholesale for a single call is exactly the kind of dependency that quietly balloons a bundle without adding proportional value.
- Build tool choice. Benchmarks comparing modern bundlers show measurable gaps — Vite producing an average production bundle around 130KB against roughly 150KB from Webpack for comparable applications — which means the build tool itself is now a legitimate lever, not just the code written on top of it.
Image formats: the other big lever
Since images still account for the largest single share of page weight — HTTP Archive data from early 2026 puts images at 45–65% of total page bytes on the median site — format choice is one of the highest-leverage decisions available for cutting weight without touching a line of application code. Modern format benchmarks are consistent: AVIF produces files 20–30% smaller than WebP at equivalent visual quality, and 20–50% smaller than an equivalent JPEG. Browser support has also caught up enough to make AVIF a safe default rather than a risky bet — current estimates put AVIF support around 93–95% of global browser traffic, with WebP even higher at 96–98%, and AVIF adoption is reported to have grown 386% over the past two years as JPEG usage continues fading.
The tradeoff worth knowing about is encoding speed rather than file size: AVIF encoding is roughly three times slower than WebP and about eight times slower than JPEG, which matters mainly for services doing real-time or on-the-fly image processing rather than for a typical static site that encodes images once at build time. For most websites, the practical recommendation that's converged across current guidance is to serve AVIF as the primary format with WebP and JPEG as fallbacks through the <picture> element — giving modern browsers the smallest possible file while keeping older or less common browsers fully covered.
Why this matters beyond vanity metrics
Size optimization isn't an aesthetic preference — it has a direct, measurable relationship to whether people actually complete an install or stick around on a page. The emerging-market install-completion data from Android App Bundle adoption is the clearest evidence of that on mobile: shave enough megabytes off a download and measurably more people finish installing rather than abandoning partway through on a slow or metered connection. On the web, the same dynamic shows up as bounce rate and Core Web Vitals scores — a page that takes multiple seconds to become interactive because the browser is still parsing JavaScript is a page a meaningful share of visitors will leave before it's usable.
That's a direct, practical concern for anyone embedding third-party scripts on a website — chat widgets, analytics tags, support tools. Every embedded script adds to the exact JavaScript weight this research is about, and a poorly optimized third-party widget can undo a site's own careful performance work in a single <script> tag. It's one reason lightweight injection matters for a tool like an AI chat widget: something meant to help convert a visitor shouldn't be the reason that visitor's page fails Interaction to Next Paint before the widget even has a chance to start a conversation. Techvea's widgets are built with that tradeoff explicit — a small footprint that doesn't compete with a site's own performance budget.
Measuring before optimizing
None of the above is useful without measurement, and the tooling for that has gotten better on both platforms. On mobile, bundle-size analyzer tools built into CI pipelines can flag a size regression on a pull request before it ships, catching a newly added dependency or an unoptimized asset before it reaches an app store build rather than after users start noticing slower downloads. On the web, browser DevTools' coverage tab and bundle analyzer plugins for tools like Vite and Webpack show exactly which modules contribute the most bytes to a shipped bundle, which turns "our JavaScript feels heavy" from a vague impression into a concrete, prioritized list of what to cut first.
The discipline that separates teams who keep size under control from teams who don't isn't a one-time optimization pass — it's treating size as a metric that gets checked on every release, the same way test coverage or error rates get checked. A dependency that seemed reasonable when it was added can quietly become the single largest contributor to a bundle eighteen months later, after several unrelated updates pulled in additional transitive dependencies nobody audited individually.
The bottom line
App and page size optimization in 2026 isn't about squeezing out a few extra megabytes for the sake of it — it's about respecting the real, measured cost that every kilobyte imposes on a device's CPU, not just its download queue. Store-level automation (Android App Bundle, iOS App Thinning) has handled a large share of the device-variant problem automatically, but the manual work — auditing dependencies, splitting code, compressing assets, choosing efficient build tools — remains squarely on developers, and the data suggests it still moves real business outcomes: completed installs, lower bounce rates, and pages that actually become interactive before a visitor gives up and leaves.
Sources:
- AVIF vs WebP: Which Image Format Reigns Supreme in 2026? | Elementor
- AVIF vs WebP vs JPEG: Real Benchmarks (2026)
- How to reduce your mobile app size - Bitrise Blog
- What is App Size? Limits and Optimization | Adapty
- Reducing Mobile App Size: Practical Techniques for Android and iOS
- Average Web Page Size in 2026 - Page Weight and Performance Benchmarks
- JavaScript Bundle Optimization 2026 | Web Perf Clinic
- Why Bundle Size Still Matters in 2026 — PkgPulse Guides
Get new posts as they publish
No spam — just the next post, straight to your inbox.