DEV Community

NOGUCHILin
NOGUCHILin

Posted on

I turned 38 "why is my site slow" audits into a Claude Code skill

#webperf #claude #webdev #showdev

For the last couple of weeks I've been replying to "roast my website" and "why is my site slow" posts — the ones where someone drops a URL and asks for brutal feedback. Not with opinions. I'd actually measure the page and reply with numbers.

After ~38 of these, the same handful of problems kept showing up. Not the ones people expect. The boring, invisible ones:

  • Images served 14x larger than they display. A logo shipped at 768x768, rendered at 56x56. A hero exported straight from Figma at full res. This was the single most common win, on more than half the sites.
  • The same file downloaded twice. Two different ?dpl= deploy-id query strings on the same font file — different cache entries, so the browser fetches it twice and the preload never matches. ~15% of the page, wasted, silently.
  • The favicon eating the page. One site's tab icon was 914KB — 95% of total page weight. A .ico that was really a full-size logo.
  • Unbundled ES-module waterfalls. 74 separate JS files resolving imports one after another. On the dev's own machine (near-zero latency) it felt fine; for real visitors every level of the import chain added a round trip. 8+ seconds to interactive.
  • High TTFB with no CDN. The server thinking for 1.5s before a single byte, on a page whose images were already fine.

None of these show up if you eyeball a site. You have to measure. So I'd open DevTools, run the same Performance-API checks every time, rank the findings by impact, and write them up.

Then I got tired of doing it by hand

The measurement was mechanical — the same script every time — and the write-up followed the same rubric. That's exactly the kind of thing Claude Code is good at. So I packaged the whole workflow into two skills:

  • web-speed-audit — point Claude at a URL, it runs the measurement pass and returns a ranked report where every finding is backed by a real number.
  • web-speed-fix — "now fix the top 3" and it applies the fixes in impact order (right-size images, bundle JS, add a CDN, de-dupe downloads), then re-measures so you see before/after.

The detectors are just the patterns above, encoded. Here's the shape of the oversized-image check (the full engine also handles timing, weight, duplicates, waterfalls, favicons, TTFB):

const oversized = [...document.querySelectorAll('img')]
  .map(i => ({
    src: i.currentSrc,
    linear: Math.max(i.naturalWidth / i.clientWidth, i.naturalHeight / i.clientHeight),
  }))
  .filter(x => x.linear >= 2)   // served 2x+ larger than displayed
  .sort((a, b) => b.linear - a.linear);
Enter fullscreen mode Exit fullscreen mode

Does it actually work?

The playbook is the same one I used to rebuild a slow landing page and take Lighthouse mobile from 44 to 99 (LCP 13.9s to 2.0s, TBT 1920ms to 0, ~1/15 the transfer weight). Both before/after versions are public so you can run them through PageSpeed yourself.

If you want the packaged version

I put the two skills + a pre-optimized Astro starter + the 44-to-99 case study together as SpeedKit for Claude Code ($29): https://noguchilin.gumroad.com/l/ywtkug

But honestly, if you just take the pattern list above and check your own site against it in DevTools, you'll catch most of what I catch. The value of the kit is not having to remember to.

Happy to run a quick audit on your site if you drop the URL in the comments.

Top comments (0)