MDN wants to learn about developers like you:

What is web performance

This page is not complete.

Web performance is the objective time from when a request for content is made until the requested content is displayed in the user's browser and the subjective user experience of load time and runtime. Objectively, it is 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. Subjectively, it is the user's perception of whether content feels slow or fast it takes between the time the user requests the content and the time until the user feels the content requested is available and usable.  Web performance optimization is the developer process of increasing subjective and objective web performance.



Imagine loading, 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 on of your site's users loading your site on a $35 Huweii device in India.

A 22.6 MB sites takes 83 seconds to load, with DOMContentLoaded at 31.86 seconds, on 3G, and costs 11% of the average Indian's daily wage. Load that site on a mobile device in Mauitania and it costs the user 2 full days of their average salary.  Load the site 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 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 the client and the server lowers the costs to the 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.

Web performance includes how long it takes to load the content required, how long it takes to get that content displayed and 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, which are more difficult to measure but often more important, of how long it felt like it took the content to load.

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 longer 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 too in the course of this module.

In these tutorials, we look at:

How content is rendered

When you request a URL and hit Enter, the browser sends a request to the server. Once the browser receives the HTML response, it has to convert the markup into what we see on the screen. The browser follows a well-defined set of steps and it all starts with processing the HTML and building the DOM.

The structure of the HTML markup is critical. The initial request for a document generally returns an HTML document. The performance of the intitial 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 stylessheets, 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 render 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 fo 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

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 start 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


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

See Also



Document Tags and Contributors

Contributors to this page: estelle, anthoniaocc, minas1, spencercorwin, sanunes, mdnwebdocs-bot
Last updated by: estelle,