WordPress Performance and Core Web Vitals Triage Brief

Public field comparison

WordPress Performance and Core Web Vitals Triage Brief

WordPress Performance and Core Web Vitals Triage Brief

Review WordPress performance, Core Web Vitals, theme bloat, plugin impact, caching, images, scripts, hosting, database overhead, and optimization priorities.

Produce an evidence-led WordPress performance diagnosis and staged optimization roadmap covering Core Web Vitals, themes, plugins, assets, caching, hosting, databases, third parties, regression controls, and validation.

Use this for reviewing WordPress speed, Core Web Vitals, theme bloat, plugin impact, caching, image loading, database overhead, third-party scripts, and optimization priorities.

Use this prompt to distinguish observed WordPress performance bottlenecks from unverified hypotheses, prioritize safe Core Web Vitals improvements, and define measurable staging, rollout, and rollback controls.

Core Web Vitals triage
WordPress plugin performance review
Image and cache optimization planning
Theme bloat analysis
SEO performance prioritization
Hosting and TTFB review
Third-party script impact review

Reconciling WordPress field and lab Core Web Vitals evidence across templates and user segments
Tracing LCP, INP, CLS, and TTFB symptoms through WordPress, cache, CDN, database, and frontend layers
Designing controlled staging experiments for suspected theme, page-builder, plugin, or third-party impact
Reviewing cache correctness and performance risks for WooCommerce, membership, login, forms, and personalized pages
Building an approval-gated optimization roadmap with rollback and before-and-after validation

Site URL
Core Web Vitals data and performance tool results
Theme name and page builder details
Plugin list and business-critical plugins
Hosting plan, PHP version, server stack, and CDN setup
Caching setup, optimization plugins, and cache exclusions
Image strategy, media library issues, and lazy loading setup
Traffic patterns, key templates, and priority pages
Recent theme, plugin, hosting, or content changes
Business constraints, downtime tolerance, and review owners

Site URL and environment scope
Field and lab performance evidence
Priority URLs, templates, devices, and traffic segments
Theme, child theme, and page builder inventory
Plugin and must-use plugin inventory
Hosting, PHP, web server, database, and CDN configuration
Caching and optimization configuration
Critical user journeys and functional requirements
Images, fonts, scripts, and third-party inventory
Recent changes and known incidents
Business constraints, release controls, owners, and downtime tolerance

Fill in the variables with the site URL, Core Web Vitals data, performance tool results, theme name, page builder details, plugin list, hosting plan, PHP version, CDN setup, caching setup, image strategy, traffic patterns, priority pages, recent changes, business constraints, downtime tolerance, and review owners. Then run the complete prompt on ChatGPT. Use the output to diagnose WordPress performance issues, prioritize Core Web Vitals improvements, plan safe optimizations, and measure before/after impact.

In ChatGPT, replace every bracketed variable with the corresponding site context. Provide redacted source materials such as CrUX or Search Console exports, PageSpeed Insights or Lighthouse reports, WebPageTest waterfalls, RUM summaries, response headers, traces, WordPress inventories, Query Monitor evidence, configuration exports, incident history, and release constraints. Then run the prompt. If blocking evidence is unavailable, answer ChatGPT’s consolidated clarification request or use the resulting brief only as a bounded preliminary review.

A WordPress content site has declining organic traffic, poor mobile Core Web Vitals, slow LCP, and several recently added plugins, and the owner needs a safe optimization roadmap before changing the theme, cache setup, or plugin stack.

A WooCommerce publisher sees poor mobile LCP and INP after adding a page-builder update, consent platform, and advertising scripts. The team supplies URL-level CrUX data, Lighthouse JSON, waterfalls, plugin and cache inventories, CDN headers, critical checkout flows, and release controls. ChatGPT produces an evidence ledger, competing causal hypotheses, staging experiments, cache-safety checks, approval gates, rollback triggers, and a validation matrix without claiming that any plugin caused the regression or that a fix has been deployed.

Expert

Expert

ChatGPT

ChatGPT

performance

performance

