By ByteBot
LinkedIn consumes 2.4 gigabytes of RAM across just two browser tabs—more memory than many full desktop applications. This isn’t a LinkedIn-specific bug or an outlier worth dismissing. It’s a symptom of an industrywide web performance crisis where speed has been sacrificed on the altar of feature velocity, and developers have normalized bloat as the price of progress.
A recent Hacker News thread exposing LinkedIn’s memory consumption drew 558 points and 333 comments, with developers sharing stories of tabs consuming over 1GB after sitting dormant for 20 minutes. One user reported a single LinkedIn tab using 3.2GB while other tabs stayed under 200MB. The pattern is clear: modern web applications, built on single-page architectures and JavaScript-heavy frameworks, have become resource gluttons.
The Web Bloat Epidemic Is Real and Quantified
LinkedIn isn’t alone. Web page sizes have grown 6% year-over-year, with the median page now weighing 2.2 megabytes and serving 627KB of JavaScript across 24 requests. At the 90th percentile, pages hit 8.2MB—5.7MB of that being images alone. Moreover, these numbers reflect an acceleration in bloat that shows no signs of slowing.
The extremes reveal how far we’ve fallen. A major news publication was found serving 49 megabytes of data for four headlines—the equivalent of the entire Windows 95 operating system or 10-12 MP3 songs. Loading that page required 422 network requests and took two full minutes to settle. Furthermore, modern web applications have become so bloated that some are harder to render than PUBG on entry-level devices.
This isn’t just about large files. CPU performance for web apps hasn’t scaled nearly as quickly as bandwidth, meaning the web is becoming inaccessible to users with low-end devices even if they have high-end connections. Consequently, bloat is outpacing hardware improvements, destroying performance, user experience, and search rankings.
How We Got Here: Feature Bloat and Developer Complicity
The root cause is organizational and cultural, not purely technical. Product teams ship features relentlessly because they’re rarely criticized for adding too many. Meanwhile, 45% of software features are rarely or never used, yet continue to consume development and maintenance resources. As one developer put it: “Just because you can ship something fast doesn’t mean you should.”
Single-page application architectures enable this bloat. SPAs load massive JavaScript bundles upfront, create complex state management systems, and often leak memory through improper cleanup of event listeners, timers, and asynchronous operations. Additionally, React components that don’t clean up on unmount, aggressive caching strategies without garbage collection, and features layered on features without considering the cumulative weight all contribute to poor web performance.
Developers are complicit. We’ve normalized the idea that poor performance is an acceptable trade-off for developer experience and feature velocity. “Users can just buy more RAM” has become an unspoken justification. However, we accept framework overhead without question, treat performance optimization as a nice-to-have rather than a requirement, and prioritize shipping over sustainability.
The True Cost: Environmental, User, and Business Impact
Web bloat isn’t just a developer annoyance—it has real-world consequences. The internet is responsible for approximately 1 billion tons of greenhouse gas emissions annually, equal to the entire global aviation industry. Data centers consumed 460 terawatt-hours of energy in 2022 and are projected to hit 620-1050 TWh by 2026. An average website with 10,000 monthly page views emits about 31.5 kilograms of CO₂ per year.
For users, bloated sites create an accessibility crisis. Entry-level devices can’t run “simple” web pages. Mobile batteries drain faster. Users on slower connections are excluded entirely. The web was built on principles of universal access; today’s bloated applications violate that foundation. In addition, businesses pay through customer churn, lost search visibility (page speed is a Google ranking factor), higher infrastructure costs, and accumulating technical debt.
Solutions Exist, But We Lack the Discipline to Use Them
Performance budgets offer a path forward. A performance budget is a threshold applied to metrics you care about—First Contentful Paint under 1.5 seconds, Time to Interactive under 3 seconds, total resource size under 500KB, fewer than 30 HTTP requests. Teams set budgets by analyzing their worst performance over 2-4 weeks, then configure monitoring tools to send alerts or break the build when budgets are violated.
Performance budgets are rare because they require organizational discipline. They force teams to say no to features. They challenge PM pressure to ship, ship, ship. They require choosing architecture based on use case rather than trend. For instance, LinkedIn, a content-heavy social platform, uses SPA architecture—a poor fit when server-side rendering or static generation would better serve users.
The technical solutions exist: image optimization, code minification, compression, lazy loading, CDN usage, proper memory cleanup. Nevertheless, the problem is will. Teams must prioritize performance, enforce budgets, and push back when features threaten user experience. Developers need to advocate for performance as a first-class concern, not an afterthought.
Better Is Possible
Wikipedia and GitHub prove that performance and complexity aren’t mutually exclusive. Wikipedia serves billions of page views with minimal JavaScript, server-side rendering, and a tiny environmental footprint. GitHub is feature-rich yet optimized, using efficient caching strategies and progressive enhancement. Both sites demonstrate that performance is a choice, not a constraint.
The most efficient way to reduce a website’s carbon footprint is to improve its performance. Optimization isn’t just good engineering—it’s environmental responsibility, accessibility ethics, and business sense. Web bloat is out of control, and developers have agency to change it. Performance budgets, architectural discipline, and organizational pushback can reverse the trend. Therefore, we’ve normalized poor performance for too long. It’s time to challenge that norm and build a web that respects users, devices, and the planet.
