---
type: audit
tags: [audit, links-check, chrome-devtools, browser-automation]
date: 2026-05-15
status: aktiv
---

# ChromeDevTools/devtools-protocol — Audit für Aria

**Repo:** https://github.com/ChromeDevTools/devtools-protocol
**Stars:** ~1.5k · **Releases:** 539 (sehr hohe Cadence, getrieben von Chrome-Releases)
**Lizenz:** BSD (Spec) · **Bezug:** Liefert die JSON/TS-Spec für CDP, kein Runtime-Tool.

## TL;DR

Das `devtools-protocol`-Repo ist die **Spec/Type-Definition** für das Chrome DevTools Protocol — kein direkt nutzbares Tool. Aria nutzt CDP **bereits indirekt** über Playwright (gstack, Kadi-v2-Tests, agent-browser). Direkter CDP-Use lohnt sich für Aria **nicht**. **Aber:** der parallele Fund `ChromeDevTools/chrome-devtools-mcp` ist hochrelevant — offizieller MCP-Server, der CDP für Coding-Agents wie Claude Code exposed (Performance-Traces, Network-Inspection, Console-Logs, Lighthouse). Das ist ein konkreter Aria-Adoption-Kandidat.

## Was ist CDP

Chrome DevTools Protocol ist die JSON-RPC-API, über die Chrome-DevTools mit dem Browser-Kernel reden. Drittanbieter (Puppeteer, Playwright, Selenium-CDP-Mode, Lighthouse) nutzen genau diese Schnittstelle.

**Domain-Struktur** (Auswahl):
- **Network** — Request-Interception, Header-Manipulation, Throttling
- **Page** — Navigation, Screenshots, PDF-Print, Lifecycle-Events
- **Performance / Tracing** — Trace-Recording, Metriken (LCP, CLS, TBT)
- **Runtime** — JS-Evaluation im Page-Context
- **DOM** — Strukturzugriff, Event-Listener-Inspection
- **Emulation** — Device, Network, Geo, Locale
- **Target** — Multi-Tab/Worker-Steuerung
- **Security, Storage, Fetch, Debugger, Profiler**

**Versionierung:**
- `tip-of-tree` (tot) — bleeding edge, breaks anytime
- `v8-inspector` — Node.js-Debugging
- `stable v1.3` (Chrome 64) — Subset mit Backward-Compat-Garantie

Das Repo selbst liefert: `protocol.json`, TS-Definitionen (`protocol.d.ts`, `protocol-proxy-api.d.ts`, `protocol-mapping.d.ts`), npm-Paket `devtools-protocol`. Keine Runtime, kein Client.

## Direkter Use vs. Wrapper

| Ebene | Wer | Wann sinnvoll |
|---|---|---|
| **CDP raw** (WebSocket + JSON) | Lighthouse-Internals, exotische Tooling | Nie für App-Code — zu low-level |
| **`chrome-remote-interface` / `devtools-protocol` types** | Spezialisierte Debugger | Custom-Profiling, Protocol-Features die Wrapper nicht exposen |
| **Puppeteer** | Google-First-Party-Wrapper | Chrome-only, sehr nahe an CDP |
| **Playwright** | Aria-Stack | Cross-Browser, höhere Abstraktion, eigene Auto-Wait-Logik |

Playwright nutzt CDP **unter der Haube** für Chromium und exposed via `page.context().newCDPSession(page)` einen Escape-Hatch, falls man doch direkt auf CDP-Domains muss. Aria braucht das praktisch nie.

## Aria-Use-Cases

| Use-Case | CDP-direct nötig? | Aria-Status |
|---|---|---|
| Browser-Automation (Click/Fill/Navigate) | Nein — Playwright reicht | gstack, agent-browser, Kadi-v2 ok |
| Visual Regression / Screenshots | Nein — Playwright `screenshot()` | gstack ok |
| Performance-Audit (LCP/CLS/TTI) | **Ja indirekt** — via Lighthouse | nicht in Aria |
| Network-Throttling für Tests | Nein — Playwright `route()` | bei Bedarf in Kadi-v2 |
| Trace-Recording mit Insights | **Ja** — via CDP `Tracing` | nicht in Aria |
| Memory-Snapshot / Heap-Analysis | **Ja** — via CDP `HeapProfiler` | nicht in Aria |
| Console-Log-Inspection mit Source-Maps | Teils CDP-direct besser | nur rudimentär in gstack |
| LLM-Agent debugging Live-App | **Ja, via MCP** | offen |

## Implementation-Vorschlag

**Direkter CDP-Use für Aria-Brain/Skills: nein.** Begründung:
1. Aria hat keinen Use-Case, der über Playwright hinausgeht und nicht durch dessen `newCDPSession`-Escape lösbar wäre.
2. CDP-tot ist instabil — Wartungslast bei jedem Chrome-Release.
3. Doppelung zur Playwright-Abstraktion.

**Aber:** `chrome-devtools-mcp` als Aria-Plugin — **ja, prüfen**. Siehe MCP-Bezug unten.

