Performance Cwv Stinger

Performance Cwv Stinger

Forge status: stages 1-6 of the seven-stage forge pipeline complete (Topic, Research, Distillation, References, Guides, final Skill/Bee authorship). Stage 7 (Register, pair registration in beekeeper-suit and deploy) has not run yet. Everything below this line is grounded in this pair's PRD, the build plan, and the two raw sources archived in references/research/raw/; every claim traces to one of those, is explicitly labelled as general/uncited HTTP-CDN knowledge, or is an explicit cross-link to lighthouse-pagespeed-stinger.

You are equipping performance-cwv-worker-bee, part of the Website Auditor by Legion Code Inc. plugin. Full scope and acceptance criteria: prd-016-performance-cwv.

Purpose

Score a site's CDN/edge-delivery presence, caching-header strategy, and Core Web Vitals across three leaves of the "Technical deployment" scoring category (11% of the final grade): CDN presence (3%), caching-header strategy (4%), Core Web Vitals (4%). This Stinger's own research archive covers only what's specific to assessing an external, unauthenticated target with no source access and no CI integration; it explicitly cross-links lighthouse-pagespeed-stinger for general Lighthouse/PageSpeed methodology and CWV threshold provenance rather than re-deriving it.

The distinction to state plainly, every time it's relevant: lighthouse-pagespeed-worker-bee (a different plugin, vibe-coding-tools) runs Lighthouse CI on a repository the customer owns, with source access, deploy rights, and a CI gate. This Stinger assesses CDN/caching strategy and Core Web Vitals for an external site the customer does not necessarily control the infrastructure of, from the outside, once per audit engagement, with no source access and nothing to gate. Same subject matter, genuinely different posture. See guides/05-external-audit-vs-lighthouse-ci.md.

When to use this skill

• Wave W5 of every audit run, after site-crawler-worker-bee has finished and site-data/ exists.
• Any standalone request specifically about a site's CDN, caching-header strategy, or Core Web Vitals scores from an external, unauthenticated audit posture.
• Deciding whether a performance question belongs here or with lighthouse-pagespeed-stinger, see guides/05-external-audit-vs-lighthouse-ci.md's concrete scenario table.

When not to use this skill

• Before site-data/ exists.
• For a CI-gated Lighthouse pass on a repository the customer owns. That is lighthouse-pagespeed-worker-bee's territory; route there instead.
• To assert that a specific caching-header configuration is objectively correct or incorrect for a specific page type. That adequacy judgment is a documented research gap in this Stinger's own archive, see guides/02-cdn-and-caching-headers.md.
• To implement a performance fix in a customer's codebase. This Bee has no source access; it diagnoses and reports, it does not remediate.

Procedure

1. Load site-data/ and build the sampled page set.
2. Capture CDN and caching headers with references/scripts/cdn-header-scan.py (fresh, read-only requests, since site-data/'s crawl capture does not preserve response headers).
3. Collect Core Web Vitals: lab data via the shared cwv-collect.py script, field data via PageSpeed Insights/CrUX where coverage exists.
4. Score the three leaves on the plugin-wide zero-to-six scale, every score with a numeric value, an evidence pointer, and a one-line justification.
5. Cross-link lighthouse-pagespeed-stinger rather than re-deriving its methodology, per guides/05-external-audit-vs-lighthouse-ci.md.
6. Log rejected/reframed candidates to the run's verification log.
7. Write 09-performance/performance-findings.md from references/templates/performance-findings-template.md, per guides/06-report-format.md.

Full step-by-step detail lives in guides/01-audit-procedure.md, read it first on every invocation.

References map

Load on demand; do not read everything up front.

Quality bar

A pass through this Stinger is done when: guides/01-audit-procedure.md ran in order, every factual claim used traces to references/research/raw/ or is explicitly labelled general/uncited HTTP-CDN knowledge or [subjective], every score has all three mandatory fields, any Lighthouse/PSI-adjacent question is cross-linked to lighthouse-pagespeed-stinger rather than re-derived, rejected/reframed candidates are logged, and 09-performance/performance-findings.md was written per guides/06-report-format.md.

Related bees and stingers

• performance-cwv-worker-bee - this Stinger's paired Bee.
• lighthouse-pagespeed-stinger (a different plugin, vibe-coding-tools, not this repo, no resolvable relative path from here) - internal-repo CWV/Lighthouse specialist, run on a repository the customer owns via CI. Consult for general Lighthouse/PageSpeed methodology and CWV threshold provenance; this pair covers only the external-audit-specific delta. Do not duplicate its guides here.
• site-crawler-stinger - upstream, produces site-data/, this Stinger's one declared read.
• web-security-posture-stinger - sibling in wave W5; consult when a caching or CDN header finding overlaps a security-header finding (e.g. the same response headers, different scoring lens).
• audit-scoring-stinger - consumes this Stinger's three leaf scores into the "Technical deployment" category rollup (11% of the final grade).

Critical Directive

• You must read all files and context contained within your skill.
• In the event your core knowledge does not provide sufficient guidance you must make every attempt to search the internet, related knowledge base documentation files, and other available resources to supplement your knowledge prior to proceeding with your task.
• Additional related skills can be found here:
  • performance-cwv-worker-bee - this Stinger's paired Bee.
  • lighthouse-pagespeed-stinger (a different plugin, vibe-coding-tools, not this repo, no resolvable relative path from here) - internal-repo CWV/Lighthouse specialist; consult for threshold research and general methodology, this pair covers only the external-audit-specific delta.

Ship Gate decision

Does not apply to a per-run audit. This Stinger's output is a set of findings written into the customer's audit workspace (09-performance/performance-findings.md), not a code change to this plugin's own repository, so the security-stinger, quality-stinger, github-repo-health-stinger Ship Gate defined for repo-improvement Bees is not triggered by running an audit. The Ship Gate does apply, per the build plan's Question 22, before any change to this plugin's own source (this file, the paired Bee, shared scripts) is committed and pushed, that is a plugin-development-time gate, not an audit-run-time gate. Do not conflate the two.