Chrome DevTools MCP: Performance-Debugging mit KI

Was ist MCP und warum bei Chrome DevTools MCP um verwaltete Ingenieurdiagnostik geht

Model Context Protocol (MCP) ist ein offener Standard, der von Anthropic im November 2024 entwickelt wurde und definiert, wie LLMs ueber eine Client-Server-Architektur mit strukturierten Tool-Calls eine Verbindung zu externen Tools und Datenquellen herstellen. Im Dezember 2025 hat Anthropic MCP an die Linux Foundation uebergeben, unter dem Dach der Agentic AI Foundation. Das Protokoll wird mittlerweile von OpenAI, Google, Microsoft, AWS und Cloudflare unterstuetzt, mit ueber 10.000 aktiven oeffentlichen MCP-Servern im Oekosystem.

Chrome DevTools MCP wendet diesen Standard gezielt auf Browser-Diagnostik an. Basierend auf Puppeteer fuer deterministische Automatisierung ueber das Chrome DevTools Protocol (CDP) erhalten KI-Agenten strukturierten Zugriff auf Laufzeitdaten des Browsers - DOM-Zustand, Netzwerkverkehr, Konsolenprotokolle und Performance-Traces. Addy Osmani, Chrome Engineering Lead, beschrieb es so: Das Tool gibt KI-Agenten "Augen", indem es die Browser-Observability bereitstellt, die Coding-Agenten bisher fehlte.

MCP-Architektur im Ueberblick

Das MCP-Client-Server-Modell funktioniert ueber explizite Tool-Calls. Ein KI-Client (Gemini, Claude, Cursor oder VS Code Copilot) sendet eine Anfrage an den MCP-Server, der eine bestimmte DevTools-Aktion ausfuehrt und ein strukturiertes Ergebnis zurueckliefert. Human-in-the-Loop-Bestaetigungen stellen sicher, dass der Agent keine unueberprueften Aktionen durchfuehrt. Diese Architektur haelt Interaktionen kompakt und nachvollziehbar - eine entscheidende Eigenschaft fuer den Einsatz in Unternehmen.

Der praktische Unterschied zur Uebermittlung roher Browserdaten an ein LLM ist erheblich, und dies ist besonders relevant fuer Teams, die in GEO und AI SEO investieren, wo die Effizienz der Agenten die Ergebnisse direkt beeinflusst. DevTools MCP speist keine vollstaendige Trace-Datei in das Kontextfenster des Modells ein. Stattdessen verarbeitet es diagnostische Daten serverseitig und liefert kompakte Zusammenfassungen, die fuer das Token-Budget des Modells optimiert sind. Ein vollstaendiger Performance-Trace kann etwa 29,8 MB umfassen, doch die an das LLM gesendete Zusammenfassung belegt nur rund 4 KB und 48 Zeilen - ein Komprimierungsverhaeltnis von etwa 7.450 zu 1.

DevTools-MCP-Tools, die Team-Probleme tatsaechlich loesen

Chrome DevTools MCP stellt 26 Tools bereit, die in sechs Kategorien organisiert sind und den gesamten Debugging-Workflow abdecken, den Entwicklungsteams taeglich nutzen - vom Oeffnen einer Seite und Durchklicken von Ablaeufen bis zur Inspektion von Netzwerkanfragen und Aufzeichnung von Performance-Traces. Fuer Teams, die auf professionelle Webentwicklung in Deutschland setzen, liefern diese Tools strukturierte Diagnosedaten, die fuer KI-Verarbeitung konzipiert sind, nicht rohes HTML oder Screenshots.

Die sechs Tool-Kategorien bilden direkt ab, wie Entwickler in DevTools arbeiten:

• Navigation (7 Tools): navigate_page, new_page, list_pages, wait_for, go_back, go_forward, close_page - URLs oeffnen, Tabs verwalten und auf bestimmte Bedingungen warten
• Eingabeautomatisierung (7 Tools): click, fill, select_option, check, hover, drag, press_key - Interaktion mit Seitenelementen wie ein Benutzer
• Debugging (4 Tools): list_console_messages, evaluate_script, take_screenshot, take_snapshot - Konsolenausgabe lesen, JavaScript ausfuehren und visuellen Zustand erfassen
• Netzwerk (2 Tools): list_network_requests, get_network_request - HTTP-Verkehr, Antwortcodes und Ressourcengroessen inspizieren
• Performance (3 Tools): performance_start_trace, performance_stop_trace, performance_analyze_insight - Traces aufzeichnen und spezifische Performance-Insights analysieren
• Emulation (3 Tools): emulate_cpu, emulate_network, resize_page - langsame CPUs, gedrosselte Netzwerke und unterschiedliche Viewports simulieren

