Page MenuHomePhabricator

Investigate 2017-08-29 page load time increase
Closed, ResolvedPublic

Description

Looking at the last 30 days of page load times from WebPageTest, there was a consistent increase in page load time on August 29 for our standard benchmark run for desktop (us-east, Cable, Chrome, enwiki, Facebook, first view).

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

From a stable 2.5s over the weeks before, it increased to now be mostly 2.6s and 3.1s.

Event Timeline

Krinkle created this task.Sep 14 2017, 1:21 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 14 2017, 1:21 PM
Krinkle added a comment.EditedSep 14 2017, 2:26 PM

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

Fully loadedRequestsTransfer size
Before2.5s60 (3 css +1 html + 47 img + 8 js)19 KiB css, 152 KiB html, 473 KB img, 288 KiB js
After2.6-3.0s6019 KiB css, 152 KiB html, 473 KB img, 306 KiB js

Actual runs:

Visual ProgressBytes
Visually CompleteSpeedIndex
Before2.6s1414
After2.7s1503

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:

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
Gilles added a comment.EditedSep 19 2017, 1:22 PM

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.

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.

Gilles closed this task as Resolved.Sep 20 2017, 7:18 PM
Gilles claimed this task.
Krinkle renamed this task from Investigate August 29 page load time increase to Investigate 2017-08-29 page load time increase.Mar 23 2018, 7:28 PM