With my unlimited fibre connection on my MacBook Pro, I'd prefer to have a web experience that looks amazing - even if it's 5MB per page. Saying 'the smallest amount of data possible' is a truism, but it's not particularly helpful.
Yes but the resolution of those "some images" depends on what kind of connection/device you're on. It's not adequate to say 'just send the lowest bandwidth experience', because then every desktop browser on a 5mbps connection would get blurry low-res images and Arial/Times New Roman text intended for iPhone 4 on a 2G connection.
I would always like to have locally-installed fonts in preference to web fonts, regardless of connection speed (Arial and Times New Roman are hardly the only options), and right-sized, well-compressed images (in the appropriate format for the image type) are essentially a solved problem.
> right-sized, well-compressed images (in the appropriate format for the image type) are essentially a solved problem.
An image with retina resolution is going to be pretty bulky if you want it to look crisp, even if you're doing a good job of optimizing.
If you're on a bad connection you probably want non-retina and aggressive compression, even though it can introduce blurs and artifacts. That can give you a file over ten times smaller.
You'll fit in better in 2016 if you have leprosy but are killing it with a photo-heavy bootstrap theme + Angular SPA (with, of course, a healthy number of bower modules brought in).
`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.
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.
IP databases can be used to check if the device is on a mobile connection from a telco. There is also the experimental navigator.connection property: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/c...
> I would like the smallest amount of data possible
This is and should always be the default. It's the heavy content experiences that should be explicitly initiated by the user.