wordpress
core-web-vitals
seo
performance
caching
images
theme-bloat
plugins
chatgpt
optimization
page-speed
technical-seo
wordpress-speed

wordpress
core-web-vitals
wordpress-performance
technical-seo
lcp
inp
cls
ttfb
performance-diagnostics
caching
cdn
wordpress-plugins
page-builders
woocommerce
performance-validation
chatgpt

WordPress Performance and Core Web Vitals Triage Brief Prompt

WordPress Performance and Core Web Vitals Triage Prompt

Use this ChatGPT prompt to review WordPress performance, Core Web Vitals, plugin impact, theme bloat, caching, images, hosting, and optimization priorities.

Create an evidence-led WordPress Core Web Vitals diagnosis with safe experiments, approval gates, rollback controls, and measurable validation.

Prompt-body line comparison

Removed Added Unchanged context

−You are an expert WordPress performance strategist specializing in Core Web Vitals, technical SEO, theme performance, plugin impact, caching, image optimization, hosting constraints, database overhead, and safe optimization planning.
+## Objective
 
−Analyze the supplied WordPress context and produce a practical performance and Core Web Vitals triage brief. The goal is to prioritize speed improvements with measurable user and SEO impact without breaking the site, disrupting business-critical features, or making unsupported performance claims.
+Analyze the supplied WordPress evidence and produce a decision-ready performance and Core Web Vitals triage brief. Identify what is observed, what is only suspected, which additional checks can discriminate between competing causes, and which optimizations are safe to test. Do not represent a recommendation as implemented, tested, approved, or verified.
 
−## Context Placeholders
+## Inputs
 
−Use the context below. If the site URL, Core Web Vitals data, theme name, plugin list, or caching setup is missing, ask for it before making risky recommendations. If other inputs are missing, continue only with clearly labeled assumptions.
+### Blocking inputs
 
−* [Site URL]
−* [Core Web Vitals data and performance tool results]
−* [Theme name and page builder details]
−* [Plugin list and business-critical plugins]
−* [Hosting plan, PHP version, server stack, and CDN setup]
−* [Caching setup, optimization plugins, and cache exclusions]
−* [Image strategy, media library issues, and lazy loading setup]
−* [Traffic patterns, key templates, and priority pages]
−* [Recent theme, plugin, hosting, or content changes]
−* [Business constraints, downtime tolerance, and review owners]
+Reliable diagnosis requires:
 
−## Important Constraints
+- **[Site URL and environment scope]**
+- **[Field and lab performance evidence]**
+- **[Priority URLs, templates, devices, and traffic segments]**
+- **[Theme, child theme, and page builder inventory]**
+- **[Plugin and must-use plugin inventory]**
+- **[Hosting, PHP, web server, database, and CDN configuration]**
+- **[Caching and optimization configuration]**
+- **[Critical user journeys and functional requirements]**
 
−* Do not invent performance metrics, Core Web Vitals scores, tool results, traffic data, plugin impact, hosting limits, revenue impact, rankings, logs, or code behavior.
−* Separate field data, lab data, supplied evidence, assumptions, hypotheses, risks, and recommendations.
−* Label uncertainty for every major conclusion.
−* Do not assume a plugin, theme, host, CDN, image, script, or database issue is the root cause without evidence.
−* Do not recommend deleting plugins, switching themes, changing hosts, disabling scripts, modifying cache rules, changing CDN settings, editing production files, or removing business-critical features without owner review.
−* Do not recommend aggressive optimization before backup and rollback readiness are checked.
−* Do not treat a one-time lab score as the full performance picture.
−* Do not optimize only for scores while ignoring user experience, functionality, analytics, ads, forms, checkout, logged-in users, accessibility, or business goals.
−* Make recommendations specific to the supplied WordPress site, Core Web Vitals data, theme, plugins, hosting, caching, images, scripts, traffic patterns, and business constraints.
−* Include human review gates for plugin removal, theme changes, cache/CDN changes, hosting changes, checkout changes, ad/script changes, production changes, and customer-facing changes.
−* Prioritize low-risk, measurable improvements first.
+The performance evidence should identify its source, collection date, URL or origin scope, mobile or desktop profile, test location, authentication state, cache state, and available raw artifacts. Useful artifacts include CrUX or Search Console exports, PageSpeed Insights reports, Lighthouse JSON, WebPageTest waterfalls and filmstrips, RUM extracts, Chrome traces, response headers, server timing, slow-query evidence, Query Monitor captures, and reproducible incident notes.
 
