Hacker News Reader

Comment by gabemart | Hacker News Reader

Why isn't there a way for devices to indicate to a server if they are on a slow or data-capped connection?

It seems like "responsive" web design is based entirely around the size or pixel-density of a device's screen. But why can't the experience respond to the speed of a user's connection, or the amount of data the user can afford to download?

My phone already knows I have a hard data cap when I'm off wifi. Why can't it include a field in its request to every web server indicating I would like the smallest amount of data possible, and then properly configured servers can respond by omitting large images, videos, font files, etc. We have srcset for images, but AFAIK choosing which image to use is still based on screen size rather than bandwidth. And we need to get beyond srcset - as a content creator, I want to be able to mark some images and other heavy resources as optional, so I don't reference to them at all to bandwidth-sensitive devices.

View on HN

As much as HN hates adding stuff to browsers, this is something that needs to be controlled by the useragent, not the application.

Have the user tell their browser that the connection is metered, then have the browser request smaller assets, don't preload anything, maybe give the ability to mark some things as "optional", etc...

And by doing it that way it's easily "backwards compatible". Phones that don't understand the "this image is optional" attribute will just continue to render it, but those that do and know not to show them won't.

At $JOB-2, the CEO was clear in the application design that there were two classes of network: "free", and "expensive". If it's "free", do whatever; "expensive", minimise everything tenable.

I think this is quite probably the minimum possible distinction.

Either you have /unmetered/ and /fast/ and /low latency/... or you fallback to a design where every byte matters.

> Why isn't there a way for devices to indicate to a server if they are on a slow or data-capped connection?

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.

> This is and should always be the default. It's the heavy content experiences that should be explicitly initiated by the user.

This is the correct solution. Wanting the phones to send speed and cap info is just ... looking for a bandage.

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.

I'd still like unadulterated HTML with some images sprinkled in. Content > presentation

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.

One size does not fit all.

Good luck with that.

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.

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.

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.

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.

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

Lazy-loading (the practice being somewhat criticized here) is actually halfway to that goal. The BBC (cited in this article) also uses a technique they call 'cutting the mustard', which checks which features are available on the browser to determine which JS to run. So bandwidth can be one of the things tested when doing JS-based optimization like this.

