Improving Web Performance
Optimization Summary
MOST IMPORTANT: Improve page load speed by prioritizing which resources get loaded, controlling the order in which they are loaded, and reducing the file sizes of those resources
- Minimize the number of critical resources by deferring non-critical ones' download, marking them as async, or eliminating them altogether
- Optimize the number of requests required along with the file size of each request
- Optimize the order in which critical resources are loaded by prioritizing the downloading of essential assets, thereby shortening the critical path length
Critical Rendering Path
Summary
- Process HTML markup and build the DOM tree
- Process CSS markup and build the CSSOM tree
- Combine the DOM and CSSOM into a render tree
- Run the layout on the render tree to compute the geometry of each node
- Paint the individual nodes on the screen
Order of Events
- The browser sends an HTTP GET request to the server
- The server sends a response containing the resource
- The browser parses HTML, converting the received bytes to the DOM tree
- The browser initiates requests every time a new link to an external resource is found
- Some requests are render-blocking, meaning the HTML parsing is halted until the asset is handled
- The browser continues parsing the HTML until it reaches the end
- The browser then begins to construct the CSSOM
- When both are complete, the browser combines the two into the render tree
- While the render tree is being built, the browser computes all of the styles for visible elements
- After the render tree is complete, the layout occurs, defining the location and size of the render tree elements
- After the layout is complete, the browser paints the pixels
- Paint occurs at the end because showing users an un-styled page and then repainting it after the CSS styles have been parsed would be a bad user experience
Document Object Model (DOM)
- The DOM contains all of the content of the page
- The HTML response turns into tokens, which then turn into nodes
- Nodes contain all critical information about the HTML element
- Nodes are connected into a tree based on token hierarchy, with nodes inside of nodes
- The greater the number of nodes, the longer the following events in the critical rendering path will take
- A few extra nodes won't make a big difference, but keep in mind that adding many extra nodes will impact performance
- It is important to measure to find out if the number of nodes impact performance
Optimizations
General
- Use less nodes in the DOM tree and simplify the HTML
- Use a mobile-first approach to ensure that the default layout is for small-screen devices, so mobile devices can just download images suitable for their screens and don't need to take the performance hit of downloading larger desktop images
- Use HTTP/2 on your server (or CDN)
Resources
- Use a CDN for resources which can reduce load times significantly
- Lazy load parts of your application outside the viewport (below the fold), but have a fallback for SEO
- Compress your resources, and use CSS animation or SVG if possible. Images and video account for over 70% of the bytes downloaded for the average website
- Use speculative loading resource hints such as “rel=preconnect", “rel=dns-prefetch", “rel=prefetch", and “rel=preload". Preload important assets such as CSS, JavaScript, and even videos that are essential for the page. The preload <link> fetches critical resources immediately without blocking rendering.
- Provide different image resolutions via srcset and other sources for images and videos with picture element
Perceived Performance
- To maximize the perceived and actual performance, the HTML should be loaded first in the order in which it appears on the page. For example, you can preload critical CSS and fonts early but defer non-critical JavaScript until later.
- Add inline CSS required for any content rendered above the fold or what you see in the browser viewport before scrolling. These styles will improve perceived performance as the CSS does not require a file request
Examples:
<!-- Preload a JavaScript file -->
<link rel="preload" href="important-js.js" as="script" />
<!-- Preload a JavaScript module -->
<link rel="modulepreload" href="important-module.js" />
CSS Object Model (CSSOM)
- The CSSOM contains all the information on how to style the DOM
- CSS is render-blocking: the browser blocks page rendering until it receives and processes all the CSS
- CSS is render-blocking because rules can be overwritten, so the content can't be rendered until the CSSOM is complete to maintain a good user experience
- As the parser converts tokens to nodes, descendant nodes will inherit some of the styles of the parent
- The CSSOM cannot be used to build the render tree until it is completely parsed because styles that are going to be overwritten with later parsing should not be rendered to the screen
- In selector performance, less specific selectors are faster than more specific ones. For example, .foo {} is more rapid than .bar .foo {} because when the browser finds .foo, it has to walk up the DOM in the second scenario to check if .foo has an ancestor .bar. The more specific tag requires more work from the browser, but this penalty is not likely worth optimizing.
- The more specific rule is more expensive because it has to traverse more nodes in the DOM tree - but that extra expense is generally minimal as performance optimization improvements will only be in microseconds
Optimizations
General
- Cut down on image HTTP requests with CSS sprites
- Preload important assets
- Use container queries to enable querying a container's size, properties, and property values to apply CSS styles conditionally
Device Downloading Time
- Remove unnecessary styles
- Split CSS into separate modules not required at page load can be loaded later on
- Use media queries on link tags
- https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries
- Minify and compress your CSS
- Simplify selectors and don't apply styles to more elements than needed
Fonts
- Use web-safe fonts
- Preload web fonts
- Use the font-display descriptor to allow text to appear with a fallback font while a font loads
- https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display
- Use compressed web fonts or use WOFF and WOFF2 since they have compression built-in
- Within @font-face, use font-display: swap. By using font display swap, the browser will not block rendering and will use the backup system fonts that are defined
- If possible, avoid icon web fonts and use compressed SVGs. To further optimize inline your SVG data within HTML markup to avoid HTTP requests
Render Tree
- The render tree captures both the content and the styles: the DOM and CSSOM trees are combined into the render tree
- To construct the render tree, the browser checks every node, starting from the root of the DOM tree, and determines which CSS rules are attached
- The render tree only captures visible content
- If an element doesn't contain any visible information, or if there's a display: none; set on an element, neither it nor any of its descendants are in the render tree
Layout
- Layout is dependent on the size of the screen
- The layout step determines where and how the elements are positioned on the page, specifying the width and height of each element, and where they are to each other
- Block-level elements, by definition, have a default width of 100% of the width of their parent
- Unless otherwise defined, the body has a width of 100%, meaning it will be 100% of the width of the device viewport
- Layout performance is impacted by the DOM — the greater the number of nodes, the longer the layout takes
- To reduce the frequency and duration of layout events, batch updates and avoid animating box model properties
Optimizations
- Batch updates and avoid animating box model properties
Paint
- On load, the entire screen is painted
- After that, only impacted areas of the screen will be repainted, as browsers are optimized to repaint the minimum area required
- Painting is a speedy process and, therefore, likely not the most impactful place to focus on in improving performance
- It is important to remember to allow for both layout and re-paint times when measuring how long an animation frame may take
- The styles applied to each node increase the paint time, but removing the style that raises the paint by 0.001ms may not give you the biggest bang for your optimization buck
Optimizations
- Reduce animation frame duration
JavaScript Optimizations
You don't always need a framework: Minimal JavaScript is nice.
Device Downloading Time
- Keep your JavaScript bundles small, especially for mobile devices. Small bundles improve download speeds, lower memory usage, and reduce CPU costs. Avoid having a single large bundle; if it exceeds ~50–100 kB, split it into separate smaller bundles. On mobile, you’ll want to ship much less significantly because of network speeds but also to keep plain memory usage low
- Minify and compress files or use a module bundler like web pack
- Remove as much of unused code as possible, and only use as much JavaScript as needed for the current page
Execution Time
- Break down long tasks (longer than 50ms) to avoid keeping the main thread busy and can push out how soon pages are interactive. Post-download script execution time is now a dominant cost. The main thread can run only sequentially, executing one task simultaneously. If the user attempts to interact with the page or a vital UI update is requested while a long task is running, the expected response or visual update will be delayed, resulting in the UI appearing sluggish or unresponsive
- Avoid large inline scripts: if the code is over 1kb, don’t inline it
- Use web workers to keep the main thread from performing essential tasks like UI rendering. All pure startup calculations should be performed in background threads while you keep the run-time of main thread events as short as possible
Asynchronous Rendering
- Split your JavaScript into multiple files representing critical and non-critical parts
- Defer execution of non-critical JavaScript using defer or async attributes or using an “onload” event listener
- Link JavaScript assets after the page's DOM elements
Coding Practices
- Reduce DOM manipulation and batch DOM changes rather than just firing off each change as it occurs
- Consider a more straightforward, less intensive solution when creating code
- Consider using built-in browser features rather than trying to create them using JavaScript
- Use less or cut out any non-essential animations. Try to use CSS animations where possible instead of JavaScript animations
- Remove event listeners that are no longer needed and use event delegation wherever possible. When you have some code to run in response to a user interacting with any one of a large number of child elements, you can set an event listener on their parent. Events fired on any child element will bubble up to their parent, so you don't need to set the event listener on each child individually. Less event listeners to keep track of means better performance
- Reduce the amount of looped code, and avoid running the entire loop when it is unnecessary using a break. Keep as much unnecessary work outside of the loop to prevent performing single tasks multiple times
- Break your large code into separate functions, and use a "yield" function periodically to get the code to yield to the main thread. This means that our code is split into multiple tasks, between the execution of which the browser is allowed to handle high-priority tasks such as updating the U.
