Client-Side Performance Testing

Client-Side Performance Testing Importance and Introduction

If you're worried about the performance of your web application, you need to test and analyze not only with what happens on the server but also with what happens in the browser. Some commercial performance-monitoring solutions already take this into account, allowing performance engineers to see how long it takes for elements to render, and then to execute, on your users' browsers. There is also no shortage of open-source tools available for you to check and improve the ways in which your client-side programs are executing and working.

You may also like: Client-Side v/s Server-Side Rendering: What to Choose When?

Page load time is one of the most important metrics in web applications. According to Yahoo, around 80% of application response time is spent downloading elements such as images, stylesheets, scripts, etc. To speed up response time requires strong servers and a well prepared and tested application.

This is where performance tests come in. They analyze the speed, scalability, and stability, sustainability of an application, checking for memory leaks, how the application works under a certain load, and look for any bottlenecks.

To provide better feedback, performance tests are divided into two types: server-side and client-side. When you are testing server-side code, you are testing the logic and readiness of your application. When you are testing the client-side, you are doing end-to-end testing.

To verify if an application is fast and efficient enough, we use client-side performance tests. This means checking the response time of a web application from the point of view of a single user. We execute these tests against two scenarios:

1. A user coming to the web page for the first time (without cache).
2. A user coming back to our page (with cache).

Client-Side Performance Considerations

The client-side code is written in JavaScript. The code, whether inline in <script> tags or retrieved from a remote server, executes whenever the browser's parser gets to that part of the page. If you have JavaScript at the top of the page, it'll be executed when the parser gets to it, potentially delaying the rendering of the rest of your page.

If your JavaScript is at the bottom, the parser will execute it only after parsing and rendering the rest of the page. This is why so many developers learned to put their JavaScript commands inside a "document-ready" callback function. In that way, the code was executed only once the entire page had been loaded.

When loading JavaScript from remote servers means that the time it takes to render a page depends not just on the server speed, the network bandwidth, and the page's complexity, but also on the servers and networks serving such JavaScript, as well as those pages' complexity.

Consolidating all our JavaScript files into a single file has many advantages. It means the user's browser needs to download a single file, rather than many of them. If you include all of the JavaScript needed on your site in a single file, it also means that the file needs to be loaded only a single time.

On every subsequent page load, the JavaScript will be mentioned, but it won't be downloaded, because it'll already be cached in the browser's memory. This turns out to be extremely effective because compression algorithms work well wrt performance.

It is always a good practice to run your JavaScript code with “minimizer” or “minified” which removes comments, extra spaces and everything else that is not necessary for client-side programs to run. Also, by combining and compressing the files we can reduce the JavaScript size that is being sent to users’ browsers and ensure that is loaded only once per visit to your application/website.

Client-Side – Front-End Performance Testing Challenges

Performance depends almost entirely on everything. The greatest threat to performance was likely to be the connection speed, followed by server overload. The browser spent much of its time with a fully loaded page of HTML, just waiting for graphics and other content.

• How quickly basic page features load?
• Visible text.
• Graphics.
• Formatting and layout (CSS).
• Functional elements (buttons, links, forms, etc.).
• Understanding the priorities on how quickly functional elements become responsive (at all) to user actions.
• How quickly functional elements are able to carry out user requests.
• How long it takes for the entire page and all of its functionality to load.
• Matching the exact real-world environment with real content and new code.
• Identifying which elements are important in a Page and when do they load?
• Concluding the issue – Is the issue Front end or Server-side?

Client-Side Performance Priorities

1. Basic text and layout. The visible framework of the page should load quickly, with key text elements placed in the correct location.
2. Functional elements. Ideally, these should be visible, responsive, and fully functional as soon as possible.
3. Formatting and images. In a page where graphics are not crucial, CSS and graphics can load after functional elements.

Download Time

Once the JavaScript is in the user's browser, things are both easier and harder to analyze. We will see how long it takes for each of the JavaScript (and CSS, and image) files to download and how much time it takes between the user requesting your page and the content actually appearing on it. This is a great way for you to identify potential bottlenecks and then reduce their effect on the slowness of your site.

Once we have combined and compressed your JavaScript files, we should consider putting them, as well as any other static assets (such as CSS files and images), on a content distribution network (CDN) for high performance and availability. Using a CDN reduces the load on your main web server while decreasing the actual and perceived download times.

Benchmarking JavaScript

It is sometimes hard to know where your program is spending most of its time. Go to the "profile" tab in the developer tools and select the CPU option before visiting your site. You can run through your site for a few seconds or minutes before stopping the profiling from taking place. Once you've done that, you'll get a (very long) indication of which JavaScript programs were running, where they came from and how much time the CPU and memory spent in each one.

We have to profile the JavaScript code, the most frequently used code and the underlying framework that is using. All the client-side performance tools and plugins provide great details like why issues are problematic and what steps you can take in order to fix them. The tools will also suggest which images could be compressed and how much space we would save by doing it.

