Agent skill

Web Performance

by millionco in millionco/debug-agent

A skill your agent uses when the user reports jank, dropped frames, janky scrolling, slow click or typing response, poor INP, slow LCP, layout shifts (CLS), unresponsive pages, or asks to debug…

MITAuto-check passedFrontend & Design

Install Web Performance

skills CLI
$ npx skills add millionco/debug-agent --skill web-performance -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install millionco/debug-agent web-performance --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/millionco/debug-agent.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/web-performance .claude/skills/web-performance && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
web-performance
GitHub stars
303
Token cost
~4.8k tokens
SKILL.md length
1,358 words
Files
1
Skills in repo
1
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when the user reports jank, dropped frames, janky scrolling, slow click or typing response, poor INP, slow LCP, layout shifts (CLS), unresponsive pages, or asks to debug…

  • Works in 2 steps: Start the logging server (background-only) → Inject the LoAF observer
  • The user reports jank
  • SKILL.md covers Overview, When to use, Core pattern and Workflow, plus 4 more sections
  • Calls curl, npx and git

What it does

Web Performance is an agent skill from millionco/debug-agent. Use when the user reports jank, dropped frames, janky scrolling, slow click or typing response, poor INP, slow LCP, layout shifts (CLS), unresponsive pages, or asks to debug rendering, animation, or interaction performance in a browser app.

Its SKILL.md is about 4.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Frontend & Design, covering Web performance and Mobile performance. The repository describes itself as: Debugging skill for AI agents. The licence is MIT.

When your agent uses it

  • The user reports jank
  • Janky scrolling
  • Typing response
  • Layout shifts (CLS)

Example prompts

  • “/web-performance”

Requirements

  • Node.js

Workflow steps

2 steps, taken from the step headings in SKILL.md.

  1. Start the logging server (background-only)
  2. Inject the LoAF observer

What it can do on your machine

Read from SKILL.md and the folder at commit 295af90. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • curl
    • npx
    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use curl, npx and git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Web Performance loads about 4.8k tokens when it runs. Until then it costs about 64 tokens; SKILL.md has 1,358 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~64
When it runs · the whole SKILL.md, loaded when a task matches
~4.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from millionco/debug-agent at commit 295af90, republished under its MIT licence (© millionco). 1,358 words, ~4,849 tokens.

