Client Side Performance Testing

INTRODUCTION

You want to know how effective your web design is, right? We offer client side performance testing that lets you view how your users interact with your site. Get results from 50 real people, set up the test in just a few minutes. Includes 3 days of reports and data.

Testing client side performance is important if you want your websites to load quickly and efficiently. Using a Wide range of JavaScript-based benchmarks, WebPagetest can measure how quickly your website loads on different hardware and internet connections, ensuring that your users are getting the best experience possible.

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.

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 “minifier” 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’ browser 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

Basic text and layout. The visible framework of the page should load quickly, with key text elements placed in the correct location.
Functional elements. Ideally, these should be visible, responsive, and fully functional as soon as possible.
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 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.

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 tests – 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. However, 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 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.org

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 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 a 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 “NetExport” plugin allows to export 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 and

2. How content gets delivered to the end-user

Conclusion

Customer satisfaction is vital when it comes to your website. Performance testing is useful for checking the usability of your website. Client-side metrics in performance testing are tools that help you in this context.