Web
AuraScore 83/100

Enterprise Core Web Vitals Remediation Framework

Structure a performance audit and systematic remediation framework for complex web applications failing Core Web Vitals.

Use this template when web applications experience latency, high Interaction to Next Paint (INP), or Cumulative Layout Shift (CLS) regressions across production environments. It equips frontend architects to establish repeatable diagnostics, triage execution phases, and enforce performance budgets.

Template

Role: Principal Frontend Performance Engineer with fifteen years of experience optimizing high-throughput distributed web systems.

Context

  • Target application stack and host environment: {{app_architecture}}
  • Primary performance bottlenecks and failing metrics: {{target_metric_bottlenecks}}
  • Page rendering model and compilation setup: {{rendering_strategy}}
  • Real-user traffic and device profile: {{traffic_distribution}}
  • Vendor scripts and external assets: {{third_party_dependencies}}
  • Target Service Level Indicators and budget limits: {{slas_and_thresholds}}

Task

Produce an actionable Core Web Vitals remediation framework that isolates rendering bottlenecks, maps architectural remedies to specific metrics (LCP, INP, CLS), and institutes ongoing automated regression prevention.

Method

  1. Analyze the interaction between {{rendering_strategy}} and {{target_metric_bottlenecks}} to classify bottlenecks into server response, subresource loading, render-blocking scripts, or main-thread execution delays.
  2. Formulate diagnostic profiles for Largest Contentful Paint (LCP) focusing on resource prioritization, fetch priorities, and critical path minimization tailored to {{app_architecture}}.
  3. Establish Interaction to Next Paint (INP) isolation routines to pinpoint long tasks, frame drops, and unoptimized event listeners within {{traffic_distribution}} device classes.
  4. Design layout-shift containment rules mitigating dynamic content injection, un-dimensioned media, and font swapping.
  5. Evaluate {{third_party_dependencies}} impact, defining sandboxing, lazy-loading, and facade strategies.
  6. Synthesize technical interventions into sequential execution phases with explicit rollback gates based on {{slas_and_thresholds}}.
  7. Construct CI/CD performance gating mechanisms incorporating synthetic and Field Data (RUM) verification.

Constraints

  • Recommendations MUST be directly applicable to {{app_architecture}} without requiring total stack re-platforming.
  • Framework MUST NOT accept regressions in telemetry fidelity or accessibility standards.
  • Every proposed optimization MUST link directly to at least one metric defined in {{target_metric_bottlenecks}}.
  • Vendor scripts listed under {{third_party_dependencies}} must receive explicit containment measures.
  • Phase transitions must define measurable verification thresholds.

Output format

Provide the remediation framework across exactly four structured sections:

  1. Metric Diagnostics Matrix (table mapping metric, failure mechanism, component path, and diagnostic command)
  2. Architectural Intervention Roadmap (3 chronological phases with rationale, implementation specifics, and expected delta)
  3. Third-Party Governance Protocol (isolation tactics, execution budgets, and fallback rules)
  4. Automated CI/CD Performance Gate Spec (synthetic assertions, RUM alerting triggers, and threshold limits) Limit the total framework to under 1,500 words.

Self-review

  • Are all metrics in {{target_metric_bottlenecks}} addressed with concrete architectural solutions?
  • Does the framework respect the constraints imposed by {{rendering_strategy}}?
  • Are third-party governance tactics actionable for the scripts listed in {{third_party_dependencies}}?
AuraScore breakdown
83/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness5/5 · Strong

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-web
technology-software
web-performance
core-web-vitals
frontend