Last modified: 2014-02-12 23:35:48 UTC
Add preference to turn off srcset delivery. For those who don't need it, it's just bloating of the code. Typical sport article with zillions of flag icons grows even 30 kB or more... :-(
(In reply to comment #0) > Add preference to turn off srcset delivery. I don't imagine this will ever be a user preference. It's user preferences bloat, it'll fragment the parser cache, and nobody will have any idea what it even means. > For those who don't need it, it's just bloating of the code. Typical sport > article with zillions of flag icons grows even 30 kB or more... :-( Yes, the HTML is larger. Is this a problem? If so, how?
(In reply to comment #1) > (In reply to comment #0) > > For those who don't need it, it's just bloating of the code. Typical sport > > article with zillions of flag icons grows even 30 kB or more... :-( > > Yes, the HTML is larger. Is this a problem? If so, how? Isn't it gzipped anyway? The real download size increase should be minimal.
(In reply to comment #1) > > For those who don't need it, it's just bloating of the code. Typical sport > > article with zillions of flag icons grows even 30 kB or more... :-( > > Yes, the HTML is larger. Is this a problem? If so, how? You are obviously lucky to live in the place with low cost fast internet connection without any FUP. However, not the entire world is like that. Consider also mobile internet (not to be confused with mobile view) etc...
(In reply to comment #3) > You are obviously lucky to live in the place with low cost fast internet > connection without any FUP. However, not the entire world is like that. > Consider also mobile internet (not to be confused with mobile view) etc... I'm sympathetic to slow or limited Internet connections. I'm not sympathetic to the view that some additional HTML attributes (compressed, even) are contributing to noticeable performance problems. We're talking about a few extra bytes per request, aren't we? Have you looked at bug 32138?
Looking at a couple of pages, the size difference is indeed relatively small once compressed: http://cs.wikipedia.org/wiki/Seznam_m%C4%9Bn -rw-r--r-- 1 brion staff 239K Dec 23 15:06 seznam.html -rw-r--r-- 1 brion staff 32K Jan 10 16:46 seznam.html.gz with 200+ 'srcset' attributes removed: -rw-r--r--@ 1 brion staff 181K Jan 10 16:46 seznam-nosrc.html -rw-r--r-- 1 brion staff 27K Jan 10 16:46 seznam-nosrc.html.gz Only 5kb difference in the transfer amount; this will be by far dwarfed by the actual images. Rather than a preference exactly as requested, I'd recommend considering a combination of: Reduce unnecessary image payload: * something like bug 32138 to avoid loading images that aren't onscreen Make image payload size switchable: * client-side option to disable the use of srcset for people on high-resolution displays but metered connections (think iPhone or Android or iPad on a 2g or 3g connection with a hard limit) Reduce unnecessary HTML payload: * load sections separately, as we're starting to on mobile... ?? * cleaner naming conventions to avoid having to output 3 full URLs in every <img> ** (eg if we have @1.5x and @2x suffixes, we could add the 'srcset' or set 'src' at runtime from JS, without having to store any of the common) ** this would only save 1kb or so on most pages, but it adds up eh
(It's not worth fragmenting the parser cache for this, but if the payload can be reduced cleanly, that makes us more flexible and could save a little transfer.)
