A Proposal for High-Performance Web [via High-Performance Baseline for Web Apps Community Group]

The Web was born 35 years ago, back when desktop computers were the main way to get online. Today, mobile internet and touchscreens dominate. To keep up with this shift, the Web needs some changes.



Let’s start by comparing the old PC internet to today’s mobile internet.



What’s Changed?



1. How We Access the Internet



In the desktop era, browsers were the gateway to the internet. People used search engines or navigation sites to find stuff, and websites were linked together by hyperlinks (remember that term?).



Now, in the mobile world, the entry points are app icons on your phone and push notifications. Browsers? Most people don’t bother with them anymore. Typing URLs by hand feels clunky, and who even remembers more than a couple of addresses?



2. Where Web Traffic Comes From



User habits have shifted, and so has web traffic. It’s moved from browsers to inside apps—think social media, news feeds, or e-commerce platforms. These apps still use Web tech (like H5 pages), but they’re not open internet sites anymore. They’re custom pages locked inside each app’s ecosystem. This weakens the Web’s interconnectedness. 



So, in the mobile era, the internet isn’t really a “web” anymore—it’s more like a chain of isolated islands. Apps prioritize keeping users inside rather than letting them jump around.







Looking at the Web Through a Mobile Lens



Despite all these changes, Web standards haven’t evolved much.



1. PC-First, Mobile as an Afterthought



The Web was built for desktops—mice and keyboards ruled the day. Mobile devices, with fingers and touchscreens, work totally differently. Features like long list scrolling, gesture controls, and smooth page transitions? The Web doesn’t have them natively.



The most the Web has done for mobile is make sure desktop pages work on phones. That makes sense—smartphones didn’t take over overnight, and early on, people just wanted to view PC sites on their tiny screens. W3C did a ton of compatibility work for that, like adding zoom effects so small phone screens could handle desktop layouts.



Even the forward/back buttons from PC browsers got copied over to mobile. But if you look at native apps, none of them use zoomable pages or arrow buttons for navigation. That’s not mobile-friendly. Today, with mobile traffic calling the shots, it’s backward to keep patching the Web to fit phones. Mobile isn’t the guest anymore—it’s the host. Tons of apps exist only on mobile, no desktop version in sight. Compatibility patches feel outdated now.



2. Performance Problem



If Web pages performed as well as native apps, we wouldn’t have so many cross-platform frameworks like React Native or Flutter. Their popularity is proof the Web’s performance isn’t cutting it.



Performance gripes are old news, so I’ll keep it short with some numbers:




A default  comes with 246 properties and 82 methods.





HTML has 139 tags. Compare that to React Native’s 5 default tags.




Analyze tag usage on core pages of major sites. Turns out, they don’t use that many:



WebsiteTag TypesGitHub45Facebook33Google38YouTube26X.com31Amazon39QQ.com24VS Code24Average32







(These Include 8 non-UI tags like , , , . Subtract those, and the average drops to 24.) Most HTML tags barely touched.




CSS has 380 properties. React Native get by with ~100. But even then, they implement way fewer values than raw CSS. Take display: CSS has 23 options; React Native has 2 (none, flex). 




W3C keeps adding features but rarely cuts anything. New CSS and APIs pile up, making it nearly impossible to build a new browser engine from scratch—it’s too much baggage. Even outdated stuff like document.write() still has to stick around.



That said, the Web still holds a huge chunk of mobile usage. Its cross-platform nature, flexible UI, and dynamic updates make it a go-to for hybrid app development. A survey of China’s top 1000 apps found 60% of pages were Web or Web-like.



But these mobile Web pages? They’re not full-fledged sites anymore—they’re fragmented pieces.



So, if we had a shot at making the Web truly mobile-friendly, where should we take it?







A High-Performance Web Built for Mobile



Different companies have different ideas on how to pull this off. Generally, there are two paths: slim down the existing Web or build a brand-new Web core. Let’s break them down.



Option 1: Slim Down the Web



This means taking the Web’s full feature set and carving out a leaner subset to boost browser efficiency.



Vendors with legacy projects love this—it keeps old code mostly intact. Developers wouldn’t need to rewrite much to get started. But there are downsides:




Performance Limits




Slimming down hits a ceiling fast. The Web’s big flaw—logic and rendering threads fighting each other—means long JS tasks drop frames. Without scrapping that outdated design, performance won’t soar.




Experience Gaps




A trimmed Web still won’t feel mobile-native. You’d need to bolt on stuff like long lists and gestures anyway.




Long-Term Bloat




Defining the subset is tricky and subjective. Worse, it’ll grow over time as tech evolves, undoing the “slim” part. Google’s AMP tried this route and fizzled out.



Option 2: A New Core



If we’re branching off the Web anyway, why not go all-in and build a fresh core?



This means creating a new runtime kernel for next-gen Web apps. Future browsers could run dual engines—the old one stays for legacy, while the new one starts clean. Benefits? Ditch the baggage, separate rendering and logic threads, slim down UI components, and bake in mobile-friendly features.



What might this new Web app look like?




Distributed as Packages Mobile internet’s island-like structure calls for self-contained, low-linkage packages—think mini-apps or cross-platform frameworks.





Bundle UI, CSS, and JS together.



Use a new content-type: application/webapp to define it.



Give packages self-managed lifecycles and updates.



Unlike mini-apps, keep packaging flexible—bundle one page or a full app.




Why? Packages fit mobile use cases:




Embedded in Apps: Most Web traffic comes from apps. Packages can preload locally for native-like performance.



Real-Time Pages: Like H5 share links or QR code pages—small packages users fetch on the fly, downloading and running simultaneously for speed.



Mini-App Ecosystem: This could standardize mini-apps under W3C. The Mini App Working Group started in 2021 but stalled. A solid Web app model could jumpstart it, making mini-apps a global standard. Any browser or Webview could run them natively.





Extensibility Redoing a full browser kernel (GPU, audio, XR, WebTransport, etc.) is insane—too much work. Most apps don’t need it all anyway. A new core should let developers or platforms plug in custom native components, written in high-performance languages. For Webviews, devs could pick only what they need, keeping the core lean. Web devs could call native components directly, no matter the language. High performance, Web efficiency—best of both worlds. Plus, native components could grow into a thriving ecosystem.



Mobile-Friendly by Default This means friendly for devs and users. (Sometimes dev-friendly design helps users too—like iOS’s built-in fade animations. Set animated:YES, and it’s smooth. Most iOS apps feel polished by default.) H5 pages, though? Flickering, jitters, abrupt shifts—few devs bother with transitions, widening the gap with native. A new core should bake in smooth animations, page switches, long lists, and gestures, cutting dev effort.




Bonus: A new core lands easily. As a cross-platform alternative, devs just drop the new Webview into their app—no system or browser updates needed. Full control.







Beyond Phones



It’s not just phones—smartwatches, glasses, car systems, speakers, TVs, and appliances all need UI platforms. Right now, every device and vendor uses different OSes and dev stacks. Building for one means learning its quirks from scratch. Standardized, low-cost software development could even spark innovation in hardware devices.



Imagine a unified, cross-device Web tech that works everywhere. Dev costs drop, and W3C standards could tie it all together. That’s pretty exciting.



----------

This post sent on High-Performance Baseline for Web Apps Community Group



'A Proposal for High-Performance Web'

https://www.w3.org/community/high-perf-baseline/2025/03/09/a-proposal-for-high-performance-web/



Learn more about the High-Performance Baseline for Web Apps Community Group: 

https://www.w3.org/community/high-perf-baseline

Received on Sunday, 9 March 2025 06:29:22 UTC