Developers usually focus on server-side or backend performance testing. This type of testing looks at the server’s behaviour under different conditions, such as large loads during peak times. In this blog we’ll cover what, why and how frontend performance testing is done. We will also cover optimisation techniques for frontend and briefly review frontend performance testing tools.
What is frontend performance testing?
Frontend performance testing tests how quickly an end user gets a response on their browser. How fast components load on the frontend is very important to the end user experience. Users tend to lose interest if the page load time increases by a few seconds. Sometimes, buttons or images load a little later than other web page components. This leads to a poor user experience. Frontend performance testing should be done to check for these issues, and in general developers should always try to optimise the frontend for a better user experience.
Testing how fast frontend resources load is the main use of frontend performance testing.
How is it different from backend or server performance testing?
Server-side performance testing deals with how fast the server responds to the requests, how it will handle a large load of users, how scalable it is and how it handles load balancing (if applicable). Frontend performance testing deals with “How fast the page loads” from a single user perspective. Server performance testing is done from multiple users’ points of view where resources are used concurrently.
A study at Yahoo found that on average only 10-20% of total page loading time is spent on the backend and the other 80-90% time is spent on the frontend. Developers need to optimise that 80% part to enhance user experience in terms of speed and reliability. With the advent of frontend frameworks like Vue js, AngularJS and React, frontend performance becomes even more critical.
Frontend optimisation for better performance
Some optimisation techniques that developers use are:
CDN: Content Delivery Network is the network of interconnected computers. In the past, static resources like images and fonts were served from a single system on which the web application was deployed. Users who were geographically away from that location used to face performance issues because of the late rendering of these components. Some of the private players started their own CDN services. This rapidly changed the web. These components were hosted on CDN networks and helped with the quick exchange of information, thereby improving the speed components are rendered on web pages. Some of the advantages of CDNs are:
Decrease in server load: With the advent of CDN, the load on a single server decreased and the content was served from different locations using different servers.
Less jitter and improved quality: Due to less network latency, streaming content involved less jitter and high quality. It's because of this that property services like Netflix or Amazon Prime can deliver high quality video content without lags.
Audience segmentation: CDNs can deliver different content to different users depending on their geographical locations. They are capable of delivering device-specific content as well.
Limiting the number of HTTP requests: The higher the number of requests to the end server, the longer it will take to render content. It’s best practice to combine multiple requests into a single request. This improves the performance as well.
One such approach is to combine multiple style sheets and scripts into one. Similarly images, etc. could be combined by using CSS sprites, image maps and inline images.
Caching: Storing the content on browser cache for a specific time has considerably improved performance. Without caching, fetching resources used to take a lot of time, thereby decreasing performance. This limits the number of requests as well, which also decreases the load on the end server.
Compressing components: All modern browsers support compressed components. Components like HTML, CSS, and XML files can be loaded in compressed form on the server side. This reduces the load on the server. When these files are transferred to the browser, a decompression process occurs. The following figure shows the impact of compression on various components.
Defer local and third-party scripts: Deferring local and third-party scripts means allowing essential bits of the website to load first. This can be achieved by adding defer along with the script tag.
Avoiding redirects: Redirects are achieved by using HTTPS codes like 301 (moved permanently) and 302 (found). Redirects are commonly found when a site is migrated to a newer system or a new framework. Redirects slow the page load time and thereby decrease the performance.
Placing the stylesheets at the document HEAD: This allows the browser to render progressively and makes the page load faster.
Following the above techniques will considerably improve the overall performance on the client side, thereby improving the user experience.
Metrics in frontend performance
Before deep diving into the metrics involved in frontend performance, we need to understand when exactly a web page becomes usable to us. The Google core developer team answered this using the following parameters:
Is it happening? Has the navigation started successfully? Has the server responded?
Is it useful? Has enough content rendered that it’s useful to end users?
Is it usable? Can users interact with the page or it is still busy?
Is it delightful? Are the interactions smooth and natural, free of lag?
1. Is it happening?
How does a user know that something is happening? When they start seeing some things loading, they understand that loading has started and the server has responded. When something usually appears on screen, it’s called a “paint”.
There are three types of paints:
First paint (FP): The time taken to render first pixels visually on screen is called first paint. When there is a visual change from the previous page, we say the first paint has started.
First contentful paint (FCP): The time taken to render the first content or element.
First meaningful paint (FMP): The time taken to load the most important content is called as FMP, for example hero content on the homepage.
2. Is it usable?
This is measured using time to interactive component (TTI): Users term the component or element usable when they are able to interact with that component, for example focusing or clicking on the element. TTI is the time taken for the page to become fully interactive.
3. Is it delightful?
Sometimes it takes time for a page to become fully interactive. This delay is called the first input delay. When users click on some button there is always a delay in response. First input delay can happen at any time.
Tools and techniques used to measure frontend performance
Some of the commonly used tools for measuring frontend performance are:
Lighthouse: is a Chrome utility available under the audits tab in developer tools. It’s also available as an npm package and can be used in CI/CD pipeline as well. It provides information regarding performance scores based on the metrics discussed above. It also has an option to measure performance on mobile viewport as well. Scores for accessibility and SEO are also available. Lighthouse also provides suggestions for improving performance if it finds any loopholes. In the below screenshots we can see opportunities and some suggestions.
WebPagetest: is a simple website that allows you to generate reports based on the URL entered. It has options for selecting the device, browser and location. An example report for the current Salsa website is shown below:
Dareboost: provides a free site performance test along with a good, interactive report and suggestions to improve performance. Following is a snapshot from a site performance test on the Salsa website:
Frontend performance testing should be a key element of every team's workflow. When this kind of testing and optimisation is done properly, user experience improves as well.
We can employ Lighthouse as part of a CI/CD pipeline. Tools like WebPagetest and Dareboost should be used by developers as well QAs during development phases to check the performance improvements towards the end of the project delivery.