6 ms·

Something I have had at the back of my mind for a long time: in 2017, what's the correct way to present optional resources that will improve the experience of u

Something I have had at the back of my mind for a long time: in 2017, what's the correct way to present optional resources that will improve the experience of users on fast/uncapped connections, but that user agents on slow/capped connections can safely ignore? Like hi-res hero images, or video backgrounds, etc. Every time a similar question is posed on HN, someone says "If the assets aren't needed, don't serve them in the first place", but this is i) unrealistic, and ii) ignores the fact that while the typical HN user may like sparsely designed, text-orientated pages with few images, this is not at all true of users in different demographics. And in those demos, it's often not acceptable to degrade the experience of users on fast connections to accommodate users on slow connections. So -- if I write a web page, and I want to include a large asset, but I want to indicate to user agents on slow/capped connections that they don't _need_ to download it, what approach should I take?

gnud 10y ago
Random idea: Get the current time in a JS block in the head, before you load any CSS and JS, and compare it to the time when the dom ready event fires. If there's no real difference, load hi-res backgrounds and so on. If there is a real time difference, don't.
- curun1r 10y ago
  Wouldn't that be measuring latency more so than bandwidth? You'd run the danger of confusing a satellite internet connection (high(ish) bandwidth, high latency) with a third-world, low bandwidth connection.
  - ggreer 10y ago
    Satellite ISPs have low data caps and/or charge a lot per GB of transfer. Avoiding unnecessary downloads seems like the correct behavior in this case. I think the best solution would be an optional http header. That way, the server could choose to send a different initial response to low-bandwidth users. If connection speed is solely available via JavaScript API or media query, then only subsequent assets can be adapted for users on slow connections.
neuland 10y ago
One hack-y way to do it would be to load it via JavaScript. For example, see this stackoverflow [0]. Obviously not a great solution, but it works if your dying for something. I bet people w/ slow connections are much more likely to disable javascript, though. let loadTime = window.performance.timing.domContentLoadedEventEnd- window.performance.timing.navigationStart; if (loadTime > someArbitraryNumber) { // Disable loading heavy things } [0] http://stackoverflow.com/questions/14341156/calculating-page-load-time-in-javascript#14878493 http://stackoverflow.com/questions/14341156/calculating-page...
- gnud 10y ago
  It's too late to disable loading heavy things at that point - the loading is already started. Do the opposite, start loading heavy things if the page loaded quickly. A clean way would be to set one of two classes, connection-slow or connection-fast, on the body element. Then you could use those classes in CSS to choose the correct assets for background images, fonts and so on.
  - neuland 10y ago
    Well, I meant to leave the heavy things out of the HTML you send over to the browser and then inject them only if they can be loaded. So, yeah totally agree with you. Should have been clearer.
  - ComodoHacker 10y ago
    >start loading heavy things if the page loaded quickly ...and not loaded from cache. You need a way to determine this reliably. AFAIK there's no way to determine this for the main page itself.
chpill 10y ago
I think this is an important question. Like another reply to your comment, I thought about having a very small js script in the header puting `Date.now()` in a global, then on page load, having another script checking the amount of time that had passed to see if it was worth downloading the "extra" at all. But then again where do you put the threshold? Has anyone tried this with some degree of success?
curun1r 10y ago
This seems like the thing that we'd want cooperation with the browser vendors rather than everyone hacking together some JS to make it happen. If browsers could expose the available bandwidth as a media query, it would be trivial to have different resources for different connections. This would also handle the situation where the available bandwidth isn't indicative of whether the user wants the high-bandwidth experience. For example, if you're on a non-unlimited mobile plan, it doesn't take that long to load a 10mb image over 4G, but those 10mb chunks add up to overage charges pretty quickly, so the user may want to set his browser to report a lower bandwidth amount.
- rev_bird 10y ago
  >If browsers could expose the available bandwidth I don't know why this seems like such an imposition, but I think I'd be uncomfortable with my browser exposing information about my actual network if it didn't have to. I have a feeling way more people would be using this to track me than to considerately send me less data. That said, browser buy-in could be a huge help, if only to add a low-tech button saying, "request the low-fi version of everything if available." This would help mobile users too -- even if you have lots of bandwidth, maybe you want to conserve.
  - Aeolun 10y ago
    I think if someone wants to track you, the bandwidth is not the first thing they'll be looking at. It's just another signal, but there's already a few tens of them, so adding one more is not going to make a significant difference.
    - blixt 10y ago
      If you consider every identifying piece of information as a bit in a fingerprint, it makes more than a significant difference; it makes an exponential difference. Consider the difference between 7 bits (128 uniques) and 8 bits (256 uniques) and then 15 bits (32K uniques) and 16 bits (65K uniques). Every additional bit makes a difference when fingerprinting a browser.
  - 10y ago
splatcollision 10y ago
Design your UX so that any large assets can be requested at will by the user, and indicate the file size? That way it's the user's choice if they want to load that large video over their slow network, etc.
- tempestn 10y ago
  Most users on fast connections are not going to enjoy explicitly clicking to download every background image, font, etc. For videos it might make more sense, but there are many more optional assets to deal with.
  - flukus 10y ago
    Background images and fonts are examples of things probably not needed at all. I already have fonts on my computer, I don't need yours.
    - tempestn 10y ago
      I have to agree with the original comment here: > Every time a similar question is posed on HN, someone says "If the assets aren't needed, don't serve them in the first place", but this is i) unrealistic, and ii) ignores the fact that while the typical HN user may like sparsely designed, text-orientated pages with few images, this is not at all true of users in different demographics.
      - flukus 10y ago
        I think your underestimating how perceptibly slow the internet has become for a lot of people. They don't realise they're downloading 2MB of JavaScript, they don't realise what JavaScript or css are. They'll say things like "I think my computers getting old" or "I think I have a virus". More often than not this is just because they're favourite news site has become so slow and they can't articulate it any better than that. All they want to do is read their text oriented news sites with a few images.
