How to optimise frontend performance

You should focus on frontend performance when developing your service’s website. This will improve the user experience of your service by making your website respond faster and work better on all devices.

Prioritise performance tasks

You can optimise your site’s frontend performance by prioritising tasks that will improve your site speed. Prioritise things you must do (high) over nice to have (medium or low priority) tasks.

For example:

Priority	Example	Action
High	Position assets correctly	Set styles at the top of the page and `defer` scripts.
	Compress static resources	Minify CSS and JavaScript and use a compression algorithm like Gzip and Brotli on assets.
	Set correct Headers	Set correct Cache-Control and ETag headers on assets for optimal caching.
	Minimise unused code	Avoid including CSS and JavaScript that is not used on your site.
Medium	Include `width` and `height` attributes on images to minimise layout thrashing	Make sure to include these attributes to improve visual stability and the Cumulative Layout Shift (CLS) metric.
	Minimise TCP connections	Use fewer third-party domains to reduce the number of DNS + TCP + SSL negotiations per page.
	Investigate lazy loading	For pages with many images, only load images in the immediate browser viewport.
	Investigate the impact of loading @font-face assets on perceived performance	Use the CSS `font-display` property or other font-loading strategies to manage common issues like FOUT, FOIT and FOFT.
	Minimise HTTP requests	Minimise the number of CSS and JavaScript files to reduce the number of round-trips to the server. See ‘Code splitting’ below.
Low	Reduce cookie size	Because every cookie is sent with each HTTP request, enable HTTP/2 to enable HPACK header compression or HTTP/3 for QPACK.
	Investigate using a Content Delivery Network (CDN)	A CDN will improve site performance by using a network of servers to deliver resources to users. The user will get delivered resources from the server that is located nearest to the user. A CDN is well-suited to handling heavy traffic and traffic spikes.
	Keep JSON payloads small	Avoid adding too much data to JSON objects, as parsing them can be slow.
	Investigate using WebSockets	Consider using WebSockets rather than XMLHttpRequestfor tasks involving streaming from the server - an HTTP request packet has 1,684 bytes of overhead, compared to 8 bytes for a WebSocket packet.
	Investigate using a service worker	Consider using a service worker for fine grain cache control of critical assets on users’ machines instead of transferring them over the network.

Automate optimisation

You can automate performance optimisation using tools such as:

You should integrate these tools into your Continuous Delivery (CD) and Continuous Integration (CI) workflow so they automatically run before deployment.

Consider automating common tasks like:

CSS and JavaScript linting and optimisation
CSS and JavaScript minification
image optimisation
sprite and icon generation
SVG optimisation

Automate testing

You can automate frontend performance testing using third-party services such as:

Using Speedcurve to automate frontend performance testing

You can use Speedcurve to test the performance of your service.

Speedcurve provides an extensive set of tools to test your service such as the following:

Test from different locations and different browsers.
Schedule regular tests using tools like Google Lighthouse and Webpage Test.
Real user monitoring, which allows you to collect data that shows you how your real users experience the speed of your site.

Contact a Lead Frontend Developer to request an account.

Performance budget

You should set a performance budget for your website’s pages. Once you’ve set a performance budget, test to check your website’s pages stay within your budget. There are many tools available to do this, such as:

Code splitting

You should concatenate your Javascript and CSS files by default, as this minimises the number of requests and makes compression more effective. However, you may benefit from splitting your code into multiple bundles in some cases:

if a specific feature is only used sporadically, it may make sense to split it out and only load it on pages where it is needed.
if some of your code is updated more regularly than others, it may make sense to split it out so that less frequently updated code is still cached.

Use HTTP/2 or above

HTTP/2 is supported in all of the Service Manual’s browsers to test in. It improves speed for most users by allowing browsers to:

Download multiple resources at once
Compress cookies in request headers
Prioritise specific assets for download.

You should also consider enabling HTTP/3. While this isn’t supported as widely as HTTP/2, it is supported by most of the Service Manual browsers and it solves an issue with HTTP/2 that affects users with slow connections.