slightlyoff

I'm well aware of the data on residual browsers; we have better metrics on the browser side than most public data sets. I also track the high/mid/low device mix, and we see that users on low-spec machines are generally less up-to-date:

https://infrequently.org/2025/11/performance-inequality-gap-...

This makes intuitive sense because those users are more likely to be out of disk space or bandwidth limited by geography or metering.

Regardless, while this issue is pronounced in the Android and Windows ecosystems, it's in a dramatically better place than it was in, e.g., the late Naughts when we had to build exotic solutions like Chrome Frame to address stagnation and fragmentation. So I'm not ignoring the issue, but again, to the extent we're discussing platforms that Apple has influence over, the ball is squarely in Cupertino's court. Every iPhone running an unsupported OS could be getting an updated browser, but Apple chooses not to make one or allow anyone else to plug the gap.

Author here. I work for Microsoft and can assure you I am not invested in Google's ad market position (except, perhaps, in the negative sense).

Article's author here. Arguments about "older browsers" are specious, particularly on iOS where Apple couples the browser engine to the OS, and forces all browsers to use Apple's binary.

If there is a legacy browser problem today, it is entirely within Cupertino's gift to address. Everyone else already moved to out-of-band, decoupled autoupdates. Even ChromeOS is dramatically more up-to-date fleet-wide.

The data is from my blog series, the latest installment of which is here:

https://infrequently.org/2025/11/performance-inequality-gap-...

The top two lines are the fastest devices available in the iOS and Android ecosystems each year, and when using Samsung S-series devices, I have made sure to pick the faster of the Qualcomm vs. Samsung Semi parts (both are used historically, but Qualcomm is most prevalent in the US). As explained in the piece, the bottom two lines are taken from representative devices in the mid-range and low-end price categories. There's wild variation in those market segments due to short-run discounting, and the most meaningful uplift in CPU speeds has coincided with 5G radios (for obvious signal-processing reasons). Because the lowest-priced segment doesn't yet feature 5G, those processors have remained stubbornly slow, even if they get cheaper every year.

This data is from a series I publish; the latest update is here and includes multi-core scores:

https://infrequently.org/2025/11/performance-inequality-gap-...

Mobile devices rarely last beyond the 5 year mark, although the age span has been increasing in the past several years and the resale market is booming thanks to inflation, geopolitical instability, and a global cost-of-living crisis.

Hey Domenic,

Sucks to be corresponding via The Second Worst Website In The World (TM), but here we are. Hope all's well on your end.

A minor correction from Edge's perspective: we've participated in OT using Phi models, but have not shipped to Stable, and are unlikely to given the current shape of things. Developers have not given us feedback that they're relaxed about compatibility, but I would obviously welcome that sort of data in case anyone has it to hand.

Best,

Alex

That's the inspiring thing about the EU and UK regulatory frameworks: the penalties can be more than a slap on the wrist. Apple is playing a dangerous game by continuing to flout EU law and pursue a maximalist, scorched-earth strategy. Reputation matters, and they are not making friends by re-upping false arguments at every turn.

"TL;DR: The UK’s Competition and Markets Authority (CMA) has officially designated Apple as having Strategic Market Status (SMS). After four years investigating Apple’s restrictions on browser engines and web apps, the CMA now has statutory authority to enforce remedies proposed in its Market Investigation Reference completed this year.

The most important outcomes being:

- Apple can be compelled to allow third-party browsers on iOS to use their own engines.

- Apple can be compelled to provide equivalent access to functionality for browsers using their own browser engines.

- Apple can be compelled to let third-party browsers install and manage web apps using their own engines.

- Apple can be compelled to remove barriers to web app adoption, such as implementing a web app equivalent to smart banners or install prompts in iOS Safari."

It's not insane that you have to explain it to me, because your premise is _wrong_. Go look at the founding documents for web SDOs. Voluntary adoption is foundational to the entire effort, and as I keep pointing out, Apple is the only party that has undermined it:

https://infrequently.org/2025/09/apples-crimes-against-the-i...

Let's try this again: was Apple wrong to ship Storage Access ahead of everyone else?

https://caniuse.com/mdn-api_document_requeststorageaccess

In the world you want, how should leadership in designs manifest when there isn't consensus? Should nothing ship? And who does that help?

Author here. You seem to have missed the bleedingly obvious point that responsibilities are a function of scale.