Scope of Client-Side Performance Testing

We always include client-side performance tests in our scope of tests to ensure that the delivery of projects is of the highest quality. Every performance engineer should care about industry standards and always seek to implement best practices to ensure better performance.

The first step is to define the scope of Client-Side Performance Testing. This should be defined in the Non-Functional Test plan and agreed by the client. The scope may include:

• Client-side analysis of all aspects of performance.
• Find bottlenecks.
• System optimization.
• Identifying risk related to client-side performance.

We would then provide a recommendation on client-side performance bottlenecks after completing the client-side performance tests. The results will be published with detailed analysis and recommendations along with the performance issues fixed from the client-side with the help of Client-side Performance testing tools that we use wrt to our various business demands.

Client-Side Test Types

The Non-Functional Test plan should also present information about Client-side performance test types. We can execute three types of tests:

• Desktop tests — Client-side tests on the desktop browser.
• Mobile tests — Client-side tests on mobile devices.
• Limited resources test — Client-side tests with limited resources of CPU, memory, network, localization, etc.

When Client-Side Performance Testing should happen?

The Non-Functional Test plan will also summarize when Client-Side performance tests should be executed. Usually, this would be before or during the UAT phase. But the good practice is to execute it as soon as an application or even a single page is ready.

Which Environment We Should Use for Client-Side Performance Testing?

Ideally, for Client-side performance testing, the application should be released and present in an environment similar to production. In order to act early and to protect from any issues, we can run static analysis on any other environment where new code is present.

Performance engineers should make sure that the application is ready for non-functional tests and is populated with real content. We recommend running tests on real content because this shows the information on how content can affect the size of the page and the whole performance of the page. If real content is not available, the best practice is to prepare a production-like environment with new code to execute the client-side performance tests.

If we are executing the client-side performance test on a production-like environment with a new code, we always consider what is most important for the client and try to cover as many components and templates as possible. Last but not least, we make sure that we have access to the environment where we conduct these Client-side performance tests. Without access, our tests will not be executed or our results will be inaccurate.

Client-Side Performance Testing Tools

We have many Client-side Performance testing tools available in the market. When we are ready with the client-side performance testing strategy, scope and plan we can execute our tests but we still need to choose which tools we will use. The simplest tools that we use in our daily work are Chrome Developer tools. We can use these for client-side performance tests but this will mostly be manual work.

Google PageSpeed

To automate tests we can use Pagespeed also developed by Google. It is an automated scanner that analyzes an application and gives us a grade and helpful tips on how to improve the performance of the tested application.

WebPageTest

We also use and recommend WebPageTest which speeds up the execution time of tests. Or, Automated Scanner provides grades from scanning the application but also provides information such as speed index, total load time or time to the first byte

Dynatrace

Dynatrace is a powerful tool for profiling page load. It records all activities which occur during the load and gives comprehensive reports. The collected data includes information about all subrequests, information on internal timings values (full page loading, DOM model loading, rendering of the page and so on), the execution time for each JS-function and much more.

Talking about drawbacks, the tool works only with IE browsers as it operates via plugin and works only in the Windows environment. Despite this minor inconvenience, I think this tool is a “must-have” for every web developer.

Browser Plugin’s

Everyone knows FireBug for the Firefox browser. But not everyone uses it for performance testing purposes. The “Net” tab within the plugin provides the ability to analyze the statistic of each activity taking place within the browser. Adding the "NetExport" plugin allows exporting all recorded data to the HAR format for further investigations.

There are two other similar plugins: PageSpeed from Google and YSlow from Yahoo. Both tools provide reports about the general performance of a page and hints for improvement. Another tool — online service GTmetrix- helps to leverage all the plugins mentioned above. You just enter the URL of a webpage and promptly receive a summary report.

Important Metrics in Client-Side Performance Testing —What To Measure?

First Reaction – Time to First Byte (TTFB)

Time from the start of the initial navigation until the first byte of the base page is received by the browser (after following redirects)

Content Appears – Time to Start Render

Time from the start of the initial navigation until the first non-white content is painted to the browser display

Page Processing Completed – DOM Content Ready End

The point when the HTML Parser has reached the end of the document which means it has executed any blocking scripts. The CSSOM may not be complete yet

Full Page Loaded – Doc Complete Time

The onload event which fires when all of the scripts, CSS, and images defined in the HTML have finished loading (including below the fold content)

Techniques to Improve Client-Side Performance

We need to understand and optimize the following:

1. Architecture.

2. How content gets delivered to the end-user.

Conclusion

Using a wide variety of client-side performance testing tools to check the site/application performance, as well as to reduce the size and time of JavaScript and CSS downloads, will go a long way towards improving the users' satisfaction of the websites and applications

Thanks for reading the article. Happy Learning:)

Further Reading

Should Your Browser Make Client-Side Web API Calls?

Performance Testing of Mobile — How Is This Different?

Skills Required To Be A Perfect Performance Engineer