T233675: Audit startup JavaScript payload (Aug 2018—Sept 2019) | T233676: Audit default module payload (2019)

Objective

This task proposes to focus on the following theme for a quarter: Reduce use of @embed to only images that generally render above-the-fold.

Expected impact, based on "Size of stylesheets" at https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Page_load_performance:

• Improved visual progression for readers (first paint earlier, last paint same or better as today).

Rationale

Smaller stylesheets download quicker. The sooner the styles arrive to completion, the sooner the browser is allowed to start rendering the above-the-fold HTML it already got in its buffer.

In T187266#4996608, @Krinkle wrote:

In 2010, we decided to embed images because of:

• how browsers worked at the time and our understanding of how browsers worked,
• the use of HTTP/1 (relatively high cost for each additional request, limited number of connections that each can only start requesting the next resource after the previous has gotten its complete response),
• our focus on reducing the total time taken and bandwidth spent for loading a page.

Embedding images allowed the images to act like a super-sprite in terms of compression (saving on bytes transferred) and reduced the number of requests (fewer roundtrips, thus faster page load time). Between then and 2019, some things have changed:

• we now use HTTP/2, in which parallel requests have fewer disadvantages, less overhead, and there is no longer a concurrency limit after which requests would be stalled. There is still non-zero overhead and saving requests can still benefit. But, its overhead is now smaller, and as such there are now also scenarios in which an extra request would actually save time rather than increase time. It's also important to note that we spent fewer bytes on HTTP in HTTP/2 due to the ability to compress values over multiple requests (HPACK).
• we still consider bandwidth cost an important factor. But for a given individual and a given quantity of bytes on the network, it is now cheaper than it was ten years ago (citation needed). Hence, while 10 KB may've been a deal-breaker in some trade offs before, a similar trade off might now only be justified for 30 KB. Depending on how many bytes a change saves or adds, and how much it improves other factors (e.g. UX, perceived performance, rendering speed, battery power, etc.), it may now be acceptable to be less optimal on bytes if it means a significant improvement on other factors.
• several browsers now support HTTP Preload.
• we now have much better insight into visual rendering in browsers (RUM: Paint Timing. WebPageTest: Visual metrics). And we've decided to make them part of the key performance metrics we monitor.

The way browsers work, and have worked even in 2010, is that a stylesheet blocks the appearance of any content or layout on the page. The flow is as follows:

1. Browser requests HTML page from server, and
2. Browser starts to receive HTML from server.
3. Browser detects sub resources, such as stylesheets, images, and scripts. And requests them. Stylesheets are given a high priority through the HTTP/2 semantics.
4. Browser continues to receive HTML from the server and parses it, but may not yet render.
5. Browser starts to receive the stylesheet.
6. Browser receives the remaining parts of the stylesheet.
7. Browser may now render the HTML it's parsed so far. (First paint)
8. Browser continues to receive HTML and will progressively parse/render in chunks until it reached the end of the HTML stream. The same applies to images and scripts.

By embedding icons in stylesheets, no page content, text, or layout may appear until all icons are downloaded. This is in essence a sort of "ultra high priority" hack, analogous to synchronous scripts (and we know how much we don't like synchronous scripts). The use of embedding is therefore imho unacceptable, without exception. No icon can be more important than the layout of the website, and the article text itself.

By letting our icons load separately (in parallel with preload) I hope that the first paint (above-the-fold content and layout) can occur sooner than today.

The paint with the icons would still be at the same time as today, in browsers supporting Preload. In other browsers (shrinking population over time) icons would appear 1 RTT later than today, but still before the load event, given other loadevent-tracked sub resources taking at least 2 RTT as well.

In retrospect, this isn't really anything new. Most any major site today works the same way. GitHub, Google properties, Twitter, Facebook. They load at once with content and layout in their final resting place, but icons pop in later. Unlike layout FOUCs, these seem quite acceptable and not fundamentally different to how other images render in a browser. That is, the website logo or infobox images also appear separate from the text. Same for native applications as well.

Best practices

• If used in a styles-only module, the entire article will remain blank until the embedded image has been downloaded and processed. No text, no skin layout, nothing will appear. This the the absolute strongest form of blocking and critical path available on the web. As such, it requires equally strong rationale before using :)
  
  Also, the styles queue varies between page-views which means users may have to download the same embedded icons multiple times. Without embedding, they enjoy the benefits of browser caching.

• If used in a JS module that also contains styles, the module will not be "ready" until the image is downloaded. This delays execution of other modules that depend on it, as well as any mw.loader promise, until the styles are downloaded, parsed, and added to the page (regardless of whether the CSS rules match).
  
  This means if a module is lazy-loaded on-demand only where it is definitely needed, and the selector for the background image will definitely match, then using @embed does not waste bandwidth. But, you might still want to avoid it. For example, if a JS module contains a complex dialog framework that is only loaded when you are about to create a dialog, do you want the dialog to be visible sooner without the image first, or block any use of the dialog on the image being downloaded? If the dialog would look broken or incomplete without the image, then embedding might make sense. But, otherwise, best to avoid it still and allow progressive rendering.

Plan

• Remove unneeded use of @embed in MediaWiki core modules and WMF-deployed extensions.
• Determine whether we can improve the internals of @embed for the remaining use cases.
  • Cost of parsing data URIs: Analyse the cost in browsers on various mobile devices / and OSes for downloading and parsing stylesheets with data URIs vs regular urls. Safari and Firefox were once known to parse the image binary data forcefully while processing the stylesheet, instead of skipping the data URI to only parse it when the CSS rule matches (like browsers already do for regular urls).
  • Compressibility of data URIs: Even if data URIs are around the same length as the path URL, the path urls should compress much better in practice given most of the paths are similar, with only the base name differing. This should very significantly shrink icon packs.
• If useful, implement @preload
• Migrate from @embed to @preload.
• Coordinate roll out with performance survey (@Gilles), and attempt to A/B test.