Nothing you allege was missed, and indeed it was considered at length in the longer series on these topics:

https://infrequently.org/series/browser-choice-must-matter/

That's not how any of this works;

https://infrequently.org/2025/09/standards-and-the-fall-of-i...

The author here.

It will seem odd to most, but my big concerns about Chrome relate to Android and ChromeOS. In neither environment did Chrome win share competitively. I think this has made them weaker and less useful, and that was mirrored in the tremendous difficulty we had in getting expansions of web capabilities done within the Chrome team, nevermind what I am documenting in this most recent post.

Sadly, the CrOS problem will be partially resolved when Google trashes it with Android rebasing in upcoming releases. On the Android side, Google is still withholding WebAPK support from competitors (suppressing PWAs on Android) and has failed to follow Apple's lead on hotseat browser replacement when choice screens are shown in the EU.

But neither of the bad effects are nearly as structural or impactful as Apple's out-and-out suppression of the web on mobile, because wealthy people carry iPhones and they have all the power:

https://infrequently.org/2025/09/apples-crimes-against-the-i...

Original author of the article here; I went out on a limb to document a bit of this in a footnote to a post a few years ago. Saying that it is unusual to call this behaviour out is a drastic understatement:

https://infrequently.org/2023/02/safari-16-4-is-an-admission...

And it was only this year that I wrote up the broader thesis:

https://infrequently.org/2025/08/how-do-committees-fail-to-i...

Most of my current and former colleagues wouldn't dare for (legitimate) fear of reprisal in the form of even worse blockage in important design areas.

I'm simply pointing out that Apple declined to try to constructively solve the problems developers expressed, demurred from engaging in design work in many areas, and did not ship alternatives instead (as it could have, and did in the past when Safari/WebKit were not on a starvation budget).

The downsides to this are not lost on me. Why do you think I'm making an issue of it publicly now? We tried literally everything else. This is last resort stuff. The goal is always more collaboration, and through it, better, better-funded, and more capable browsers. Apple is the unique obstacle to all of that today.

That's simply a misunderstanding of how features come to the web. There is no immaculate conception for web APIs. No magical room in which they are dreamt up, or spring fully-formed from the head of Zeus.

Instead, they come from open, honest, iterative design (when done well), and shipping ahead of others is risky, but that's why we designed the Blink Launch Process to demand so much pre-work (specs, tests, origin trials, good faith attempts to include other vendors in design, etc.) in order to launch that way.

Some background on these points here:

https://infrequently.org/series/effective-standards-work/

https://youtu.be/1Z83L6xa1tw?si=939PBH4_idtZGI6Y

As to, "should Apple follow Chromium's lead", perhaps ask "how would that be different than today?"

See:

https://infrequently.org/2023/02/safari-16-4-is-an-admission...

And:

https://infrequently.org/2025/06/the-ghost-of-christmas-past...

The author here. It wasn't addressed in this post because it was treated separately several years ago in the same series (linked at the top):

https://infrequently.org/2022/06/apple-is-not-defending-brow...

TL;DR is that the premise of the argument is false, or at least almost entirely so, and deprives Apple of agency, when in fact it has all the power in the equation.

0 for 2. Impressive.

Fixed.

It's the new mobile UI, built on Web Components (via Lit), and it's much faster. Parts of it have apparently already migrated to the old experience.

Author here.

So, if you read the post, you probably saw this:

https://infrequently.org/2023/02/the-market-for-lemons/#fn-t...

The little model there helps us distinguish types of sites, and so the very first thing to do is to note that you probably aren't building one of these.

But let's say you are!

In that case, it might help you to know that I've consulted with 4 of the 5 teams you mention, and because they have high management maturity, they often make choices that look different than the stacks you're being pitched at JS conferences.

Outside the editing canvas itself (a 20+ year old codebase ported to WASM), Adobe realised they couldn't afford the overhead of using React the "usual" way and have moved to Lit-based Web Components for PS:

https://web.dev/ps-on-the-web/

