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 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 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.
performance culture and
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.
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 a browser renders the page and 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. 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
<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
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.
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.
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.