Client-Side Performance Testing
Client-Side Performance Testing
If you're worried about the performance of your web application, you need to test and analyze what happens in the browser.
Join the DZone community and get the full member experience.Join For Free
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:
- A user coming to the web page for the first time (without cache).
- A user coming back to our page (with cache).
Client-Side Performance Considerations
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.
- 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.
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.
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.
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 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.
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:
2. How content gets delivered to the end-user.
Thanks for reading the article. Happy Learning:)
Opinions expressed by DZone contributors are their own.