−## Step-by-Step Instructions
+### Supporting inputs
 
−1. Review the supplied performance evidence:
+- **[Images, fonts, scripts, and third-party inventory]**
+- **[Recent changes and known incidents]**
+- **[Business constraints, release controls, owners, and downtime tolerance]**
 
−   * Core Web Vitals data
−   * PageSpeed or Lighthouse results
−   * field data vs lab data
−   * mobile vs desktop results
−   * priority URLs
−   * key templates
−   * traffic patterns
−   * recent changes
+If a blocking input is absent, first issue one consolidated clarification request. You may still provide a bounded preliminary review when evidence supports it, but mark unavailable sections as blocked and do not infer site behavior. Preserve conflicts between sources in a conflict register rather than silently choosing one.
 
−2. Diagnose Core Web Vitals risks:
+## ChatGPT operating boundary
 
−   * LCP
−   * INP
−   * CLS
−   * TTFB
−   * render-blocking resources
−   * long tasks
−   * unused JavaScript or CSS
−   * layout shifts
−   * image loading
−   * font loading
−   * third-party scripts
+Use ChatGPT to organize and reason over materials supplied in the conversation. A URL alone does not establish access to the site, WordPress administration, hosting, analytics, logs, databases, source code, CDN, or testing tools. Do not claim to have crawled pages, run Lighthouse, queried CrUX, inspected PHP, executed WP-CLI or SQL, changed configuration, purged caches, tested a journey, or deployed a fix unless corresponding execution evidence is supplied.
 
−3. Review WordPress-specific causes:
+You may propose commands, queries, experiments, and configuration changes for an authorized operator. Clearly label them as proposed and explain purpose, scope, prerequisites, expected observation, rollback, and risk. Never request or expose passwords, API secrets, session cookies, customer records, full IP addresses, payment data, or unnecessary personal data; ask for redacted extracts.
 
−   * theme bloat
−   * page builder overhead
−   * plugin conflicts
−   * duplicate plugin functionality
−   * cache plugin configuration
−   * CDN setup
−   * database overhead
−   * autoloaded options
−   * excessive revisions or transients
−   * admin-ajax requests
−   * cron behavior
−   * logged-in vs anonymous user differences
+## Evidence rules
 
−4. Review image and media performance:
+Assign stable evidence identifiers such as E1 and E2 to supplied artifacts. For every major finding, state:
 
−   * image dimensions
−   * compression
−   * next-gen formats
−   * lazy loading
−   * hero image handling
−   * responsive images
−   * media library bloat
−   * video embeds
−   * background images
+- evidence identifiers and observation;
+- evidence class: field, lab, server, application, configuration, change history, or stakeholder report;
+- scope and collection time;
+- status: observed fact, hypothesis, assumption, unknown, conflict, or unsupported claim;
+- confidence: high, medium, or low, with a reason;
+- the next discriminating check when causality is not established.
 
−5. Review scripts, fonts, and third-party tools:
+Keep correlation separate from attribution. A recently added plugin, slow request, large asset, or failing score is not automatically the root cause. Reject fabricated metrics, rankings, conversion effects, revenue effects, logs, plugin behavior, approvals, and test outcomes.
 
−   * analytics tags
−   * ad scripts
−   * chat widgets
−   * tracking pixels
−   * social embeds
−   * font files
−   * consent tools
−   * marketing plugins
−   * unnecessary frontend assets
+## Diagnostic workflow
 
−6. Review caching and hosting:
+### 1. Normalize the measurement set
 
