As of k6 version 0.43.0, xk6-browser is now bundled in k6 as an experimental module! 🙌 Since announcing xk6-browser in November 2021 at Grafana ObservabilityCON, the team have been busy adding on new features to include browser automation in k6. The interest from the community has also increased, which shows that browser automation and frontend performance is as important as backend performance.
Load and performance testing remains a vital aspect of any software delivery process. Ensuring that your application supports the anticipated number of concurrent users prevents brand damage, system failures in production, and loss of revenue. There is a saying in engineering that the shape of the solution is dictated by the shape of the problem. Translating this to performance testing solutions, there are several common design elements that all load and performance testing solutions share.
In this article, we will discover the process of sending custom metrics, provided to us through the xk6-browser, in order to gain a better understanding of our performance tests. Through the integration of these metrics, we will be able to create more tailored Slack messages that will help to manage our rule sets.
Grafana Faro and xk6-browser are both new tools within the Grafana Labs open source ecosystem, but the pairing is already showing a lot of potential in terms of frontend monitoring and performance testing. Faro, which was announced last November, includes a highly configurable SDK that instruments web apps to capture observability signals that can then be correlated with backend and infrastructure data.
We are going to look at how performance testing can work hand in hand with Artificial Intelligence and Machine Learning: As there are many Artificial Intelligence solutions to choose from and for the purposes of this post this is the easiest way to discuss the principles of Artificial Intelligence working with performance testing rather than discussing a particular framework.
The first month of 2023 has already ended and we are excited to share the new updates and features that we implemented in Loadero over the past month and some of the fixes we made during that time. If you are using Loadero to test WebRTC solutions, make sure to read the section about updates for WebRTC metrics gathering, it also has information about important upcoming changes.
The last thing a business wants is to be known as an unreliable and poorly performing service, especially if there are similar solutions a few clicks away. So being aware of the performance of a WebRTC application or any other software solution is a must to avoid issues in the future. A solution can be developed by experienced people and tested before it is released, but even so it doesn’t mean performance degradations will never appear.
As holiday season winds down, we can reflect on the reverse load test that we did to make sure our customers could prepare for their own holiday traffic. What’s a reverse load test? OK, it's a term we just made up. But it started like any load test, with two systems: the load generator and the system under test (SUT). The focus of our test, however, was inverted. In normal load tests, testers really care only about how the SUT performs—that’s the point of the test.
At k6, we get frequent requests to compare k6 vs. LoadRunner, and since I am an experienced user with LoadRunner (even certified), I will try to put both tools head to head. But comparing these tools is difficult as their components do not match 1:1. Each is a robust ecosystem with different parts, some doing multiple things that make straight comparisons more complicated. And on top of that, we constantly get new features that match up with many other components.
This post explains how to get started with xk6-browser, a k6 extension that adds browser-level APIs to interact with browsers and collect web performance metrics as part of your k6 tests.
