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" >
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.
The fastest request is no request
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.