Performance testing splits into three layers. Pick one open-source tool per layer.

No, and conflating them is the root cause of most bad tool selection. Load testing means: hold N concurrent virtual users hitting your API and measure throughput, latency, and error rate at the protocol layer. Browser-perceived performance means: a real Chromium opens your page, paints pixels, runs JavaScript, and the user feels how long until the first interaction worked. Network-edge testing sits between them, asking how a TCP connection or HTTP/2 multiplexing behaves under contention. Open-source tools cluster around one of those three layers and only rarely cross over. k6 is a load testing tool. Lighthouse is a browser-perceived performance tool. wrk is a network-edge tool. Treating them as substitutes is how teams end up with a green k6 dashboard while real users experience a 6-second LCP.

If your team writes JavaScript or TypeScript every day, k6 is the path of least resistance. Tests are JavaScript modules, the CLI is a single binary, and CI integration is a one-line shell command. The tradeoff is that k6 open source is licensed under AGPL v3, which is copyleft, so be aware if your usage is unusual (most teams running k6 in CI are unaffected). If you write Python, Locust is the same shape but Pythonic, MIT licensed, and the web UI is friendly for non-engineers spectating a run. JMeter and Gatling are both Apache 2.0, both more powerful, both with steeper learning curves. JMeter is GUI-first and battle-tested across ten-plus years of enterprise deployments; Gatling is code-first in Scala or Java with excellent reporting. Pick by language fluency, not by feature checklist, because the second-day operability difference is much larger than any feature gap.

k6 is now part of Grafana Labs, and Grafana Labs uses AGPL on its open-source projects to limit competing managed cloud services without limiting in-house use. AGPL is a strong copyleft license: if you modify k6 and run it as a service for third parties, you must publish your modifications. Running k6 inside your own CI to test your own application is the normal use case and is not affected. If you are wary of AGPL specifically because your legal team has a blanket policy against it, JMeter (Apache 2.0), Gatling (Apache 2.0), and Locust (MIT) are the permissive alternatives.

They measure what an individual user experiences in the browser: First Contentful Paint, Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint. None of those are load metrics. They tell you whether the page is slow for one user, not how it behaves under thirty thousand users. The right pairing is to run k6 or JMeter to put load on the API while Lighthouse runs the page in headless Chrome against the same backend. If LCP doubles under load, you have a backend bottleneck affecting the frontend; if LCP stays flat under load but is bad in isolation, the problem is in the JavaScript bundle or render path. Tools that try to merge both layers usually do one of them poorly.

Almost always no, and the framework should tell you so out loud. End-to-end test frameworks (Playwright, Cypress, WebdriverIO, Selenium, Assrt) verify correctness against a real DOM. They use timing internally for waits and stability detection, but their assertions are about whether the right thing rendered, not how fast. The Assrt MCP server, for example, ships a discovery prompt at src/core/agent.ts:267 and an MCP server prompt at src/mcp/server.ts:233 that explicitly forbid the LLM from generating performance test cases. That refusal is committed to the public MIT-licensed repo. It is the right call: a tool that pretends to do performance testing while measuring DOM ready timestamps in a non-isolated browser will mislead you. Use a real load testing tool for load, a real perceived-performance tool for perceived performance, and an E2E framework for correctness.

Three open-source tools, each at one layer. For protocol load: k6 (AGPL) or Locust (MIT). For network-edge benchmarking when you are debugging the connection itself: wrk or oha as a single binary. For browser-perceived performance: Lighthouse CI on every deploy, optionally extended with Sitespeed.io for a fuller waterfall view. The same dev pipeline runs all three; they produce different signal; you do not need a fourth tool unless you are testing a non-HTTP protocol (gRPC, MQTT, WebRTC), at which point Tsung or k6 with the relevant extension fills the gap.

Slightly, but not in the way the discussion usually frames it. JMeter test plans are XML files; you can run them headless with the JMeter CLI in any CI. The friction is editorial: every change to the test plan opens the GUI, and most teams end up with a JMeter expert who owns the .jmx files because nobody else wants to. k6 and Gatling avoid that bottleneck by making the test a normal source file in a normal language. Per-run wall clock is comparable. Per-week team velocity is not.

Three checks. First, look at the connection model: a load testing tool that opens one TCP connection per virtual user (k6, Gatling) is closer to real browser behavior than one that pools connections aggressively (some HTTP benchmarkers). Second, look at think time: if your test fires 10,000 RPS with no inter-request delay, you are stress testing your own load generator's network stack as much as the system under test. Third, run the same scenario from multiple geographic egresses (k6 cloud, your own CI runners in different regions) and compare: if the latency profile changes wildly, you are measuring your egress, not your application.