−   * page cache
−   * object cache
−   * browser cache
−   * CDN cache
−   * cache exclusions
−   * logged-in user behavior
−   * TTFB
−   * PHP version
−   * server resources
−   * database performance
−   * traffic spikes
+Build an evidence ledger and reconcile URL-level versus origin-level data, field versus lab data, mobile versus desktop, anonymous versus authenticated sessions, cold versus warm cache, geographic location, connection and CPU profile, template, and collection period.
 
−7. Prioritize optimization opportunities:
+Interpret field Core Web Vitals at the 75th percentile where the supplied source supports that interpretation. Treat LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less as conventional good thresholds, while recording any different threshold or eligibility rule stated by the supplied tool. Note that CrUX commonly reflects a rolling historical window and may be unavailable for low-traffic URLs. Do not expect a production change to appear immediately in field data.
 
−   * likely impact
−   * evidence strength
−   * implementation effort
−   * regression risk
−   * reversibility
−   * owner approval needed
−   * measurement method
+Treat Lighthouse and PageSpeed lab results as controlled diagnostic samples, not proof of population-level experience. Record Lighthouse version and test settings when available. Use repeated comparable lab runs to reduce run-to-run noise; do not select only the best run.
 
−8. Create a safe optimization roadmap:
+### 2. Diagnose metric mechanisms
 
−   * immediate low-risk checks
−   * staging-first actions
−   * production-safe changes
−   * owner review gates
−   * before/after measurement
−   * rollback plan
−   * follow-up monitoring
+For LCP, identify the candidate element and separate TTFB, resource-load delay, resource-load duration, and element-render delay where traces permit. Examine discovery priority, server-rendered versus script-inserted markup, preload and fetch priority, responsive image selection, CSS backgrounds, lazy loading of the hero, render-blocking CSS, fonts, client-side rendering, and consent or animation delays. Warn that broad preloading can compete for bandwidth.
 
−## Output Format
+For INP, distinguish field interaction latency from lab proxies such as Total Blocking Time. Examine interaction type, input delay, event-handler duration, presentation delay, long tasks, main-thread contention, layout work, hydration, page-builder JavaScript, third-party callbacks, and DOM complexity. Require RUM attribution or reproducible traces before assigning an interaction-specific cause.
 
−### 1. Missing Context
+For CLS, identify shifted elements, shift clusters and session windows where available, missing image or iframe dimensions, responsive ad slots, injected consent banners, web-font swaps, sticky headers, late CSS, embeds, and animations that trigger layout. Exclude user-initiated shifts only when the evidence supports exclusion.
 
−List missing inputs needed before a reliable WordPress performance review can be completed. If enough context is available, say so.
+Treat TTFB as a diagnostic signal rather than a Core Web Vital. Decompose available timing into DNS, connection and TLS, CDN or edge handling, redirect time, and origin response. Compare cache HIT, MISS, BYPASS, age, vary, and server-timing headers where supplied.
 
−### 2. Performance Evidence Summary
+### 3. Trace WordPress delivery paths
 
−Use this table:
+Map the request path across DNS, CDN or edge, web server, PHP workers, WordPress bootstrap, theme and child theme, must-use plugins, standard plugins, database, object cache, external APIs, page cache, browser cache, and frontend execution.
 
−| Evidence Area | Supplied Data | What It Suggests | Uncertainty |
−| ------------- | ------------- | ---------------- | ----------- |
+Check the supplied evidence for:
 
−Cover Core Web Vitals, tool results, mobile/desktop differences, priority pages, recent changes, and traffic patterns.
+- full-page cache eligibility, exclusions, TTLs, invalidation, cookie and query-string variation, cache fragmentation, purge behavior, stale content, and accidental caching of personalized responses;
+- authenticated pages, previews, wp-admin, cart, checkout, account, nonce-bearing forms, geolocation, consent state, and other paths that must not receive unsafe shared caching;
+- PHP version compatibility, worker saturation, memory pressure, CPU throttling, process restarts, slow upstream calls, cron overlap, loopback requests, and WP-Cron traffic coupling;
+- persistent object-cache availability, hit behavior, invalidation correctness, oversized or frequently changing objects, and cache stampedes;
+- slow or repeated queries, missing evidence for indexes, autoloaded option volume, transients, revisions, orphaned metadata, Action Scheduler backlogs, and database cleanup risk;
+- admin-ajax.php, REST API, Heartbeat API, XML-RPC where relevant, and external API calls on critical paths;
+- theme and page-builder asset loading, template-specific bundles, duplicate libraries, unused CSS or JavaScript, inline payloads, DOM size, and per-page asset controls;
+- plugin ownership of requests, hooks, assets, queries, scheduled tasks, and third-party calls.
 
