core-web-vitals-hunt

Diagnose and fix one Core Web Vitals regression using Datadog RUM field data.

7|12|Updated Mar 26, 2026
One-click install
npx skills add https://github.com/OpenRouterTeam/docs --skill core-web-vitals-hunt-openrouterteam
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: core-web-vitals-hunt
Source: https://github.com/OpenRouterTeam/docs/tree/main/.agents/skills/core-web-vitals-hunt
Command: npx skills add https://github.com/OpenRouterTeam/docs --skill core-web-vitals-hunt-openrouterteam

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It finds the highest-value Core Web Vitals problem in a Next.js web app from production Datadog RUM field data, ships one narrowly scoped fix per run, and proves the fix with lab measurements and equivalence tests before a human reviews the PR. ## Core Features & Use Cases - RUM-driven candidate ranking: Aggregates p75 LCP, FCP, INP, CLS, and TTFB by route from Datadog RUM, ranks by population-weighted headroom, and prioritizes public indexable routes that affect SEO. - Mechanism-first diagnosis: Maps slow views to concrete code causes such as hydration-gated content, client fetch waterfalls, oversized chunks, unoptimized LCP images, or layout-shifting skeletons. - Evidence-backed PRs: Validates fixes with production-build lab measurements, bundle deltas, and equivalence tests, then writes a PR with RUM queries, field success criteria, and review-loop results. - Use Case: Run on a schedule to continuously hunt frontend performance regressions, for example detecting that a public route's CLS comes from a Suspense fallback above the main content and shipping a geometry-matched fallback fix. ## Quick Start Ask the agent to hunt the worst Core Web Vitals problem in the web app from production RUM data and open a PR with one fix.

Frequently Asked Questions about core-web-vitals-hunt

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find Core Web Vitals problems from Datadog RUM data?▼

Aggregate p75 of LCP, FCP, INP, CLS, and TTFB grouped by view name over the last 24 hours of production data, split by loading type. Rank candidates by population-weighted headroom over the good thresholds, then confirm the mechanism with resource and long-task events before touching code.

How to measure LCP and CLS improvements before merging a fix?▼

Build the app with NODE_ENV=production, serve it with next start, and drive the route with Playwright under CPU and network throttling matching the affected device class. Run at least 10 iterations per side against a baseline build and report medians with spread.

Why are Datadog RUM resource and long-task aggregates empty?▼

Resource and long-task aggregates grouped by view can return empty even with trackResources and trackLongTasks enabled. Try once, then place the cost using view-level facets like first_byte, first_contentful_paint, and largest_contentful_paint instead of chasing those aggregates.

Can lab Lighthouse scores replace field Core Web Vitals data?▼

No. Field data at p75 by route is the source of truth, and lab scores serve only as regression detection for an unmerged change. A lab result whose direction disagrees with the diagnosed mechanism blocks the PR rather than shipping.

When should a Core Web Vitals candidate be rejected?▼

Reject candidates whose signal comes from traffic mix shifts, cohorts below 200 views, or bot and headless browser fleets. Also reject slow metrics inherent to signed-in interaction-gated surfaces with no server-renderable content.