tommorris 10y ago
There is a proposed API for that. https://wicg.github.io/netinfo/ https://wicg.github.io/netinfo/ And like most such APIs, it has been kicked around for a long time and it has only been adopted by Chromium on Android, ChromeOS and iOS. It'd be great if it were more widely adopted...
- disposablename 10y ago
  Yay, more browser fingerprinting data points!
  - tommorris 10y ago
    Well, to be fair, as the spec notes, you can already fingerprint on speed by timing how long an AJAX call takes. Also, "on a shit home DSL connection" doesn't really distinguish me from millions of other UK residents.
    - mod 10y ago
      Yes it does, when used in combination with the other data points. That said, I always get "unique" on those fingerprinting tests. You can't be "extra unique," so I guess I don't mind it.
pilom 10y ago
We outsource this to CloudFlare and their Mirage service: https://support.cloudflare.com/hc/en-us/articles/200403554-What-Does-Mirage-Do- https://support.cloudflare.com/hc/en-us/articles/200403554-W...
Chyzwar 10y ago
Server side logs and sessions. You should be able to tell users devices/browser and what bandwidth they operate. Then calculate average speed they use. You could then create tiered service where media quality and JS features can be adjusted. You will periodically process logs to make sure that grouping is still correct. As additional feature users could choose in theirs setting what tier they want to use. On client side, You can achieve some of this by heavy use of media queries. https://msdn.microsoft.com/en-us/library/windows/apps/hh453556.aspx https://msdn.microsoft.com/en-us/library/windows/apps/hh4535... You can basically manipulate resolution/disable of assets based on screens quality. This is under assumption that someone with retina screen will have decent internet.
gnarly 10y ago
Simple. Design your webpages to only load the functional lighter weight essential stuff by default. Then use javascript to add in all the large assets you want. Users with slow connections can browse with javascript turned off.
- aethertron 10y ago
  I like this solution. Unfortunately there is little consistency in how well browsers accommodate JS-less browsing. Firefox removed the ability to switch off JS from its standard settings panel. Brave lets you switch JS on/off for each domain from the prominent lionface button panel.
gkya 10y ago
> Every time a similar question is posed on HN, someone says "If the assets aren't needed, don't serve them in the first place", but this is i) unrealistic, and ii) ignores the fact that while the typical HN user may like sparsely designed, text-orientated pages with few images, this is not at all true of users in different demographics. And in those demos, it's often not acceptable to degrade the experience of users on fast connections to accommodate users on slow connections. This is prejudice. People use Craigslist, for example. If the thing is useful, people will use it. If there's a product being sold, and if it's useful to the potential clientele, they'll buy it. Without regard to the UI. In the past ten years while my connection speed increased, the speed at which I can browse decreased. As my bandwidth increased, all the major websites madly inflated. > So -- if I write a web page, and I want to include a large asset, but I want to indicate to user agents on slow/capped connections that they don't _need_ to download it, what approach should I take? Put a link to it with (optionally) a thumbnail.
- sjy 10y ago
  > People use Craigslist, for example. If the thing is useful, people will use it. If there's a product being sold, and if it's useful to the potential clientele, they'll buy it. Without regard to the UI. Craigslist achieved critical mass in the 90s, so it's not a good example. Many useful products disappear because they can't attract enough users to become sustainable. A nice UI can affect users' credibility judgments and increase the chance that they'll stick around or buy things. [1] http://dl.acm.org/citation.cfm?id=1315064 http://dl.acm.org/citation.cfm?id=1315064
