frontend-performance skillA
frontend-performance is agent-read markdown (skill) from nahid-sparktales/agent-dispatcher: Make a page measurably faster — pick the metric that is actually bad, measure it under stated conditions, find the real cause, apply the fix that moves that specific metric, re-measure the same way. Use when a page is called slow, when LCP, CLS, INP, TTFB, a Lighthouse score or bundle size is named, when a bundle has grown, or before claiming an optimization worked. Not for backend query or API latency, not for choosing a framework, and not a substitute for checking the page still works afterwar.
Indexed from public GitHub and served as immutable, content-addressed versions. Install it pinned to an exact SHA-256 with the mdr CLI, and every file is verified against the hash recorded here before it reaches your agent. The deterministic audit below grades the latest version, and the same file always earns the same grade.
What the file says
# Frontend performance Most frontend performance work fails in one of two ways: optimizing something that was never the bottleneck, or reporting an improvement that was measurement noise. Both are avoided by deciding what to measure before touching anything. ## When this fires A page is reported slow, a Core Web Vital is out of range, a bundle grew, or a change is about to be described as a performance improvement. It does not fire for slowness that traces to a server response or a database query — that is backend work, and the giveaway is a bad TTFB with a fast render once bytes arrive. ## What actually gets measured Three Core Web Vitals, at the **75th percentile of real page loads, segmented by device class**: | Metric | Good | Poor above | What it is | | --- | --- | --- | --- | | LCP | ≤ 2.5s | 4.0s | When the largest content element finishes rendering | | CLS | ≤ 0.1 | 0.25 | Unexpected layout movement over the page's life | | INP | ≤ 200ms | 500ms | Worst-case latency from an interaction to its next paint | TTFB and FCP are diagnostics, not Core Web Vitals — useful for locating a cause, not for grading. …
Read the whole file at its exact version.
How to install
mdr add nahid-sparktales/agent-dispatcher/frontend-performance@git:20260919.a0d4f55mdr add nahid-sparktales/agent-dispatcher/frontend-performance@sha256:bcddd2654b5df107Pin to a label to follow the author's releases, or to a sha256 to freeze the exact bytes forever. Either way the resolved hash is written to mdr.lock, and mdr install reproduces it on any machine.
[](https://markdownregistry.com/a/art_li62lumf32dxdzd5)
1 badge views in 30 days
Versions
Audit of the latest version
- pass: Frontmatter block present
- pass: Frontmatter declares a name
- pass: Frontmatter declares a description
- pass: Size between 200 bytes and 200 KB (8186 bytes)
- pass: No zero-width or bidi control characters
- pass: No instruction hidden inside an HTML comment
- pass: No link to an exfiltration or paste host
- pass: No credential-shaped string
- pass: No instruction to send local credentials anywhere
- pass: No text hidden with inline styles
- pass: No prompt-injection phrasing
- pass: No curl or wget piped into a shell
- pass: No recursive delete of root, home or parent
- pass: No instruction to read or print local credentials
- pass: No base64 blob over 200 characters
- pass: No link to a raw IP address
- pass: No script tag
Source
nahid-sparktales/agent-dispatcher · 49 stars · license MIT · pushed 2026-09-23 · branch main
API
GET https://markdownregistry.com/api/v1/artifacts/art_li62lumf32dxdzd5 GET https://markdownregistry.com/api/v1/resolve?ref=nahid-sparktales/agent-dispatcher/frontend-performance GET https://markdownregistry.com/api/v1/blob/bcddd2654b5df107f4f60b3d34c49382219ed5021de58500d06bc33d66ea6724
Your agent does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.
More from nahid-sparktales/agent-dispatcher
Every file in nahid-sparktales/agent-dispatcher