Thread by @slightlylate

So @maxlynch hit me right in the feels with this one:

https://twitter.com/maxlynch/status/1446490027182145537?s=20

I have deep, deep regrets that I have not been able to convince browser makers to refuse to load 2.7MB of JS, critical path, served uncompressed.

https://twitter.com/slightlylate/status/1446521275959021576

Browser teams (the folks who work on UI) don't think of content as "their problem". For historical reasons, they care about TLS and that has helped them make common cause with security interests.

But no such enlightenment has occurred around performance...and in particular, perf so bad that it endangers accessibility.

Platform teams, meanwhile, focus on making the runtime faster, rather than building common cause between users on high-end and low-end devices.

At the extreme, platform managers can be convinced to invest in dealing with some of the squeakiest wheels, but not in effective ways.

Using browser UI and platform/devtools pressure to push back on behavior that will predictably suck for users is ~~controversial~~

Nevermind that this is the *EXACT* playbook that has worked so effectively in the security domain.

Interlocking platform, browser, and devtools changes have migrated a RIDICULOUS amount of traffic to be encrypted on the wire.

transparencyreport.google.com/https/overview….

This involved potential breakage of HUGE amounts of content!

But we did it.

How? By pre-committing URL bar pixels to the cause:

wired.com/2016/11/google…

What browser makers put in ever-present UI is what they *actually* care about.

Browser makers, as a class, DO NOT CARE about sites that are so slow as to be functionally inaccessible by a huge majority of users.

BUT -- they will say -- look at all the features we added! Lite modes! Reader modes! Slow-link detection!

The common thread between these features is that, like the platform performance optimisation work that toils on endlessly, they must attempt to make change without ever confronting the wealthy and the enfranchised with the reality that these websites are failures.

So decision makers -- CEOs, CTOs, marketing leads, etc. -- are never perturbed with the reality that their own websites are failing everyone.

But they'll sure as hell know if there is stray mixed content.

Into this voide a disturbing, now-perennial denial has emerged.

Web developers do not *have* to fix performance for the least of these, our users, and so they do not.

Instead, they lean into the most "modern" tools.

Are they good?

No. Not in terms of results.

Let me say that again: modern web development is a failure.

This is not even the dozenth public-sector, critical infrastructure that I've seen sunk by Modern Webdev.

Are there lots of things going on here?

Yes! And that's the failure.

The systems developers are encouraged to use are so complex they *TEND* to fail.

*CAN* they be good? Of course.

But the reduction to a single example is, like all discussions of performance, an epistemic failure.

You have to look at the distributions.

...and the distribution of web pages that do OK by most users most of the time that are primarily HTML and CSS vs. those that are mostly JS is shockingly different.

RIP my notifications as everyone piles into "ok, but doesn't Core Web Vitals cause people to care?"

And the answer is: at the margin.

Do we need that margin of improvement? Yes, but others too.