aczerepinski 10y ago
I think srcsets are a reasonably proxy for this. Serve extremely optimized images to mobile devices, and the full images to desktops. It isn't perfect - you'll get some mobile devices on wifi that could have consumed the hero images and some desktop devices still on dial up, but it's still a lot better than doing nothing.
erikpukinskis 10y ago
Which demographic likes large images that are not necessary for the task at hand?
avhon1 10y ago
In the ideal future, FLIF [0] would become a standard, universally supported image and animation format. Almost any subset of a FLIF file is a valid, lower-resolution FLIF file. This would allow the browser - or the user - to determine how much data could be downloaded, and to display the best-quality images possible with that data. If more bandwidth or time became available, more of the image could be downloaded. The server would only have one asset per image. Nice and simple. [0] http://flif.info/ http://flif.info/
greenyouse 10y ago
I don't think there is an easy way to tell the browser not to download something because the connection is slow. Progressive enhancement can work well for giving users a basic page that loads quickly with minimal assets while also downloading heavier content in the background that renders later. That's still different than putting a timer on a request to download the content (which would require JS to detect the slow connection). If you make a page well it should render quickly under any network condition, slow or fast. As an example, you could try serving pictures quickly by providing a placeholder picture which uses lossy compression to be as small as possible. It could be byte64 encoded so it's served immediately even over a slow connection. Then after the page is rendered, a request could go out to download the 0.5Mb image and a CSS transition could fade the image in over the placeholder. People on fast connections wouldn't notice a change because it would load right away, while people on a 40kbit 2G connection would be OK with your page too. The requests to download larger content will still go out over a slow connection but the user won't suffer having to sit through seconds of rendering. Maybe similar to how people have done mobile-first responsive design, people could try doing slow-first design. Get everything out of the critical rendering path and progressively enhance the page later.
niutech 10y ago
There are two ways: 1. Serve the AMP version of your page (https://www.ampproject.org https://www.ampproject.org) which uses lazy loading and other optimizations 2. Use the Network Information API (https://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation https://developer.mozilla.org/en-US/docs/Web/API/NetworkInfo...) to load heavy assets only on high bandwidth connections.
ddebernardy 10y ago
Here's a proxy: buy a 1st-gen iPad, turn JS off, and then use it to browse the site. If it crashes the device, you're way off. If it's appreciably slow or clunky, find ways to improve it. Iterate until it's fast and usable.

gnud 10y ago

Random idea: Get the current time in a JS block in the head, before you load any CSS and JS, and compare it to the time when the dom ready event fires. If there's no real difference, load hi-res backgrounds and so on. If there is a real time difference, don't.

curun1r 10y ago
Wouldn't that be measuring latency more so than bandwidth? You'd run the danger of confusing a satellite internet connection (high(ish) bandwidth, high latency) with a third-world, low bandwidth connection.
- ggreer 10y ago
  Satellite ISPs have low data caps and/or charge a lot per GB of transfer. Avoiding unnecessary downloads seems like the correct behavior in this case. I think the best solution would be an optional http header. That way, the server could choose to send a different initial response to low-bandwidth users. If connection speed is solely available via JavaScript API or media query, then only subsequent assets can be adapted for users on slow connections.

neuland 10y ago

One hack-y way to do it would be to load it via JavaScript. For example, see this stackoverflow [0]. Obviously not a great solution, but it works if your dying for something. I bet people w/ slow connections are much more likely to disable javascript, though. let loadTime = window.performance.timing.domContentLoadedEventEnd- window.performance.timing.navigationStart; if (loadTime > someArbitraryNumber) { // Disable loading heavy things } [0] http://stackoverflow.com/questions/14341156/calculating-page-load-time-in-javascript#14878493 http://stackoverflow.com/questions/14341156/calculating-page...

gnud 10y ago
It's too late to disable loading heavy things at that point - the loading is already started. Do the opposite, start loading heavy things if the page loaded quickly. A clean way would be to set one of two classes, connection-slow or connection-fast, on the body element. Then you could use those classes in CSS to choose the correct assets for background images, fonts and so on.
- neuland 10y ago
  Well, I meant to leave the heavy things out of the HTML you send over to the browser and then inject them only if they can be loaded. So, yeah totally agree with you. Should have been clearer.
- ComodoHacker 10y ago
  >start loading heavy things if the page loaded quickly ...and not loaded from cache. You need a way to determine this reliably. AFAIK there's no way to determine this for the main page itself.

chpill 10y ago

I think this is an important question. Like another reply to your comment, I thought about having a very small js script in the header puting `Date.now()` in a global, then on page load, having another script checking the amount of time that had passed to see if it was worth downloading the "extra" at all. But then again where do you put the threshold? Has anyone tried this with some degree of success?

curun1r 10y ago

This seems like the thing that we'd want cooperation with the browser vendors rather than everyone hacking together some JS to make it happen. If browsers could expose the available bandwidth as a media query, it would be trivial to have different resources for different connections. This would also handle the situation where the available bandwidth isn't indicative of whether the user wants the high-bandwidth experience. For example, if you're on a non-unlimited mobile plan, it doesn't take that long to load a 10mb image over 4G, but those 10mb chunks add up to overage charges pretty quickly, so the user may want to set his browser to report a lower bandwidth amount.

rev_bird 10y ago
>If browsers could expose the available bandwidth I don't know why this seems like such an imposition, but I think I'd be uncomfortable with my browser exposing information about my actual network if it didn't have to. I have a feeling way more people would be using this to track me than to considerately send me less data. That said, browser buy-in could be a huge help, if only to add a low-tech button saying, "request the low-fi version of everything if available." This would help mobile users too -- even if you have lots of bandwidth, maybe you want to conserve.
- Aeolun 10y ago
  I think if someone wants to track you, the bandwidth is not the first thing they'll be looking at. It's just another signal, but there's already a few tens of them, so adding one more is not going to make a significant difference.
  - blixt 10y ago
    If you consider every identifying piece of information as a bit in a fingerprint, it makes more than a significant difference; it makes an exponential difference. Consider the difference between 7 bits (128 uniques) and 8 bits (256 uniques) and then 15 bits (32K uniques) and 16 bits (65K uniques). Every additional bit makes a difference when fingerprinting a browser.
- 10y ago

splatcollision 10y ago

Design your UX so that any large assets can be requested at will by the user, and indicate the file size? That way it's the user's choice if they want to load that large video over their slow network, etc.

tempestn 10y ago
Most users on fast connections are not going to enjoy explicitly clicking to download every background image, font, etc. For videos it might make more sense, but there are many more optional assets to deal with.
- flukus 10y ago
  Background images and fonts are examples of things probably not needed at all. I already have fonts on my computer, I don't need yours.
  - tempestn 10y ago
    I have to agree with the original comment here: > Every time a similar question is posed on HN, someone says "If the assets aren't needed, don't serve them in the first place", but this is i) unrealistic, and ii) ignores the fact that while the typical HN user may like sparsely designed, text-orientated pages with few images, this is not at all true of users in different demographics.
    - flukus 10y ago
      I think your underestimating how perceptibly slow the internet has become for a lot of people. They don't realise they're downloading 2MB of JavaScript, they don't realise what JavaScript or css are. They'll say things like "I think my computers getting old" or "I think I have a virus". More often than not this is just because they're favourite news site has become so slow and they can't articulate it any better than that. All they want to do is read their text oriented news sites with a few images.

