Basic Web Performance and Optimization
Web performance is directly related to UX; page load time (on mobile and a desktop) plays an important role in a website’s success:
47% of consumers expect a web page to load in 2 seconds or less.
40% of people abandon a website that takes more than 3 seconds to load.
A 1 second delay in page response can result in a 7% reduction in conversions.
If an e-commerce site is making $100,000 per day, a 1 second page delay could potentially cost you $2.5 million in lost sales every year.
Two of the big culprits of slow page rendering is the DOM (document object model) and the CSSOM (CSS object model); optimizing each of these steps is necessary when thinking about rendering performance.
Ilya Grigorik, a web performance engineer at Google wrote the book High Performance Browser Networking, is a great read, free to read online. It covers networking and optimization. Generally the three factors to consider when optimizing is:
- number of critical resources (resource that may block initial rendering of the page — typically HTML, CS or JS files)
- number of critical bytes (total amount of bytes required to get to first render of the page, which is the sum of the transfer file sizes of all critical resources.)
- critical path length. (number of roundtrips, or the total time required to fetch all of the critical resources.)
The first step to understand front end optimization would be to understand on a high level how a page on a browser is constructed. I analyzed the critical rendering path of the main page of Todoist, one of my favorite note taking sites.
First, we take a look at the HTML to build the Critical Rendering Path diagram.
Upon analyzing the HTML, I identified 7 critical resources.
Without these resources, our page cannot be rendered (see the DOM and CSSOM construction)
Async Javascript!
Resource #4 has an async tag applied to the script. Because Javascript blocks the document parser, we want to defer any unnecessary JS execution, such as analytics scripts (we don’t need this script to render the page). Unless the JS modifies the DOM or CSSOM, they shouldn’t block rendering. Use of async attribute on scripts is a strategy to allow the browser to continue building the DOM without the async JS execution.
Using the Google Developer Tools > Network tab on Chrome, I identified the size of the resources that are being downloaded. The image below shows the sizes of the CSS stylesheet sizes.
The following is the Critical Path diagram for the Todoist page:
Digging a little deeper into the critical rendering path, we’ll explore the DOM and the CSSOM construction and talk about specific optimizations for each step.
The DOM
Once an initial GET request is sent to the server, the server responds by sending over HTML resources, the content of the page.
Optimizing this step: Compression, Minification, Caching
Reducing payload sizes reduces the amount of data that needs to be shipped to the browser. It’s not cut and dry:
Ilya Grigorik explains: “Depending on the resource type — text, images, fonts, and so on — we have a number of different techniques at our disposal: generic tools that can be enabled on the server, pre-processing optimizations for specific content-types, and resource specific optimizations that require input from the developer. Delivering the best performance requires the combination of all of these techniques.”
- Strip out unnecessary code to reduce size of the page: This includes white space characters, new line characters, comments
- Preprocess, compress your CSS
- Browser caching
The CSSOM
Its construction is very similar to the DOM. Unlike the DOM, where incremental processing is possible, the entire CSSOM tree needs to be processed before page is displayed. The earliest point where a browser can paint a page is when the render tree (dictates what is displayed and how it is displayed is constructed. CSS, like HTML is render blocking — this resource is necessary and the browser will not be able to render the page until that resource is delivered and the CSSOM is complete.
Optimizing this step: media queries, ‘lean’ CSS (compressed and minified),
Even though all CSS resources are downloaded by the browser, some CSS might not be needed to render the page. For example, CSS that defines styles under specific or dynamic conditions (i.e. displayed on small screen desktops, or displays that change on screen orientation or resize) isn’t necessary to render the current page! Media types and media queries lets mark CSS resources as non-render blocking. When the browser sees the style sheet that may not apply to the current conditions, it doesn’t need to block rendering.
Back to the Critical Rendering Path…
The general sequence of steps to optimize the critical rendering path is:
- Analyze and characterize your critical path: number of resources, bytes, length.
- Minimize number of critical resources: eliminate them, defer their download, mark them as async, etc.
- Optimize the order in which the remaining critical resources are loaded: you want to download all critical assets as early as possible to shorten the critical path length.
Optimize the number of critical bytes to reduce the download time (number of roundtrips).
