Skip to main content

Performance

General web performance optimization and standards

Optimizing web performance is critical for user retention, involving server-side compression, modern protocols like HTTP/2, and efficient script loading strategies to ensure rapid page delivery.

Better user experience

Waiting for a page to load and for expected content to display is a bad user experience. Making sure the most important content loads fast is really important to keep your visitors focused on your site.

Read more

Read more about the importance of fast load times at https://lawsofux.com/en/doherty-threshold

Core Web Vitals

Core Web Vitals are metrics for measuring real-world loading performance, responsiveness and visual stability.

The main metrics are:

  • LCP (Largest Contentful Paint) for loading performance.

  • INP (Interaction to Next Paint) for responsiveness.

  • CLS (Cumulative Layout Shift) for visual stability.

Use Core Web Vitals as important indicators of user experience, but always consider the site and its users as a whole.

Server

Keeping a website performant does not only make the end user happy. If the server needs less time to process more concurrent users can be processed or maybe a cheaper server can be used.

Compression

Text-based resources such as HTML, CSS, JavaScript, JSON and SVG should be compressed when transferred over the network.

Use Brotli or gzip compression. This can significantly reduce the amount of data transferred and improve loading performance.

HTTP/2 and HTTP/3

Websites should be served using HTTP/2 or HTTP/3. These protocols allow browsers to efficiently load multiple resources over the same connection.

Updated

It is important to keep your server updated to make use of updates in the system and software used. This might sometime mean that also the code base needs updates to make use of these updates.

Load scripts

Avoid loading more JavaScript than the page needs. Large amounts of JavaScript increase download, parsing and execution time and can make the page less responsive.

JavaScript should not block the initial rendering unless it is required for the initial page content.

ES module scripts are deferred by default:

<script type="module" src="app.js"></script>

For classic scripts, use defer when the script depends on the DOM or execution order:

<script src="app.js" defer></script>

Use async for independent scripts that can execute as soon as they have loaded:

<script src="analytics.js" async></script>

Preloading and preconnect

If any of your scripts load any other files (like a script or style), then it could be a good idea to make sure that those files are preloaded. That means that the site won't wait until the first file is downloaded, then executed to start to download any other files needed. Instead, these files are loaded just like any script references in your HTML.

Example script.js fetches fetched-js.js. To preload that file, add:

<link rel="preload" href="fetched-js.js" as="script" />

If you don't know the exact path to a file on another domain that you know will be needed, then you can instead use preconnect to prepare a connection to a specific domain to make sure that when a file is requested, a connection is already established (if the file is requested within 10 seconds). That can be if a specific query string is used or if the filename uses some kind of hash that changes.

<link href="https://cdn.domain.com" rel="preconnect" crossorigin>

Notice

Both preload and preconnect uses CPU to initiate a download or connection. And should only be used for files that are essential for the initial rendering.

Tools to test

There are multiple web tools to test the performance of your site. Notice that there is no solution that is perfect, and for each site, the results of the tools must be analyzed. As an example, a site might not load super fast on the first page, but clicking links loads the pages super fast. The performance tools might not test this and give the page a poor result, even if it is perceived as fast.

To do

  • Text-based resources use Brotli or gzip compression.

  • The website is served using HTTP/2 or HTTP/3.

  • Server software is kept supported and updated.

  • Core Web Vitals are checked for important pages.

  • Non-critical JavaScript does not block initial rendering.

  • Unnecessary and third-party JavaScript is minimized.

  • preload and preconnect are only used for important resources.