tommorris 10y ago

There is a proposed API for that. https://wicg.github.io/netinfo/ https://wicg.github.io/netinfo/ And like most such APIs, it has been kicked around for a long time and it has only been adopted by Chromium on Android, ChromeOS and iOS. It'd be great if it were more widely adopted...

disposablename 10y ago
Yay, more browser fingerprinting data points!
- tommorris 10y ago
  Well, to be fair, as the spec notes, you can already fingerprint on speed by timing how long an AJAX call takes. Also, "on a shit home DSL connection" doesn't really distinguish me from millions of other UK residents.
  - mod 10y ago
    Yes it does, when used in combination with the other data points. That said, I always get "unique" on those fingerprinting tests. You can't be "extra unique," so I guess I don't mind it.

pilom 10y ago

We outsource this to CloudFlare and their Mirage service: https://support.cloudflare.com/hc/en-us/articles/200403554-What-Does-Mirage-Do- https://support.cloudflare.com/hc/en-us/articles/200403554-W...

Chyzwar 10y ago

Server side logs and sessions. You should be able to tell users devices/browser and what bandwidth they operate. Then calculate average speed they use. You could then create tiered service where media quality and JS features can be adjusted. You will periodically process logs to make sure that grouping is still correct. As additional feature users could choose in theirs setting what tier they want to use. On client side, You can achieve some of this by heavy use of media queries. https://msdn.microsoft.com/en-us/library/windows/apps/hh453556.aspx https://msdn.microsoft.com/en-us/library/windows/apps/hh4535... You can basically manipulate resolution/disable of assets based on screens quality. This is under assumption that someone with retina screen will have decent internet.

