A closer look at Grafana k6 browser: alignment with Playwright, modern features for frontend testing, and what’s next

Over the years, we’ve seen our community embrace Grafana k6 browser as a key component of their frontend testing strategies. By helping collect frontend web vitals, capture custom metrics, and simulate user actions like clicking buttons or completing forms, the module offers teams a deeper understanding of performance and availability from their end users’ point of view.

One of the most common pieces of feedback we’ve received relates to the module’s compatibility with Playwright, a popular open source automation library for browser testing. Typically, we refer to the k6 browser module as having “rough compatibility” with Playwright and, understandably, some users have asked for more clarity on what, exactly, that means. 

In this blog post, we hope to provide that clarity by outlining how k6 browser works with and compares to Playwright. We’ll also walk through other key features of k6 browser for modern frontend testing and explore what’s to come.

k6 browser and Playwright: key similarities and differences

Grafana k6 browser is a browser automation and end-to-end web testing module that you can use in Grafana k6 OSS, Grafana Cloud, and Grafana Cloud Synthetic Monitoring.

As mentioned above, we often refer to the module as being “roughly compatible” with the Playwright API. By this, we primarily mean that if you are familiar with Playwright, you will find the k6 browser API and scripting style to be very similar. The goal has been to make it easy for users to write browser automation tests in Grafana k6 without having to learn a completely new API.

Other key points of compatibility between k6 browser and Playwright include:

• Async-first design: Like Playwright, k6 browser APIs are asynchronous and require await, ensuring operations finish before the script moves on.
• Different runtime: Unlike Playwright’s NodeJS environment, k6 runs on Sobek, a JS runtime written in Go. This means minor differences in behavior or features may occur.
• Script portability: Playwright scripts can often be ported to k6 with minimal changes, letting teams reuse existing test logic and knowledge.

For example, below we have a Playwright test script using modern and stable APIs for the website under test:

JavaScript Copy

import { test, expect } from '@playwright/test';

test('test', async ({ page }) => {
  await page.goto('https://quickpizza.grafana.com/');
  await expect(page.locator('h1')).toContainText('Looking to break out of your pizza routine?');
  await page.getByRole('button', { name: 'Pizza, Please!' }).click();
  await expect(page.locator('#pizza-name')).toContainText('Our recommendation:');
  await expect(page.getByRole('button', { name: 'No thanks' })).toBeVisible();
  await expect(page.getByRole('button', { name: 'Love it!' })).toBeVisible();
});

You can simply copy and paste the main body of the test from your Playwright script into k6 browser and run it with k6 (again, sometimes with a few small modifications):

JavaScript Copy

import { browser } from 'k6/browser';
import { expect } from "https://jslib.k6.io/k6-testing/0.5.0/index.js";

export const options = {
  scenarios: {
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
  },
};

export default async function () {
  const page = await browser.newPage();
  await page.goto('https://quickpizza.grafana.com/');
  await expect(page.locator('h1')).toContainText('Looking to break out of your pizza routine?');
  await page.getByRole('button', { name: 'Pizza, Please!' }).click();
  await expect(page.locator('#pizza-name')).toContainText('Our recommendation:');
  await expect(page.getByRole('button', { name: 'No thanks' })).toBeVisible();
  await expect(page.getByRole('button', { name: 'Love it!' })).toBeVisible();
}

k6 browser will never achieve 100% parity with Playwright, and that’s by design. We were inspired by Playwright and other open source testing tools when creating the module. We selectively adopted the APIs and patterns that best serve our users’ needs in the context of performance and synthetics testing.

For example, Playwright has an extensive API surface designed to handle virtually every browser automation scenario imaginable. While this breadth is powerful, much of it extends beyond what’s needed for frontend performance and synthetics testing. Our approach is more focused: we identify and implement the Playwright APIs that our users need, ensuring they can leverage modern frontend testing best practices without added complexity.

Benefits of this approach 

