<story><title>The web sucks if you have a slow connection</title><url>https://danluu.com/web-bloat/</url></story><parent_chain><item><author>gabemart</author><text>Something I have had at the back of my mind for a long time: in 2017, what&amp;#x27;s the correct way to present optional resources that will improve the experience of users on fast&amp;#x2F;uncapped connections, but that user agents on slow&amp;#x2F;capped connections can safely ignore? Like hi-res hero images, or video backgrounds, etc.&lt;p&gt;Every time a similar question is posed on HN, someone says &amp;quot;If the assets aren&amp;#x27;t needed, don&amp;#x27;t serve them in the first place&amp;quot;, 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&amp;#x27;s often not acceptable to degrade the experience of users on fast connections to accommodate users on slow connections.&lt;p&gt;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&amp;#x2F;capped connections that they don&amp;#x27;t _need_ to download it, what approach should I take?</text></item></parent_chain><comment><author>curun1r</author><text>This seems like the thing that we&amp;#x27;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.&lt;p&gt;This would also handle the situation where the available bandwidth isn&amp;#x27;t indicative of whether the user wants the high-bandwidth experience. For example, if you&amp;#x27;re on a non-unlimited mobile plan, it doesn&amp;#x27;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.</text></comment>
<story><title>The web sucks if you have a slow connection</title><url>https://danluu.com/web-bloat/</url></story><parent_chain><item><author>gabemart</author><text>Something I have had at the back of my mind for a long time: in 2017, what&amp;#x27;s the correct way to present optional resources that will improve the experience of users on fast&amp;#x2F;uncapped connections, but that user agents on slow&amp;#x2F;capped connections can safely ignore? Like hi-res hero images, or video backgrounds, etc.&lt;p&gt;Every time a similar question is posed on HN, someone says &amp;quot;If the assets aren&amp;#x27;t needed, don&amp;#x27;t serve them in the first place&amp;quot;, 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&amp;#x27;s often not acceptable to degrade the experience of users on fast connections to accommodate users on slow connections.&lt;p&gt;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&amp;#x2F;capped connections that they don&amp;#x27;t _need_ to download it, what approach should I take?</text></item></parent_chain><comment><author>tommorris</author><text>There is a proposed API for that.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;wicg.github.io&amp;#x2F;netinfo&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;wicg.github.io&amp;#x2F;netinfo&amp;#x2F;&lt;/a&gt;&lt;p&gt;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&amp;#x27;d be great if it were more widely adopted...</text></comment>