What is web performance

Draft
This page is not complete.

Web performance is the objective time of when a request for content is made until the requested content is displayed on the user's browser, objective render times, and the subjective user experience of load time and runtime. Objectively, it is the measurable time, in milliseconds, it takes for the web page or web application to be downloaded, painted in the user's web browser, and become responsive and interactive. It is the frames per second and times the main thread is not available for user interactions. Subjectively, it is the user's perception of whether the time it takes between the time the user requests the content and the time until the user feels the content requested is available and usable feels slow or fast.  Web performance optimization is the developer process of increasing subjective and objective web performance.

Overview

Imagine loading CNN.com, with over 400 HTTP requests totaling over 22.6MB. Now imagine loading that same site while using tethered mobile data commuting home on public transportation or your great uncle loading it on his 9-year-old iPad while riding the Zephyr in the middle of the Colorado Rockies. Now imagine one of your site's users loading your site on a $35 Huawei device in India.

A 22.6 MB site can take up to 83 seconds to load, with DOMContentLoaded at 31.86 seconds, on 3G, and costs 11% of the average Indian's daily wage. If this site was loaded on a mobile device in Mauritania, it would cost the user two full days of their average salary.  However, if this site was loaded on a US carrier's international roaming plan and ... no, don't. The costs will make you cry.

To build websites and applications people want to use, which attract and retain users, you need to create a good user experience. Web performance is part of user experience; it is ensuring the content is quick to load and responsive to user interaction. Building websites requires HTML, CSS, and JavaScript, often including binary file types such as images and video. The decisions you make and the tools you choose as you build your site can greatly impact the performance of your application.

Good performance is an asset. Bad performance is a liability. Site speed directly affects bounce rates, conversion rates, revenue, user satisfaction, and search engine ranking.  Performant sites have been shown to increase visitor retention and user satisfaction. Slow content has been shown to lead to user abandonment, and many of them won’t come back. Reducing the amount of data that is sent between the client and the server lowers the costs to all parties. Reducing JavaScript and media reduces both the time to load and a site's power consumption. See building a performance culture and performance budgets.

When optimzing for web performance, consideration include network performance, parse and execution performance, and render performance. Web performance includes how long it takes to load the content required, how long it takes to parse, execute, display, and make content usable in the browser, and how responsive and smooth the site is to user interaction. Is the scrolling smooth? Are buttons clickable? Are pop-ups quick to open up, and do they animate smoothly as they do so? Web performance includes both objective measurements like time to load, frames per second, and time to interactive, and subjective experiences of how long it felt like it took the content to load and how responsive the application feels, which is more difficult to measure but often more important, .

Many features impact performance including latency, application size, the number of DOM nodes, the number of resource requests made, JavaScript performance, CPU load, and more.  It is important to minimize the loading and response times, and add additional features to conceal latency by making the experience as available and interactive as possible, as soon as possible, while asynchronously loading in the long tail parts of the experience.

There are tools, APIs, and best practices that help us measure and improve web performance. We'll look at these two in the course of this module.

In these tutorials, we look at:

How content is rendered

Populating the page: how the browser works

When you request a URL and hit Enter, the browser sends a request to the server. But it first needs to find where that serve is, and establish a connection. Once connected, the browser can make the request. Once it receives the response content, it has to convert the assets received into what we see on the screen. The browser follows a well-defined set of steps.

See populating the page: how the browser works to get an overview of the steps the browser takes to render the page from the user clicking on a link to the requested URL being painted to the page. This article is the best place to start as the following articles dig a bit deeper into some of the performance concerns introduced in the process.

Latency

Depending on the protocol, required assets may or may not be fetched all at once. Generally, the browser opens a limited number of connections to each server hosting requested assets. There is overhead involved in establishing TCP and HTTP connections, and some unavoidable latency in pushing the request and response bytes back and forth across the network. The TLS handshake for secure content served over HTTPS takes longer than a TCP connection, but is worth the overhead. Content served over HTTP/2 is not connection limited. Content served over HTTP/2 is binary instead of textual, is fully multiplexed instead of ordered and blocking, which means it can use a single connection for parallelism. HTTP/2 also has the benefit of using header compression to reduce overhead and is well supported by modern browsers.

See Understanding Latency

Critical Rendering Path

The browser constructs a DOM incrementally, which you can take advantage to improve rendering speed.

Before the server queries the database or otherwise fully creates a response, it returns the page header that is the same for all users, allowing the browser to possibly render the header, but at least starts processing the HTML response and incrementally construct the DOM.

Once the server has fully done the work it needs to do to formulate the actual response, the rest of the HTML can be sent, which the browser parses and displays. The browser doesn't have to wait for all of the HTML to arrive before processing, and neither should your server. 

See Critical Rendering Path

Source Order

The structure of the HTML markup is critical. The initial request for a document generally returns an HTML document. The performance of the initial request and response is important, and is measured by time to first byte (TTFB), but, on average, this request is less than 10% of the load time. The number of assets, number of domains hosting those assets, ordering of the assets, deferred and asynchronous loading of some assets, and location of those assets (locally cached or remote) are critical factors in its performance. The browser parses the HTML, fetching the stylesheets, scripts, and media assets requested by the initial document, with those files potentially making additional requests. The download of additional assets is generally sequential, based on source order, but this can be manipulated and should definitely be optimized, realizing that some resources block additional downloads until their content is parsed and executed. Optimizing the critical rendering path -- prioritizing the display of content that relates to the current user action -- improves content rendering time.

Document Object Model

The HTML specification contains a set of rules on how the data received must be processed. The browser's tokenizer emits a token each time it encounters a tag (the text contained within angle brackets). Each token, such as the <html>, <head>, <body>, <p>, etc, is converted into a node object. The tokenizer emits start and end tokens, which tells us the relationship between the nodes: any node that finds itself contained between the start and end tokens of a node is a descendant of that node. For example, the head and body are children of the html node, and the  meta and link nodes are children of the head node.
The result of all the tokens is the document object model or DOM. The DOM is a tree structure that captures the content and properties of the HTML, including all the properties or attributes and the relationships between the nodes.   

See Document Object Model

See Also

Document Tags and Contributors

Last updated by: estelle,