Download SKILL.mdSave it as .claude/skills/web-performance/SKILL.md (or your agent's skills folder).
name
web-performance
description
Use when the user reports jank, dropped frames, janky scrolling, slow click or typing response, poor INP, slow LCP, layout shifts (CLS), unresponsive pages, or asks to debug rendering, animation, or interaction performance in a browser app.

Web Performance

Overview

Browser performance debugging via PerformanceObserver, with LoAF (long-animation-frame) as the primary signal. LoAF is the only entry type that, in one record, attributes a slow frame to a specific sourceURL + sourceFunctionName + sourceCharPosition + invokerType, with per-script forcedStyleAndLayoutDuration (sync reflow), pauseDuration (sync XHR / alert), and blockingDuration. Code inspection and performance.now() cannot reach this. Start with LoAFs, conclude from LoAFs.

When to use

Symptoms:

  • Jank, dropped frames, janky scroll/swipe, complaints about frame rate
  • Slow click / keypress / touch response, "unresponsive" complaints, poor INP
  • Slow LCP, layout shifts (CLS)
  • Animation stutter, transition jank, expensive renders during interaction

Do NOT use for:

  • Backend / non-browser perf — use raw NDJSON file appends from your server runtime
  • Memory leaks, bundle-size regressions — heap snapshots / bundle analyzers
  • Logic bugs unrelated to timing — use raw fetch instrumentation

Core pattern

Before — manual performance.now() (wrong):

js
const t0 = performance.now();
drawSeries(data);
console.log("drawSeries took", performance.now() - t0);

Tells you a number. Doesn't tell you the function caused a long frame, what scheduled it, or whether it forced sync layout. Requires you to already suspect drawSeries.

After — LoAF observer (right):

js
new PerformanceObserver((list) => {
  for (const loaf of list.getEntries()) send(loaf);
}).observe({ type: "long-animation-frame", buffered: true });

Reports every frame > 50ms across the whole page, with scripts[].sourceURL + sourceFunctionName + sourceCharPosition + invokerType + forcedStyleAndLayoutDuration for each script that ran in the frame. You don't need to know where the bug is in advance.

Workflow

  1. Generate 3-5 hypotheses about what's slow and where.
  2. Start the logging server (Implementation → STEP 0).
  3. Inject the LoAF observer as the first script in <head> or top of SPA entry.
  4. Reproduce — automate via Playwright/Puppeteer if possible; otherwise give numbered steps and ask the user to confirm in their UI (do NOT ask them to type "done").
  5. Clear the log file before each run via the deletion tool (NOT rm).
  6. Analyze LoAFs first; consult secondary signals only if LoAF is silent. Mark hypotheses CONFIRMED / REJECTED / INCONCLUSIVE with cited entries.
  7. Fix only with 100% confidence. Keep instrumentation in place; tag post-fix runs with runId="post-fix".
  8. Verify by re-running and comparing before/after LoAFs with cited lines. If failed, revert rejected-hypothesis code (keep instrumentation), generate new hypotheses, iterate.
  9. Cleanup — remove the #region debug log block only after verified success + explicit user confirmation.

Implementation

STEP 0: Start the logging server (background-only)
bash
npx debug-agent@latest --json --daemon

--daemon forks the server into a detached process and exits immediately (your shell unblocks instantly — no need for &/nohup). --json makes the parent emit one machine-readable JSON line (without it you get a colored spinner). It prints one JSON line on startup:

json
{
  "sessionId": "a1b2c3",
  "endpoint": "http://127.0.0.1:54321/ingest/a1b2c3",
  "logPath": "/tmp/debug-agent/debug-a1b2c3.log"
}

Capture endpoint (POST traces here), logPath (NDJSON written here on macOS at /var/folders/.../T/debug-agent/debug-<sessionId>.log), sessionId (in every payload). The log file is auto-created on first write — do NOT pre-create. Server is idempotent: re-running --json --daemon returns the same sessionId/port/logPath of the existing server, so it's safe to call at the start of every session. If startup fails, STOP and inform the user.

To clear the log file via HTTP without deleting/recreating it: curl -X DELETE <endpoint> returns {"ok":true,"cleared":true}.

STEP 1: Inject the LoAF observer

Replace __ENDPOINT__ and __SESSION_ID__. Paste once as the very first script in <head> (above framework bootstrap), or top of the SPA entry module (main.tsx, index.ts, app.tsx). One IIFE in one #region debug log block.

html
<script>
  // #region debug log
  (() => {
    const ENDPOINT = "__ENDPOINT__";
    const SESSION_ID = "__SESSION_ID__";
    const send = (kind, payload) =>
      fetch(ENDPOINT, {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({
          sessionId: SESSION_ID,
          location: "PerformanceObserver:" + kind,
          message: kind,
          data: payload,
          timestamp: Date.now(),
        }),
        keepalive: true,
      }).catch(() => {});
    const observe = (type, mapEntry) => {
      try {
        new PerformanceObserver((list) => {
          for (const entry of list.getEntries()) send(type, mapEntry(entry));
        }).observe({ type, buffered: true });
      } catch {}
    };
    observe("long-animation-frame", (loaf) => ({
      startTime: loaf.startTime,
      duration: loaf.duration,
      renderStart: loaf.renderStart,
      styleAndLayoutStart: loaf.styleAndLayoutStart,
      blockingDuration: loaf.blockingDuration,
      firstUIEventTimestamp: loaf.firstUIEventTimestamp,
      scripts: (loaf.scripts || []).map((scriptTiming) => ({
        invoker: scriptTiming.invoker,
        invokerType: scriptTiming.invokerType,
        sourceURL: scriptTiming.sourceURL,
        sourceFunctionName: scriptTiming.sourceFunctionName,
        sourceCharPosition: scriptTiming.sourceCharPosition,
        executionStart: scriptTiming.executionStart,
        duration: scriptTiming.duration,
        forcedStyleAndLayoutDuration: scriptTiming.forcedStyleAndLayoutDuration,
        pauseDuration: scriptTiming.pauseDuration,
      })),
    }));
  })();
  // #endregion
</script>

buffered: true and keepalive: true are required (early entries + survival across navigation). The try/catch lets the observer no-op on browsers without LoAF support.

FORBIDDEN: logging DOM text, form values, cookies, tokens, PII-bearing URLs — emit only tag names, URLs, durations, rects.

Secondary observers (add inside the same IIFE only when LoAF can't see it)
Add this observerWhen
eventINP investigation (input delay / handler / presentation breakdown)
layout-shiftCLS investigation
largest-contentful-paintSlow LCP investigation
longtaskSafari/Firefox fallback (no script attribution)
paintFirst Paint / FCP investigation
js
observe("event", (e) => ({
  name: e.name,
  startTime: e.startTime,
  duration: e.duration,
  processingStart: e.processingStart,
  processingEnd: e.processingEnd,
  interactionId: e.interactionId,
  targetTag: e.target?.tagName ?? null,
}));
observe("layout-shift", (s) => ({
  startTime: s.startTime,
  value: s.value,
  hadRecentInput: s.hadRecentInput,
  sources: (s.sources || []).map((x) => ({
    nodeName: x.node?.nodeName ?? null,
    previousRect: x.previousRect,
    currentRect: x.currentRect,
  })),
}));
observe("largest-contentful-paint", (p) => ({
  startTime: p.startTime,
  renderTime: p.renderTime,
  loadTime: p.loadTime,
  size: p.size,
  url: p.url,
  elementTag: p.element?.tagName ?? null,
}));
observe("longtask", (t) => ({
  startTime: t.startTime,
  duration: t.duration,
  attribution: (t.attribution || []).map((a) => ({
    name: a.name,
    containerType: a.containerType,
    containerSrc: a.containerSrc,
  })),
}));
observe("paint", (p) => ({ name: p.name, startTime: p.startTime }));
STEPs 2-5: Log lifecycle
  • Clear logPath before each run. Two equivalent options: file-deletion tool (NOT rm) on the path, or curl -X DELETE <endpoint>. Only your session's file — never another session's. Clearing ≠ removing instrumentation.
  • Read logPath after the user confirms reproduction. Each line is { sessionId, id, timestamp, location, message, data }. Empty/missing → reproduction failed; clear and retry.
  • Keep all instrumentation through fixes. Tag verification runs with runId="post-fix". Removing logs before verification is FORBIDDEN.
  • Cleanup after verified success + user confirmation: grep #region debug log, delete each region (line-inclusive, including the wrapping <script> if injected via HTML), re-grep to confirm zero markers, git diff review.
Show full SKILL.md (660 more words)Show less

Quick reference: decoding LoAF entries

Sort entries by duration (or blockingDuration for input-blocking jank), worst first. The script with the largest duration inside the worst LoAF's scripts[] is your culprit. If forcedStyleAndLayoutDuration > 10ms or > 25% of script duration, it's layout thrashing — look for sync offsetHeight / getBoundingClientRect / scrollTop reads interleaved with DOM writes.

FieldMeaningDiagnostic use
durationtotal frame time (ms), only fires > 50msseverity
blockingDurationinput-blocking portionINP impact
renderStart − startTimeJS work before render"long script" share
styleAndLayoutStart − renderStartrAF / ResizeObserver / IntersectionObserver callbackspre-paint callback cost
(startTime + duration) − styleAndLayoutStartstyle + layout + paintCSS / layout cost
scripts[].sourceURL + sourceFunctionName + sourceCharPositionexact code siteculprit
scripts[].invokerprecise scheduler (e.g. BUTTON#btn-foo.onclick, TimerHandler:setTimeout, IMG#hero.onload)which DOM node / timer / promise scheduled it
scripts[].invokerTypecategory — event-listener / user-callback (covers setTimeout/setInterval/requestAnimationFrame/requestIdleCallback) / resolve-promise / reject-promise / classic-script / module-scripthow it ran
scripts[].forcedStyleAndLayoutDurationsync reflow inside the scriptlayout thrashing
scripts[].pauseDurationsync XHR / alert timehard blocks

invoker vs invokerType: invokerType is a fixed-vocabulary category; invoker is the precise instance. Use invoker to tell setTimeout from requestAnimationFrame (both are user-callback), or to identify which button's click handler ran (e.g. BUTTON#btn-thrash.onclick).

Validated thrash fingerprint: when forcedStyleAndLayoutDuration / scripts[].duration > 0.5, the script is dominated by sync layout — almost always reads of offsetHeight / getBoundingClientRect / scrollTop / getComputedStyle interleaved with style/DOM writes. Example seen in practice: duration=252ms, forcedStyleAndLayoutDuration=247ms (98%) for a 1500-iteration read/write loop.

Cite the specific entry when concluding:

CONFIRMED hypothesis B: LoAF startTime=12483ms, duration=128ms, scripts[2]: sourceURL=https://app.com/static/chart.bundle.js, sourceFunctionName=drawSeries, invokerType=event-listener, duration=84ms, forcedStyleAndLayoutDuration=42ms — chart redraw triggers sync layout in scroll handler.

Secondary signal decoding (only when LoAF is silent):

  • event — input delay = processingStart − startTime; handler = processingEnd − processingStart; presentation = (startTime + duration) − processingEnd; > 200ms is poor INP. Filter out noise: a single click emits 10+ entries (pointerover, pointerenter, pointerdown, mousedown, pointerup, mouseup, click, mouseover, pointerout, mouseout, …). Most have interactionId: 0 (not real interactions) and share the same duration (they were all queued behind the same long task). Only entries with interactionId !== 0 represent distinct interactions for INP purposes — and within those, name === "click" (or keydown/pointerdown) is the canonical one.
  • layout-shift — CLS = sum of value where hadRecentInput === false; sources[] pinpoints node + rects.
  • longtask — > 50ms main-thread tasks; attribution[0].containerSrc often points at a third-party script. Coarser than LoAF; no sourceFunctionName.

Common mistakes

MistakeWhy it failsFix
Snippet pasted after framework bootstrapMisses early LoAFs and pre-bootstrap LCPFirst <script> in <head> or top of entry module before any side-effecting import
Forgetting buffered: trueDrops entries that fired before observation startedAlways { type, buffered: true }
Logging server in foregroundStalls the agent foreverUse & / nohup / block_until_ms: 0
Manual fetch logs alongside the observerPollutes traces, breaks one-region cleanupUse only the IIFE; add observers, not separate logs
Concluding from duration onlyIgnores attribution; you'll guess wrongCite scripts[].sourceURL + sourceFunctionName + forcedStyleAndLayoutDuration
Counting every event entry as a real interactionOne click emits 10+ entries (pointer*, mouse*, click); most are not "interactions"Filter interactionId !== 0; usually the click/keydown/pointerdown row is canonical
Reading invokerType and stopping theresetTimeout, setInterval, rAF, rIC all share invokerType=user-callbackUse invoker (e.g. TimerHandler:setTimeout) to disambiguate
"Fix" by wrapping in setTimeoutDefers work; jank just shifts to a later frameVerify post-fix LoAFs show the script duration is gone, not relocated
Reading bundled sourceURL literallyMinified path is meaninglessResolve via sourcemap; sourceCharPosition disambiguates collisions
Testing on Safari/Firefox firstLoAF is Chromium-only; you'll think the snippet is brokenReproduce on Chrome/Edge ≥ 123 first
Removing instrumentation before verificationCan't prove fix worked; no traces if it regressedKeep #region debug log until verified + user confirms
Deleting another session's log fileCorrupts an unrelated debug sessionOnly touch the logPath from YOUR STEP 0

Red flags — STOP and re-instrument

  • "I'll just setTimeout(..., 0) and call it fixed" → prove the script work is gone, not deferred
  • "The duration looks fine, must be CSS" → check forcedStyleAndLayoutDuration and styleAndLayoutStart first
  • "No LoAF entries appeared" → wrong browser, snippet too late, or no frame > 50ms
  • "All hypotheses rejected" → never fix without runtime evidence; generate new hypotheses
  • "I'll claim success based on the manual fix" → no, cite before/after LoAF lines

© millionco, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/web-performance of millionco/debug-agent.

Open the folder on GitHubat commit 295af90

Compare with similar skills

Web Performance next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Web Performance compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Web Performance this skillmillionco/debug-agent303—~4.8kAutomated safety check: PassMIT
Speedupskilljjcm/makefaster162—~4.8kAutomated safety check: PassNone
Optimize Loadtextura-agency/next16-claude-starter132—~4.6kAutomated safety check: NotesUnlicense
React Native Best Practicescallstackincubator/agent-skills1.7k4 repos~3.1kAutomated safety check: PassMIT
React Doctormakeplane/plane60k12 repos~657Automated safety check: PassAGPL-3.0
Fixing Motion Performanceibelick/ui-skills9.4k5 repos~1.4kAutomated safety check: PassMIT

Similar skills

  • Speedupskill

    jjcm/makefaster

    Use this when speeding up a web or Electron app's load or input.

    162 GitHub stars~4.8k tokensUpdated 21 days ago
    Frontend & DesignAuto-check passed
  • Optimize Load

    textura-agency/next16-claude-starter

    Get a page into Lighthouse's green zone on desktop and mobile, for people AND for the robot form crawlers get — build it, audit all four categories (Performance, Accessibility, Best Practices, SEO)…

    132 GitHub stars~4.6k tokensUpdated today
    Frontend & DesignAuto-check: notes
  • React Native Best Practices

    callstackincubator/agent-skills

    Official

    Provides React Native performance optimization guidelines for FPS, TTI, bundle size, memory leaks, re-renders, and animations.

    1.7k GitHub starsUsed in 4 repos~3.1k tokens
    MobileAuto-check passed
  • React Doctor

    makeplane/plane

    Scans React code for lint, accessibility, bundle size and architecture issues, reports a health score and checks that changes do not lower it.

    60k GitHub starsUsed in 12 repos~657 tokens
    Frontend & DesignAuto-check passed
  • Fixing Motion Performance

    ibelick/ui-skills

    Audits and fixes web animation performance: layout thrashing, work that belongs on the compositor, scroll-linked motion and costly blur effects.

    9.4k GitHub starsUsed in 5 repos~1.4k tokens
    Frontend & DesignAuto-check passed
  • GSAP Performance Tuning

    greensock/gsap-skills

    Guides the agent to keep GSAP animations smooth by animating transforms and opacity, batching DOM reads and writes, and avoiding layout-heavy properties.

    16k GitHub starsUsed in 4 repos~1k tokens
    Frontend & DesignAuto-check passed

Questions about Web Performance

What does Web Performance do?

A skill your agent uses when the user reports jank, dropped frames, janky scrolling, slow click or typing response, poor INP, slow LCP, layout shifts (CLS), unresponsive pages, or asks to debug…. Web Performance is an agent skill from millionco/debug-agent. Use when the user reports jank, dropped frames, janky scrolling, slow click or typing response, poor INP, slow LCP, layout shifts (CLS), unresponsive pages, or asks to debug rendering, animation, or interaction performance in a browser app.

When should I use Web Performance?

Web Performance fits situations like: the user reports jank; janky scrolling; typing response; layout shifts (CLS).

How do I install Web Performance in Claude Code?

Run `npx skills add millionco/debug-agent --skill web-performance -a claude-code`. Or copy the skill folder (.agents/skills/web-performance in millionco/debug-agent) into .claude/skills/web-performance in your project. Claude Code loads it when a task matches its description.

How do I install Web Performance in Codex?

Run `npx skills add millionco/debug-agent --skill web-performance -a codex`. Or copy the skill folder (.agents/skills/web-performance in millionco/debug-agent) into .agents/skills/web-performance in your project. Codex loads it when a task matches its description.

Can I use Web Performance in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add millionco/debug-agent --skill web-performance -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/web-performance, .gemini/skills/web-performance, .github/skills/web-performance and .opencode/skills/web-performance in your project.

What does Web Performance need to run?

Going by SKILL.md and its folder, Web Performance needs the command-line tools its instructions call (curl, npx and git). Our summary lists: Node.js.

Does Web Performance access the network?

SKILL.md contains no URLs. Its commands use curl, npx and git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Web Performance safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Web Performance use?

Web Performance is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Web Performance use?

About 4.8k tokens (SKILL.md is roughly 19k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Web Performance?

Skills that share tags, products or a category with Web Performance: Speedupskill (jjcm/makefaster, 162 stars), Optimize Load (textura-agency/next16-claude-starter, 132 stars), React Native Best Practices (callstackincubator/agent-skills, 1.7k stars) and React Doctor (makeplane/plane, 60k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Web Performance?

millionco (a GitHub organization) maintains it in millionco/debug-agent, which has 303 GitHub stars. The repository was last updated on May 25, 2026.

Source: millionco/debug-agent on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.