This approach, where we build off the best ideas from across the open source ecosystem to create something specifically optimized for performance and synthetics testing, unlocks several advantages for our users that wouldn’t be possible if we simply wrapped existing tools. 

These include:

• A unified testing ecosystem: We can build a cohesive solution that excels at both load testing and synthetics testing. Our k6-jslib-testing library provides Playwright-like assertions and testing utilities, allowing teams to use familiar patterns while benefiting from k6’s testing capabilities.
• Cloud-scale browser testing: We can run browser modules at scale with Grafana Cloud, offering distributed browser testing capabilities that integrate seamlessly with our observability and performance testing infrastructure.
• Opinionated, actionable results: We can be deliberate about which metrics and results matter most for web performance. For example, we’ve made Web Vitals a core component of the browser module, surfacing the metrics that directly impact user experience.
• Freedom to innovate: When Playwright or other frameworks don’t align with our users’ needs, we can diverge. We’re not constrained by maintaining direct compatibility with features that don’t serve performance and synthetics testing use cases.

Our short-term goal: strategic API adoption

In the near term, we’re working through a curated list of the most valuable Playwright APIs (based on user feedback and analyses of Playwright scripts) to incorporate into k6 browser. You can track our progress on this initiative in our GitHub issue. This strategic approach serves two key purposes:

1. Embracing modern best practices: Users get access to the latest, most effective patterns in frontend testing. This includes working with getBy* APIs that allow for more user-centric, stable, and self-documenting element location.

2. Enabling smoother migrations: Teams already using Playwright can more easily transition their most common test patterns to k6 browser for performance and synthetics testing scenarios.

We’ll continuously analyze community needs and incorporate additional APIs as they prove valuable for our use cases.

Our long-term vision: simplify frontend testing

Our main goal, which goes beyond API compatibility with Playwright, is to fundamentally simplify frontend testing. We’ve identified four key areas where current browser testing tools, including k6 browser, require too much specialized knowledge. These four areas reflect where we want to focus our efforts as we continue developing the module:

1. Website architecture: Test writers won’t always have knowledge of iframe hierarchies, or know how to manually traverse complex page structures. Looking ahead, we’d like to build some intelligence into k6 browser to handle these tasks automatically.

2. Browser model abstractions: The typical browser testing mental model — browsers, browser contexts, pages, frames, element handles — represents implementation details that many test writers shouldn’t need to understand. We want to abstract these complexities away where possible.

3. JavaScript: We frequently hear from teams who want to write tests in their preferred languages rather than work with JavaScript (which is the supported language in k6 browser). As such, one of our goals is to make it easier to work with JavaScript through more intuitive, concise APIs.

4. Frontend-specific concepts: Frontend testing tools are designed primarily for frontend developers, creating unnecessary barriers for other engineers. Skilled backend engineers, QA professionals, or SREs can struggle with concepts like CSS selectors, DOM traversal, and frontend-specific debugging techniques. We want k6 browser to be as broadly accessible as possible — you shouldn’t have to be a frontend expert to use it for testing. We’ve made progress in this area with k6 Studio, an open source application that helps you create test scripts quickly and easily via a visual interface. 

Beyond these four areas, we’re also exploring ways to support frontend tests that read like natural language. Instead of requiring deep technical knowledge about browser internals or complex JavaScript patterns, tests could be written in a way that focuses on user behavior and business logic.

Final thoughts and how to get involved 

Looking ahead, we’ll continue to selectively implement Playwright APIs for k6 browser, prioritizing simplicity and ease of use over full coverage. We’ll specifically focus on performance and synthetics testing, evolving with community feedback and best practices.

We’re excited about this direction and would love to hear your thoughts. What aspects of frontend testing do you find most complex today? Which Playwright APIs are most important for your testing workflows? We hope you’ll share your feedback in our community forums or GitHub issues — your input directly shapes our roadmap.

Grafana Cloud is the easiest way to get started with Grafana k6 and performance testing. We have a generous forever-free tier and plans for every use case. Sign up for free now!