We probably don’t need to explain that a large file size for your assets comes with a large page load, so here are some other tips on how to efficiently manage your styles, scripts and images on your website you might not know.

Limit the DNS lookups used for all your assets

When visiting a domain or subdomain a DNS lookup must be performed. Every DNS lookup comes with a page load cost. Using multiple subdomains (like static, media, assets, …), so called ‘domain sharding’, was a performance best practice in the past. It was used to overcome the browser limit on simultaneous requests per domain. Due to new technologies like HTTP/2 this is no longer the case for most websites. By enabling HTTP/2 on your website you’re allowing the browser to download multiple assets at once. This is a huge performance improvement. Thanks, Kim, for sharing that with us during a ‘Knowledge Sharing’ presentation.

The www subdomain also requires a DNS Lookup. Therefore, it might be a good practice to choose whether to use it as the primary domain and load all assets from the primary domain instead of using another (sub)domain. Also make sure to redirect the www subdomain or vice versa and make proper use of https.

Please note these remarks:

• CDN’s are still recommended for global availability if this is important.
• By using a CDN you are moving the server load for assets away from the web server to the CDN server. This doesn’t necessarily lower the page load, but it can lower the server load.
• If you are using a lot of cookies, using a cookie-free domain for assets might improve performance.

Check the HTTP response status code for the assets

When a URL is requested. The server responds with a HTTP response status code. Ideally this should be 200 or 304 for all assets. 200 means the requested URL can be downloaded without any issues or notices. 304 means this asset is already downloaded and is (implicit) redirected to the cache. If you see any other HTTP response status code you should take a look at this. If the asset is redirected (e.g. 301 or 307), it might add up to the page load, and if the asset is missing (404), most likely, some of the website’s functionality is not working. The favicon is an example of an asset that might be missing or is having a default fallback (redirect) via the CMS.

Lazyload for images

Images are mostly large to download and actually, there is no need to download an image positioned outside the viewport and thereby blocking the load of the website. So, wouldn’t it be handy to download these just before these are visible and consequently lowering the initial page load? This can be done with lazy loading. You can enable this by adding the loading attribute to the img tag.

The loading attribute has two possible values:

• lazy: this file should be lazy loaded
• eager: this file should be loaded ASAP

<img src="..." alt="..." loading="lazy" >

Async/defer JavaScript assets

When the browser encounters a script tag it will stop the HTML parsing, download the script and run it.

This will make you wait and the page may not be fully visible until the script is executed. To convert the script loading from synchronous to asynchronous you can use the async and defer keywords.

Both async and defer will download the script without interrupting the HTML parsing. The difference is when to execute the script.

Async scripts will be executed once the download is complete. Therefore, execution can block the HTML parsing. Multiple async scripts will be executed as soon as the download is complete so their relative order is not guaranteed.

Defer scripts will be executed after the HTML parsing is finished. Therefore, execution will not block the HTML parsing. Multiple defer scripts will be executed after the HTML parsing and their relative order is guaranteed.

Leverage browser caching

Once the assets are downloaded, you might want to store them for an amount of time, so they don’t need to be downloaded again when a visitor revisits the website or visits another page on the website.

There is a way to define how long an asset should be cached by the client’s browser. This so-called browser caching can be enabled by configuring the HTTP header to contain a Cache-Control header for the file types you would like to be cached by the client’s browser.

If you want to be able to update a cached asset, a CSS or JavaScript file e.g., you can include a hash or version in the filename or appended as a get parameter. If you change that hash or version the browser will see this as a new file and will download it again.

The fastest request is no request

There is no request faster than not having to request the asset at all. This might seem obvious, but sometimes this gets forgotten out of ease. In that case there are a lot of assets downloaded without using them. You can check this by going through all pages of your website and see if you can remove requests that are not needed on that page. You probably don’t need to load the lightbox JavaScript or CSS files if that page is not using a lightbox for example.

You can also apply the same logic to the content of the JavaScript and CSS files. Instead of creating one large JavaScript and CSS file you should create one for each page layout. This file should only contain the scripts and styles needed for that page layout. I’ll illustrate this with an example. Let’s say the website contains a home, faq, blog, contact and testimonials page. We start with the main.css file containing all the styles for the website. If we take a look at the testimonials page, you could create a testimonials.css file containing only the styles needed on that page.

You can even take it a step further and create files for each component on the page. More files will not increase the page load due to HTTP/2 multiplexing. Splitting up files will allow you to cache a component’s JavaScript or CSS file for different page layouts. If we take a look at our previous example, testimonials.css could be split up into header.css, testimonials.css and footer.css. This has the advantage that header.css and footer.css can be cached for other pages and the total CSS size is lower than the main.css file we used before.

Please note that this approach might not be possible for your website and can be a bit complex to set up. But I think it’s an interesting idea and worth checking out.