DEV Community: NOGUCHILin

The on-page SEO problems you can't see are in the HTML — so I made Claude Code read it

NOGUCHILin — Sat, 11 Jul 2026 02:12:40 +0000

A couple of weeks ago I built a Claude Code skill that measures why a page is slow (SpeedKit). While I was auditing all those "roast my site" pages, I kept noticing something: the SEO problems were as invisible as the speed ones — and just as mechanical to check.

Not keyword strategy. Not backlinks. The boring, technical stuff that quietly keeps a page out of search or makes it look broken in the results:

an accidental noindex in the robots meta — the page is literally telling Google to drop it, and nobody notices
a canonical pointing at a different URL than the one you want ranked
a 195-character meta description that gets truncated with an ellipsis in the SERP
a title cut off at 60 chars, or zero/multiple H1s
missing Open Graph tags, so the link renders bare and unclickable-looking when shared on Slack/X/LinkedIn
JSON-LD structured data that's present but malformed, so it does nothing

Every one of these is readable straight from the page's HTML. You don't need a crawler subscription or an API key — you need to actually look. Which is exactly the kind of mechanical, every-time checklist Claude Code is good at.

So I made it read the page

onpage-seo-audit is a SKILL.md plus a seo-measure.js that runs in the page context and reads: the title and its length, the meta description length, H1 count and heading order, the canonical (and whether it points at the current URL), the robots meta, Open Graph + Twitter cards, JSON-LD blocks and their @type, image alt coverage, lang/viewport/charset, internal-vs-external links, body word count, and it fetches /robots.txt and /sitemap.xml to check crawlability.

It returns a ranked report — indexability blockers first — where every finding is a real value read from the page, not a guess.

Here's the shape of the canonical check, which is my favorite because it catches a genuinely sneaky bug:

const canonicalHref = document.querySelector('link[rel="canonical"]')?.href;
const self = canonicalHref
  ? canonicalHref.replace(/\/$/, '').split('#')[0] === location.href.replace(/\/$/, '').split('#')[0]
  : null;
// self === false → the page says the "real" version is a *different* URL.
// Sometimes that's correct (www → non-www consolidation). Sometimes you've
// just told Google to de-index the page you're looking at. Worth a human look.

The part that mattered most: keeping it honest

The whole thing only works if the model reports what it measured and nothing else. The SKILL.md is explicit about it: report the real character count, the real flag, the real ratio — never invent a metric you didn't read. And when a "problem" is plausibly intentional (a canonical consolidating www → non-www, a deliberately short landing page), say "verify this" rather than "this is broken."

It also refuses to promise rankings. On-page SEO removes the technical reasons a page can't be indexed or looks wrong in search. That's the honest scope — no keyword-density myths, no "submit to 500 directories."

Try the pattern on your own site

Open DevTools → Console on any page and check the list at the top by hand — you'll probably find at least one. That's most of the value right there.

If you'd rather not remember to, I packaged it (audit + a fix skill that applies the corrections and re-reads the page) as SEO Audit for Claude Code ($19): https://noguchilin.gumroad.com/l/gywwrj

It's the sibling of the speed one — SpeedKit reads why a page is slow, this one reads why it can't be found. Two halves of the same "is this site technically healthy" question.

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

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

NOGUCHILin — Sat, 11 Jul 2026 00:32:59 +0000

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);

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.

3 patterns I keep finding when I actually measure "slow" landing pages

NOGUCHILin — Fri, 10 Jul 2026 02:01:26 +0000

TL;DR

I spend a chunk of most weeks replying to "roast my website" posts with real numbers instead of opinions. This week's batch turned up the same three problems, over and over, on completely unrelated sites (a SaaS API, a kids' chore app, a local service business). If you only fix one thing on your landing page this month, it's probably one of these three.

1. The one oversized image that's secretly most of your page

Pattern: a single image — usually a logo, hero photo, or video poster — accounts for 40-90% of total page weight, because it was uploaded at its original resolution instead of resized for where it's actually displayed.

Two real examples from this week:

A logo displayed at 167x72px in the header, shipped at its original 2726x1177px — about 16x more pixels than anyone would ever see. It alone was 143KB of a 195KB page (73%).
A profile photo displayed at 56x56px, shipped at 1080x1080px. 911KB of a 2.1MB page (43%) was that one photo.

The fix is boring and doesn't require touching your framework: export images at roughly 2-3x their actual display size, not their original camera/design resolution. If you're not sure what's oversized, open DevTools -> Network, sort by size, and look at whichever request is way bigger than you'd expect for what it visually is.

// quick check in the console: rendered size vs actual file size
[...document.querySelectorAll('img')].map(i => ({
  rendered: `${i.clientWidth}x${i.clientHeight}`,
  natural: `${i.naturalWidth}x${i.naturalHeight}`,
}));

If natural is more than ~2x rendered in either dimension, that image is a resize-before-upload candidate.

2. Lossless formats for photographic content

Related but distinct from #1: a correctly-sized image can still be bloated because it's saved as PNG when it's a photo or screenshot.

One site had a video poster frame — a UI screenshot, basically a photo — saved as a 1920x1080 PNG at 293KB (47% of the page's total weight). PNG is lossless, which is right for logos/icons/flat graphics with sharp edges, but wasteful for anything photographic. Re-exporting the same image as WebP or an optimized JPEG typically gets you 80-90% smaller with no visible difference, because you're finally using a format designed for what the image actually is.

Rule of thumb: flat graphics (logos, icons, illustrations with few colors) -> PNG or SVG. Photos, screenshots, anything with gradients/noise -> JPEG or WebP.

3. JS weight that doesn't match what the page does

The last pattern is less visual and more structural: a landing page that's mostly static content (headline, a few sections, a CTA) shipping 200-300KB of JavaScript across a dozen-plus chunks, because the framework's default code-splitting wasn't reconsidered for a page that doesn't need much client-side interactivity.

One example: 66% of a 379KB landing page was JS, split across 12+ separate chunks, for a page whose actual job is "explain what this API does in five seconds." None of that JS was doing anything wrong exactly — it's just what you get by default from a JS framework's build if nobody goes back and asks "does this page need to be this dynamic?"

Same audit also turned up a broken analytics call (503 then 404 on the tracking init) — worth checking your Network tab for red rows even when the page feels fine, because a broken analytics pixel fails silently and you just... don't get the funnel data you think you're getting.

Why this matters more than it sounds

None of these are exotic. They're the kind of thing that gets waved off as "we'll optimize later" — except later rarely comes, and in the meantime every visitor on a slow connection is paying for it in bounce rate before they've read a single word of your copy. The fix for all three is usually a few hours, not a rebuild.

If you want a free pass on your own site — no pitch, just the actual numbers — I still do this on Reddit/X most days (search "roast my landing page"). If it turns out the problem is bigger than a few images (routing, architecture, a full rebuild), that's the kind of thing I take on as paid work:

Astro Rebuild Pack (Contra): https://contra.com/s/kslvEs2R-astro-rebuild-pack-turn-your-slow-site-into-a-fast-one

I rebuilt a slow landing page in Astro and took Lighthouse from 44 to 99

NOGUCHILin — Mon, 29 Jun 2026 20:49:34 +0000

TL;DR

Rebuilding a heavy landing page in Astro moved the Lighthouse performance score from 44 → 99 (measured).
Most of the weight was JavaScript, images, and render-blocking resources. Astro's "zero JS by default" does the heavy lifting.
I ran the work async through Claude Code. The human only owns direction and verification.
There's a live before/after demo you can poke at (below).

This is the "make it fast" write-up. The flashy part (text exploding into particles and reassembling — glyphdust) gets one paragraph at the end.

Why Astro (what "slow" actually is)

When a landing page is slow, it's usually one of these:

Too much JavaScript — decoration libraries, analytics tags, unused bundles.
Unoptimized images — full-size PNGs, no width/height (hello CLS).
Render-blocking — CSS/JS loaded synchronously in <head>.

Astro attacks this structurally:

Island architecture: zero client JS by default; only the components you mark with client:* get hydrated.
Image optimization: astro:assets <Image /> / <Picture /> handles width/height, lazy loading, and modern formats (the demo uses <Picture>).
Build-time rendering: HTML is static; CSS is easy to scope and inline.

The point isn't "switch frameworks." It's "structurally ship less JS."

What I actually did (checklist)

I used a fictional cafe ("KURADO") landing page, built twice with the same visual design: a Before (heavy) and an After (Astro).

[ ] Replace images with astro:assets <Picture /> (width/height set, modern formats auto)
[ ] Hero image loading="eager", everything else loading="lazy"
[ ] Self-host fonts; preload variable fonts with <link rel="preload" as="font" crossorigin>
[ ] Remove decorative JS, or island-ify it (client:visible, only when needed)
[ ] Scope CSS per component; drop the unused parts
[ ] async/defer third-party scripts; lazy-load where possible

Note: for self-hosted fonts use preload, not preconnect (preconnect is for warming up connections to external origins). The After also preloads two latin-subset variable fonts.

Nothing exotic. Just killing JS, images, and blocking moves the numbers a lot.

Results (measured)

Same look, built two ways, Lighthouse on both (my own demo, fictional cafe):

Metric	Before (heavy)	After (Astro)
Performance score	44	99
LCP	13.9s	2.0s
TBT	1920ms	0ms
Transfer size	baseline	~1/15
CLS	~0	~0

Honest footnote: CLS was already ~0 in the Before (it wasn't a layout problem). Not inflating numbers matters, so I only claim the metrics that actually improved (LCP / TBT / transfer size).

LCP 13.9s → 2.0s, TBT 1920ms → 0ms. That's where the felt difference is.

Running it async with Claude Code

A human doesn't need to do all of this by hand. I hand it to Claude Code and keep direction and verification for myself.

"Replace this image set with astro:assets <Picture />, set width/height from intrinsic dimensions."
"Extract the XX decoration into a client:visible island."
"Run Lighthouse before/after and report the diff."

The key is verifying with an independent command — not "it should be faster," but actually running Lighthouse and reading the numbers. As long as the human holds that, the implementation can be safely delegated.

Signature: glyphdust

It's a speed post, but I leave one "signature" of my work on it: glyphdust, a small OSS react-three-fiber component I built.

Note: in the demo above, glyphdust is only named as a signature — the hero itself is a performance-first static implementation (piling on effects in a speed article would defeat the point). Here's what glyphdust does on its own.

With a single scroll progress 0 → 1, it shatters text into thousands of GPU particles → recomposes them into another glyph → and finally resolves to real, selectable DOM text.

import { GlyphDust } from "glyphdust";

<GlyphDust
  keyframes={[
    { type: "text", text: "KURADO", domSelector: "#headline" },
    { type: "scatter", spread: 1 },
    { type: "text", text: "FAST", dense: true, resolveToDom: true },
  ]}
/>

three / @react-three/fiber / react are peer dependencies (React 18+, three 0.160+). With prefers-reduced-motion or no WebGL, it falls back to your own static markup (the screen never goes blank).

Repo: https://github.com/linno-inc/glyphdust

The last spoonful for pages that are both fast and memorable.

Demo, and if you want a rebuild

There's a live before/after demo you can touch (my own sample, fictional cafe):

Demo (/ , /after , /before): https://astro-rebuild-demo.pages.dev/

If you've got a slow landing page or small site and want it fast without changing how it looks, I offer a fixed-scope, fully async (no calls) package on Contra:

Astro Rebuild Pack (Contra): https://contra.com/s/kslvEs2R-astro-rebuild-pack-turn-your-slow-site-into-a-fast-one

Core Web Vitals pass guaranteed (if it doesn't pass, I keep working until it does). Delivery is a Loom walkthrough + a staging link. No meetings.

Takeaways

Astro "structurally reduces JS," so a slow LP's score can move a lot (44 → 99, measured).
The work is unglamorous (kill JS, images, blocking). You can run it async with Claude Code.
Always verify numbers by measuring. Don't inflate.
A spoonful of signature (glyphdust) for the finish.