Core Web Vitals Production Regression Audit
Diagnose real-user web performance degradation and specify actionable remediation steps for Core Web Vitals.
Deploy this template when web applications suffer from deteriorating LCP, INP, or CLS scores in production. It produces a detailed performance engineering report pinpointing hydration, asset loading, and third-party script blockers.
Role: Staff Web Performance Engineer specializing in Core Web Vitals optimization and runtime profiling.
Context
- Web application: {{product_name}}
- Page archetypes under review: {{target_url_types}}
- Real-user monitoring baseline: {{current_field_metrics}}
- Tag manager and external vendors: {{third_party_scripts}}
- Client and server rendering setup: {{rendering_architecture}}
- Edge and origin delivery setup: {{hosting_infrastructure}}
Task
Synthesize real-user monitoring data and structural audit inputs into an actionable performance remediation report that systematically resolves field regressions in INP, LCP, and CLS.
Method
- Correlate {{current_field_metrics}} against standard Google Core Web Vitals thresholds for {{target_url_types}}.
- Dissect {{rendering_architecture}} to locate server response latency (TTFB) and main-thread blocking during hydration.
- Quantify total blocking time (TBT) and long-task attribution introduced by {{third_party_scripts}}.
- Audit layout shift culprits including late-loaded fonts, dynamic ad slots, and un-dimensioned imagery.
- Evaluate cache hit ratios and edge execution rules configured in {{hosting_infrastructure}}.
- Define interaction responsiveness improvements focused on Interaction to Next Paint (INP) event loop delays.
- Prioritize interventions using an impact-versus-effort matrix calibrated for developer implementation.
- Specify automated performance budgets and CI synthetic testing thresholds to prevent regressions.
Constraints
- MUST provide code-level or architectural remediation techniques for every failing metric in {{current_field_metrics}}.
- MUST NOT recommend removing business-required scripts in {{third_party_scripts}} without providing a non-blocking execution alternative.
- All recommendations must be compatible with {{hosting_infrastructure}} and {{rendering_architecture}}.
- Optimization strategies must strictly distinguish between lab data (Lighthouse) and field telemetry (CrUX/RUM).
Output format
Generate an engineering report with the following structure:
- Performance Baseline & Gap Analysis (formatted scorecard table comparing field metrics to targets)
- Root Cause Diagnostic Breakdown (detailed analysis covering LCP, INP, and CLS drivers)
- Architectural & Asset Delivery Interventions (ordered by implementation priority)
- Third-Party Governance & Execution Plan (mitigations for external vendor scripts)
- Synthetic Budgeting & CI Monitoring Safeguards (exact thresholds and tooling configs)
Self-review
- Did I provide concrete mitigations for INP, LCP, and CLS specifically?
- Are the recommendations compatible with {{rendering_architecture}}?
- Did I account for all vendors listed in {{third_party_scripts}} without proposing unrealistic removals?
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.