Dive into the world of browser-based load testing with Grafana and K6, focusing on enhancing the performance of front-end web applications. Explore the seamless integration of Grafana and K6, gaining insights into effective strategies for testing and optimizing website performance. Uncover practical tips, best practices, and real-world examples to elevate your front-end load testing proficiency. Join us for an engaging session at the intersection of Grafana, K6, and front-end performance optimization.

1. Browser-Based
Load Testing with
Grafana K6
Himanshu Gupta (Software Consultant)
Test Automation Competency

2. 1. Introduction to Load Testing
• What is Load Testing?
• Why Load Testing is important?
• Real World Example of Performance Failure
2. Overview of Browser-Based Load Testing
• Browser-Based Load Testing & its Key Features
 Why Browser-Based Load Testing?
 Browser Based Testing over API Testing
 Pros & Cons of Browser Based Testing
3. Selection of Tool for Browser-Based Load Testing
4. Introduction to K6
• Leveraging K6 Browser Module
• Use Case of Browser Testing
• Writing a Basic Browser Level K6 Script
• Running Browser Level K6 Script
• Understanding Browser Metrices Output
5. Reporting Mechanism
6. Leveraging POM in K6
• What is Page Object Model?
 Implementation of Page Object Model in K6
7. Tips for Writing Browser level Scripts
8. Common Pitfalls to avoid in Browser-Based Load Testing
9. Best Practices for Browser-Based Load Testing
10. Demo/QnA

3. WHAT is Load Testing
The goal is to assess how well the application can handle a specific amount of concurrent
users or transactions while maintaining acceptable performance levels.
WHY Load Testing
Load testing is particularly important for several reasons:
• Resource Planning
• Performance Optimization
• User Experience Optimization
• Identifying Performance Bottlenecks
• Reliability and Stability

4. Real World Examples of Performance Failure

5. Let's Discuss Browser-Based Load Testing
Browser-based load testing verifies the frontend performance of an application by simulating real users using a
browser to access your website. Unlike traditional load testing tools that operate at the protocol level, browser-
based load testing tools interact with web applications just like real users do, using web browsers.
For example, a browser-based load testing script might include instructions to navigate to a page, click on a
button and type out text on a form. Those user actions then trigger underlying requests on the protocol layer,
but only user actions are scripted in browser-based testing.
Key features of browser-based load testing include:
o Realistic User Scenarios
o JavaScript Execution
o Browser Diversity
o Load Distribution

6. Why Browser Based Load Testing

7. Browser Based Testing over API Testing
1. Scope
a. Targets the underlying application servers.
b. Focuses on how assets are processed, served, and
downloaded.
2. Testing Environment:
a. Conducted on application servers in a production-like setup..
3. Flexibility:
a. API testing allows targeting specific components.
4. Early Issue Identification:
a. Chances of finding performance issues in early stages.
5. Resource Intensity:
a. Less resource-intensive compared to frontend testing.
6. Suitability for Load Testing:
a. More suitable for generating high loads on the server..
API Based Testing
1. Scope:
a. Measures end-user experience at the interface level.
b. Concerned with how and when page elements
appear.
2. Testing Environment:
a. Requires a fully integrated environment with UI.
3. Flexibility:
a. Primarily focused on the user interface level.
4. Early Issue Identification:
a. Excels at identifying issues on a micro-level.
5. Resource Intensity:
a. More resource-intensive, especially for automation.
6. Suitability for Load Testing:
a. Tends to be easier to run on a small scale due to
resource constraints.
Browser Based Testing

8. Pros & Cons of Browser-Based Load Testing
Higher Memory Usage
Occasionally Longer Runtime
Limited Browser Environment
Capabilities
Simple Scripts
User Perspective
Low Maintenance
Front-end Optimization
Reduced Test Complexities

9. Tool Selection For Browser Based Load Testing
S
E
I
U
R
C
Scripting Language
Choose a tool that supports a scripting language your
team is comfortable with or one that aligns with your
project requirements.
Cost
Consider the licensing costs or any associated
costs with the tool, especially if you are working
within budget constraints.
Integration
Check for integration capabilities with other tools and
your existing CI/CD pipelines.
Ease of Use
Consider the learning curve and ease of use
for your team, especially if they are not
experienced with a particular tool.
User Simulation
Evaluate how accurately the tool can simulate real user
interactions. This is crucial for realistic load testing.
Reporting & Analysis
Look for tools that provide detailed and meaningful
reports, as well as options for result analysis.