Wie sich dies von Playwright und Selenium unterscheidet

Playwright und Selenium automatisieren Browser-Interaktionen, konzentrieren sich aber auf Testausfuehrung statt auf diagnostische Intelligenz. Ein Agent, der Playwright nutzt, kann einen Button klicken und das Ergebnis verifizieren, kann aber nicht fragen "Warum ist diese Seite langsam?" und eine strukturierte Antwort erhalten. DevTools MCP schliesst diese Luecke, indem es die Performance Insights Engine freigibt, die Chrome intern verwendet.

Die Performance-Tools verdienen besondere Aufmerksamkeit. Wenn ein Agent performance_start_trace aufruft, zeichnet DevTools MCP einen vollstaendigen Browser-Trace auf, verarbeitet ihn durch Chromes Insights-Pipeline und liefert eine kompakte Zusammenfassung mit Core-Web-Vitals-Metriken, LCP-Subparts-Aufschluesselung und identifizierten Problemen. Der Agent kann dann performance_analyze_insight mit einem spezifischen Insight-Typ wie LCPDiscovery oder RenderBlocking aufrufen, um gezielte Empfehlungen zu erhalten. Das ist diagnostische Intelligenz, nicht blosse Automatisierung.

Performance-Debugging in der Praxis: LCP, CLS, INP und Subparts

DevTools MCP ermoeglicht einen strukturierten Performance-Debugging-Workflow, der widerspiegelt, was erfahrene Performance-Ingenieure manuell tun: einen Trace unter realistischen Bedingungen aufzeichnen, Core-Web-Vitals-Metriken ablesen, in Subparts eintauchen, um den Engpass zu isolieren, und umsetzbare Empfehlungen erhalten, die an spezifische DevTools-Insights gebunden sind. Der Unterschied besteht darin, dass diese gesamte Schleife innerhalb einer einzelnen Agentensitzung laeuft und jeder Schritt maschinenlesbare Ausgaben erzeugt.

Core Web Vitals definieren drei Schwellenwerte, die als Engineering-SLOs fuer die Seitenleistung dienen:

• Largest Contentful Paint (LCP) - misst die Ladeleistung. Ein guter Wert liegt bei 2,5 Sekunden oder darunter
• Cumulative Layout Shift (CLS) - misst die visuelle Stabilitaet. Ein guter Wert liegt bei 0,1 oder darunter
• Interaction to Next Paint (INP) - misst die Reaktionsfaehigkeit. Ein guter Wert liegt bei 200 Millisekunden oder darunter

Laut web.dev verzeichnen Websites, die alle drei "Gut"-Schwellenwerte erfuellen, messbare Verbesserungen in der Suchsichtbarkeit - ein entscheidender Faktor fuer jede Google SEO-Strategie. Die Metriken sind keine abstrakten Qualitaetsindikatoren - es sind konkrete Messungen, die DevTools MCP in strukturiertem Format erfasst und meldet.

Diagnose eines langsamen LCP mit Subparts

Wenn der LCP den Schwellenwert von 2,5 Sekunden ueberschreitet, kann die Ursache in einem von vier Subparts verborgen sein. DevTools MCP schluessselt die gesamte LCP-Zeit in diese Komponenten auf, sodass der Agent genau bestimmen kann, wo Zeit verloren geht:

• TTFB (Time to First Byte) - Serverantwortzeit, bevor der Browser Daten empfaengt
• Resource Load Delay - Zeit zwischen TTFB und dem Beginn des Ladens der LCP-Ressource durch den Browser
• Load Duration - Zeit zum Herunterladen der LCP-Ressource selbst
• Render Delay - Zeit zwischen Abschluss des Ressourcenladens und der Darstellung des Elements auf dem Bildschirm