−### 3. Core Web Vitals Diagnosis
+Do not attribute impact to a theme or plugin from its name or installation status. Prefer trace attribution, request ownership, controlled staging isolation, Query Monitor evidence, or a reversible experiment. Never propose disabling a security, commerce, consent, analytics, advertising, localization, membership, forms, or authentication component without documenting its business function and approval owner.
 
−Use this table:
+### 4. Review assets and third parties
 
−| Metric | Current Evidence | Likely Cause | Confidence | Next Check |
−| ------ | ---------------- | ------------ | ---------- | ---------- |
+Inspect supplied waterfalls, coverage, traces, and inventories for image intrinsic dimensions, srcset and sizes behavior, compression, format support, quality trade-offs, hero priority, below-the-fold lazy loading, decoding cost, oversized variants, animated media, poster images, and CDN transformation behavior.
 
−Cover LCP, INP, CLS, TTFB, render-blocking resources, and third-party script impact where relevant.
+Review font origin, subsets, weights, preload selection, fallback metrics, font-display behavior, cache lifetime, and privacy or licensing constraints. Review CSS and JavaScript for dependency order, defer or async safety, code splitting, delayed initialization, duplicated libraries, long tasks, and breakage risks.
 
−### 4. Theme and Plugin Impact Review
+For analytics, advertising, tag managers, consent platforms, chat, maps, video, social embeds, A/B testing, and fraud tools, distinguish transfer cost from main-thread and layout impact. Record contractual, attribution, consent, revenue, and measurement trade-offs before suggesting delay or removal.
 
−Use this table:
+### 5. Form hypotheses and experiments
 
−| Theme or Plugin Area | Evidence | Performance Risk | Recommendation | Review Needed |
−| -------------------- | -------- | ---------------- | -------------- | ------------- |
+Construct a causal map from symptom to candidate mechanism. For each hypothesis, specify supporting and contradicting evidence, affected segments, confidence, and a discriminating experiment. Prefer one controlled variable at a time where feasible. Define baseline conditions, test environment, cache state, sample method, functional checks, expected observation, actual-observation field left pending, acceptance rule, rollback trigger, and owner.
 
−Cover theme bloat, page builders, duplicate plugins, cache plugins, image plugins, security plugins, SEO plugins, forms, checkout, ads, and analytics tools where relevant.
+Do not use staging performance as a direct production forecast when infrastructure, traffic, cache warmth, CDN behavior, data volume, or third-party configuration differs. Use staging primarily for compatibility and causal isolation; use authorized canary or production measurement for production effects.
 
−### 5. Image, Media, Font, and Script Review
+### 6. Prioritize without false precision
 
−Use this table:
+Rank candidate actions using evidence strength, likely affected population, metric mechanism, business importance, implementation effort, reversibility, regression risk, operational dependency, and time to obtain trustworthy validation. Use qualitative ratings unless supplied data supports numerical estimates.
 
−| Asset Area | Evidence | Likely Impact | Safe Optimization |
−| ---------- | -------- | ------------- | ----------------- |
+Separate:
 
−### 6. Caching, CDN, Hosting, and Database Review
+1. measurement repairs and low-risk configuration checks;
+2. reversible staging experiments;
+3. production-sensitive changes requiring approval and a maintenance plan;
+4. architectural or vendor decisions requiring broader evaluation;
+5. deferred items lacking evidence or acceptable risk.
 
−Use this table:
+### 7. Define rollout, rollback, and stop conditions
 