10. Introduction to K6
• Grafana K6 is an open-source load testing tool that makes
performance testing easy and production for developer and DevOps
teams.
• K6 benefits from a vibrant community, providing support, sharing
scripts, and contributing to continuous improvement.
• K6 is compatible with various systems and environments, making
it suitable for a wide range of applications and use cases.
• K6 empowers teams to identify and address performance issues
early in the development lifecycle, ensuring robust and
scalable applications.

11. Leveraging K6 Browser Module
• The browser module brings browser automation and end-to-end web
testing to k6 while supporting core k6 features. It enables you to get
insights from your front-end application during performance testing.
• You can now mix browser-level and protocol-level tests in a single and
unified script using k6. This can simulate the bulk of your traffic from
your protocol-level tests and run one or two virtual users on a browser
level to mimic how a user interacts with your website, thus leveraging a
Hybrid approach to Performance Testing.
• The browser module offers a unique solution as you don’t have to use
separate tools to test your frontend and backend systems. It also offers
a simplified experience and aggregated view of performance metrics.

12. Use case for Browser Testing
• The main use case for the browser module is to test performance on the browser level. Browser-level testing
provides a way to measure user experience and find issues that are difficult to catch on the protocol level.
Browser-level testing can help you answer questions like:
• When my application is receiving thousands of simultaneous requests from the protocol-level, what happens to
the frontend?
• How can I get metrics specific to browsers, like total page load time?
• Are all my elements interactive on the frontend?
• Are there any loading spinners that take a long time to disappear?

13. Writing a Basic Browser level K6 Script

14. Running Browser level K6 Script
Execute this command to run tests:
K6_BROWSER_HEADLESS=false k6 run script.js

15. Understanding the Browser Metrics Output
When a browser test finishes, k6 reports a top-level overview of the aggregated browser metrics output. HTTP
requests that were triggered by the browser test are also reported. Below is the example of browser Metrics:

16. Reporting Mechanism
• The summary report provides a high-level overview
of the key performance indicators from your test.
It's useful for quickly understanding the overall
health of your system during the test.
• Information Included:
− Total number of virtual users (VUs).
− Duration of the test.
− Response time percentiles (e.g., 50th, 95th, 99th
percentiles).
− Request and response statistics.
− Error rate.
− Virtual user distribution.
Summary Report
• The HTML report is more detailed and provides a
visual representation of the test results. It includes
various graphs and charts that can help in-depth
analysis.
• Information Included:
− Response time trends over time.
− Requests per second (RPS) trends.
− Latency distributions.
− Error rates.
− Virtual user activity over time.
− Custom metrics and their trends.
HTML Report

17. Leveraging Page Object Model (POM) in K6
 Page Object Model, also known as POM, is a
design pattern that creates an object repository
for storing all web elements.
 It helps reduce code duplication and improves test
case maintenance. In Page Object Model, consider
each web page of an application as a class file.
 The main idea behind the Page Object Model is to
abstract the details of the user interface
(UI) components and their interactions with the
underlying code, making the automation code
more modular and readable.

18. Implementation of Page Object Model in K6

19. 02
01
Tips For Writing Browser Level Scripts
03
Script User Actions,
not Requests
04
Lorem Ipsum is
simply dummy text of
the printing.
Identify Unique
Selectors Lorem Ipsum is
simply dummy text of
the printing.
Use Elements to
Verify Responses Lorem Ipsum is
simply dummy text of
the printing.
Take Screenshots for
every action while
debugging

20. Best Practices for Browser Based Load Testing
01 02
03
05
04
Identify business goals
Lorem ipsum 3
Always keep end-users in mind
Ramp-Up Gradually
Script Realistic User Scenarios
Continuous Monitoring
Lorem ipsum 6
Choose a suitable tool
06

21. Common Pitfalls to Avoid in Browser-Based Load Testing
• Ignoring Realism
• Neglect Data Variability
• Inadequate Monitoring
• Overlooking Isolation
• Poor Documentation
• Incomplete Reporting
• Limited Test duration
• Ignoring User Experience
• Static Parameterization