CoreDash vs Request Metrics
Request Metrics ist ein gutes RUM-Tool. Das Reporting für Long Animation Frames gehört zum Besten, was ich gesehen habe. Ich habe CoreDash gebaut. Ich halte es nach ein paar Monaten an Daten immer noch für die bessere Wahl. Für manche Teams passt Request Metrics aber besser.
Wer Request Metrics macht
Request Metrics stammt von den Leuten hinter TrackJS. Todd Gardner und Eric Brandes bauen seit langem Monitoring-Tools. Das Produkt ist aufgeräumt und leicht zu lernen. Wenn du dem Support schreibst, antworten die Entwickler, die es gebaut haben. Ihre Kunden erwähnen das oft. Nach dem, was ich vom Produkt gesehen habe, glaube ich das.
Ich habe CoreDash gebaut. Behalte das im Hinterkopf. Request Metrics macht einiges besser als CoreDash. Darauf weise ich hin. Ich halte CoreDash immer noch für die bessere Wahl, sobald du die ersten Monate hinter dir hast. Für manche Teams ist Request Metrics aber das richtige Tool.
Was Request Metrics gut macht
Hauptsächlich Long Animation Frames. Es gibt ein eigenes LoAF-Dashboard. Dort kannst du Frames durch Interaktionen von Frames durch Skript-Ausführung trennen. Du kannst das pro Seite und pro Skript herunterbrechen, bis hin zum Event-Listener oder setTimeout-Callback, der ausgeführt wurde. LoAFs werden auch in den Wasserfall der Ladezeit gezeichnet. Dort sind sie am sinnvollsten. Es gibt sogar einen „Show Code“-Button. Er ruft das Inline-Skript auf, du musst DevTools also nicht öffnen. Er holt das Skript so, wie es jetzt live ist. Direkt nach einem Deploy kann es also vom tatsächlich ausgeführten Code abweichen. Wenn du wissen willst, was LoAF ist und warum es für INP wichtig ist: Ich habe über die Long Animation Frames API auf corewebvitals.io geschrieben.