In einem praktischen Szenario, dokumentiert von DebugBear, oeffnete ein Agent eine URL mit aktiviertem Slow-4G-Throttling ueber emulate_network, zeichnete einen Performance-Trace auf und erhielt die LCP-Subparts-Aufschluesselung. Der Trace zeigte eine hohe Resource Load Delay - das LCP-Bild wurde ueber CSS als Hintergrundbild geladen, wodurch es aus dem HTML nicht auffindbar war. Der Agent fuehrte dann performance_analyze_insight mit LCPDiscovery aus, was bestaetigte: Die Ressource muss aus dem HTML auffindbar gemacht werden, fetchpriority="high" sollte hinzugefuegt und loading="lazy" entfernt werden.

Render-blockierende Ressourcen

Synchrone Skripte, die die Render-Pipeline blockieren, sind ein haeufiges LCP-Problem, das DevTools MCP ueber den RenderBlocking-Insight identifiziert. In einem Testfall mit einem Drittanbieter-Widget-Skript, das ohne defer oder async geladen wurde, schlug der Agent vor, das defer-Attribut hinzuzufuegen. Ein erneuter Trace unter denselben Slow-4G-Bedingungen ergab eine LCP-Verbesserung von etwa 55% - von einem fehlgeschlagenen Wert auf deutlich innerhalb des "Gut"-Schwellenwerts.

Diese Art der iterativen Messung - eine Aenderung anwenden, erneut tracen, den Effekt bestaetigen - entspricht genau der Arbeitsweise von Performance-Ingenieuren. DevTools MCP macht diese Schleife fuer KI-Agenten zugaenglich und haelt dabei jede Iteration messbar und vergleichbar.

Vom KI-Vorschlag zum verifizierten Fix: Hypothesen, Experimente, Regressions-Gates

Ein KI-Agent, der vorschlaegt "Fuegen Sie fetchpriority="high" zu diesem Bild hinzu", liefert noch keine Loesung, solange der Fix nicht in einer Staging-Umgebung gemessen und bestaetigt wurde, dass er andere Metriken nicht verschlechtert. In der Unternehmensentwicklung fuegt sich DevTools MCP in einen strukturierten Vorschlagen-Verifizieren-Workflow ein, in dem jede vorgeschlagene Aenderung zu einer testbaren Hypothese mit messbarem Ergebnis wird.

Der Workflow folgt einem vorhersehbaren Muster. Der Agent zeichnet einen Baseline-Trace auf, identifiziert einen Engpass ueber DevTools-Insights, schlaegt einen spezifischen Fix vor und fuehrt dann den Trace erneut aus, um den Effekt zu messen. Im DebugBear-Beispiel schlug der Agent vor, loading="lazy" von einem LCP-Bild zu entfernen und fetchpriority="high" hinzuzufuegen. Diese Empfehlungen stimmten praezise mit Chromes LCP Request Discovery-Insight ueberein, der drei Bedingungen prueft: ob die Ressource aus dem HTML auffindbar ist, ob sie eine angemessene Fetch-Prioritaet hat und ob Lazy Loading das fruehe Laden beeintraechtigt.

Jeder Vorschlag ist einem DevTools-Insight-Typ zugeordnet, was bedeutet, dass der Verifizierungsschritt direkt in das Tool eingebaut ist. Nach Anwendung des Fixes auf einem Staging-Server fuehrt der Agent einen weiteren Trace aus und prueft, ob der spezifische Insight, der das Problem markiert hat, nun bestanden wird. Dies erzeugt eine geschlossene Schleife - vorschlagen, anwenden, messen, bestaetigen - die prueffaehige Nachweise der Verbesserung liefert.

Aufbau von Regressions-Gates

Performance-Verbesserungen sind nur dann relevant, wenn sie ueber Deployments hinweg bestehen bleiben. Regressions-Gates nutzen DevTools-MCP-Traces als CI-Checks und setzen Regeln durch wie "LCP darf auf wichtigen Landingpages 2,5 Sekunden nicht ueberschreiten" oder "INP muss nach jedem Merge unter 200 Millisekunden bleiben."

Effektive Regressionsstrategien kombinieren Labor- und Felddaten:

• Synthetisches Monitoring - geplante DevTools-MCP-Traces gegen Staging mit konsistenten Throttling-Profilen (Slow 4G, CPU 4x Slowdown) fuer kontrollierte, vergleichbare Messungen
• Real User Monitoring (RUM) - Felddaten von echten Besuchern ueber CrUX oder Analytics, die bestaetigen, dass Labor-Verbesserungen sich in der Produktion niederschlagen
• Performance-Budgets - explizite Grenzen fuer LCP, CLS und INP, die Deployments blockieren, wenn sie ueberschritten werden
• Isolierte Messungen - ein Fix pro Deployment, ein gemessener Effekt, keine Batch-Aenderungen ohne Zuordnung pro Aenderung

Diese Disziplin verwandelt DevTools MCP von einem Debugging-Komfort in eine Engineering-Praxis. Teams, die diesen Workflow uebernehmen - ob sie eine Immobilien-Webplattform oder ein SaaS-Produkt verwalten - erhalten wiederholbare Diagnostik, dokumentierte Baselines und messbare Nachweise, dass jede Aenderung die Seitenleistung verbessert oder beibehalten hat.

Enterprise-Integration: Zugriffskontrolle, Sicherheit, Compliance

Chrome DevTools MCP legt dem KI-Client den vollstaendigen Browser-Inhalt offen - Cookies, localStorage, Sitzungsdaten und alles, was im DOM sichtbar ist. Das offizielle GitHub-Repository stellt dies ausdruecklich in seinem Haftungsausschluss fest, und die Einfuehrung in Unternehmen erfordert, diese Angriffsflaeche mit derselben Sorgfalt zu behandeln wie jedes andere Tool, das mit sensiblen Daten umgeht.

Die Sicherheitsueberlegungen gehen ueber die Browser-Datenexposition hinaus und betreffen sowohl Online-Marketing-Teams als auch Entwickler gleichermassen. Performance-Tools koennen optional Trace-Daten an die CrUX-API zur Korrelation mit Felddaten senden, was mit Datenhaltungs- oder Compliance-Richtlinien kollidieren kann. Das MCP-Oekosystem birgt auch inherente Risiken, die von Sicherheitsforschern dokumentiert wurden: Prompt-Injection-Angriffe, bei denen schaedliche Inhalte auf einer Seite das Verhalten des Agenten manipulieren, Tool-Poisoning, bei dem modifizierte Tool-Definitionen zu unautorisierten Aktionen fuehren, und OAuth-Token-Leaks in Authentifizierungsablaeufen.

Best Practices fuer die Sicherheit

Organisationen, die DevTools MCP einfuehren, sollten von Anfang an folgende Kontrollen implementieren:

• Sitzungsisolierung - verwenden Sie dedizierte Chrome-Profile und Testkonten fuer Diagnosesitzungen, niemals persoenliche oder Produktionsanmeldedaten mit echten Benutzerdaten
• Versionsfixierung - fixieren Sie den MCP-Server auf eine bestimmte Version ([email protected], nicht @latest), damit Updates Workflows nicht unterbrechen oder unueberprueftee Aenderungen mitten im Sprint einfuehren
• Telemetriekontrolle - deaktivieren Sie die Datenerfassung mit --no-usage-statistics und CrUX-API-Aufrufe mit --no-performance-crux, wenn es die Compliance erfordert
• Human-in-the-Loop - Chrome M144 fuehrt einen Bestaetigungsdialog fuer Remote-Debugging-Anfragen ein, der ein manuelles Genehmigungsgate hinzufuegt, bevor der Agent auf den Browserzustand zugreifen kann
• Lieferkettensicherheit - fuehren Sie SBOM-Generierung und SCA-Scanning fuer MCP-Server-Pakete durch, verifizieren Sie Paketsignaturen und behandeln Sie MCP-Komponenten als Teil der Software-Lieferkette
• Zero-Trust-Scoping - wenden Sie das Prinzip der geringsten Rechte auf den MCP-Tool-Zugriff an, fuehren Sie Audit-Logs aller Agentenaktionen und validieren Sie sowohl Eingaben als auch Ausgaben

Diese Kontrollen stehen im Einklang mit den umfassenderen MCP-Sicherheitsempfehlungen von Red Hat und den Sicherheits-Best-Practices der offiziellen MCP-Spezifikation. Das Ziel ist nicht, das Tool zu meiden, sondern es innerhalb eines kontrollierten Sicherheitsperimeters zu nutzen, der der Risikotoleranz der Organisation entspricht.

Konfiguration und Prompt-Vorlagen fuer Ihr Team

