Web Performance Cheat Sheet
Checklist of things to consider to improve the performance of your website
December 22nd, 2021
Table of Contents
TL;DR
Use Lighthouse to check your website's performance. You will see the same exact information in the Performance report.
Introduction
Web performance is the measure of a website's performance from the user's perspective. A website could have high download speeds, but if it takes too long to load, the user would perceive it as slow. That is why web performance includes not only download speed and throughput but also page load times and interactivity.
This blog contains a list of things to consider when improving your website's performance which is categorized in the following metrics:
- Largest Contentful Paint
- First Contentful Paint
- Cumulative Layout Shift
- Total Blocking Time
LCP (Largest Contentful Paint)
What is LCP?
The Largest Contentful Paint (LCP) metric reports the render time of the largest image or text block visible within the viewport, relative to when the page first started loading.
Largest Contentful Paint (LCP) is an important, user-centric metric for measuring perceived load speed because it marks the point in the page load timeline when the page's main content has likely loaded—a fast LCP helps reassure the user that the page is useful.
To learn more about LCP, check the original article where I copy-pasted the descriptions above.
What can we do to improve LCP?
- Reduce unused JavaScript
Reduce unused JavaScript and defer loading scripts until they are required to decrease bytes consumed by network activity.
- Use video formats for animated content
Large GIFs are inefficient for delivering animated content. Consider using MPEG4/WebM videos for animations and PNG/WebP for static images instead of GIF to save network bytes.
- Preload Largest Contentful Paint image
Preload the image used by the LCP element in order to improve your LCP time
- Avoids enormous network payloads
Large network payloads cost users real money and are highly correlated with long load times.
- Avoid chaining critical requests
The Critical Request Chains below show you what resources are loaded with a high priority. Consider reducing the length of chains, reducing the download size of resources, or deferring the download of unnecessary resources to improve page load.
- Largest Contentful Paint element
This is the largest contentful element painted within the viewport.
FPC (First Contentful Paint)
What is FCP?
The First Contentful Paint (FCP) metric measures the time from when the page starts loading to when any part of the page's content is rendered on the screen. For this metric, "content" refers to text, images (including background images), <svg> elements, or non-white <canvas> elements.
First Contentful Paint (FCP) is an important, user-centric metric for measuring perceived load speed because it marks the first point in the page load timeline where the user can see anything on the screen—a fast FCP helps reassure the user that something is happening.
To learn more about FCP, check the original article where I copy-pasted the descriptions above.
What can we do to improve FCP?
NOTE: If you check the Chrome's Lighthouse report, you will see that everything in
FCPis also inLCP.Meaning, the following list below can be included in the list in
LCP.
- Eliminate render-blocking resources Resources are blocking the first paint of your page. Consider delivering critical JS/CSS inline and deferring all non-critical JS/styles.
- Minify CSS
Minifying CSS files can reduce network payload sizes.
- Minify JavaScript
Minifying JavaScript files can reduce payload sizes and script parse time.
- Reduce unused CSS
Reduce unused rules from stylesheets and defer CSS not used for above-the-fold content to decrease bytes consumed by network activity.
- Enable text compression
Text-based resources should be served with compression (gzip, deflate or brotli) to minimize total network bytes.
- Preconnect to required origins
Consider adding preconnect or dns-prefetch resource hints to establish early connections to important third-party origins.
- Initial server response time was short
Keep the server response time for the main document short because all other requests depend on it.
- Avoid multiple page redirects
Redirects introduce additional delays before the page can be loaded.
- Preload key requests
Consider using <link rel=preload> to prioritize fetching resources that are currently requested later in page load.
- Avoid chaining critical requests
The Critical Request Chains below show you what resources are loaded with a high priority. Consider reducing the length of chains, reducing the download size of resources, or deferring the download of unnecessary resources to improve page load.
- All text remains visible during webfont loads
Leverage the font-display CSS feature to ensure text is user-visible while webfonts are loading.
CLS (Cumulative Layout Shift)
What is CLS?
CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifespan of a page.
Cumulative Layout Shift (CLS) is an important, user-centric metric for measuring visual stability because it helps quantify how often users experience unexpected layout shifts—a low CLS helps ensure that the page is delightful.
To learn more about CLS, check the original article where I copy-pasted the descriptions above.
What can we do to improve CLS?
- Avoid non-composited animations
Animations which are not composited can be janky and increase CLS.
- Avoid large layout shifts
These DOM elements contribute most to the CLS of the page.
- Image elements have explicit
widthandheight
Set an explicit width and height on image elements to reduce layout shifts and improve CLS.
TBT (Total Blocking Time)
What is TBT?
The Total Blocking Time (TBT) metric measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread was blocked for long enough to prevent input responsiveness.
Total Blocking Time (TBT) is an important lab metric for measuring load responsiveness because it helps quantify the severity of how non-interactive a page is prior to it becoming reliably interactive—a low TBT helps ensure that the page is usable.
To learn more about TBT, check the original article where I copy-pasted the descriptions above.
What can we do to improve TBT?
- Avoid long main-thread tasks
Lists the longest tasks on the main thread, useful for identifying worst contributors to input delay.
- Remove duplicate modules in JavaScript bundles
Remove large, duplicate JavaScript modules from bundles to reduce unnecessary bytes consumed by network activity.
- Avoid serving legacy JavaScript to modern browsers
Polyfills and transforms enable legacy browsers to use new JavaScript features. However, many aren't necessary for modern browsers. For your bundled JavaScript, adopt a modern script deployment strategy using module/nomodule feature detection to reduce the amount of code shipped to modern browsers, while retaining support for legacy browsers.
- Avoids an excessive DOM size
A large DOM will increase memory usage, cause longer style calculations, and produce costly layout reflows.
- JavaScript execution time
Consider reducing the time spent parsing, compiling, and executing JS. You may find delivering smaller JS payloads helps with this.
- Minimizes main-thread work
Consider reducing the time spent parsing, compiling and executing JS. You may find delivering smaller JS payloads helps with this.
- Minimize third-party usage
Third-party code can significantly impact load performance. Limit the number of redundant third-party providers and try to load third-party code after your page has primarily finished loading.
- Lazy load third-party resources with facades
Some third-party embeds can be lazy loaded. Consider replacing them with a facade until they are required.
- Has a
<meta name="viewport">tag withwidthorinitial-scale
A <meta name="viewport"> not only optimizes your app for mobile screen sizes, but also prevents a 300 millisecond delay to user input.
Other performance consideration
- Avoids
document.write()
For users on slow connections, external scripts dynamically injected via document.write() can delay page load by tens of seconds.
- Keep request counts low and transfer sizes small
To set budgets for the quantity and size of page resources, add a budget.json file.
- User Timing marks and measures
Consider instrumenting your app with the User Timing API to measure your app's real-world performance during key user experiences.
- Properly size images
Serve images that are appropriately-sized to save cellular data and improve load time
- Defer offscreen images
Consider lazy-loading offscreen and hidden images after all critical resources have finished loading to lower time to interactive.
- Efficiently encode images
Optimized images load faster and consume less cellular data.
- Serve images in next-gen formats
Image formats like WebP and AVIF often provide better compression than PNG or JPEG, which means faster downloads and less data consumption.
- Use
HTTP/2
HTTP/2 offers many benefits over HTTP/1.1, including binary headers and multiplexing.
- Uses efficient cache policy on static assets
A long cache lifetime can speed up repeat visits to your page.
- Largest Contentful Paint image was not lazily loaded
Above-the-fold images that are lazily loaded render later in the page lifecycle, which can delay the largest contentful paint.
- Uses passive listeners to improve scrolling performance
Consider marking your touch and wheel event listeners as passive to improve your page's scroll performance.