Ein Entwickler stellte fest, dass das Anhängen eines Chrome DevTools-Debuggers über Playwright oder Puppeteer fetch-basierte Uploads um mehr als das 20-Fache drosselt, wodurch alltägliche Performance-Benchmarks zu irreführenden Daten werden.

Das Rätsel, das die Untersuchung auslöste

Coffer, ein browserbasierter Dateispeicher, der Daten vor dem Senden an den Server verschlüsselt, führt routinemäßig Uploads im Gigabit-Bereich über ein lokales Netzwerk durch. Als das Team die Upload-Geschwindigkeiten maß, bemerkte es eine Diskrepanz: Während die Downloads die Leitung voll ausnutzten, kriechten die Uploads mit etwa einem Achtel der verfügbaren Bandbreite dahin. Diese Abweichung führte zu drei Runden Code-Änderungen, die nichts bewirkten, bis ein vierter „Fix“ scheinbar einen massiven Sprung lieferte – nur um wieder zu verschwinden, sobald der Debugger entfernt wurde.

Was das Team zuerst versuchte

Die Ingenieure suchten nach den üblichen Verdächtigen:

  • Chunk-Größe – Die Verdoppelung des Blocks von 16 MiB auf 32 MiB ließ den Durchsatz unverändert.
  • Pipelining – Das Überlappen der Verschlüsselung des nächsten Blocks mit dem aktuellen Upload brachte einen bescheidenen Gewinn von 13 %, der nicht von Messrauschen zu unterscheiden war.
  • Nebenläufigkeit (Concurrency) – Das Ausführen mehrerer Uploads parallel war bei der gleichen Gesamtgeschwindigkeit gedeckelt, was auf ein globales Limit hindeutete.

Keine dieser Variationen erklärte die 8-fache Verlangsamung.

Ein überraschender direkter Vergleich

Um das Problem zu isolieren, tauschte das Team die Client-Implementierung aus. Mit .NET HttpClient verzeichneten sie 700 Mbps im selben Netzwerk; dieselbe Anfrage über die fetch()-API von Chromium stockte bei 140 Mbps. Der krasse Kontrast deutete auf den Netzwerk-Stack des Browsers als Schuldigen hin – bis das nächste Experiment das Gegenteil bewies.

Die versteckten Kosten des Debuggers

Playwright und Puppeteer steuern Chrome über das Chrome DevTools Protocol (CDP). Dieses Protokoll hängt einen Debugger an den Browser-Prozess an und macht Netzwerkereignisse, DOM-Snapshots und Konsolenprotokolle sichtbar. Das Team führte einen gezielten Test durch: ein fetch()-Aufruf, der eine Uint8Array-Payload sendet, einmal mit angehängtem CDP-Debugger und einmal ohne.

  • Debugger angehängt: 113 Mbps

Die Anwesenheit des Debuggers reduzierte die Upload-Geschwindigkeit um mehr als das 20-Fache. Ein manueller Test in einem regulären Edge-Fenster – ohne angehängten Debugger – erreichte über 600+ Mbps, was bestätigte, dass der Browser selbst den Datenverkehr bewältigen kann, wenn er nicht behindert wird.

Eine bescheidene, echte Verbesserung

Obwohl der Debugger für den Großteil der Verlangsamung verantwortlich war, entdeckte das Team dennoch eine echte Optimierung: Der Wechsel des Request-Bodys von einem Uint8Array zu einem Blob steigerte die Geschwindigkeit von Chromium um etwa 30 %. Es ist ein nützlicher Kniff, aber weit entfernt von dem „Wunder-Boost“, auf den man ursprünglich gehofft hatte.

Warum das für Ingenieure wichtig ist

  • Messinstrumente können lügen. Performance-Tools, die Browser automatisieren, sind selbst Teil der Messkette.
  • Benchmarks, die unmöglich erscheinen, verdienen einen Sanity Check. Wenn Zahlen massiv von der Netzwerkkapazität abweichen, sollte die Messumgebung der erste Verdächtige sein.
  • Ein Nullergebnis ist wertvoll. Die Bestätigung, dass eine Änderung nichts bewirkt, verhindert verschwendete Mühe bei der Suche nach Phantom-Bugs.
  • Manuelle Kontrollen sind eine günstige Versicherung. Das Ausführen derselben Operation in einem einfachen Browserfenster kann versteckten Overhead durch die Instrumentierung aufdecken.

Gegenargument: Wenn Debugger unverzichtbar sind

Debugger bieten Einblicke in das Seitenverhalten, Fehlerspuren und Netzwerk-Zeitpläne, die anderweitig nicht zugänglich sind. Für Regressionstests, Sicherheitsaudits oder komplexe UI-Interaktionen ist das Anhängen eines CDP-Debuggers oft unverzichtbar. Der Schlüssel liegt darin, funktionale Tests von der reinen Performance-Messung zu trennen und den Debugger zu deaktivieren, wenn Letzteres das Ziel ist.

Fazit: Die Werkzeuge, die automatisiertes Testen ermöglichen, können auch zur größten Quelle für Performance-Verzerrungen werden. Bevor man dem Browser, dem Netzwerk oder dem Code die Schuld gibt, sollte man prüfen, ob ein Debugger heimlich den Datenstrom drosselt.