requestmetrics.com, Oktober 2026.
Es macht auch mehr als RUM. Seit Januar 2025 führt es wöchentliche Lighthouse-Scans für Desktop und Mobile auf deinen meistbesuchten Seiten aus. Es gibt ein CrUX-Dashboard, in dem du jede öffentliche Konkurrenz-Origin hinzufügen kannst. Die Scans beginnen, bevor du etwas installierst. Du hast also an Tag eins etwas zum Anschauen. Im Professional-Plan bekommst du auch JavaScript-Fehler-Monitoring, API-Monitoring, Traffic-Analytics, Funnel und Session-Timelines. Alles aus demselben Skript.
Die Attribution ist gut. Die LCP- und CLS-Elemente kommen als CSS-Selektoren. Du kannst sie direkt in DevTools einfügen. Der Agent erfasst die LCP-Subparts (Resource Load Delay, Ladezeit und Render Delay) neben der TTFB.
Datenschutz ist gut gelöst: Keine Cookies. IP-Adressen werden mit einem Salt gehasht und dann verworfen. Die Daten liegen in Kanada. Enterprise-Kunden können selbst hosten oder eine dedizierte Instanz bekommen. Die Installation per CDN-Snippet oder NPM-Modul ist einfach. Es ist sicher für Server-Side Rendering. Du kannst den Collector über deine eigene Domain routen, damit Adblocker deine Beacons nicht schlucken. Nicht viele Tools helfen dir dabei. Verlorene Beacons sind ein echtes Problem.
Die Preise sind berechenbar. Es gibt einen kostenlosen Plan. Essentials startet bei 34 $ pro Monat bei jährlicher Abrechnung mit unlimitierten Nutzern. Es gibt nie eine Nachzahlung.
Wenn du Request Metrics bereits nutzt
Dann misst du bereits deine echten Besucher. Die meisten Seiten, die ich auditiere, tun das nicht. Sie arbeiten mit Lighthouse-Scores und einem Bericht der Search Console, der nur URL-Gruppen zeigt. Jedes RUM ist besser als keines. Request Metrics ist ein gutes.
Wenn es die Fragen beantwortet, die du stellst, bleib dabei. RUM-Tools zu wechseln, kostet dich deine Historie und eine Woche Aufmerksamkeit. Es lohnt sich erst, wenn dein aktuelles Tool keine Antworten mehr liefert. Für viele Teams passiert das später. Nämlich dann, wenn die einfachen Gewinne erzielt sind und die Fragen schwieriger werden.
CoreDash vs Request Metrics auf einen Blick
Preise und Features geprüft im September 2026.
| CoreDash | Request Metrics | |
|---|---|---|
| Fokus | Core Web Vitals RUM | RUM, Lighthouse und CrUX, plus Fehler, Analytics und API-Monitoring bei Professional |
| Collector-Größe | Unter 2 KB | Etwa 13 KB gezippt (enthält Fehler- und Netzwerk-Tracking) |
| LCP-Attribution | Element, Elementtyp, Bild-URL, Preload/Lazy-Loading-Status, vier Phasen | Element-Selektor, Bild-URL, Subparts erfasst |
| INP-Attribution | Element, Input-Typ, Load State, Input Delay / Processing / Presentation, LoAF Script-URL | Element-Selektor, Event-Typ, Load State |
| Long Animation Frames | Script-URL als Dimension, nach der du INP filtern kannst | Eigenes Dashboard, Invocation vs. Evaluation, Berichte pro Seite und pro Skript |
| CrUX | CrUX-Querverweis | CrUX-Dashboard mit Konkurrenz-Origins |
| Labortests | Pre-Deploy-Check in CI, synthetisches Monitoring | Wöchentliche Lighthouse-Scans (Desktop und Mobile), On-Demand-Durchläufe |
| Datenexport | API, plus ein MCP-Server in jedem Plan für Claude, Cursor und andere Agenten | CSV-Export |
| Alerts | E-Mail und Slack, Custom- und automatische AI-Alerts | E-Mail-Benachrichtigungen |
| Datenhaltung | 6 Monate bis 8 Jahre | 24 Stunden (Free), 30 Tage (Essentials), 90 Tage (Professional) |
| Traffic-Limits | Monatliche Seitenaufrufe pro Plan, Zusatzblöcke | Gemessen pro Minute, Seitenaufrufe über dem Limit werden verworfen |
| Einstiegspreis (jährlich) | 16 $/Monat: 75.000 Seitenaufrufe, 1 Seite, 3 Nutzer | Kostenlos: 1.000 Seitenaufrufe, 24h Datenhaltung. 34 $/Monat: 75.000 Seitenaufrufe, unlimitierte Nutzer |
| Etwa 500.000 Seitenaufrufe (jährlich) | Standard, 31 $/Monat, 1 Jahr Datenhaltung | Professional, 88 $/Monat, 90 Tage Datenhaltung |
| Agenturen | Agency-API mit Master-Key, gepoolte Seitenaufrufe, kein White-Label | White-Label-Berichte bei Professional |
| Datenstandort | EU | Kanada, Self-Hosting oder dedizierte Instanz bei Enterprise |
Wo CoreDash später davonzieht
Wie lange du deine Daten behältst
Request Metrics speichert 30 Tage bei Essentials und 90 Tage bei Professional. Das reicht, um eine Regression vom Deploy letzter Woche zu finden. Es reicht nicht, um zu beantworten: „Sind wir schneller als letzten November?“. Das fragt nach Black Friday immer jemand. CoreDash speichert 6 Monate bei Starter, 1 Jahr bei Standard, 3 Jahre bei Studio und 8 Jahre bei Enterprise.
Traffic-Limits funktionieren ebenfalls anders. Request Metrics misst deine Kapazität pro Minute. Seitenaufrufe über dem Limit werden verworfen. Sie gehen offen damit um. So können sie garantieren, dass du nie eine Überraschungsrechnung bekommst. Ihre Doku empfiehlt, das 1,5- bis 2-fache deines erwarteten Traffics zu kaufen. An den meisten Tagen merkst du das nicht. An einem großen Sale-Tag wird die Spitze verworfen. Genau diese Stunde wolltest du aber sehen.

