Performance-Analysen sind eigentlich kein Informationsproblem mehr. Die Daten gibt es, Lighthouse gibt es, Google PageSpeed Insights gibt es, Chrome DevTools sowieso. Das eigentliche Problem ist der Workflow dazwischen. Genau dort wird es in der Praxis schnell unpräzise: eine URL im Browser prüfen, Werte ablesen, Opportunities notieren, in Claude wieder erklären, zurück in DevTools springen, dann im Code nach der Ursache suchen. Für eine einzelne Seite geht das. Für wiederholbare technische Arbeit ist es unnötig langsam.

Deshalb habe ich mir ein eigenes PageSpeed Insights MCP gebaut. Der Gedanke dahinter war einfach: Wenn ich ohnehin mit Claude, Codex und Chrome DevTools arbeite, dann will ich die Audit-Daten direkt als Tools verfügbar haben, statt sie jedes Mal manuell zusammenzutragen. Aus einem losen Analyseprozess wird damit ein reproduzierbarer Workflow.

Demo: Das Video zeigt den MCP im Einsatz mit Claude, inklusive Audit-Aufruf, Interpretation der Ergebnisse und dem Übergang in die technische Analyse.

Warum ich dieses MCP überhaupt gebaut habe

Mich hat vor allem der Medienbruch genervt. Ein Score im PageSpeed-Interface ist schnell gesehen, aber damit ist das eigentliche Problem noch nicht gelöst. Die wichtigen Fragen beginnen erst danach: Welche Audits ziehen den Wert nach unten? Sind es echte Felddaten oder nur Labormetriken? Ist Mobile kritisch, während Desktop unauffällig bleibt? Und welche Maßnahmen sind tatsächlich die schnellsten Hebel?

Vor dem MCP sah der Ablauf meistens so aus:

  • URL in Google PageSpeed Insights einfügen
  • Scores und Opportunities manuell lesen
  • wichtige Punkte in den Chat oder in Notizen übertragen
  • bei Bedarf Chrome DevTools öffnen
  • dort tiefer analysieren
  • anschließend entscheiden, ob die Ursache eher im Markup, in Bildern, im JavaScript oder im Server liegt

Dieser Ablauf ist nicht nur langsam, sondern produziert auch Reibung. Je öfter man Werte manuell überträgt, desto größer wird die Chance, dass Kontext verloren geht. Genau deshalb wollte ich die Analyse an die Stelle holen, an der ich die Entscheidungen sowieso treffe: in den Agent-Workflow.

Was mein PageSpeed Insights MCP konkret kann

Das MCP hängt an der offiziellen Google-API und stellt die Analyse als Werkzeuge bereit. Im Kern habe ich vier Funktionen gebaut:

  • run_pagespeed_audit
  • compare_pagespeed_strategies
  • batch_pagespeed_audit
  • get_pagespeed_audit_details

Damit decke ich praktisch genau die Fälle ab, die im Alltag wirklich vorkommen. Ich kann einen einzelnen Audit ausführen, mehrere URLs vergleichen, Desktop und Mobile direkt nebeneinander legen oder mir gezielt nur die problematischen Audit-Details holen, statt mich durch einen ganzen Dump zu kämpfen.

Wichtig war mir außerdem, dass das Tool nicht bloß rohe JSON-Antworten durchreicht. Es fasst die Daten so zusammen, dass ein Modell oder ein Mensch sofort damit weiterarbeiten kann. Ich will nicht nur sehen, dass eine Seite bei SEO 92 und bei Best Practices 96 hat, sondern warum. Erst diese zweite Ebene macht das Ganze für einen KI-Workflow nützlich.

Standardmäßig mobile, aber nicht eingeschränkt

Ein Detail war mir dabei besonders wichtig: mobile sollte der Standard bleiben, weil das in vielen realen Projekten die kritischere Perspektive ist. Gleichzeitig wollte ich die Flexibilität nicht verlieren. Deshalb unterstützt das MCP weiterhin mobile, desktop und both.

Das klingt nach einer Kleinigkeit, ist im täglichen Arbeiten aber relevant. Wenn ich schnell prüfen will, ob eine Änderung riskant war, reicht oft der Mobile-Run. Wenn ich Unterschiede zwischen Desktop und Mobile sauber sehen will, ist both der sinnvollere Modus. Genau an dieser Stelle trennen sich gute Defaults und ein starres Tool.

Welche Daten zurückkommen und warum das wichtig ist

Ein einzelner Score ist eine nette Kennzahl, aber kein technischer Befund. Deshalb holt mein MCP nicht nur die Kategorien Performance, Accessibility, Best Practices und SEO, sondern auch die Metriken dahinter:

  • Lighthouse-Kategoriescores
  • Feldwerte aus CrUX wie LCP, INP, CLS, FCP und TTFB
  • Labordaten aus Lighthouse
  • Opportunities mit geschätztem Einsparpotenzial
  • auffällige oder fehlgeschlagene Audits

