WebPageTest metrics

Grafana close-up: https://grafana.wikimedia.org/dashboard/db/webpagetest-drilldown?orgId=1&from=1503978678915&to=1504093812637&var-wiki=enwiki&var-users=anonymous&var-page=Facebook&var-location=us-east-1&var-browser=Google_Chrome&var-view=firstView

Actual runs:

• Before: http://wpt.wmftest.org/result/170828_41_HR/1/details/
• After: http://wpt.wmftest.org/result/170830_8P_Q/5/details/
• Compare: http://wpt.wmftest.org/video/compare.php?tests=170830_8P_Q%2C170828_41_HR&thumbSize=200&ival=100&end=full#

Visual Progress	Bytes

Waterfall (load.php requests, uncompressed sizes):

1. startup - 77KB unchanged
2. base (jquery+mediawiki) - 174.2KB unchanged
3. page queue (no group) - 420KB -> 485KB +65KB
4. page queue group=site (e.g. gadgets) - 16KB unchanged
5. TimedMediaHandler, lazy (no group) - 225KB unchanged
6. TimedMediaHandler, lazy group=jquery.ui (jQuery UI) - 93KB unchanged

The difference in request 3 (page queue modules) was the addition of the following three modules being loaded on all pages from the main module queue:

• ext.popups
• ext.popups.images
• mediawiki.template.mustache

RUM

The real-user metrics from Navigation Timing weren't affected in any obvious way. There were some changes if you look hard, but nothing conclusive.

NavTiming loadEventEnd:

• overall median: +0.05s
• overall p95: +0.4s
• platform=desktop p95: +1s

Deployments

Started sometime between 12:00 and 16:00 on August 29:

From https://tools.wmflabs.org/sal/production?p=0&q=&d=2017-08-29

13:09 zfilipin@tin: Synchronized static/images/project-logos/: SWAT: Add several HD logos (T150618) (duration: 00m 43s)
13:10 zfilipin@tin: Synchronized wmf-config/InitialiseSettings.php: SWAT: Add several HD logos (T150618) (duration: 00m 43s)
13:12 zeljkof: EU SWAT finished
14:33 marostegui: Shutdown db1055 to replace its BBU - T174265

For later reference, with popups, 70% of pageloads result in a link interaction:

SELECT COUNT(DISTINCT(event_sessionToken)) FROM Popups_16364296 WHERE event_popupEnabled = 1 AND event_action = "pageLoaded" AND timestamp >= 20170831000000 AND timestamp < 20170901000000

885334


SELECT COUNT(DISTINCT(event_sessionToken)) FROM Popups_16364296 WHERE event_popupEnabled = 1 AND event_action != "pageLoaded" AND timestamp >= 20170831000000 AND timestamp < 20170901000000

624578

Something worth discussing here is whether the page queue *should* make visual progression worse. After all, from the code's perspective, we are already loading things with the lowest priority possible. But there's no option offered (out of the box) to load something low priority while being sure that it's not going to make the initial pageload worse in any way.

Some manual work will still be required to have a bootstrap module that captures user interaction, but for the very-lazy preloading (1-2 secs after pageload), we might benefit from having a generic solution that loads things efficiently, in the least disruptive manner possible and long enough after the initial pageview to avoid interfering with it.

In T175916#3617413, @Gilles wrote:

Something worth discussing here is whether the page queue *should* make visual progression worse. After all, from the code's perspective, we are already loading things with the lowest priority possible. But there's no option offered (out of the box) to load something low priority while being sure that it's not going to make the initial pageload worse in any way.

Agreed. Deferring execution of the module queue further (e.g. to after dom-ready or after window-load) would significantly worsen time-to-interaction for enhanced features. On the other hand, we do want a way to efficiently preload modules without executing them.

Something dedicated seems justified here, and would help. Written down some thoughts at T176262.