−| Infrastructure Area | Current Pattern | Risk or Bottleneck | Suggested Check |
−| ------------------- | --------------- | ------------------ | --------------- |
+Require a current backup or configuration export appropriate to the proposed change, a named rollback operator, rollback steps, cache purge sequencing, monitoring, and a defined observation window. Stop and escalate if there is evidence of checkout, login, form, consent, analytics, advertising, accessibility, security, personalization, data-integrity, or cache-isolation regression; unexplained error-rate growth; conflicting ownership; unavailable rollback; or a production change outside the stated authority.
 
−Cover cache layers, CDN, TTFB, PHP version, server resources, database overhead, object cache, and cache exclusions.
+Database cleanup, schema or index changes, host migrations, PHP upgrades, theme replacement, plugin removal, CDN rule changes, cache variation changes, script suppression, and production deployment require explicit human authorization. Recommendations are not approvals.
 
−### 7. Optimization Priority Matrix
+## Required deliverable
 
−Use this table:
+Return the following sections in order.
 
−| Priority | Action | Expected Impact | Effort | Regression Risk | Owner Review |
−| -------- | ------ | --------------- | ------ | --------------- | ------------ |
+### 1. Intake and scope status
 
−Separate low-risk fixes, staging-first actions, production-sensitive changes, and deferred improvements.
+List received inputs, blocking omissions, redactions, ambiguities, conflicts, environment scope, and whether the result is a full triage or bounded preliminary review.
 
−### 8. Measurement Plan
+### 2. Evidence ledger
 
−Use this table:
+| Evidence ID | Artifact and Source | Evidence Class | URL or Segment Scope | Collected At | Observation | Limitations |
+| --- | --- | --- | --- | --- | --- | --- |
 
−| Measurement | Tool or Source | Before Baseline | After Check | Success Criteria |
−| ----------- | -------------- | --------------- | ----------- | ---------------- |
+### 3. Core Web Vitals segment scorecard
 
−Include field data, lab data, priority URLs, mobile checks, conversion-critical flows, and monitoring cadence.
+| Segment or Template | Field LCP | Field INP | Field CLS | Lab Signals | TTFB Signal | Coverage and Period | Status |
+| --- | --- | --- | --- | --- | --- | --- | --- |
 
−### 9. Risk Register
+Use unavailable rather than estimating missing values. Explain URL-level and origin-level differences.
 
−Use this table:
+### 4. Metric diagnosis and causal map
 
−| Risk | Impact | Likelihood | Mitigation | Owner |
−| ---- | ------ | ---------- | ---------- | ----- |
+| Finding ID | Metric or Symptom | Evidence IDs | Observed Mechanism | Candidate Cause | Contradicting Evidence | Confidence | Next Discriminating Check |
+| --- | --- | --- | --- | --- | --- | --- | --- |
 
−### 10. Recommended Action Plan
+### 5. WordPress subsystem review
 
−Provide a practical sequence:
+| Subsystem | Current Configuration or Observation | Evidence IDs | Failure Mode | User or Business Exposure | Required Check |
+| --- | --- | --- | --- | --- | --- |
 
−1. document current performance baseline
−2. confirm backup and rollback readiness
−3. test high-risk changes on staging
−4. apply low-risk optimizations first
−5. review plugin and theme impact
−6. optimize images and scripts
−7. validate caching and CDN behavior
−8. rerun performance checks
−9. monitor field data over time
−10. review business-critical flows before final rollout
+Cover relevant theme, child theme, page builder, plugins, must-use plugins, PHP, workers, database, object cache, page cache, CDN, cron, external APIs, and authenticated or personalized paths.
 
−### 11. Human Review Gates
+### 6. Asset and third-party review
 
−Use this table:
+| Asset or Service | Owner | Loading or Execution Evidence | Metric Mechanism | Functional or Commercial Dependency | Safe Test |
+| --- | --- | --- | --- | --- | --- |
 
−| Decision | Owner Role | Review Needed | Reason |
−| -------- | ---------- | ------------- | ------ |
+### 7. Prioritized opportunity register
 
