WordPress Performance and Core Web Vitals Triage Brief

## Objective

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.

## Inputs

### Blocking inputs

Reliable diagnosis requires:

- **[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]**

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.

### Supporting inputs

- **[Images, fonts, scripts, and third-party inventory]**
- **[Recent changes and known incidents]**
- **[Business constraints, release controls, owners, and downtime tolerance]**

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.

## ChatGPT operating boundary

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.

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.

## Evidence rules

Assign stable evidence identifiers such as E1 and E2 to supplied artifacts. For every major finding, state:

- 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.

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.

## Diagnostic workflow

### 1. Normalize the measurement set

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.

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.

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.

### 2. Diagnose metric mechanisms

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.

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.

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.

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.

### 3. Trace WordPress delivery paths

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.

Check the supplied evidence for:

- 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.

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.

### 4. Review assets and third parties

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.

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.

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.

### 5. Form hypotheses and experiments

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.

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.

### 6. Prioritize without false precision

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.

Separate:

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.

### 7. Define rollout, rollback, and stop conditions

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.

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.

## Required deliverable

Return the following sections in order.

### 1. Intake and scope status

List received inputs, blocking omissions, redactions, ambiguities, conflicts, environment scope, and whether the result is a full triage or bounded preliminary review.

### 2. Evidence ledger

| Evidence ID | Artifact and Source | Evidence Class | URL or Segment Scope | Collected At | Observation | Limitations |
| --- | --- | --- | --- | --- | --- | --- |

### 3. Core Web Vitals segment scorecard

| Segment or Template | Field LCP | Field INP | Field CLS | Lab Signals | TTFB Signal | Coverage and Period | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |

Use unavailable rather than estimating missing values. Explain URL-level and origin-level differences.

### 4. Metric diagnosis and causal map

| Finding ID | Metric or Symptom | Evidence IDs | Observed Mechanism | Candidate Cause | Contradicting Evidence | Confidence | Next Discriminating Check |
| --- | --- | --- | --- | --- | --- | --- | --- |

### 5. WordPress subsystem review

| Subsystem | Current Configuration or Observation | Evidence IDs | Failure Mode | User or Business Exposure | Required Check |
| --- | --- | --- | --- | --- | --- |

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.

### 6. Asset and third-party review

| Asset or Service | Owner | Loading or Execution Evidence | Metric Mechanism | Functional or Commercial Dependency | Safe Test |
| --- | --- | --- | --- | --- | --- |

### 7. Prioritized opportunity register

| Rank | Proposed Action | Finding IDs | Evidence Strength | Likely Impact Scope | Effort | Reversibility | Regression Risk | Approval Owner | Disposition |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |

Disposition must be one of ready for measurement, ready for staging, approval required, blocked, or deferred.

### 8. Experiment and change cards

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.

### 9. Validation matrix

| Check | Environment and Segment | Tool or Evidence Source | Baseline | Expected Observation | Actual Observation | Acceptance Rule | Result State |
| --- | --- | --- | --- | --- | --- | --- | --- |

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.

### 10. Risk, approval, and rollback register

| Change or Risk | Failure Mode | Detection Signal | Stop Condition | Mitigation or Rollback | Required Approver | Approval Status |
| --- | --- | --- | --- | --- | --- | --- |

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.