It's surprising that so many good tools are regretted because of lack of clear documentation and intuitive API (looking at you, Webpack).

No, a good user experience is not a luxury you can afford to omit. Stop creating backlog tickets to "simplify code". It's just plain selfishness.

`navigation.connection` only tells if the user is on cellular/wifi. While this is certainly helpful, cellular connections themselves can vary enormously.

There is connection.type (bluetooth, cellular, ethernet, wifi, wimax, other, mixed, unknown, none) and connection.downlinkMax (megabits/sec of the first hop) both available.

You can read the W3C draft for more details: https://w3c.github.io/netinfo/

It's not perfect but far better than nothing. It's relatively easy to figure out a "slow" profile based on both device and connection and optimize some of the heavier resources.

But even then there is only so much the application can (and should) do.

I don't want my application making decisions like trading download speed/size for battery life (better compression, etc...), or deciding to sacrifice quality because it thinks I don't want to wait.

We need APIs that let the useragents choose what they want, and let the users configure their useragent (or choose one that aligns with their ideas at the moment).

Like how srcset works, build APIs that let developers offer up several different assets, and let the useragent choose which is best for that moment (combining preferences for battery-life, connection speed, connection-capping and how close to the cap you are, preferred load time, and if it should "upgrade" to a better resource at a later time if possible)

Sure, better capabilities reporting + user control is the ideal. This will take a long time though considering how slow this all moves so incremental progress is still good until we get there.

Very interesting, but how does requesting an optimized version of seemingly a gazillion different pages by a billion different authors magically make any of that happen? From what I've seen, web devs throw the kitchen sink even on mobile.

I suppose that could be useful, but max downlink is the least useful metric they could have gone with. The times when I need traffic minimization the most also tend to be times when max downlink and average downlink are very far apart.

True, but the poor browser support for connection type and even poorer support for downlink means it cannot be relied on all the time.

Very true.