Today, the internet is facing a silent crisis: software obesity. According to Smart and Indigo (2024), the median desktop page has bloated by 120% (1.4 MB) over the past decade. By October 2024, the median page reached 2,652 KB, which is a staggering footprint for delivering what is often simple text and imagery.
This growth isn’t just a technical nuisance; it carries a measurable environmental impact. With the digital sector now responsible for 4% of global greenhouse gas emissions (The Shift Project, 2024), the defining engineer challenge for 2026 is no longer “How much can we build?” but “How efficiently can it run?”
This is where the philosophy of “Digital Sobriety” becomes essential. Far from an exercise in minimalism for its own sake, digital sobriety is a rigorous engineering discipline. It challenges us to build code that is fast, lightweight, and resilient, proving that superior performance isn’t about doing less, but about achieving more with fewer resources.
The “Developer Experience” Trap
Why are websites becoming so heavy? The main reason is a shift in focus. For many years, the industry has prioritized Developer Experience (DX) over User Experience (UX).
We use massive JavaScript frameworks and heavy CMS platforms because they are convenient for developers. They offer ready-made solutions for every problem. But this convenience has a high energy cost. These tools often include thousands of lines of code that the user never actually needs.
When a website is bloated, the user’s device (phone or computer) must work much harder. The CPU (Central Processing Unit) uses more electricity to process the code. This drains the battery and generates heat. Furthermore, heavy sites create digital exclusion. People with older devices or slow internet connections simply cannot access the information. Digital sobriety is the solution to these technical and social issues.
Pillar 1: Runtime Efficiency and “Zero-Overhead”
The first step toward a sober web is to optimize how the server handles every visit. This is the logic of the “Runtime.”
The hidden cost of abstractions
Most modern PHP frameworks rely on heavy abstractions. When a user visits a site, the server often initiates a complex process, utilizing “service containers” to manage dependencies. The system then uses the“Reflection API” to scan classes and methods. It performs these calculations for every single request. This is like rebuilding a car every time you want to drive it.
OTRA: Performance by elimination
I developed the OTRA Framework to solve this specific problem. OTRA follows a Zero-Overhead philosophy. Instead of adding layers of comfort for the developer, it removes layers of work for the machine.
- No Service Container: OTRA does not use a container to resolve dependencies at runtime. This removes the CPU-heavy task of scanning and mapping services during the request.
- The Shortest Path: We focus on the “Call Stack.” This is the list of functions the server must call to produce a result. By keeping the stack short, the server executes the minimum number of PHP instructions.
- Direct Logic: Without unnecessary abstractions, the CPU power is dedicated entirely to the application’s specific logic. This makes the application more resilient and less energy-hungry.
Pillar 2: Shifting Workload to the Build Phase
The second pillar of digital sobriety is moving the workload away from the user’s visit. This is where Static Site Generation (SSG) and specialized build tools become essential.
Why build scripts matter
For many projects, such as blogs, news sites, or documentation, the content does not change every second. Using a dynamic backend to generate these pages for every visitor is a waste of energy.
For my own technical blog, I use a custom Static Site Generator script. This tool ensures that the server does almost zero work when a visitor arrives.
High-performance transformation with FFI
In my build script, I use a powerful PHP feature called FFI (Foreign Function Interface). FFI allows PHP to call functions from libraries written in the C language. C is much closer to the hardware and much faster than PHP.
- Parsing with speed: My script calls the libcmark library to transform Markdown files into HTML. This process happens during the “Build Phase.”
- Generate once, serve many: Because this work is done before the user arrives, the final result is a pure HTML file. The server only needs to send a file from the disk to the network. There is no database to query and no HTML to build in real-time.
Pillar 3: Advanced Compression (Brotli & Zstd)
Data transfer is a major part of the web’s energy consumption. Every byte that travels through the network uses electricity in routers, cables, and data centers. Compression is our best tool to reduce this footprint.
Brotli for the static web
Brotli is a modern, lossless compression algorithm developed by Google that typically achieves better compression than gzip for text-based assets such as HTML, CSS, and JavaScript (Wilhelm, 2019; web.dev, 2023). In real-world reports summarized by Fasterize, Brotli delivered 14%–21% better compression than gzip in some cases, and LinkedIn reported improvements of up to 30% when comparing Brotli level 11 to gzip level 6 (Wilhelm, n.d.). For static assets, you can pre-compress using higher Brotli quality settings (for example, 9–11) to maximize byte savings, while using mid-range settings is usually a better trade-off when compressing dynamically at request time (Bullock, 2023; web.dev, 2023). Reducing page weight and data transfer can also reduce the energy needed to load webpages (ClimateAction.Tech, 2025).
Zstd for the dynamic web
What if the content must be dynamic? For these cases, Zstandard (Zstd) is the new standard. Created by Facebook, Zstd is designed for speed. it compresses and decompresses data very quickly while maintaining a very high compression ratio. It uses less CPU power than other algorithms to achieve the same result. By using Zstd for API responses or dynamic data streams, we maintain performance without wasting energy.
Pillar 4: Front-End “Vanilla” Philosophy
The front-end is where the user feels the weight of the web. A sober front-end should be “Vanilla-first”. This means using native browser features instead of large libraries.
The True Cost of Web Fonts
Custom web fonts are one of the biggest causes of page weight. Many sites download three or four font files. This often adds 300 KB or 500 KB to the page. Instead, we should use System Fonts. These are the fonts already installed on the user’s device:
- San Francisco on macOS and iOS.
- Segoe UI on Windows.
- Roboto on Android.
By using these fonts, there is no download. The text appears instantly. This improves the “Largest Contentful Paint” (LCP) and saves a significant amount of data transfer.
Avoiding “Div Soup”
Many frameworks generate unnecessary HTML tags, creating a “Div Soup”. This makes the browser’s rendering engine work harder to draw the page. Writing clean, semantic HTML is an act of digital sobriety. It makes the site faster for the CPU and easier to navigate for the user.
The Business Value of Digital Sobriety
Digital sobriety is not just an ethical choice. It is a powerful business strategy. In 2026, companies that ignore these principles will face risks.
SEO and User Retention
Google’s search ranking systems aim to reward pages that provide a good page experience, and Core Web Vitals are used in ranking (Google Search Central, 2025a, 2025b). A sober website is naturally faster, which improves your Core Web Vitals. Furthermore, Google reports that 53% of mobile visits are abandoned if a page takes longer than three seconds to load (Google, 2016). Sobriety helps you keep your customers.
The European Accessibility Act (EAA 2025)
In June 2025, the European Accessibility Act (EAA) transitioned from a directive into a mandatory legal requirement for the private sector (Directive 2019/882). This shift requires businesses to ensure their digital interfaces meet strict accessibility standards.
Crucially, as highlighted in the RGESN framework (Institut NR, 2024), there is a symbiotic link between eco-design and accessibility. A “sober” site, built with clean code and minimal dependencies, provides benefits beyond the environmental; it is inherently more readable for assistive technologies like screen readers and remains highly performant on legacy hardware.
A Roadmap for Change
The future of web development is moving toward “doing more with less.” To begin your transition toward digital sobriety, I suggest three foundational actions:
- Audit Dependencies: If a library is used for only one small feature, replace it with native CSS or JavaScript.
- Pre-render Everything Possible: If content does not change for every user, shift the computation cost from the user’s visit to the build phase, by pre-rendering it.
- Optimize the Stack: Choose tools designed for efficiency. Adopt lightweight frameworks like OTRA and modern high-performance compression like Brotli and Zstd.
By prioritizing optimized code over developer convenience, we build a web that is faster, more inclusive, and better for the environment. It is time to make the web light again.
References
- Smart, D., & Indigo, J. (2024, December 30). Page weight. In The Web Almanac 2024. HTTP Archive. Link
- The Shift Project. (2024, March 15). Mondes virtuels & réseaux face à la double contrainte carbone. Link
- Bullock, M. (2023, June 23). All the way up to 11: Serve Brotli from origin and Introducing Compression Rules. The Cloudflare Blog. Link
- ClimateAction.Tech. (2025). EcoWeb Report 2025 (PDF). Link
- web.dev. (2023, December 11). Optimize the encoding and transfer size of text-based assets. Link
- Wilhelm, E. (2019, May 27). La compression Brotli en quelques clics avec Fasterize. Fasterize. Retrieved January 15, 2026, from Link
- Google. (2016). The need for mobile speed: Better user experiences, greater publisher revenue. Think with Google (PDF). Link
- Google Search Central. (2025, December 10). Understanding Core Web Vitals and Google search results. Google for Developers. Link
- Google Search Central. (2025, December 10). Understanding page experience in Google Search results. Google for Developers. Link
- European Parliament and Council. (2019). Directive (EU) 2019/882 on the accessibility requirements for products and services. Official Journal of the European Union.
- Institut du Numérique Responsable (INR). (2024). Référentiel Général d’Écoconception de Services Numériques (RGESN). Produced in collaboration with DINUM, ADEME, and the Ministry of Ecological Transition. Link
Author Bio
Lionel Péramo is a Full Stack Developer and the creator of the OTRA Framework and EcoComposer. He specializes in high-performance architecture and digital sobriety. Lionel teaches developers how to build inclusive and eco-friendly websites by using a “Vanilla-first” approach.
Connect with Lionel: LinkedIn | OTRA Framework | EcoComposer | Blog
Subscribe to our newsletter!
+ There are no comments
Add yours