−Include plugin removal, theme changes, cache/CDN changes, checkout changes, analytics/ad script changes, hosting changes, database cleanup, and production rollout.
+| Rank | Proposed Action | Finding IDs | Evidence Strength | Likely Impact Scope | Effort | Reversibility | Regression Risk | Approval Owner | Disposition |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
 
−### 12. Follow-Up Questions
+Disposition must be one of ready for measurement, ready for staging, approval required, blocked, or deferred.
 
−List exact questions for the site owner, developer, SEO lead, hosting provider, marketing team, or analytics owner.
+### 8. Experiment and change cards
 
−### 13. Final Performance Notes
+For every high-priority action, provide scope, prerequisites, operator, exact proposed change or test, controlled variable, baseline method, expected observation, actual observation marked pending, functional checks, acceptance rule, rollback trigger, rollback procedure, monitoring window, and evidence to retain.
 
−Give concise guidance on what to fix first, what to measure, what to avoid changing without review, and what should be monitored after implementation.
+### 9. Validation matrix
 
−## Verification Checklist
+| Check | Environment and Segment | Tool or Evidence Source | Baseline | Expected Observation | Actual Observation | Acceptance Rule | Result State |
+| --- | --- | --- | --- | --- | --- | --- | --- |
 
−Before finalizing, confirm that:
+Result State must remain not run, unavailable, blocked, passed, failed, or inconclusive according to actual evidence. Include repeated comparable lab tests, eventual field-data review, cache HIT and MISS behavior, response correctness, console and server errors, and critical journeys such as login, search, forms, checkout, account, consent, analytics, and ads where applicable.
 
−* recommendations cite supplied Core Web Vitals data, performance tool results, logs, site context, or labeled assumptions
−* field data and lab data are separated
−* mobile and desktop differences are considered
−* plugin or theme impact is not claimed without evidence
−* no plugin removal is recommended without business owner review
−* cache, CDN, hosting, database, and production changes include rollback planning
−* before/after measurement steps are included
−* business-critical flows such as forms, checkout, login, ads, analytics, and consent tools are protected
−* optimization recommendations are prioritized by impact, effort, reversibility, and regression risk
−* every major finding is tied to supplied context or labeled as an assumption
−* no performance metrics, rankings, revenue impact, logs, approvals, or code behavior were invented
+### 10. Risk, approval, and rollback register
 
−## Final Instruction to Begin
+| Change or Risk | Failure Mode | Detection Signal | Stop Condition | Mitigation or Rollback | Required Approver | Approval Status |
+| --- | --- | --- | --- | --- | --- | --- |
 
−Begin now. First review the supplied site URL, Core Web Vitals data, performance tool results, theme name, page builder details, plugin list, hosting plan, PHP version, CDN setup, caching setup, image strategy, traffic patterns, priority pages, recent changes, business constraints, downtime tolerance, and review owners. If critical context is missing, ask for it. Otherwise, produce the full WordPress Performance and Core Web Vitals Triage Brief in the requested markdown format.
+Never infer approval. Use pending or unknown unless supplied evidence records it.
+
+### 11. Phased roadmap
+
+Present immediate evidence collection, low-risk checks, staging experiments, authorized canary or production changes, short-term monitoring, and field-data follow-up. State dependencies and handoff owner for every phase.
+
+### 12. Conflicts, unknowns, and follow-up questions
+
+Record unresolved evidence conflicts and ask concise, role-specific questions for the site owner, WordPress developer, SEO lead, analytics owner, marketing or ad owner, security or privacy owner, and hosting or CDN provider.
+
+### 13. Decision summary
+
+State what the evidence currently supports, the first three actions or checks, changes that must not proceed without approval, expected decision points, and which outcomes remain unverified.
+
+## Final integrity check
+
+Before returning the brief, confirm that every major conclusion cites evidence or is labeled as a hypothesis; field and lab evidence remain separate; plugin and theme attribution is justified; metric segments and collection periods are visible; proposed actions include functional safeguards and rollback; expected and actual observations are distinct; conflicts remain explicit; and no implementation, test, approval, or performance improvement is claimed without corresponding evidence.