gnarly 10y ago

Simple. Design your webpages to only load the functional lighter weight essential stuff by default. Then use javascript to add in all the large assets you want. Users with slow connections can browse with javascript turned off.

aethertron 10y ago
I like this solution. Unfortunately there is little consistency in how well browsers accommodate JS-less browsing. Firefox removed the ability to switch off JS from its standard settings panel. Brave lets you switch JS on/off for each domain from the prominent lionface button panel.

gkya 10y ago

> Every time a similar question is posed on HN, someone says "If the assets aren't needed, don't serve them in the first place", but this is i) unrealistic, and ii) ignores the fact that while the typical HN user may like sparsely designed, text-orientated pages with few images, this is not at all true of users in different demographics. And in those demos, it's often not acceptable to degrade the experience of users on fast connections to accommodate users on slow connections. This is prejudice. People use Craigslist, for example. If the thing is useful, people will use it. If there's a product being sold, and if it's useful to the potential clientele, they'll buy it. Without regard to the UI. In the past ten years while my connection speed increased, the speed at which I can browse decreased. As my bandwidth increased, all the major websites madly inflated. > So -- if I write a web page, and I want to include a large asset, but I want to indicate to user agents on slow/capped connections that they don't _need_ to download it, what approach should I take? Put a link to it with (optionally) a thumbnail.

sjy 10y ago
> People use Craigslist, for example. If the thing is useful, people will use it. If there's a product being sold, and if it's useful to the potential clientele, they'll buy it. Without regard to the UI. Craigslist achieved critical mass in the 90s, so it's not a good example. Many useful products disappear because they can't attract enough users to become sustainable. A nice UI can affect users' credibility judgments and increase the chance that they'll stick around or buy things. [1] http://dl.acm.org/citation.cfm?id=1315064 http://dl.acm.org/citation.cfm?id=1315064

aczerepinski 10y ago

I think srcsets are a reasonably proxy for this. Serve extremely optimized images to mobile devices, and the full images to desktops. It isn't perfect - you'll get some mobile devices on wifi that could have consumed the hero images and some desktop devices still on dial up, but it's still a lot better than doing nothing.

erikpukinskis 10y ago

Which demographic likes large images that are not necessary for the task at hand?

avhon1 10y ago

In the ideal future, FLIF [0] would become a standard, universally supported image and animation format. Almost any subset of a FLIF file is a valid, lower-resolution FLIF file. This would allow the browser - or the user - to determine how much data could be downloaded, and to display the best-quality images possible with that data. If more bandwidth or time became available, more of the image could be downloaded. The server would only have one asset per image. Nice and simple. [0] http://flif.info/ http://flif.info/

greenyouse 10y ago

I don't think there is an easy way to tell the browser not to download something because the connection is slow. Progressive enhancement can work well for giving users a basic page that loads quickly with minimal assets while also downloading heavier content in the background that renders later. That's still different than putting a timer on a request to download the content (which would require JS to detect the slow connection). If you make a page well it should render quickly under any network condition, slow or fast. As an example, you could try serving pictures quickly by providing a placeholder picture which uses lossy compression to be as small as possible. It could be byte64 encoded so it's served immediately even over a slow connection. Then after the page is rendered, a request could go out to download the 0.5Mb image and a CSS transition could fade the image in over the placeholder. People on fast connections wouldn't notice a change because it would load right away, while people on a 40kbit 2G connection would be OK with your page too. The requests to download larger content will still go out over a slow connection but the user won't suffer having to sit through seconds of rendering. Maybe similar to how people have done mobile-first responsive design, people could try doing slow-first design. Get everything out of the critical rendering path and progressively enhance the page later.

niutech 10y ago

There are two ways: 1. Serve the AMP version of your page (https://www.ampproject.org https://www.ampproject.org) which uses lazy loading and other optimizations 2. Use the Network Information API (https://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation https://developer.mozilla.org/en-US/docs/Web/API/NetworkInfo...) to load heavy assets only on high bandwidth connections.

ddebernardy 10y ago

Here's a proxy: buy a 1st-gen iPad, turn JS off, and then use it to browse the site. If it crashes the device, you're way off. If it's appreciably slow or clunky, find ways to improve it. Iterate until it's fast and usable.