Eine fixierte MCP-Server-Konfiguration und eine standardisierte Prompt-Vorlage verwandeln Ad-hoc-KI-Debugging in einen wiederholbaren Team-Prozess. Wenn jeder Entwickler dieselbe Konfiguration und denselben Diagnose-Prompt verwendet, werden Ergebnisse ueber Sitzungen, Projekte und Teammitglieder hinweg vergleichbar.

MCP-Server-Konfiguration

Fixieren Sie die Serverversion und deaktivieren Sie standardmaessig die Telemetrie. Dies stellt konsistentes Verhalten im gesamten Team sicher und verhindert, dass stille Updates die Diagnoseausgabe mitten im Projekt aendern:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "[email protected]",
        "--no-usage-statistics",
        "--no-performance-crux"
      ]
    }
  }
}

Das Flag --no-usage-statistics deaktiviert die anonyme Nutzungsdatenerfassung. Das Flag --no-performance-crux verhindert, dass der Server Trace-URLs an die Chrome User Experience Report API sendet - wichtig fuer Organisationen mit Anforderungen an die Datenresidenz.

Schnellstart

Fuer Teams, die Gemini CLI verwenden, ist die Einrichtung mit drei Befehlen erledigt:

npm install -g @google/gemini-cli
gemini mcp add chrome-devtools npx chrome-devtools-mcp@latest
gemini

Ersetzen Sie fuer den Produktionseinsatz @latest durch eine fixierte Versionsnummer, die der getesteten und freigegebenen Version Ihres Teams entspricht. Unternehmen jeder Branche - einschliesslich Reparaturdienste fuer Haushaltsgeraete mit lokalen Landingpages - profitieren von konsistentem, versionsfixiertem Tooling.

Prompt-Vorlage fuer Performance-Debugging

Standardisierte Prompts stellen sicher, dass jede Diagnosesitzung denselben Umfang abdeckt. Diese Vorlage kann als interner Vertrag Ihres Teams fuer Performance-Analyse-Anfragen dienen:

Oeffne [URL]. Aktiviere Slow-4G-Throttling und CPU 4x Slowdown.
Nimm einen Performance-Trace auf und berichte:
1. LCP, CLS, INP mit Schwellenwerten (gut / verbesserungswuerdig / schlecht)
2. LCP-Subparts (TTFB / Load Delay / Load Duration / Render Delay)
3. Top 3 Hypothesen, verknuepft mit DevTools Insights (LCPDiscovery, RenderBlocking, DocumentLatency)
4. Minimaler Fix (1-2 Aenderungen) und wie der Effekt mit einem erneuten Trace verifiziert wird

Code-Fix-Beispiele

Zwei Muster tauchen haeufig in DevTools-MCP-Diagnosen auf. Das erste ist ein render-blockierendes Skript, das den LCP verzoegert:

<!-- Vorher: render-blockierend -->
<script src="https://cdn.example.com/vendor/widget.js"></script>

<!-- Nachher: nicht-blockierend -->
<script src="https://cdn.example.com/vendor/widget.js" defer></script>

Das zweite ist ein LCP-Bild, das ueber CSS geladen wird, wodurch es bis zum Parsen des Stylesheets nicht auffindbar ist. Das Hinzufuegen eines Preload-Hinweises mit fetchpriority="high" macht die Ressource aus dem HTML auffindbar:

<link
  rel="preload"
  href="https://cdn.example.com/hero.svg"
  as="image"
  fetchpriority="high"
/>

Googles eigene Tests zeigten, dass Fetch Priority den LCP bei Google Flights von 2,6 Sekunden auf 1,9 Sekunden verbesserte - eine 27%-ige Reduktion durch eine einzige Attributaenderung.

Bekannte Einschraenkungen und was als Naechstes zu erwarten ist

Chrome DevTools MCP befindet sich in der oeffentlichen Vorschauphase, und mehrere Einschraenkungen beeinflussen, wie Teams es heute nutzen koennen. Das Verstaendnis dieser Grenzen hilft, realistische Erwartungen zu setzen und Einfuehrungszeitplaene zu planen, die den aktuellen Reifegrad des Tools beruecksichtigen.

