Client-side performance matters – a lot. In fact, most of the time, that is where client-side optimization efforts should go. In this article, I would like to point out fundamental tools for getting deep insight into performance of client-side assets, visualizations of what causes the assets’ size and load time and finally provide some tips on how a developer can be efficient in making assets lighter (I would even fancy it term ‘aircraft carrier-style efficiency’.)
When searching the internet for performance testing resources, it is important to know what you are looking for. There are many tools out there that can be used for different performance tests; however, not all of them will provide accurate results or improve your website’s speed. To solve this issue, I have taken some time to review each of the following tools and determine what they are best used for.
You can conduct performance testing to ensure that the software is working properly. Software performance testing is divided into two distinct categories.
- Client-side Testing: The scope of client-side testing is to evaluate end-to-end scenarios while evaluating the rendering of elements such as CSS and JavaScript files.
- Server-side Testing: The scope of server-side testing is to evaluate logical scenarios, focus on the application behavior under user load, and check the server response time.
In both of these testings, experiments are run to check the performance of the website. These tests check the application for bottlenecks, review the time it takes to load under different speeds, and analyze its loading speed, stability, and scalability.
In the instance of conducting client-side performance testing, what we are checking is:
- How fast and efficient the application is.
- The response time of a web application if the user is using the website for the first time and when they revisit the website the second time.
- The time it takes to render web page elements to the users.
- The time it takes for the user to interact with the first web element and the average time to display the web content.
The Objective of Client-Side Performance Testing
The objective of client-side performance testing, or any performance testing, is to ascertain, evaluate, and make necessary changes in the problem areas.
For optimal results on your client-side performance testing, you can:
- Compress the images and the JS (JavaScript) code.
- Provide faster response times, enable better cache techniques. JS code caching reduces the start-up time of websites.
- Ensure implementation of necessary changes after evaluating the results of server-side performance testing.
- Minimize HTML, CSS (Cascading Style Sheets), and JavaScript content.
- Remove all unused CSS and JavaScript codes.
- Upgrade the server hardware to create more memory space, if needed.
To study, analyze, and make necessary changes in the application, software engineers use metrics to study the key performance indicators to form a conclusion.
Metric Performance Testing
Metrics define the performance of an application by estimating the health, quality, and productivity of the software. A metric establishes the quality of the performance in quantitative terms. Studying metrics can help software engineers and web developers in the following areas:
- It assists in understanding how much improvement is required and where it is required.
- It helps with the early detection of problems within an application or website.
- It is a determiner to check the progress of the development.
- They provide critical insights about application/ software behavior.
- It is a measure of quality assurance and is easy to discuss and improve upon due to its quantitative nature.
- It also helps developers make important decisions, such as estimating the cost of a project and scheduling a future project.
- It evaluates whether the current technology needs any modifications.
Types of Software Testing Metrics
- Process Metrics: This metric defines the characteristics and execution and is essential for improving the software development life cycle.
- Product Metrics: It defines a product’s performance, design, quality, and complexity to tackle its quality.
- Project Metrics: It measuresthe overall quality of a project. It calculates the team’s performance, calculates the project’s costs and defects, and estimates the deliverables.
Client-side Metrics in Performance Testing
Client-side metrics in performance testing test the application’s response for different clients using different platforms such as desktop, mobile, smart TV, etc. Client-side metrics check interaction speed, location, and connection speed.
Important Client-side Metrics in Performance Testing
- Time to First Byte (TTFB)
Time to First Byte is a client-side metric that measures the time spent connecting with the server and downloading the site’s contents. The acceptable range of TTFB is between 100-500ms (milliseconds), with anything being under 100ms is even better.
The unacceptable range of TTFB is anything more than 500ms. Developers can improve upon this by reducing HTTP requests, optimize the application code and database queries, and use a content delivery network.
- CPU Idle Time
CPU Idle Time metric measures the amount of time the CPU was not busy and was waiting for a response from the third party.
- Payload
In web development, the word ‘payload’ refers to the difference between essential information in a chunk of data and the information used to support it. In the context of malware, ‘payload’ refers to the transmission of malicious code via worms, phishing emails, and other mechanisms.
- Time to Interact
Time to Interact or TTI metric measures the time it takes for a website to become fully interactive. A fully interactive page displays useful content and is responsive to user interaction within 50 milliseconds. The acceptable range of the TTI metric is between 0 and 7.3 milliseconds. Between 0-4 milliseconds, it is fast, and between 4.1-7.3 milliseconds is moderate.
The unacceptable range of the TTI metric is anything above 7.3 milliseconds which is considered slow. Some ways to improve the TTI score are reducing payloads with code splitting, decreasing JavaScript, lowering main thread work, and optimizing third-party JavaScript.
- Speed Index
The Speed Index metric calculates the time it takes for the contents of a page to become visibly populated. They are measured in milliseconds, and the lower the score, the faster is the loading performance.
- Load Time
The Load time metric measures the time it takes for a page to appear on your screen. It is calculated from the time you click on a link to when it finishes loading to completion. It is crucial because it determines search engine ranking and increases customer satisfaction.
You can reduce the load time by minimizing the file size, combining HTML, CSS, and JavaScript files, choosing the most appropriate hosting option, and enabling browser caching.
The acceptable range of load time is a contentious subject, with users wanting the optimal time to be 3 seconds, while the average load time is 15 seconds.
- Time to Render
This metric calculates its time to process and display elements to the users.
Measuring client side performance
Due to these factors when we are measuring client-side performance for Single Page application for optimizations we can split them into 3 areas:
- Initial Page load performance
This is the time browser takes to load the application into the browser, this includes static resources, CSS files, JS files, etc. This performance is affected by the Payload size of all static content, Network Latency, SSL negotiations (if any), caching, etc.
- Server-Side Performance
Yes, server-side performance affects the user perceived performance, without having to explain further. This is the time the APIs take to respond with the data. We can say this is mostly affected by server-side performance e.g.: network latency, server-side business logic, DB performance, payload etc.
- Client side execution performance
This is the time taken by the browser to render the page with meaningful content to the user. Don’t forget single page application navigation may not force load contents if the cache is used effectively. Parsing/compiling of client side code/CSS, Client-side code execution (e.g.: JavaScript) and rendering is the performance we are talking about here
Now that we are clear about how the user perceived performance is impacted, lets looks at how we can measure and optimize this performance. We won’t dive into the second point since there are plenty well known tools to help measure the server-side performance. Instead, let’s take a look at the other two.
Initial page load performance
As I have mentioned above, the way we deliver the payload to the browser causes most of the client side performance testing issues here. E.g. uncompressed/non-minified JS, CSS and static contents. Render blocking JS and CSS, non-compressed server-side responses. There are many tools available which can help you with identifying these problems. Below I have listed a few which are free and provided most of the inputs we are looking for:
These will look for bottlenecks in your application such as: render blocking JS, render blocking CSS and heavy resources which can be optimized deferring of unused CSS, JS and critical chains which needs to be optimized.
Client side execution performance
Here, we look how to optimize the performance of the client’s side. How do we check and bench mark these? Combination of tools provided by Chrome Dev Tools is quite powerful to identify issues. Let’s see how:
- Open the web application or a page which you have performance problems with in Chrome latest version (APM tools can suggest which are slow, but, as I said earlier they may not be accurate)
- Now, from Chrome Dev Tools we need to open Performance Tab
- Start Profiling
- Perform the action/navigation you want to optimize
- Stop Profiling
- From the results:
- Expand Network
- Expand Main
- Switch to Bottom Up
- Network longest block shows you the network call which is taking most of the time (to be addressed at API level). This also shows how the requests are fired, you can identify a critical patch and try to optimize this to be as parallel as possible.
- Main shows the program execution details, again look for the largest block here to find the bottleneck. You can start by looking at the API(XHR) calls in network and see the events which are in Main immediately after the response is complete. You may find XHR Load event in Main (these could be targets for optimization).
- Once you select the item in Main, you can look at the Bottom-Up and then drill down to your application method which is taking most of the time. You can jump directly to the code block as well from here. Please see the example below
CONCLUSION
Each month thousands of Javascript file are sent to user’s browser. Some of these files are necessary but most aren’t required by the website. All these functions may lead to a bad experience and performance issues. Client-side performance testing is the need of the hour. When you are evaluating potential tools for client side performance testing, there are certain factors that should be considered before committing to one of them. Below listed are certain notable parameters to evaluate.
Performance is an important part of digital marketing. If your website takes time to load, you might be losing critical sales. In addition, if your site takes too long to load, Google Chrome might even label it as a slow loading site and it will affect your rankings in SERPs. So if you run a business website or blog, it is important for a business website’s performance as well. There are lots of ways you can speed up your site’s page load time like optimizing images, reducing server response time, reducing the size of the code etc. While optimizing images and server response time are easy to understand and follow but the code optimization can be made messier for some people. To make it easy for small business owners who don’t have any knowledge about coding or technical stuff I am going to share some tools which would make your client side performance testing easier.