Request Metrics Doku zu Traffic-Limits, Oktober 2026.
Und der Preisunterschied wird mit dem Traffic größer. Bei etwa 500.000 Seitenaufrufen im Monat kostet Request Metrics Professional 88 $ im Monat bei jährlicher Abrechnung. Dazu 90 Tage Historie. CoreDash Standard kostet 31 $ mit einem Jahr Historie. Fairerweise gibt dir Professional auch Fehler-Monitoring, Funnel und Analytics. Das macht CoreDash nicht. Standard hat 10 Nutzer, Professional unlimitierte. Bei CoreDash zahlst du für Seitenaufrufe und Datenhaltung. Jeder Plan hat jedes Dashboard.
INP-Phasen
Request Metrics sagt dir, welches Element das INP-Ziel war. Es zeigt, ob es ein Keyboard- oder Pointer-Event war und ob die Seite noch lud. Das ist nützlich, aber dort endet es. CoreDash teilt auch jeden INP in Input Delay, Processing und Presentation auf. Es verknüpft das mit der LoAF Script-URL, dem Input-Typ und dem Load State. Die Phasen sagen dir, was du beheben musst. Ein langes Input Delay bedeutet, dass etwas anderes den Main Thread blockiert hat, als der Besucher geklickt hat. Meistens ein Tag-Manager oder Consent-Skript. Langes Processing bedeutet, dein eigener Handler ist langsam. Lange Presentation bedeutet, der anschließende Render ist zu groß. Zwei Seiten mit demselben INP können einen komplett unterschiedlichen Fix brauchen. Oft von einem anderen Team.
Ich konnte in der Request Metrics Doku keine Aufschlüsselung der INP-Phasen finden. Sie haben noch keinen INP-Guide. Wenn INP dein Hauptproblem ist, prüfe das in ihrer Testphase.
Beim LCP-Wert ist der Unterschied kleiner. Request Metrics erfasst die Subparts ebenfalls. CoreDash fügt den Elementtyp hinzu. Es zeigt, ob das LCP-Bild via Preload oder Lazy Loading geladen wurde. Das ist eines der ersten Dinge, die ich bei einem langsamen LCP-Wert prüfe. Das Diagnosis-Dashboard gibt dir dann den Fix für deinen Stack.
Dein AI-Agent kann deine Field Data lesen
Für mich ist das der größte Unterschied. Ich konnte in Request Metrics keine öffentliche API finden, um deine Performance-Daten zu lesen. Die API in ihrer Doku ist die Browser-Agent-API, um Daten hineinzusenden. Die Daten kommen als CSV-Exporte heraus. Sie waren jedoch früh bei AI dabei: Bereits 2023 haben sie einen ChatGPT-basierten Assistenten namens Professor Sloth gestartet. Der lebt in ihrem Dashboard.
CoreDash hat eine Read-only-API und einen MCP-Server auf demselben Endpunkt. Der MCP-Server ist in jedem Plan enthalten, auch bei Starter. Füge ihn zu Claude als Custom Connector hinzu. Oder zu Claude Code, Cursor, Windsurf, VS Code oder der Gemini CLI. Dein Agent kann deine Field Data dann selbst abfragen. Etwa so: Gib mir den p75-LCP-Wert auf Mobile für den Checkout, gruppiert nach LCP-Element, verglichen mit letzter Woche.
Ich habe auch CWV Superpowers gebaut. Das ist ein kostenloser Agent unter MIT-Lizenz. Er findet den schlimmsten Flaschenhals in deinen CoreDash-Daten. Er führt einen Chrome-Trace auf dieser Seite aus. Er liefert einen Code-Fix (Datei, Zeile und Diff) oder einen HTML-Bericht zurück. Er schaut sich nie einen Lighthouse-Score an. Ich habe darüber geschrieben, wie das für das Beheben von INP mit einem AI-Agenten funktioniert.
Viel von meinem eigenen Debugging beginnt damit, dass ein Agent die Field Data etwas fragt. Wenn die Daten nur als CSV herauskommen, kann der Agent sie nicht befragen. Egal, wie gut die Dashboards sind.
Agenturen
Request Metrics gibt Agenturen bei Professional White-Label-Berichte. Das ist nett, wenn du Kunden Berichte unter deinem eigenen Namen schicken willst. CoreDash ist nicht White-Label. Stattdessen gibt dir die Agency-API einen Master-Key. Der erstellt, aktualisiert und löscht Kundenprojekte und liest die Daten von allen. Seitenaufrufe werden über alle Kunden hinweg gepoolt. Es gibt eine einzige Rechnung. Du baust dein eigenes Reporting. CoreDash liefert die Daten. Siehe Agentur-Preise.
Wann du stattdessen Request Metrics wählen solltest
- Du willst RUM, JavaScript-Fehler, API-Monitoring und Funnel in einem Tool mit einem Skript. Das Error-Monitoring kommt vom TrackJS-Team. Sie machen das seit Jahren.
- Du verbringst die meiste Zeit mit Long Animation Frames und magst ein eigenes LoAF-Dashboard.
- Du brauchst White-Label-Berichte für Kunden.
- Deine Daten müssen in Kanada bleiben. Oder du brauchst eine selbst gehostete oder dedizierte Instanz.
- Deine Seite ist klein genug für den kostenlosen Plan. Oder dein Team braucht unlimitierte Nutzer im Einstiegsplan.
- Du willst Lighthouse-Scans und CrUX-Daten der Konkurrenz ab Tag eins, bevor du etwas installierst.
Probiere es auf deiner eigenen Seite aus
Der einfachste Weg zum Vergleich ist, beide für zwei Wochen laufen zu lassen. Beide Skripte laden async und kommen sich nicht in die Quere. Die CoreDash-Testphase dauert 14 Tage und erfordert keine Kreditkarte. Du kannst es mit einem Skript-Tag oder dem WordPress-Plugin installieren. Siehe Preise. Oder buche eine 20-Minuten-Demo und ich gehe mit dir durch deine eigenen Daten.
Für andere Tools, siehe alle CoreDash-Vergleiche.
Quellen: Request Metrics Preise, Preis-Doku, Traffic-Limits, LoAF-Guide, LCP-Guide, CrUX-Guide, Browser Agent API-Referenz, Endnutzerdaten, Unified Web Performance Launch, Professor Sloth Ankündigung. Agent-Größe gemessen an rm.js v2.4.1.