Das ist der Unterschied zwischen „Die Seite ist langsam“ und „Die Seite verliert ihren Score vor allem durch Render-Blocking, Bildgewicht, Antwortzeit oder unnötige Main-Thread-Arbeit“. Erst wenn diese Ebene klar ist, lässt sich sinnvoll priorisieren.

Warum die Kombination mit Claude und Chrome DevTools so stark ist

PageSpeed sagt mir sehr schnell, dass es ein Problem gibt. Chrome DevTools hilft mir herauszufinden, warum es existiert. Claude wiederum ist in diesem Setup die Schicht, die strukturiert weiterdenkt.

Ein typischer Ablauf sieht bei mir inzwischen so aus:

  1. Claude bekommt eine URL und ruft das PageSpeed-Tool auf.
  2. Das MCP liefert Scores, CrUX-Werte und priorisierte Opportunities zurück.
  3. Claude bewertet, welche Auffälligkeiten wirklich relevant sind.
  4. Falls nötig, geht der nächste Schritt direkt in Chrome DevTools.
  5. Dort prüfe ich den kritischen Pfad, Requests, Render-Verhalten oder das tatsächliche LCP-Element.
  6. Daraus entstehen konkrete Maßnahmen statt bloßer Diagnose.

Genau diese Verbindung aus Audit, Einordnung und Ursachenanalyse war für mich der eigentliche Grund, das MCP nicht nur als kleines Script, sondern als richtigen MCP-Server zu bauen.

Die technische Architektur dahinter

Das Plugin selbst läuft lokal als MCP-Server über stdio. Ich habe es als Codex-Plugin aufgesetzt, die Tools mit klaren Schemas versehen und die Ausgaben so strukturiert, dass sowohl Claude als auch andere MCP-fähige Clients sinnvoll damit arbeiten können.

Der Aufbau ist absichtlich pragmatisch:

  • lokaler MCP-Server auf Node-Basis
  • offizielle Google PageSpeed Insights API als Datenquelle
  • definierte Eingabevalidierung
  • lesbare Ergebniszusammenfassungen
  • ergänzende Anbindung an den Chrome-DevTools-MCP

Mir ging es nicht darum, daraus ein riesiges Monitoring-System zu machen. Das Ziel war ein Werkzeug, das im echten Tagesgeschäft sofort hilft: URL prüfen, Problem priorisieren, Ursache eingrenzen, Änderung umsetzen.

Was sich dadurch in der Praxis verbessert

Seit das PageSpeed Insights MCP steht, lassen sich viele typische Aufgaben viel direkter erledigen. Ich kann eine Landingpage vor dem Launch prüfen, nach einem Redesign gezielt Mobile gegen Desktop vergleichen oder problematische URLs im Batch schnell durchscannen. Vor allem aber spare ich mir die permanente Übersetzungsarbeit zwischen Browser, Audit und Chat.

Das klingt unspektakulär, ist aber genau der Punkt, an dem Produktivität entsteht. Gute technische Workflows scheitern selten an fehlenden Informationen. Sie scheitern daran, dass Informationen in zu vielen getrennten Werkzeugen liegen. Ein gutes MCP schließt diese Lücke.

Warum ich solche Tools lieber selbst baue

Der eigentliche Charme an MCPs ist für mich nicht nur die Integration, sondern die Kontrolle über den Workflow. Ich kann Defaults setzen, die für meine Arbeit sinnvoll sind. Ich kann die Ausgabe so strukturieren, dass sie für Agenten wirklich brauchbar ist. Und ich kann mehrere Werkzeuge so kombinieren, dass aus isolierten Datenpunkten ein zusammenhängender Prozess entsteht.

Gerade im Performance-Bereich ist das wertvoll. Ein Tool, das nur Scores ausgibt, hilft am Ende weniger als ein Tool, das Kontext und nächste Schritte vorbereitet. Genau deshalb war mir bei diesem Projekt die Verbindung aus PageSpeed Insights, Claude und Chrome DevTools wichtiger als irgendein besonders cleveres UI.

Fazit

Ich habe das PageSpeed Insights MCP gebaut, weil ich keine Lust mehr auf fragmentierte Audits hatte. Ich wollte nicht länger zwischen Browser-Tab, Lighthouse-Report, DevTools und Chat pendeln, sondern einen klaren technischen Workflow, in dem Daten, Analyse und nächste Schritte zusammenlaufen.

Für mich ist genau das der Mehrwert eines guten MCPs: nicht bloß ein API-Wrapper, sondern eine operative Schnittstelle zwischen Diagnose und Umsetzung. Gerade wenn man viel mit KI-Assistenten arbeitet, wird dieser Unterschied schnell spürbar. Die Analyse ist dann nicht mehr nur ein Bericht, sondern ein direkt nutzbarer Arbeitsbaustein.

Die im Video aufgezeigten Bugs habe ich natürlich gleich mit Codex gefixt.