YouTube is made of Polymer Web Components, and before that (for most of it's history) was a server-rendered Python frontend with progressive enhancement.

Maps is built on the usual Google frontend tech (Closure Library, Soy, etc.), and while that means it's still lugging around a lot of legacy cruft, it performs because the team both works hard to keep it in check and that the tools started in an era that (correctly) assumed that CPU and bandwidth are not plentiful on the client.

Figma uses React outside the canvas, but their team also includes former browser engineers. They don't use it naïvely. Nor does Excalidraw, as the author knows where the (latency) bodies are buried.

In all these cases, the reason these experiences work well is management maturity, not tech. Strong teams that need to have deep local interaction respect the problem and usually make choices that go against the "HN consensus" because better user experiences matter more than in-group signaling:

https://infrequently.org/2022/05/performance-management-matu...

Most are from a world that is better, but which the complexity merchants have convinced (thanks to asymmetric information) all but their closest competitors to replace with unwieldy tech.

E.g.:

https://app.speedcurve.com/benchmarks/usa/retail/fast/fully-...

The fast sites on "legacy" stacks have 1/10th the COGS for the same performance versus the absolutely stupid costs invoked for React/NG/Ember/etc. SSR + hydration.

Which brings up the real issue: when the framework is both baseline-costly and runtime nasty, metrics like INP will suffer without extraordinary controls. When you see a React site in the list above, it's a fair guess that I've talked with their tech teams and they have felt trapped between unsubstantiated narratives and the reality that shipping React-based sites is losing them tons of money.

The antidote is a frank discussion of up-front cost vs. per-interaction latency. And we aren't having that debate right now. Presumptively the careers of the last decade's charlatans depends on us not levelling up. It's the only reason I can peep for why we haven't evolved past new ways to spell old ideas.

Author of the article here.

TL;DR: your JS is probably worse than you think. Write HTML and CSS instead. It will go better for everyone. And feel free to ignore the most popular JS framework vendors; they have not known what they are talking about for at least a decade.

Hey; OP here. Thanks for taking the time to read.

Something I've tried to highlight in other posts, and perhaps skimped on in the verbiage around the lists, was that results for users are the result of culture, not technology. I've worked with teams that absolutely killed it using slow-as-molasses tools (React, Angular...even Ember), and I've seen teams screw things up with "fast" tools.

But the outliers are just that. In the main, what I observe as most determinative of good outcomes is the marriage of stack complexity with management (which can be at the TL level, not necessarily PMs or EMs) that has the capacity to wrestle with the dimensions of complexity a stack presents.

This writeup (linked from the original article) might be helpful in outlining the way culture is co-variate with good outcomes and _tends_ to select for more appropriate tooling:

https://infrequently.org/2022/05/performance-management-matu...

Hard pass:

https://www.webpagetest.org/video/compare.php?tests=230205_B...

You might try https://sh.reddit.com

Device performance has been growing in diversity as we approach smartphone saturation (the last couple of hundred million flipphones getting traded for < $100 low-end smartphones). I'm working on an update to this series, but here's a recap from last year:

https://infrequently.org/2021/03/the-performance-inequality-...

As this relates to latency, JS-mediated UI is slower to materialize for a host of reasons, not least of all the problems with getting it across the wire (as you note). Naive SPA designs tend to serialize what should be parallel (data fetching and shell setup). Getting better at this requires more sophistication, whereas teams that stick to basic HTML + light progressive enhancement tend to end up with simpler systems that are faster for light-to-medium session depths and are easier to diagnose/fix when things go sideways.

OP here; at a tactical level, prefer HTML/CSS and MPA architecture until you have firm evidence of long sessions and many interactions per session that justify JS, and when you add JS to smooth a common interaction based on data, build from progressive enhancement unless it's impossible (e.g., a text or image editor).

More pithily, maybe PHP was good, actually?

Popping up a level, this isn't about tools, it's about culture and how we decide to choose. I work every day with teams that need to claw back to sanity from years in the JS fever swamps, and nobody's having a good time when launches are blocked on terrible perf, a11y, etc. The root issues here are down to complexity and eng/management capacity to master it. What gets teams in trouble is picking stacks that have mountains of implicit complexity without attendant controls.

Some of that is captured in this post; hope it helps:

https://infrequently.org/2022/05/performance-management-matu...

The Web Push Standard supports e2e encryption for messages sent from your app to the device:

https://web.dev/push-notifications-web-push-protocol/#the-pa...

Original author of the post here. I'm also a Blink API OWNER, so can happily report that Container Queries have 3 LGTMs and will ship in Chromium browsers very shortly, likely 105 (shipping to Stable in September):

https://chromestatus.com/feature/6525308435955712

Subgrid is progressing thanks to engineering from the Edge team, and I expect it to land this year.