13 ms·

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 entir

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.

manigandham 10y ago
> 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/connection 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.
- JustSomeNobody 10y ago
  > 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.
  - blowski 10y ago
    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.
    - douche 10y ago
      I'd still like unadulterated HTML with some images sprinkled in. Content > presentation
      - firasd 10y ago
        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.
        stan_rogers 10y ago
        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.
        Dylan16807 10y ago
        > 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.
      - wwweston 10y ago
        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).
- webartisan 10y ago
  `navigation.connection` only tells if the user is on cellular/wifi. While this is certainly helpful, cellular connections themselves can vary enormously.
  - manigandham 10y ago
    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/ 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.
    - Klathmon 10y ago
      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)
      - manigandham 10y ago
        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.
    - Dylan16807 10y ago
      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.
firasd 10y ago
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.)
- mattmanser 10y ago
  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.
  - firasd 10y ago
    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.)
deleted 10y ago
[deleted]
id122015 10y ago
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
Klathmon 10y ago
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.
- vacri 10y ago
  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.
  - mjevans 10y ago
    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.
inian 10y ago
Part of this problem is solved via the Client Hints spec (http://httpwg.org/http-extensions/client-hints.html#save-data 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!
FussyZeus 10y ago
> "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.
- damptowel 10y ago
  > 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.
petercooper 10y ago
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.
- sillysaurus3 10y ago
  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.
- toomanythings2 10y ago
  Navigation Timing API https://developer.mozilla.org/en-US/docs/Web/API/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.
  - petercooper 10y ago
    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?hl=en https://developers.google.com/web/updates/2016/02/save-data?... .. The header is: Save-Data: on.
- petercooper 10y ago
  It's this: https://developers.google.com/web/updates/2016/02/save-data?hl=en https://developers.google.com/web/updates/2016/02/save-data?... .. the header is: Save-Data: on.

manigandham 10y ago

> 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/connection 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.

JustSomeNobody 10y ago
> 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.
- blowski 10y ago
  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.
  - douche 10y ago
    I'd still like unadulterated HTML with some images sprinkled in. Content > presentation
    - firasd 10y ago
      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.
      - stan_rogers 10y ago
        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.
        Dylan16807 10y ago
        > 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.
    - wwweston 10y ago
      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).
webartisan 10y ago
`navigation.connection` only tells if the user is on cellular/wifi. While this is certainly helpful, cellular connections themselves can vary enormously.
- manigandham 10y ago
  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/ 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.
  - Klathmon 10y ago
    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)
    - manigandham 10y ago
      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.
  - Dylan16807 10y ago
    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.

firasd 10y ago

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.)

mattmanser 10y ago
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.
- firasd 10y ago
  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.)

deleted 10y ago

[deleted]

id122015 10y ago

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

Klathmon 10y ago

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.

vacri 10y ago
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.
- mjevans 10y ago
  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.

inian 10y ago

Part of this problem is solved via the Client Hints spec (http://httpwg.org/http-extensions/client-hints.html#save-data 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!

FussyZeus 10y ago

> "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.

damptowel 10y ago
> 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.

petercooper 10y ago

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.

sillysaurus3 10y ago
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.
toomanythings2 10y ago
Navigation Timing API https://developer.mozilla.org/en-US/docs/Web/API/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.
- petercooper 10y ago
  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?hl=en https://developers.google.com/web/updates/2016/02/save-data?... .. The header is: Save-Data: on.
petercooper 10y ago
It's this: https://developers.google.com/web/updates/2016/02/save-data?hl=en https://developers.google.com/web/updates/2016/02/save-data?... .. the header is: Save-Data: on.