Page MenuHomePhabricator

Add Time to First Preview to the Page Previews Grafana dashboard
Open, Needs TriagePublic

Description

During the review of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Popups/+/876267, we discussed delaying the execution of Page Previews by two seconds, which was originally proposed in T176211: Page Previews could load less JS on pageload.

AIUI the concern from Performance is that delaying loading and executing Page Previews will reduce network congestion and CPU load during the initial render of the page; and the concern from Readers Web is that delaying loading and executing Page Previews will lead to an inconsistent and/or slow UX.

Balancing these concerns hinges on knowing when a user first shows a preview.

EventLogging

We do have a trove of data from the EventLogging-based instrumentation from circa late December 2017 in event_sanitized.popups, from which we should be able to derive the various percentiles of when a user first shows a preview. It's worth remembering that the instrument was running when Readers Web were A/B testing Page Previews prior to enabling it everywhere and that, now the users are now accustomed to it, their usage patterns may have changed.

 StatsD

Page Previews' StatsD-based instrumentation is still enabled in production. It powers the Page Previews dashboard. We could instrument TTFP using this instrumentation by:

  1. Updating the boot action to be a timed action to be a timed action (c.f. the fetch start action)
  2. Updating the statsv reducer to

2.1. On boot: Store that timestamp on the state tree in bootedAt
2.2. On preview show: If timeToFirstFetchStartLogged is falsy, calculate the difference between the timestamp in 2.1. and update the state tree to include something like:

{
  action: 'timing.PagePreviews.time_to_first_preview_show',
  data: mw.now() - bootedAt,
  bootedAt: null,
  timeToFirstFetchStartLogged: true
}