## MCP-Bezug

Das ist der eigentliche Hebel: **`ChromeDevTools/chrome-devtools-mcp`** (https://github.com/ChromeDevTools/chrome-devtools-mcp) — offizieller Google/Chrome-MCP-Server, im Mai 2026 announced. Stack:
- Puppeteer-basiert (nicht Playwright)
- Node 20.19+ LTS
- Chrome stable oder Chrome-for-Testing
- 40+ Tools in 7 Kategorien

**Tool-Kategorien:**
- **Input** (10) — click, drag, fill, type_text
- **Navigation** (6) — navigate_page, new_page, close_page
- **Performance** (3) — `performance_start_trace`, `performance_stop_trace`, `performance_analyze_insight`
- **Network** (2) — list/get requests
- **Debugging** (8) — `take_screenshot`, `evaluate_script`, `list_console_messages`, `lighthouse_audit`
- **Memory** (4) — Heap-Snapshots
- **Extensions/WebMCP** (9)

**Install in Claude Code:**
```
claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest
```

**Was Aria damit gewinnt** (über gstack/agent-browser hinaus):
- **Performance-Insights** für Kadi-v2 (LCP/CLS-Regression-Detection vor Deploy)
- **Lighthouse-Audit** als MCP-Call, nicht als CLI-Wrapper
- **Source-mapped Console-Errors** statt nur Plain-Logs
- **Memory-Snapshots** für Leak-Hunting in Aria-Control-Panel

**Spannungsfeld zu gstack:** gstack ist Playwright + Aria-Custom-Layer (Annotations, Bug-Evidence). chrome-devtools-mcp wäre **komplementär** — gstack für QA/Dogfooding-Flows, chrome-devtools-mcp für Performance/Debug-Sessions. Kein Ersatz, sondern Ergänzung.

## Risiken

1. **Overkill-Risiko:** Wenn Aria nur Click/Screenshot braucht, ist gstack schlanker. → Triage: Aria nutzt chrome-devtools-mcp **nur** wenn Performance/Memory/Lighthouse gefragt ist.
2. **Maintenance:** Chrome-only (kein Firefox/WebKit). Bei Chrome-Major-Updates kann der MCP brechen — aber Google maintained es, nicht wir.
3. **Security:** „Exposes content of the browser instance to MCP clients" — sensible Sessions (Logins, Tokens) **nicht** im selben Browser-Profil wie Agent-Sessions. Eigenes Chrome-for-Testing-Profil verwenden.
4. **Doppelung mit gstack:** Klarer Use-Case-Cut nötig, sonst Skill-Drift à la Hermes-Curator-Lessons.
5. **Telemetrie:** Default-on, abschaltbar via `--no-usage-statistics`. Standing-Order-konform: bei Aria-Install **immer** mit `--no-usage-statistics`.
6. **Puppeteer statt Playwright:** Aria-Stack ist Playwright-zentriert — neuer Browser-Kontext-Stack im Hintergrund, mehr Disk/RAM bei parallelem Use.

## Empfehlung

**Repo `devtools-protocol` selbst:** Bookmark, kein direkter Use. Reference-Material wenn mal CDP-Domain-Doku gebraucht wird (z.B. wenn Playwright `newCDPSession` für was Exotisches genutzt wird).

**Echter Action-Item — als Linear-Issue im KAR-Team anlegen:**
- **Spike:** `chrome-devtools-mcp` als Aria-MCP-Server testen (1h)
- **Use-Case-Validation:** Lighthouse-Audit auf Kadi-v2-Preview-Deploy via MCP-Call
- **Decision-Point:** wenn Performance-Insights ohne Custom-Code abrufbar → adoption; sonst skip
- **Standing-Order-Check:** `--no-usage-statistics`-Flag setzen, eigenes Browser-Profil isoliert von User-Sessions
- **Skill-Cut zu gstack:** in beiden Skill-Descriptions klären (gstack = QA/Dogfooding, chrome-devtools-mcp = Performance/Debug)
- **Integration-Wishlist:** in `02-Wissen/integration-wishlist.md` aufnehmen

## 5-Zeilen-Summary

1. `devtools-protocol`-Repo ist nur die Spec/TS-Types — Aria braucht's nicht direkt, Playwright deckt 95% ab.
2. Direkter CDP-Use lohnt sich für Aria nicht — Wrapper-Overhead vs. Wartungslast bei Chrome-Releases.
3. **Echter Hebel:** `ChromeDevTools/chrome-devtools-mcp` (Mai 2026) — offizieller MCP-Server mit 40+ Tools für Performance, Network, Console, Lighthouse, Memory.
4. Komplementär zu gstack: gstack = Dogfood/QA, chrome-devtools-mcp = Performance/Debug-Sessions; kein Ersatz.
5. Action: Linear-Spike anlegen, mit `--no-usage-statistics` und isoliertem Browser-Profil installieren, Lighthouse-Audit auf Kadi-v2 als Validierungs-Use-Case fahren.