Wikimedia Performance Team/Page load performance

This document describes aspects of a web page that impact page load performance, and what results can be expected when those aspects are improved. This was originally drafted in February 2016 (T127328) and was revised in October 2018.

We focus in particular on the following three metrics:


 * Visual rendering: Most of the page should render to completion as quickly as possible. Observed through the Paint Timing API (first-paint, first-contentful-paint).
 * Total page load time: The load indicator in web browsers, tracks the download and rendering of HTML document and the download and initial execution of its sub resources (JS, CSS, IMG). Observed through the Navigation Timing API (domComplete, loadEventEnd).
 * Responsiveness: When interacting with the page it should not lag or freeze. Observation of this is still experimental, but possible in synthetic tests via the Time-To-Interactive metric. In the future this can be measured in browsing using the Long Tasks API.

HTTP caching
Improving the cachability of responses to web requests used in the critical path, is expected to have the following impact:


 * First views: None.
 * Repeat views:
 * For any resources:
 * Consume less bandwidth (reduces mobile data costs).
 * Consume less power (fewer cell-radio activations required).
 * For CSS files:
 * Improvement of all paint metrics. Cached stylesheets load faster without network roundtrip, allowing rendering to start and complete sooner.
 * Reduce time to  and   metrics. Stylesheets are subresources required for DOM completion.
 * For JavaScript files:
 * Reduce "Time to Interactive". Cached scripts load, parse, and compile quicker. Browser may store the compiled bytecode from previous page views. Given that the parsing/compilation of JS code often takes more than the initial execution, this can benefit repeat views more than e.g. optimising what the actual code does.

Preloading
Avoid using  links or headers on the main HTML navigation response as this can cause congestion and competition against the HTML resource itself, as well as the critical CSS resources needed for initial rendering. In MediaWiki these resources are already linked from the  and discovered and pre-fetched as soon as possible, by the browser's lookahead parser.

To start the download of late-discovered resources earlier than usual, consider preloading closer to the time they are needed to avoid this competition.

How to:


 * Dynamically insert  elements with JavaScript based on a user interaction toward the feature in question.
 * Or; emit  headers on a subresource between the HTML and the feature in question.

For example, in MediaWiki we generally display the logo as a CSS background image on a particular  element. The image is specified by a stylesheet. When the browser parses and applies this stylesheet, it ignores the url because the CSS rule in question does not apply yet. (Rules are only applied if the rule matches the state of an element in the DOM, and when the browser first renders an article it typically has not yet reached the HTML of the sidebar). The "natural" point where the browser will start the download for the logo file is when that sidebar HTML has been reached and rendered to the user (first without logo). In order to optimise this, the skin stylesheet emits a  header that hints the browser to start the download immediately because we know we are going to need it soon, even if the brower hasn't reached that part of the HTML stream yet.

Size of HTML payload
The first 14 KB of the HTML (per TCP slow-start), should ideally contain everything needed to render the skin layout and a little bit of the article text. And, it should allow the browser to render that initial layout in a way that isn't later moved around or otherwise invalidated (additional components may appear later, but existing components should not move).

Examples of how to improve this:


 * Reduce amount of per-page header bloat, e.g.  tags, RLQ, mw.config, mw.loader.
 * Better minification for inline CSS, inline JavaScript and HTML within the.
 * Arranging the HTML to ensure layout and start of content render first.

See also T231168 for on-going work in this area.

Size of stylesheets
Reducing the size of the main (blocking) stylesheet loaded by the HTML, is expected to have the following impact:


 * All views (first view, and repeat views):
 * Improvement of all paint metrics. Smaller stylesheets load and parse faster, allowing rendering to start and complete sooner.
 * Reduce time to  and   metrics. Stylesheets are subresources required for DOM completion.
 * Consume less bandwidth (reduces mobile data costs).
 * Consume less power (reduce CPU time for stylesheet parsing, especially data URIs. See T121730 for on-going work).

Size of scripts
Reducing the amount of code contained in the startup module and reducing the number and size of modules queued directly onto a page by. The below does not apply to scripts that are lazy-loaded after document-ready.

Expected impact on all views (first view, and repeat views):


 * Reduce "Time to Interactive". Less code to download, parse, and execute.
 * Reduce time to  and   metrics. These scripts are sub resources part of DOM completion.
 * Consume less bandwidth (reduces mobile data costs).

The scripts run in three major phases. These run serially, which means earlier phases naturally have a bigger impact when improved because it allows subsequent phases to start their work sooner:


 * 1) Inline scripts in HTML   (including page configuration, page module queue, and the async request to the Startup module).
 * 2) The Startup manifest (including module registry, dependency tree, site configuration, and the mw.loader client).
 * 3) The page modules (the source code of modules loaded on the current page, and their dependencies).

Processing cost of scripts
Reduce the amount of time spend in executing JavaScript code during the critical path. This includes:


 * Deferring work that does not need to happen before rendering.


 * Splitting up work in smaller idle-time chunks to avoid blocking the main thread for too long (non-interactive "jank").


 * Re-arranging code so that there are no style reads after style writes in the same event loop. The browser naturally alternates between a cycle of JS execution and a cycle of style computation and rendering. If styles are changed in the main JS cycle and then read back within that same cycle, the browser is forced to pause the script and perform an ad-hoc render cycle before being able to resume the script. See also:
 * wilsonpage/fastdom (github.com)
 * Use requestAnimationFrame for visual changes (Web Fundamentals, Google Developers)
 * Avoid forced synchronous layouts (Web Fundamentals, Google Developers)

Expected impact on all views:


 * Reduce "Time to Interactive". Less execution before the page is ready. Less uninterrupted execution which blocks interactions Fewer "forced synchronous layouts" which significantly slow down code execution.
 * Reduce time to  metrics. These finishing of initial scripts' execution holds back "loadEvent".

Reduce latency
Try to find ways to reduce latency from a browser discovering a resource and requesting it, and the browser receiving the response.

Mainly in two ways:


 * 1) By making the response complete sooner. For example by improving backend response times on the server, or by improving network routing, or by adding data centres closer to the user.
 * 2) By making the request start earlier. For example, with the "dns-prefetch", "preconnect" and "preload" instructions.