Page MenuHomePhabricator

Adding a graph to a page doubles JS payload on mobile and desktop
Open, HighPublic

Description

When graphoid was undeployed, we witnessed a large spike in JS assets (179.8 KiB of JS) for the Facebook page because of the single graph that was included in the page as documented by @phuedx in T271495#6748186

facebook_regression.png (1×2 px, 346 KB)

Per Sam, that 179.8 KiB of JS is introduced by the Graph extension when $wgGraphImgServiceUrl is falsy and there's at least one graph on the page in the form of the ext.graph.vega2 RL module and the wgGraphSpecs JS config variable.

This is an unfortunate download for users that do not interact with the graph, especially considering this is more bytes than all of the images on the page combined.

Expected: The graph code should be loaded when I click on the graph or later in the page's execution (looks in the direction of the performance team for the recommendation).

Event Timeline

Milimetric added a subscriber: Milimetric.

To clarify on my broken heart, this is what I explained would happen in my RFC to replace graphoid: T249419. I really hope we can prioritize pushing that forward.

This is not a surprise, indeed. We knew that moving this feature client-side only would have this impact, since Vega is huge and monolithic.

My recommendation would be to look into ways the damage can me mitigated.

First of all, how dated are the versions of Vega we're using for this? Maybe newer ones are leaner or more modular.

Is the JS only required for interaction? I thought it was needed for rendering too. If only needed for interaction, then waiting for user interaction makes total sense.

If needed for rendering, I think that an intersection observer, with look-ahead distance, should be used on browsers that support it, in order to delay the load of the bulk of the JS involved here.

And on browsers that don't support intersection observers, I think that a delay beyond the load event is also desirable. I think it's probably uncommon for a graph to be above the fold. We shouldn't overdo the extra delay for those rare articles where a graph IS above the fold, though.

To add to Gilles's points:

  • I still think there's good reason to deprecate all old versions of Vega and support only the latest versions of Vega and Vega lite. They should be backwards compatible for the foreseeable future. I can help migrate graph definitions if that's a problem.
  • Vega is not modular at all, and it is used for rendering, not just interaction.
  • I agree with always loading it with a delay, and ideally using intersection observers, as Gilles describes. The placeholder could describe what's happening, should be usable enough.

But of course we need a longer-term solution, as this content is getting pulled all over (Alexa, Siri, Google, etc.) It's relevant to both Knowledge as a Service and Rich Media.

First of all, how dated are the versions of Vega we're using for this? Maybe newer ones are leaner or more modular.

Is the JS only required for interaction? I thought it was needed for rendering too. If only needed for interaction, then waiting for user interaction makes total sense.

At the time of writing, the current version of Vega is needed to render the graph(s) as well:

Screenshot 2021-02-04 at 12.18.59.png (1×1 px, 341 KB)

If needed for rendering, I think that an intersection observer, with look-ahead distance, should be used on browsers that support it, in order to delay the load of the bulk of the JS involved here.

Alternatively, we could explore requiring the user to click on an overlay in order to load the graph.

Intersection observer makes sense to me as does a generic graph graphic that can be clicked to turn it on.