I agree that CSS-based responsive design just comes up inadequate when we want real optimization. We have to use JS based methods like deferred/lazy loading, detecting features, bandwidth, etc. (With images you can also have a <noscript> tag that loads the image immediately in no-JS scenarios, but it's difficult to figure out alternatives for lazy-loaded fonts and other things.)

Have you used the BBC site on a mobile?

It sucks ass and has done for a while. Blank spaces where pictures should be, suddenly fading in a few seconds too late, pixelated pictures that later resolve, elements change height and jump around the screen as it loads. Even though the text is there, you shouldn't bother starting to read it as it's just going to jump around in a few seconds.

It's precisely the sort of shitty site that the article is complaining about.

The guardian is another terrible site that's "mobile optimised" and have the cheek to give other developers advice on how to code for mobile, even though the site is an absolute nightmare to use. They have expanding sections on the homepage. You click a story, read it, and go back and the page takes 10 seconds jumping around to sort itself out. And worse still is the shitty adverts suddenly popping in after 20 seconds and causing you to lose position I the story you're reading.

HN and its basic style are much more useable than either the BBC or the guardian mobile sites.

It's like the developers don't understand that the reason I'm there is for the text and the pictures, not for the UI. So treat them as king and load them first and never, ever move them once they're loaded.

But blank and pixellated images that get filled out later are what I'd recommend. The alternative is looking at a blank screen while your browser makes upfront HTTP requests for images, which can delay render-blocking resources like a stylesheet from loading quickly (thus seeing no text on the page until everything loads.)

I understand what you mean about if the layout changes while reading then there's little value in rendering text upfront. But the solution is to reduce layout reflow, not to go back to the bad old days where we don't optimize/defer resources.

So for example, if an image is 200px in height and is lazy-loaded, we should let the placeholder be 200px in height. If the placeholder has 0 height and then the image loads and reflows the page, that messes up the UX. Same with other elements that change page layout. (Also caching things once they are loaded, so the example you mention of hitting the back button and waiting for everything to reflow again doesn't happen.)

> So for example, if an image is 200px in height and is lazy-loaded, we should let the placeholder be 200px in height.

No, you should simply specify the size in the IMG element. People who care about this stuff have been doing this correctly for 15 years or more. Just as people have been advocating for what now has been labeled with the buzzword "responsive design" since then. People who cared told you 15 years ago that fixed-width layouts are stupid because they won't display properly on phones (among many other reasons which were more relevant back then). This has all been a solved problem for a long, long time, if only people cared. But they still don't, still piling on more complexity and more bloat in an attempt to "fix" things.

Yes, by "placeholder" I mean the IMG element that loads with an initial low-res/default "src" attribute. Then the actual, higher-bandwidth image will load by updating the "src" attribute.

No, you don't use an initial low-res/default source that you later switch; you specify the actual damned image in the source and use the width and height attributes.

Please follow the thread of the conversion. I'm talking about how to mitigate the page reflow issues that the posted article is talking about when lazy loading images and other resources.

Except it actually makes the problem worse, whereas the age-old solution actually solves it.

If you specify a placeholder, that placeholder still has to be loaded, and as long as it hasn't been loaded, the dimensions are unknown, leading to reflow when the placeholder has been loaded. Plus, it adds even more bandwidth usage (for the placeholder and the javascript code), more CPU/battery usage (you have to execute javascript and decode an additional image (the placeholder)). Plus, it doesn't work without JS. Lazy loading of images in JS is just a dumb idea.

If anything, that might be a sensible feature of mobile browsers, which would only have to implement it once for it to work on all sites (instead of bloating each and every website with it), which could more easily have access to information about available connectivity, and which could also do it so much more easily, as the browser's rendering engine has a lot more clue which images currently are in the viewport.

Except it actually makes the problem worse

Nope. On real world websites, deferring images, fonts, and making other optimizations can reduce time-to-first paint significantly. That drives real UX and business results (imagine clicking a link and waiting for 7 seconds to see the heading on the page vs. waiting 1.5 seconds.) There's a reason all these websites practice lazy-loading and Google takes time-to-first-render seriously enough to impact search ranking.

If anything, that might be a sensible feature of mobile browsers

Sure, I would be happy if browsers introduced something like a "lazyload" attribute on images/JS/fonts etc. There is something like that for <script> tags (defer, async) but it still downloads the script ASAP. I need something that gets the text and CSS, shows it on the page, and then opens the HTTP connections for other stuff.

That makes the end device have to download a large image, which isn't particularly optimal for bandwidth, data cap, CPU usage, and battery life. It's not as simple as one-size-fits-all, because it really doesn't.

Part of this problem is solved via the Client Hints spec (http://httpwg.org/http-extensions/client-hints.html#save-dat...) When the user turns this on in his preferences, Chrome sends this data to the server as a header and the server can respond accordingly. Your server can decide what images to omit or other optimisations if it sees the header. But this setting is applied at the browser-level and is not per connection.

The NetInfo API can help in this case but the current spec is still not the best way forward. For example, even if the user is on Wifi, he may be on someone's tethered network and might still want to get a light-weight page. Conversely, some cellular connections might have a very high limit and the user might want to get the best possible experience even though he is on a 3G network.

A user-preference per network connection type would be cool to have!

> "Why isn't there a way for devices to indicate to a server if they are on a slow or data-capped connection?"

Why do you need it? Are your fancy fonts, 1 meg CSS file, or 1 meg of Javascript that essential to the function of your website that you absolutely must have them? And if not, what are they doing there?

I've spent many years writing many websites, including more intense applications that juggle a decent amount of data. There are a select few things where you really do need a lot of code in the backend, but far too often I encounter work done by designers press ganged into development (bad, but understandable) or work done by lazy developers who need a framework to center an image (bad, not understandable, you should know better) that results in web pages that peak into Pinterest levels of bloat.

If you're juggling analytics data or managing the CMS of a large site, yes you'll need a large site in turn to do that. Literally everything else should be as small as possible and load as quickly as possible on whatever device is querying, end of story.

> Why do you need it? Are your fancy fonts, 1 meg CSS file, or 1 meg of Javascript that essential to the function of your website that you absolutely must have them? And if not, what are they doing there?

I wonder myself this every time this discussion flares up.

Stack Overflow awnsers that tell fledgling devs 'you can use framework x function y to solve problem z' are particulary irksome.

Why isn't there a way for devices to indicate to a server if they are on a slow or data-capped connection?

There is. I'll update this post if I remember what it is, but I believe there's a spec and Chrome Canary is supporting it. It uses an HTTP header.

Rather than rely on specs or browser support, why not simply measure how quickly data is being downloaded?

That wouldn't help on the first page load, but it would make the information available on subsequent loads.

Navigation Timing API https://developer.mozilla.org/en-US/docs/Web/API/Navigation_...

I have a feeling there is something else but I have trouble remembering it, too, and I bet I have it bookmarked to study when I have the need to use it.

That's a good one, but it wasn't that.

It's something that literally gets clients to add an HTTP header to specify that bandwidth should be "saved".

Actually, that reminded me of what it was called.. haha, it's https://developers.google.com/web/updates/2016/02/save-data?... .. The header is: Save-Data: on.

It's this: https://developers.google.com/web/updates/2016/02/save-data?... .. the header is: Save-Data: on.

when I opened a topic a few days ago saying that mobile version of Gmail no longer works with JS toggled off, I got a reply pretending that JS doesnt pose a problem. As if all those Analytics and Ads were not powered by JS

Reply on news.ycombinator.com