Reading/Web/Lazy loading of images on Ukrainian and Farsi Wikipedia

Rollout of lazy loaded images on fa.m.wikipedia.org and uk.m.wikipedia.org suggests a nontrivial speed improvement in page fully loaded time (initial lag excluded) and a significant reduction in image bytes shipped per pageview, leading to lighter weight pages.

Note well that the x-axis in the speed graphs is presented in log2n increments.

To reduce noise, navigation timing events are filtered to ensure key fields are present, with an emphasis on anonymous, non-redirected, plain article pageviews.

To simplify analysis for bytes shipped calculations, eligible source HTML pages are constrained as to a relative path   (on language variant wikis this path would be different, but that's out of scope here) for a given wiki without a colon ":" character in the remainder of the path, with a restriction that responses must be HTTP 200s, in order to avoid overcounting of 30x, 40x, or other such spurious responses. This aids in narrowing down the analysis to requests likely to be plain article pageviews. Image bytes are constrained to those served from upload.wikimedia.org with an eligible Referer for the same restriction as page paths.

Changes introduced to support lazy loaded images required modified (increased) JavaScript/CSS/HTML.

ukwiki

Based on back-to-back weeks just before and just after lazy loaded image implementation, pages with lazy loaded images loaded faster at the 10th, 50th (median), and 90th percentiles on both HTTP1 and HTTP2. Based on examination of two 3-day periods (3-5 May 2016 vs 28-30 May 2016), image bytes per pageview were reduced by about 44.82%. This contributed to a decrease of about 16.05% in bytes shipped for the modified JavaScript/CSS/HTML plus images as compared to the baseline JavaScript/CSS/HTML and images.

fawiki

Based on back-to-back weeks just before and just after lazy loaded image implementation, pages with lazy loaded images loaded faster at the 10th, 50th (median), and 90th percentiles on both HTTP1 and HTTP2. Based on examination of two 3-day periods (3-5 May 2016 vs 28-30 May 2016), image bytes per pageview were reduced by about 39.55%. This contributed to a decrease of about 16.79% in bytes shipped for the modified JavaScript/CSS/HTML plus images as compared to the baseline JavaScript/CSS/HTML and images.

Data Transfer Queries

The following query was used to derive the lag-excluded load time, roughLoadTimeInitialLagExcluded. select left(timestamp,8) as ts, event_lazyLoadImages, event_isHttp2, event_loadEventEnd-event_responseStart as roughLoadTimeInitialLagExcluded, event_responseEnd-event_responseStart as roughNetworkTimeInitialLagExcluded, event_requestStart, event_responseStart, event_responseEnd, event_firstPaint, event_domInteractive, event_domComplete, event_loadEventStart, event_loadEventEnd, webHost, event_originCountry, event_mediaWikiVersion from NavigationTiming_15485142 where timestamp > '20160412' and timestamp < '20160630' and event_action = 'view' and event_isAnon = true and event_mobileMode = 'stable' and event_namespaceId = 0 and event_redirectCount is null and event_loadEventEnd is not null and event_domComplete is not null and event_domInteractive is not null and event_responseStart is not null and wiki in ('bnwiki', 'fawiki', 'ukwiki') order by wiki event_lazyLoadImages, event_isHttp2, ts ; The following query was used to derive image bytes transferred using the constraints described above. select month, day, substr(referer,1,26), sum(response_size) from webrequest where year = 2016 and ((month = 5 and day in (3, 4, 5)) or (month = 6 and day in (28, 29, 30))) and uri_host = 'upload.wikimedia.org' and referer rlike '^ https://(bn|fa|uk).m.wikipedia.org/wiki/( [^:])+$' and content_type rlike '^image' and agent_type = 'user' and http_status = '200' group by month, day, substr(referer,1,26) ; The following query was used to derive page and JavaScript/CSS bytes (pre- and post-modification for lazy loading) transferred using the constraints described above. select month, day, uri_host, sum(response_size) from webrequest where year = 2016 and ((month = 5 and day in (3, 4, 5)) or (month = 6 and day in (28, 29, 30))) and ( ( uri_host = 'bn.m.wikipedia.org' and ((uri_path rlike '^/wiki/([^:])+$') or (uri_path = '/w/load.php' and uri_query rlike 'skins\.minerva\.icons\.images\.scripts&skin=minerva' and referer rlike '^ https://bn.m.wikipedia.org/wiki/( [^:])+$')) ) or ( uri_host = 'fa.m.wikipedia.org' and ((uri_path rlike '^/wiki/([^:])+$') or (uri_path = '/w/load.php' and uri_query rlike 'skins\.minerva\.icons\.images\.scripts&skin=minerva' and referer rlike '^ https://fa.m.wikipedia.org/wiki/( [^:])+$')) ) or ( uri_host = 'uk.m.wikipedia.org' and ((uri_path rlike '^/wiki/([^:])+$') or (uri_path = '/w/load.php' and uri_query rlike 'skins\.minerva\.icons\.images\.scripts&skin=minerva' and referer rlike '^ https://uk.m.wikipedia.org/wiki/( [^:])+$')) ) ) and agent_type = 'user' and http_status = '200' group by month, day, uri_host ;

The following query was used to derive pageviews for the using the constraints above. Practically all matching records were qualified as pageviews, largely ruling out the possibility of image byte transfer counts with proper Referer values being derived from anything other than qualified pageviews. select month, day, uri_host, content_type, is_pageview, count(1) from webrequest where year = 2016 and ((month = 5 and day in (3, 4, 5)) or (month = 6 and day in (28, 29, 30))) and ( ( uri_host = 'bn.m.wikipedia.org' and uri_path rlike '^/wiki/([^:])+$' ) or ( uri_host = 'fa.m.wikipedia.org' and uri_path rlike '^/wiki/([^:])+$' ) or ( uri_host = 'uk.m.wikipedia.org' and uri_path rlike '^/wiki/([^:])+$' ) ) and agent_type = 'user' and http_status = '200' group by month, day, uri_host, content_type, is_pageview ; Caveats

As with any data spanning time series and the myriad complexities involved with different devices and environments, data are subject to fluctuation. However, the data transfer savings are unambiguous, and the larger event sampling pool with ukwiki and fawiki lend a degree of confidence that pages are actually loading faster.