Topic on User talk:Jdlrobson

Hi Jon!

I was reading your post about the impact of removing srcset from mobile pageviews, and I was impressed by the amount that it reduced the image bandwidth. Do you think the reduction in 2G load time is due to devices that are running on 2G that were previously requesting the 2x version of the image, but now are forced to request the 1x version? Or is there some other explanation? I know that at least back in 2015-16 there were some bugs in browser engines that would request both the "src" image and also one of the "srcset" entries as well, although I think those have generally been fixed.

I'm also curious whether those graphs might have overestimated the effect, due to the issue Brion brought up on T134115#2257578 (sorry, AbuseFilter is blocking me from making that into a link!) which would have caused the non-srcset versions of pages to sometimes display to desktop users as well. It's a bit weird though because I think then (and even now) the majority of "retina" displays were mobile.

Also wondering whether most of those gains would have been eaten up by Reading/Web/Lazy loading of images on all wikis anyway, but that's probably harder to answer after-the-fact.

I'm mainly asking because naively, it seems like this change (plus Brion's addition to the parser cache key) roughly doubles the number of parser cache misses, because now mobile and desktop pages need to use entirely separate cache entries. Am I missing something that makes it not that way, or makes that less of a problem than I (not being associated with WMF at all) would think?

Thanks!

Hey CookMePlox, thanks for reading through and reaching out.

My knowledge is a little hazy here, but as I recall, the fully load time was the time to load all assets in the page, and that included images, so by reducing the payload of most of the images from 2x to 1x, there was less to load, and it could be loaded quicker.

My hope had been that reducing the payload of the HTTP requests there would be less competition and faster loaded resources on the critical path, but we never managed to prove that one way or the other.

Yes there was a bug a while back that loaded both srcset and src - I remember that one, and yes those should be fixed now.

I believe the Brion bug in phab:T134115#2257578 meant that depending on what got cached first, we were either stripping srcset from desktop articles, or including them on mobile. The data in those graphs is mobile only, so I think that would have underestimated impact if anything. Reading back the phab ticket, this problem got identified quickly and fixed May 2nd 2016 with a purge, so I don't think it would have impacted those graphs for the days that followed.

Yes to the cache misses problem. The mobile and desktop cache differently. It would probably be a good project at this point to explore adding native lazy loading to desktop phab:T148047 and revising the mobile site to use it, so that the two can share a cache. Assuming nothing else varies the cache, that would have quite the impact.

Lazy loading of images on all wikis had a more significant impact than the srcset removal. Not sure if you read this blog post, but that has a write up: https://diff.wikimedia.org/2016/09/19/mobile-web-improvements/