Die bedeutendste Einschraenkung ist das Fehlen der Local-Overrides-Unterstuetzung. In den manuellen DevTools koennen Entwickler Local Overrides verwenden, um Netzwerkantworten im laufenden Betrieb abzufangen und zu modifizieren - beispielsweise eine CSS-Datei aendern, um ein Layout-Fix zu testen, ohne Code zu deployen. DevTools MCP unterstuetzt diese Funktion noch nicht, was bedeutet, dass das Testen von Fixes auf Remote-Sites erfordert, Aenderungen in eine Staging-Umgebung zu deployen, anstatt sie direkt ueber den Browser anzuwenden.

Weitere aktuelle Einschraenkungen umfassen:

• Vorschaustatus - die API-Oberflaeche kann sich zwischen Releases aendern, weshalb Versionsfixierung fuer Produktionsworkflows wichtig ist
• Nur Labor-Metriken - Traces erfassen synthetische Messungen unter kontrollierten Bedingungen, keine Felddaten von echten Nutzern (obwohl eine CrUX-Integration fuer die Korrelation verfuegbar ist)
• Einzelseitenfokus - das aktuelle Toolset funktioniert am besten fuer die Diagnose einzelner Seiten, nicht fuer das Crawlen ganzer Websites oder Massen-Audits

Die Entwicklung ist aktiv. Chrome M144 hat --autoConnect eingefuehrt, das dem MCP-Server erlaubt, sich mit einer bereits laufenden Browsersitzung zu verbinden - was bedeutet, dass der Agent genau die Seite debuggen kann, die ein Entwickler gerade betrachtet, anstatt eine neue Browserinstanz zu oeffnen. Das breitere MCP-Oekosystem waechst weiter, wobei alle grossen KI-Plattformen (ChatGPT, Gemini, Cursor, VS Code Copilot) das Protokoll unterstuetzen. Laut Gartner-Prognosen werden 40% der Unternehmensanwendungen bis 2026 aufgabenspezifische KI-Agenten integrieren, was Browser-Diagnostik zu einer natuerlichen Erweiterung der Entwicklungswerkzeuge macht.

Fazit

Chrome DevTools MCP ist kein Ersatz fuer Chrome DevTools - es ist ein Weg, Browser-Observability in KI-gestuetzte Entwicklungsworkflows einzubetten. Das Tool gibt Coding-Agenten Zugriff auf dieselben Diagnosedaten, die Performance-Ingenieure taeglich nutzen: DOM-Zustand, Netzwerkverkehr, Konsolenausgabe, Performance-Traces und strukturierte Insights mit umsetzbaren Empfehlungen.

Der Kernwert fuer Entwicklungsteams liegt in drei Faehigkeiten:

• Wiederholbare Diagnostik - standardisierte Trace-Aufzeichnung, Insight-Analyse, Hypothesenformulierung und Fix-Verifizierung in einer geschlossenen Schleife
• Kompaktes Datenformat - ein 30-MB-Performance-Trace, komprimiert auf eine 4-KB-Zusammenfassung, macht KI-Agenten-Schleifen praktisch und kosteneffizient
• Strukturierte Insights - LCP-Subparts, LCPDiscovery, RenderBlocking und andere Insight-Typen liefern gezielte Empfehlungen anstelle generischer Ratschlaege

Die Einfuehrung in Unternehmen erfordert, DevTools MCP als Infrastruktur zu behandeln, nicht als Spielerei. Das bedeutet Profilisolierung, Versionsfixierung, Telemetriekontrolle, Human-in-the-Loop-Bestaetigungen und Regressions-Gates mit Performance-Budgets. Die Teams, die den groessten Nutzen aus diesem Tool ziehen, werden diejenigen sein, die SLOs fuer Core Web Vitals definieren, diese SLOs ueber CI-Gates durchsetzen und DevTools-MCP-Traces als Messschicht verwenden.

Beginnen Sie mit einer fixierten MCP-Server-Konfiguration, einer Prompt-Vorlagen-Vereinbarung fuer Ihr Team und einer isolierten Testumgebung. Fuehren Sie Ihre erste Diagnose auf einer Staging-URL mit Slow-4G-Throttling durch. Messen Sie die Baseline, wenden Sie den vorgeschlagenen Fix an, fuehren Sie einen erneuten Trace durch und vergleichen Sie. Diese einzelne Schleife wird zeigen, ob dieser Ansatz zu Ihrem Workflow passt - und die Daten sprechen fuer sich.