Duration: 12hrs
Timeboxed as 2 hours as part of prioritization. @Jdlrobson confer with @dr0ptp4kt if that is too low.
I'm going to wait till Wednesday when we'll have 30 days of data on Japanese Wikipedia. Guess I need Hive access?
@leila about 30% of users we log for are HTTP1. HTTP1 users tend to have slower experiences. Was there anything more specific you need to know ?
@Jdlrobson, I indicated approval there. I have Hive access, so we can work with that in the meantime.
Had a look at this with Adam for a 7 day period and we saw roughly a 57% bytes of images shipped to all users and a saving 90GB of images per day on Japanese Wikipedia alone after the change.
However obviously traffic flutuates per month, so it would be good to work out how page views changed from the period of June to July.
I've applied my analysis for the week versus week piece, plus plotted the longest available Hive data transfer stats (which also shows the in-scope pageview trendline) into a graph. The Kolomogorov-Smirnov statistical significance test was applied for speed on HTTP/1 lazy v HTTP/1 non-lazy and HTTP/2 lazy v HTTP/2 non-lazy (n.b., it's really not necessary on the data transfer).
For the record, we checked the traffic to mobile site, in ja.wikipedia in the months of June and July, and the user traffic is 585m vs. 587m. (normalized for a 30-day month). The two months are pretty much the same in terms of traffic for practical purposes.
Closing. There's a separate email dialogue (with a planned rollout), but the general trend of the slowest part of the curve (the righthand part of the curve) shifting left in site after site for the handful of sites where this is deployed, in combination with the dramatic image data savings, appears to support the utility of the work effort. Thanks @leila for your insights from the Bengali/Ukranian/Farsi tests and the broader review on this Japanese case.