agentleFS
moh-obaidamoh-obaida/ReadyVibe-Skills/skills/quality/performance-readiness/SKILL.md

performance-readiness

Skill2 starsChanged 25 days agoApache-2.0View on GitHub

Use when public pages must load acceptably before launch and you want practical evidence of high-impact waste: oversized images, huge JavaScript bundles, render-blocking scripts, unnecessary fonts and third parties, unsized media causing layout shift, and heavy above-the-fold content. It records lab signals and fixes obvious waste. Do not use it to promise a Lighthouse score or Core Web Vitals outcome, to invent field data, or as a performance laboratory.

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Not for load testing, server capacity, or database performance.

    line 19
  2. Distinctive:

    Mobile emphasis: test at 375px on a throttled connection profile if available.

    line 40

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

performance-readiness

Most launch-day slowness comes from a handful of avoidable things: a 4 MB hero PNG, five font files, a chat widget and two trackers on the first paint. Fix those. Deep tuning is a separate project.

Activate when

  • Any public page before launch, or the site feels slow on a phone.
  • production-all routes here (check 40).
  • Not for load testing, server capacity, or database performance.

Inspect

  1. Asset and markup sweep (paths relative to this skill's folder; production build, served with compression if possible):

    node scripts/audit-assets.mjs --url <site> --render
    node scripts/audit-assets.mjs --dir ./dist          # static sizes
    node scripts/observe-runtime.mjs --url <site> --viewport 375x812 --block-third-party   # request counts per snapshot, console/request failures

    Findings: ASSET_OVERSIZED_IMAGE/JS/CSS/FONT, RENDER_BLOCKING_SCRIPT, MANY_THIRD_PARTY_ORIGINS, EXTERNAL_FONT_HOST, FONT_DISPLAY_NOT_SWAP, MANY_FONT_FAMILIES, IMG_NO_DIMENSIONS, IMG_NOT_LAZY, PAGE_WEIGHT_HIGH.

  2. Look at what matters most:
    • Images: oversized dimensions vs displayed size; PNG photos that should be WebP/AVIF; no responsive srcset/sizes; hero image not prioritized (fetchpriority="high", priority in next/image) while below-the-fold images are not lazy; images without width/height (layout shift).
    • JavaScript: large bundles (check build output stats: next build size table, vite build report, source-map-explorer); whole libraries imported for one function (moment, lodash, icon packs); server-only code in the client; unnecessary client components; hydration of static content; heavy above-the-fold JS.
    • CSS/fonts: unused CSS frameworks shipped whole, too many font families/weights, no font-display: swap, external font hosts (self-hosting fonts removes a request and a third party: third-party-privacy).
    • Blocking resources: synchronous scripts and stylesheets in <head>; late-discovered critical resources; missing preconnect for unavoidable third parties.
    • Third parties: tag managers, chat widgets, replay, ads loaded eagerly; defer until interaction or consent.
    • Compression and caching: gzip/brotli on text assets; long-lived Cache-Control with hashed filenames; CDN for static assets (deployment layer: UNKNOWN locally).
    • Video/animation: autoplaying large video; heavy scroll animations; lottie/three.js on marketing pages.
  3. Optional lab measurement, if Lighthouse is available locally, on a production build with throttling, as lab data only. Do not install heavy tooling just for this; the helper signals suffice for a launch pass.
  4. Mobile emphasis: test at 375px on a throttled connection profile if available; the first screen should be usable quickly.

Evidence that counts

Label each claim OBSERVED, SOURCE-INDICATED, DECLARED, INFERRED, UNKNOWN, or REVIEW REQUIRED. UNKNOWN is never a pass and never a failure.

  • Measured sizes of served assets: OBSERVED for that build and server. Local dev servers skip compression and caching; production behavior is UNKNOWN until the deployed URL is measured.
  • Lab numbers are not field performance. Never state LCP/INP/CLS values you did not measure, and never predict them.
  • A "heavy" dependency is SOURCE-INDICATED cost until you measure its bundle contribution.

May change

Resize/compress/convert images (keep originals); add width/height, loading="lazy", srcset, priority for the hero; defer/async scripts; dynamic import heavy components; replace a heavy library with a lighter or native equivalent when trivial; self-host and subset fonts with font-display: swap; remove unused CSS/JS and unused dependencies (with the owner's confirmation); lazy-load third parties. Do not rewrite architecture, remove features, or change visible design without asking.

Must not claim

"Fast", "optimized", "will score N", "passes Core Web Vitals". Report before/after sizes and counts, and what was measured where.

Verify

Rebuild and re-run audit-assets on the same pages: oversized items resolved, blocking scripts fewer, total referenced weight lower; visually check that images still look right at desktop and 375px and nothing broke; confirm no layout shift from resized images.

Escalate

Poor performance rooted in architecture (heavy SPA hydration, chatty APIs, slow backend), large media libraries, or performance-critical products: deeper profiling beyond this pass; recommend field measurement (RUM) after launch.

No change is valid when

Assets are reasonably sized, nothing blocks render unnecessarily, and third parties are limited. Do not micro-optimize a healthy page.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.