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.
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.
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, .
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:
- Populating the page: how the browser works
- The critical rendering path
- Recommended Times: How long is too long
How content is rendered
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.
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.
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.
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
<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
body are children of the
html node, and the
link nodes are children of the
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.