DEV Community: NOGUCHILin

Your is downloading the file twice

NOGUCHILin — Fri, 31 Jul 2026 11:57:56 +0000

Here's a bug that hides in plain sight: a preload hint that makes your site slower, in a way that looks perfectly correct in the HTML.

I found it last week while auditing a WordPress site before a host migration. The homepage was shipping 2.88 MB across 141 requests, and I was going through the waterfall looking for the usual suspects. Then I noticed the same filename twice.

The two lines

<link rel="preload" href="/wp-content/themes/x/library/js/plugins.min.js" as="script">
...
<script src="/wp-content/themes/x/library/js/plugins.min.js?ver=2.11.5"></script>

Look at them for a second. Same path. Same file. The only difference is ?ver=2.11.5.

That difference is enough.

Why the browser doesn't care that it's "the same file"

The preload cache is keyed by the full request URL, query string included. It is not keyed by path, and it is certainly not keyed by content.

So the browser does exactly what you told it to:

Sees the preload, fetches plugins.min.js at high priority.
Parses on, hits the <script> tag, and looks for plugins.min.js?ver=2.11.5 in the preload cache.
Doesn't find it — different URL — and fetches the whole thing again.

The preloaded copy is never used. It sits there and expires.

I verified the two responses were genuinely identical rather than assuming it:

$ curl -s ".../plugins.min.js?ver=2.11.5" -o a.js
$ curl -s ".../plugins.min.js"            -o b.js
$ shasum -a 256 a.js b.js
94b4a2673e7c30d5b3dac15a9b55613ee106df3e91b0c65d052f94033ea7de74  a.js
94b4a2673e7c30d5b3dac15a9b55613ee106df3e91b0c65d052f94033ea7de74  b.js

Byte-for-byte the same file. Downloaded twice.

This is worse than a wasted request

If it were merely wasteful, I wouldn't have bothered writing about it. The problem is when the waste happens.

rel=preload exists to say "this is important, get it now." The browser honours that: it fetches at high priority, immediately, during the exact window when the page is trying to paint. So the wasted copy isn't downloading during idle time at the end. It's competing for bandwidth with your LCP resource, at the front of the queue, by explicit request.

On the site I was looking at, both of the page's script preloads had this mismatch:

File	Transferred (gzip)	Downloaded
`plugins.min.js`	248 KB	twice
`init.min.js`	28 KB	twice

~276 KB of high-priority bandwidth, spent on bytes that were thrown away. On a mobile connection during the critical rendering window.

And the LCP element on that page? A CSS background image — which the preload scanner can't see at all, so it gets discovered late and queued behind all this. The one thing that actually needed the bandwidth was the one thing not getting it.

Why WordPress produces this so reliably

wp_enqueue_script() appends a cache-busting ?ver= to script URLs. That's standard, sensible behaviour.

The preload hints, though, usually come from somewhere else — a theme's performance option, or an optimization plugin generating resource hints. That code often builds the URL from the file path and forgets that the enqueue system is going to add a version string to the tag it's pairing with.

Both halves are individually reasonable. Together they silently double-fetch.

This is not a WordPress-only failure, to be clear. Any setup where preload hints and asset URLs are generated by different layers can drift: asset pipelines with content hashes, CDN rewrites, cache-busting middleware. WordPress just makes it especially easy.

Finding it in your own site

Don't rely on spotting it by eye — the two URLs are long and differ by a few characters near the end. Paste this in the console instead:

const preloads = [...document.querySelectorAll('link[rel=preload][as=script]')].map(l => l.href);
const scripts  = [...document.querySelectorAll('script[src]')].map(s => s.src);

preloads.forEach(p => {
  if (scripts.includes(p)) return;                       // exact match, fine
  const same = scripts.find(s => s.split('?')[0] === p.split('?')[0]);
  console.warn(same ? `MISMATCH\n  preload: ${p}\n  script : ${same}` : `UNUSED preload: ${p}`);
});

MISMATCH means you're double-downloading. UNUSED means you're preloading something the page never requests at all — also worth deleting.

That's how I confirmed it on the site above: two preloads, both MISMATCH. Chrome may also surface a "preloaded using link preload but not used within a few seconds" warning in the Issues panel, but I wouldn't wait to notice it — run the check.

One caveat before you trust a clean result. That snippet reads the DOM, and on a page served by an optimization plugin the DOM is the optimizer's output, not what your server generated. I have watched the same URL hand back two different documents depending on whether it came from cache — in one case an entire inline <style> block was full on the origin and empty in the cached copy. So if the check comes back clean on a heavily cached site, confirm against the raw HTML before you believe it:

const url  = location.origin + location.pathname + '?nocache=' + Date.now();
const html = await fetch(url, { cache: 'reload' }).then(r => r.text());
console.log((html.match(/<link[^>]*rel=["']?preload["']?[^>]*>/gi) || []).length + ' preload tags at origin');
console.log(document.querySelectorAll('link[rel=preload]').length + ' preload tags in the DOM');

If those two numbers disagree, audit the origin copy — that's the one your server is actually producing.

Same idea applies to as="style", as="font", and as="image". Fonts are the nastiest of the three, because a mismatched font preload also fails to warm the cache before the font is needed, so you pay twice and still get the swap.

The fix

Make the two URLs identical. Either add the same ?ver= to the preload href, or drop the version from the script tag — whichever your setup lets you control.

If you can't easily reach the code generating the hint, just delete the preload. A missing preload costs you a little discovery latency. A mismatched one costs you the full file size at the worst possible moment. Deleting is strictly better than leaving it broken.

The lesson

A preload tag is a promise that the browser will keep literally. It doesn't check whether you meant the same file. It checks whether you typed the same URL.

So when you audit resource hints, don't read them for intent. Diff them against what the page actually requests. Two URLs that a human would call "the same file" are, to the browser, simply two files.

I do this kind of technical detective work constantly. If you're tired of guessing why your site is slow, I packaged my exact audit checklist into SpeedKit for Claude Code.

Hidden in 26,695 characters of Additional CSS: the rule that broke every mobile header

NOGUCHILin — Fri, 31 Jul 2026 11:54:57 +0000

Sometimes a performance problem isn't a lack of optimization. Sometimes it's a ghost that has been haunting your stylesheet for years.

I was recently brought in to diagnose a persistent Core Web Vitals issue on a WordPress site. Largest Contentful Paint was sitting between 5.4 and 5.8 seconds on throttled mobile and would not move. The previous developers had tried the usual things: optimizing images, adding preload tags, tuning caching. None of it helped.

When I looked at the LCP breakdown, the timing of the paint event didn't match the download of the header image we were supposed to be seeing. It matched the completion time of a completely different image file.

The investigation

The HTML was correct. The <link rel="preload"> tags were well formed and pointed at the right optimized image. The network panel showed that image downloading quickly.

But on mobile, the site wasn't displaying it.

I started stripping away layers:

Disabled custom plugins? Still there.
Checked the theme's page builder settings? Correct image selected.
Looked for rogue JavaScript swapping the src? None found.

Finally I looked at the one place you hope you never have to: Appearance > Customize > Additional CSS.

26,695 characters of "quick tweaks"

In WordPress, the Customizer has an "Additional CSS" field. It is meant for small adjustments. On this site it had grown, over years, into a single block of 26,695 characters. (That is measured, not estimated — and getting that number turned out to be its own trap, which I'll show you at the end.)

Buried in it was a rule shaped like this:

.touch #page-header .row-background.background-element {
    background-image: url(https://old-staging-host.example/wp-content/uploads/header-photo.jpg) !important;
}

Four things made it lethal:

.touch — it only fired on touch devices, so nobody testing on a desktop would ever see it.
#page-header — it targeted an ID used on every single page of the site.
background-image — a CSS background is invisible to the browser's preload scanner, so it is discovered late.
!important — no theme setting or optimization plugin could override it.

And the URL pointed at an old, abandoned staging server that nobody had thought about in years.

Because this CSS was injected globally, every mobile visitor to every page was rendering the wrong header image — one that lived on someone else's server and had never been optimized.

Why it defeated every previous attempt

This one rule explained the whole mystery:

The preload tags "didn't work" because they preloaded the correct image, while the CSS made the browser fetch and paint a different, heavier one.
Image optimization plugins couldn't touch it, because the image wasn't on this site at all.
It was invisible on desktop by construction: the selector starts with .touch.

That last point is worth sitting with. The bug was written in a way that guarantees the person checking their work will not see it.

The fix

I deleted the rule.

LCP went from a 5.4–5.8s baseline to 3.6–4.3s, across the whole site, because Additional CSS is global — removing it fixed every page at once. That is a floor of about 1.5 seconds and a ceiling of about 2.2, depending on which end of each range you compare. I'm giving you both ends rather than the flattering pair, because single runs on a page like this scatter, and one cherry-picked before/after is how people end up believing things that aren't true.

No new plugin. No new optimization. One deletion.

Check your own — and the trap that will tell you there's nothing there

WordPress prints the Additional CSS field inline in your page source, in a <style id="wp-custom-css"> block. So you can measure it from outside, without logging in.

But if you do the obvious thing — read it out of the DOM — you may get a very reassuring, very wrong answer:

document.querySelector('#wp-custom-css').textContent.length;   // 0

Zero. The element is right there and it is empty.

That is what I got on this site. The Additional CSS had not gone anywhere; a caching plugin's "remove unused CSS" feature had rewritten the cached page, emptied that block, and folded the rules it decided to keep into a generated stylesheet of its own. Reading the live DOM tells you about the optimizer's output, not about what is actually stored in your site.

Fetch the un-cached page instead:

// paste in the browser console on your own site
const url = location.origin + location.pathname + '?nocache=' + Date.now();
const html = await fetch(url, { cache: 'reload' }).then(r => r.text());
const css = (html.match(/<style[^>]*id=["']wp-custom-css["'][^>]*>([\s\S]*?)<\/style>/) || [, ''])[1];

console.log(css.length + ' characters of Additional CSS');
console.log((css.match(/!important/g) || []).length + ' !important');
console.log([...new Set((css.match(/https?:\/\/[^)'" ]+/g) || [])
  .filter(u => !u.includes(location.hostname)))]);

Side by side on the same page, same minute, that was the difference:

	HTML size	Additional CSS
Normal request (served from cache)	576,036 chars	0
Same URL with a cache-buster	177,012 chars	26,695

The last line of the snippet is the one that matters. It lists every external URL your "quick tweaks" still point at. If a staging host, an old domain, or a former agency's server shows up there, you have found the same class of bug.

And notice what the first table row means: the tool installed to make the site fast is also the reason nobody found this for years. It hid the junk drawer.

The lesson

When your optimizations aren't moving the needle, stop adding more optimizations.

Look at what actually painted. If the element rendering isn't the element you optimized, your problem isn't speed — it's that something is overriding you, and you haven't found it yet.

And check the Additional CSS box. It's the junk drawer of WordPress, and it does not show up in any audit tool's checklist.

I do this kind of technical detective work constantly. If you're tired of guessing why your site is slow, I packaged my exact audit checklist into SpeedKit for Claude Code.

WooCommerce won't filter by two attributes at once. A client needed 40 category pages that do exactly that.

NOGUCHILin — Fri, 24 Jul 2026 00:33:38 +0000

This week's job: an ecommerce store selling made-to-size products wanted 40 SEO landing pages - one per popular size. Think "12 x 24 Widget Frames" as a page that ranks, instead of a filter URL that never will.

The catch is small but real, and if you've tried this you've hit it: WooCommerce's product listing tools take one attribute filter, not two.

The problem, concretely

The store models size as two product attributes: pa_width and pa_height. Their menu links to filtered listings like:

/product-category/frames/?filter-width=341&filter-height=321

Two problems with parameter URLs like that:

They don't rank. Google mostly treats them as duplicates of the base category. Forty of these links means forty pages of crawl noise and zero landing pages.
You can't replace them with the stock shortcode. [products attribute="width" terms="341"] works - but there's no second attribute slot. Width AND height together isn't a thing.

The site had ~350 pages, Elementor everywhere, and a live store I wasn't allowed to break (their words: "please keep in mind that this is a live site"). So: no new plugins, no theme surgery, nothing clever. Small, boring, reversible.

The fix: 30 lines and one filter hook

WooCommerce's [products] shortcode builds a WP_Query and - helpfully - passes the query args through a filter before running it. So you wrap it: accept two term IDs, inject both as a tax_query, render, clean up.

// [size_products width="341" height="321"]
add_shortcode( 'size_products', function( $atts ) {
    $atts = shortcode_atts( array(
        'width'   => '',
        'height'  => '',
        'columns' => '4',
        'limit'   => '-1',
    ), $atts, 'size_products' );

    if ( ! $atts['width'] || ! $atts['height'] || ! class_exists( 'WC_Shortcode_Products' ) ) {
        return '';
    }

    $filter = function( $query_args ) use ( $atts ) {
        $query_args['tax_query'][] = array(
            'taxonomy' => 'pa_width',
            'field'    => 'term_id',
            'terms'    => array( (int) $atts['width'] ),
        );
        $query_args['tax_query'][] = array(
            'taxonomy' => 'pa_height',
            'field'    => 'term_id',
            'terms'    => array( (int) $atts['height'] ),
        );
        return $query_args;
    };

    add_filter( 'woocommerce_shortcode_products_query', $filter, 20 );
    $shortcode = new WC_Shortcode_Products( array(
        'columns' => $atts['columns'],
        'limit'   => $atts['limit'],
        'orderby' => 'menu_order title',
        'order'   => 'ASC',
    ), 'products' );
    $html = $shortcode->get_content();
    remove_filter( 'woocommerce_shortcode_products_query', $filter, 20 );

    return $html;
} );

Notes that matter:

It renders your theme's normal product cards. Because it goes through WC_Shortcode_Products, the output is the standard WooCommerce loop - same markup your theme already styles. The pages look native because they are.
Caching is free. The shortcode caches per-args, and since width/height are part of the args, every size page gets its own cache entry. No stampede.
Add and remove the filter around a single render. Leave it attached and you'll quietly contaminate every other [products] call on the page.
Drop it in via your snippets plugin or child theme. On a live site I prefer a snippets plugin: one toggle to revert.

The part that actually took thinking: don't recategorize 350 products

The obvious alternative was "just create a size category and assign products to it." That means editing every product, duplicating information the attributes already hold, and a second source of truth that drifts. The attribute-based query means product data stays exactly as the store manages it today - new products with the right width/height attributes appear on the right size page automatically.

One prep step made the rollout mechanical: before building anything, I extracted the full attribute term map from the site's own menu markup (15 widths x 15 heights, each label already paired with its term ID in the filter URLs). Forty pages then reduced to a lookup table: page title, slug, two term IDs, done.

The SEO wrapper around it

Each size page is a normal page (cloned from the client's existing landing-page template, so design review took minutes, not days):

H1 and title tag with the size phrase people actually search
a unique intro paragraph and meta description per size
clean slug like /12-x-24-widget-frames/
the shortcode with that size's two term IDs

The old parameter URLs keep working - nothing redirects, nothing breaks. The menu just points at real pages now.

One honest footnote

The grid shows exactly what's in the catalog - which is how we found that one size was missing a variant everyone assumed existed (its mirrored orientation existed; the portrait one didn't). A faithful query is also a free data audit. Report those findings to the store owner instead of papering over them; it's the most trust you can buy with one message.

I measure before I touch anything - it's how I work through Upwork and why my write-ups have numbers in them. Previous entries in this series: cutting a WooCommerce checkout by 60% by removing an optimization plugin and how to tell if your WordPress host is the real bottleneck.

The same number, two different diseases: 5 audit signals that mean something else than you think

NOGUCHILin — Thu, 23 Jul 2026 00:19:05 +0000

Last week I wrote about 5 things that kept breaking across 8 sites — failures that score fine and still hurt, because no measurement tool ever surfaces them. In the comments, @fromzerotoship handed me the mirror image from the infra side: signals that do show up, loudly, but mean something completely different than they say. A firewall rewriting legitimate 4xx responses into 405s. A 404 that means "not deployed yet," not "wrong path."

He named the split better than I could: a tool can fail you by staying silent about a real problem, or by reporting a real signal that means something else here. The silent kind wastes your time once. The lying kind teaches you to distrust the whole layer.

So here's the follow-up he suggested: the five signals I keep meeting in web audits where the number is real, but the diagnosis it implies is wrong. For each one — what it says, what it can actually mean, and the fastest check that tells you which disease you have.

1. A 200 that means "page not found"

The signal: every URL returns 200. Crawler happy, uptime monitor green, audit tool scores it.

What it can actually mean: the theme's "nothing found" template rendered beautifully — with a 200 status. Soft 404s are invisible to almost every automated check because the page is a valid page. It just isn't the one anyone wanted. Search engines eventually notice (Search Console has a dedicated bucket for this), but your monitoring never will.

The 60-second check: don't trust the status line — trust the content. curl -s <url> | grep -ci "nothing found\|no results\|not exist". If you have a sitemap, spot-check the thinnest pages in it: same boilerplate word count on ten "different" URLs is the tell.

2. A Lighthouse "regression" that means "you hit a cold cache"

The signal: yesterday's run: 78. Today's run, after your fix: 61. Conclusion: the fix made it worse. Revert?

What it can actually mean: run one hit a page-cache HIT, run two hit a MISS. On a WordPress site I traced this week, the same document arrived in ~320ms warm and 2.4s cold — that single difference reshuffles every downstream phase (FCP, LCP, even which element is the LCP). Neither run is lying. They're measuring two different servers that happen to share a hostname.

The 60-second check: look at the TTFB of the runs you're comparing before you compare anything else. If they differ by an order of magnitude, you're not A/B-testing your fix — you're A/B-testing the cache. Warm the URL once, then measure three runs and read the median. (And check response headers: most page caches announce HIT/MISS.)

3. "Element Render Delay" — one number, three unrelated fixes

The signal: Lighthouse says your LCP breakdown is dominated by render delay, 700-1700ms. The image is small and loads fast, so... the image isn't the problem. Now what?

What it can actually mean: at least three completely different things, each with a different owner:

an intro animation on the LCP element or an ancestor — the browser won't count the element painted until it reaches its final visible state, so a 0.8s hero fade is 800ms of render delay;
render-blocking CSS or fonts — the element is ready, the render tree isn't;
layout waiting on JavaScript — the element's size is computed at runtime (a height-ratio the theme resolves in JS), so paint can't happen until that script runs.

Same number. Fix one is a CSS change, fix two is resource loading, fix three is theme architecture. Guess wrong and you'll "optimize" for a week with nothing to show — which is usually the story behind "we tried everything and the score didn't move."

The 60-second check: DevTools Performance panel, mobile throttling, one recording. Click the LCP marker and read what actually sits inside the render-delay span: an animation frame, a blocking stylesheet, or a long task. It's written right there; almost nobody looks.

4. "The image is tiny and fast" — but the image was never the problem

The signal: LCP element is an image, it's 29KB, it downloads in milliseconds. So LCP should be fine. It's 6 seconds.

What it can actually mean: the "image" is a CSS background, not an <img>. The preload scanner can't see it — the request can't even start until the CSS that references it is parsed. On the site from example 2, that meant chewing through a 384KB inline style block (80% of the HTML document) before the browser learned the image existed. Load time: fast. Discovery time: 2.75 seconds. The weight of the file was never in the equation.

The 60-second check: in DevTools, hover the LCP entry and see what element it points to. If it's a div with background-image, stop optimizing the file and start optimizing its discoverability — a per-page preload, or promote it to a real <img>. Also worth 30 seconds: check what your optimizer plugin is already preloading. I found one pushing fetchpriority=high on an image that doesn't appear on the page at all — a preload actively working against the element that mattered.

5. A timeout that means "wrong network layer entirely"

This one is @fromzerotoship's, and I'm including it because it's the purest case of the pattern: an external API call times out with an error that looks exactly like "the API is down." The API is fine. Outbound IPv6 is silently blocked, and the fix is one flag forcing IPv4. Every retry, every backoff strategy, every status-page check is aimed at the wrong layer — because the error message names the wrong suspect.

The 60-second check: when a remote service "is down" but its status page disagrees, test the same call from a different network path (another box, mobile hotspot, curl -4 vs curl -6) before touching your code.

The pattern

When we compared lists in the comments, @fromzerotoship pointed out something I'd missed about my own examples: a single metric can fork on three different axes. It can fork on state — the 200 that's really an empty page (success vs. empty, same code). It can fork on condition — the Lighthouse score that moved because of cache temperature, not your fix (cold vs. warm, same page). And it can fork on cause — the render-delay band that's an animation on one site, a font on the next, JS layout on the third (three fixes, same number). So the sixty-second question isn't just "is this signal lying" — it's "which axis did it fork on?" State, condition, or cause. Answer that first and the fix usually names itself.

All five have the same shape: the signal is real, the implied suspect is wrong. The number survives being written down, travels into a ticket, and the ticket sends someone to fix the wrong thing — that's what makes this class more expensive than silent failures. A silent failure costs you the time until you notice. A misdirecting signal costs you the time you spend confidently fixing something that was never broken.

The defense is boring and works: before acting on any single metric, spend sixty seconds finding out which of its meanings you're holding. The checks above are all under a minute. The weeks I've watched people spend on the wrong fix were not.

What's the signal that lied to you the longest? The comment section on the last post turned into the best checklist I didn't write — happy to be outdone again.

I ran technical audits on 8 sites that asked Reddit for feedback. The same 5 things kept breaking.

NOGUCHILin — Tue, 21 Jul 2026 04:35:45 +0000

Over the past week I've been doing free technical audits for sites posted in feedback subreddits (r/websitefeedback, r/reviewmyshopify and similar) - measuring each one with curl, Chrome DevTools and raw HTML reads before commenting. Eight audits in, the same handful of problems keeps showing up, and they're mostly NOT the things speed tools yell about. Here they are, with real numbers.

1. Your share preview is your storefront window - and it's often empty

A merch brand about to promote its store to an engaged social audience had no og:image, no twitter:image, and no meta description. Every link shared to Instagram Stories, X, Discord or iMessage unfurled as a text-only card with a blank thumbnail - for a brand whose entire pitch is aesthetics. Same store's homepage title tag was the bare domain (the platform fallback when the SEO title is unset).

The fix is minutes: one strong social sharing image + a homepage meta description, set before the promo push, not after. If you check nothing else before launch, check what your link looks like when pasted into a chat.

2. Entrance animations hide your page from the people you're trying to impress

An education platform's hero - headline, guarantee box, CTA - sat at opacity 0 for over six seconds on my first cold load, while entrance animations waited for ~10MB of eager-loaded media. A coaching site had the same pattern: full navy screen, zero words, until a fade-in ran. Both sites look great in the founder's warm-cached browser. First-time visitors on a school Chromebook or hotel wifi see a blank panel - and that's exactly the audience being courted.

If content is invisible until JavaScript says otherwise, your worst-case first impression is nothing at all. Fade things in fast, or don't gate the hero on animation at all.

3. Photos exported as PNG are quietly most of your page weight

One founder photo: 640x720 pixels, exported as PNG with alpha, 783KB - referenced three times on the page. Saved as JPG or WebP it's ~50KB, a 15x cut on a single file with zero visible change. The same site's lifestyle photos were all 200-260KB PNGs; the page shipped ~4MB of images with not a single loading="lazy".

Rule of thumb that would have fixed every case I saw: photos are never PNG. PNG is for screenshots, flat graphics and things that need transparency - and if a photo needs transparency, it needs WebP.

4. Measure before you optimize - the platform may have already solved it

I almost posted "your hero image is 1.2MB" on a supplement store's thread. Then I re-checked with a browser Accept header: Shopify's CDN was auto-converting that PNG to an 84KB WebP for real visitors. The image problem I was about to report didn't exist - the site's actual gaps were metadata and content repetition. Same story on a Ghost blog: the theme was fine (TTFB 50-130ms, proper responsive images); the weight was two membership/payment scripts loading ~900KB on every page view, whether or not the reader would ever subscribe.

Half the value of measuring is finding problems. The other half is not "fixing" things that were never broken.

5. Config leftovers ship to production and nobody notices

My favorite find of the week: a programming blog whose article:publisher meta tag pointed at a beekeeping Facebook page - a copy-paste leftover from another site, shipping in the head of every post. The same blog's og:image was a generic stock photo served from a *.r2.dev URL - Cloudflare's dev-only preview endpoint, rate-limited and not meant for production. Elsewhere: an email popup wired to fire on first scroll, seconds into a first visit; three h1 elements on one page because a hidden brand h1 shipped in the header template.

None of these show up in Lighthouse. All of them showed up in sixty seconds of reading the raw HTML head. Your head section is small - read it once with your own eyes before launch.

The meta-lesson

Speed tools score what they can score. Most of what actually hurt these eight sites - blank share cards, animation-gated heroes, identity metadata borrowed from stock libraries and beehives - scores fine. The audit method that caught everything above is embarrassingly simple: curl the page, read the head, check the wire sizes, load it once cold on a throttled connection, and paste your own URL into a chat app to see the card.

(All examples are from public feedback threads where owners explicitly asked for critique; numbers are from my measurement logs. I've kept sites anonymous here - the point is the patterns, not the naming.)

The most expensive pixel I've ever measured: a 24px arrow that weighed 2.9MB

NOGUCHILin — Fri, 17 Jul 2026 23:10:53 +0000

I run free performance audits on "roast my website" posts. Most findings are boring in a healthy way: oversized JPEGs, render-blocking scripts, a missing cache header. This week I found something I had never seen before, and I want to show you how to check your own site for it, because nothing in your normal workflow will warn you.

A site I audited transferred 5.2MB across 20 requests on a cold load. More than half of that - 2.9MB on the wire, 8.2MB after decompression - was a single SVG file. It rendered as a navigation arrow. At 24 pixels.

One arrow. Three megabytes. That's the biggest byte-per-pixel ratio I've ever measured on a production site.

How an SVG gets to 8MB

SVG is a text format, so I opened the file expecting to find an embedded raster image (the usual way SVGs get huge - a base64 PNG hiding inside). That's not what this was.

The file was one single <path> element. Its coordinate list was exported at full machine precision: 15 decimal places per value, including scientific-notation numbers like -3.16856e-06 - for a viewBox that's 37 by 36 units, rendered at 24px.

Think about what that precision means physically. A 37-unit-wide viewBox drawn at 24px means one unit is smaller than one pixel. Fifteen decimal places of a unit is roughly a millionth of a billionth of a pixel. Every one of those digits is a byte that gets shipped, decompressed, and parsed - and none of them can possibly affect the rendered output, because the output resolution ran out twelve decimal places earlier.

This is not the site owner's fault, and that's the point of writing this up. Design tools will happily serialize paths at whatever precision their internal math produced. If a curve was generated by a boolean operation or a trace, the coordinates come out looking like floating-point noise - because they are. The exporter doesn't round; the developer pastes the asset in; the icon looks perfect; nobody ever opens a .svg in a text editor.

Why nothing warned them

It looks fine. The icon renders crisply. There is no visual symptom at all.
The site "feels fast" to the owner. On the owner's fast connection with a warm cache, the page loaded in about 1.3 seconds. The 3MB tax is only felt by first-time visitors - which for a small business site means exactly the people the site exists to convince.
Bundlers don't parse SVG geometry. Your build tool reports the file size if you look, but nothing flags "this asset is 3000x larger than its information content."
Lighthouse buries it. It shows up inside a generic "reduce payload" line item, indistinguishable from a big hero photo that might be a legitimate choice.

The two-minute check

Paste this in your browser console on your own site:

const res = performance.getEntriesByType('resource');
res.map(r => ({
  file: r.name.split('/').pop().split('?')[0],
  transferKB: Math.round((r.transferSize || 0) / 1024),
  decodedKB: Math.round((r.decodedBodySize || 0) / 1024)
})).sort((a, b) => b.transferKB - a.transferKB).slice(0, 10);

You're scanning the top-10 for two smells:

Any .svg above ~20KB. Icons should be single-digit KB. A 100KB+ SVG is either an embedded raster or precision noise.
A large decoded-to-transfer ratio on text assets. My arrow was 2.9MB transferred but 8.2MB decoded - repetitive digit soup compresses well, which is exactly why it sneaks past "the page doesn't feel that heavy" intuition while still costing real decompression and parse time on a phone.

The fix is one command

npx svgo arrow.svg --precision=1 -o arrow.min.svg

SVGO with 1-2 decimal places of precision is visually lossless for icon-sized art. For this file, the projected result was under 1KB - roughly a 3000x reduction, from more than half the page's weight to a rounding error. If you re-export from the design tool instead, set the export precision to 1 or 2 decimals; the default in several tools is "whatever the float said."

While you're at it, the same audit pass usually catches the quieter siblings of this bug: a photo shipped at 2048px into a 1300px slot (that site had one - 910KB where ~150KB would do) and a 76KB favicon (also present; ~10x the norm).

The takeaway

Vector doesn't mean small. SVG size scales with path complexity times export precision, not with rendered size, and export precision is set by a tool you probably never configured. The cheapest performance win I found all week was, literally, rounding.

I build a lot of these checks into SpeedKit, a Claude Code skill that runs a full speed audit on any site. But honestly: the console snippet above is free and takes two minutes - start there.

The biggest text on your homepage might not be a heading. Here's how to check.

NOGUCHILin — Fri, 17 Jul 2026 23:08:10 +0000

I free-audit a couple of "roast my website" posts a week. Most of the time the interesting finding is a performance number. This week it was something else: a page where the largest, most important sentence on the entire homepage wasn't marked up as a heading at all.

Not a missing <h1>. Not a skipped heading level. The actual hero line - the one in 48px type that says what the product does - was a plain <div>. The only <h1> on the page was a small uppercase label floating above it, styled like a tiny category tag.

To a sighted visitor, the hierarchy reads perfectly: small label, then big headline. To a screen reader or a search crawler, the hierarchy is inverted - the thing that gets first-class semantic weight is the label, and the actual headline is invisible structure, just text in a div.

Why this happens

I've now seen this exact pattern on three unrelated sites in the same week, so it's worth naming the cause instead of treating it as a one-off typo.

Design systems separate "what looks big" from "what's semantically first." A common layout pattern is: small uppercase eyebrow text above a large display headline. Somewhere in implementation, whichever element the developer reached for first - usually the smaller one, because it's simpler markup - gets the <h1>, and the big display text gets styled as a <div> or <p> (or a lower heading level) because by the time it's built, "the heading" already exists on the page.

It's an easy mistake to make precisely because the page looks right. Nothing renders broken. Lighthouse's automated accessibility checks don't reliably catch it either, because they check for the presence of a well-formed heading structure, not whether the heading you have is the sentence a human would actually call "the headline."

I saw the same root cause on a second site this week - a small business site built on a visual website builder. Same shape: a short label had the <h1>, the actual sales headline sat in unmarked text below it. Different stack, same blind spot.

A third site made an even easier-to-miss version of it: the <h1> was the site's own brand name in the nav bar (three letters, one of them a logo mark), and the actual hero pitch - the sentence explaining what the product does and why it's different - was marked as an <h2> one level down. No visual bug at all; the nav logo has always looked like a nav logo. It's purely a markup choice nobody revisits once the page ships.

Why it actually matters

Two concrete costs, not theoretical ones:

SEO: search engines weight <h1> content heavily as a page-topic signal. If your <h1> is "Website Monitoring" (three words, generic) and your real value proposition - the sentence that differentiates you from every competitor - lives in an unmarked div, you're handing the crawler your least useful sentence and hiding your best one.
Accessibility: a screen reader user navigating by heading (a very common navigation pattern - jumping between <h1>/<h2>/etc.) hears the small label and nothing that tells them what the product actually claims to do. The core pitch of the page is functionally invisible to them.

How to check your own site in under a minute

You don't need a crawler for this - a browser tab and view-source is enough:

Open your homepage, view source (or DevTools -> Elements).
Find the <h1> tag. Read only that text out loud.
Now look at your hero section with fresh eyes: what's the biggest, most prominent sentence a visitor actually reads first?
If the answer to 2 and 3 isn't the same text, your heading hierarchy doesn't match your visual hierarchy - and both your SEO and your accessibility are reading the wrong sentence as "the headline."

The fix is almost never a redesign. It's swapping which element carries the <h1> tag - a CSS-only change if your class names already control the visual size independent of the semantic tag.

This is the same kind of check I built into SEO Audit for Claude Code - it walks Claude through reading your rendered HTML for exactly this kind of mismatch between what a page shows and what it tells search engines and screen readers.

I measured 5 'roast my website' sites in one day. The framework was never the problem.

NOGUCHILin — Tue, 14 Jul 2026 05:04:24 +0000

There's a genre of Reddit post I keep an eye on: "roast my website." Most replies are opinions about colors. I do something different - I open DevTools, measure, and report numbers. Yesterday I did five sites in one day, and the pattern was so consistent it's worth writing down.

Not one of the five had a framework problem. Every real issue was something the builder had stopped looking at.

Site 1: The SaaS landing page with a 1080px logo in a 28px slot

A polished Next.js landing page, 467KB total - genuinely light. But:

The nav logo was a 1080x1080 PNG rendered at 28x28. That's ~1,500x more pixels than displayed.
The favicon was a 48KB SVG - 10% of the entire page weight, in the tab icon.
The load event fired at 4.4s, almost entirely because of the analytics stack: session recorder, surveys module, exception capture, plus a chat widget iframe still downloading at the 11-second mark.

That last one deserves its own sentence: the site was shipping more tooling to record visitors who don't convert than it would take to fix why they don't convert.

Site 2: The cafe page that hides itself for 30 seconds

My favorite of the day. The page finished loading in 2.9 seconds (664KB, network idle). Then a "BREWING THE RUSH... 0% FUELED" preloader sat on top of the finished page for roughly thirty more seconds, crawling to 100% on a timer.

The loader wasn't loading anything. It was a door held shut with the room ready behind it.

If you ever add a branded preloader: cap it at 1-2 seconds, and drive it from real load progress. If your page is ready in 3 seconds, the best loading animation is none.

Site 3: The joke site that beat everyone

A "roast my SaaS" gag site: 19KB total, 9 requests, loaded in 0.9s, vanilla JS. The only thing I could find to burn was a 360ms TTFB from an un-cached HTML document.

I mention it because it's the control group. No framework, no build pipeline, no optimization work - and it outperforms almost every funded SaaS landing page I've measured. Weight you never add is the only optimization that's free forever.

Site 4: The 32MB portfolio

A video production company's portfolio - the site itself is the product demo. Total transfer: 32MB. Two thumbnail JPEGs were 15.9MB each - 98% of the entire page. They were 2668x3840 exports displayed at roughly 380x680, and one of them wasn't even visible on screen; it downloaded anyway.

The fix took one sentence: re-export those two files at 800px wide, quality ~80. Page goes from 32MB to under 1MB, visually identical.

The lesson generalizes: when a page is heavy, it's almost never "everything" - it's two or three files. Sort your network tab by size before you touch anything else.

Site 5: The cinematic site where 4 files missed the pipeline

A beautifully built scroll-story site for a premium food brand: 11.2MB, load event at 15 seconds, TTFB 2.9s. Everyone in the thread was debating the scroll pacing. Nobody had opened the network tab.

The interesting part: 30 of the site's images were properly compressed WebP. Four photographic backgrounds were PNG - 7.1MB between them. The developer clearly had an image pipeline; these four files just never went through it.

That's the most common failure mode I see in real audits, and it's not a knowledge problem. It's an inventory problem. You don't need to learn image optimization - you need to notice which files skipped the process you already have.

The pattern

Five sites, five different stacks (Next.js x2, vanilla JS, a no-code builder, custom), and every substantive finding was one of these:

A few oversized files - not systemic bloat. Two images were 98% of a 32MB page. Four PNGs were 63% of an 11MB page.
Self-inflicted waiting - a fake preloader, an analytics pile, an un-cached HTML document. Time the visitor spends waiting on things that aren't the product.
Assets that skipped an existing pipeline - the site already optimizes images; these specific files missed it.

None of this requires expertise to find. It requires opening the network tab, sorting by size, and believing the numbers over your memory of the site. The builders I replied to fixed most of these within a day - one cut their page by 98% overnight.

Measure before you redesign. It's usually two files.

I do this kind of audit constantly, so I packaged the checklist I use into SpeedKit for Claude Code - it walks Claude through measuring any site the way I did above and outputs the fix list.

"Passive income with AI" is mostly a lie. Here's the version that actually paid me while I slept.

NOGUCHILin — Mon, 13 Jul 2026 22:40:16 +0000

You've seen the videos. "Make $10k/month with AI while you sleep" - and then it's a course, a dropshipping bot, or a content farm that Google will delete from existence next update.

I want to show you the unsexy version. The one with receipts.

This week, money landed in my account while I was literally unconscious. Here's the timeline from two nights ago, timestamps from my actual Upwork inbox (I'm in Japan; my clients are in North America - their afternoon is my deep night):

12:38 AM - my agent, on its scheduled patrol, finds a job posted 11 minutes earlier. Fewer than 5 proposals. Exactly my niche.
~1:10 AM - proposal submitted. The client's screening question is answered, technically and specifically, in the first line.
~40 minutes later - the client sends an offer.
Before I wake - the agent has already identified their store from public info, mapped their entire product attribute structure, and confirmed the implementation approach. It tells the client: "you'll have the first deliverable within 24h of acceptance."
Morning, coffee in hand - I read the shift report, approve the contract with one word, and the escrow is funded.

I was asleep for every interesting part of that. So: passive income? Let's be precise, because precision is the whole point of this article.

What I actually run

I'm a solo web-performance consultant. Since last week, an AI agent (Claude, wired up with browser access and a written rulebook) runs my operations around the clock:

Patrols marketplaces every 30-60 minutes. Hard filters: job posted within ~30 min, fewer than 5 proposals, payment verified, inside my specialty, and measurable - if I can't verify the problem with numbers before applying, skip.
Investigates before it ever writes a proposal. Real example: it identified a client's store from just their company name, before they shared the URL, and mapped 225 product attribute combinations from their public menu markup. The proposal explained how to solve their exact problem on their exact stack.
Answers clients in minutes at 3 AM. Scope questions, measurement results, and - house rule - honest bad news. This week it told a client "your catalog returns 7 products here, not the 8 you expected, and here's exactly why." That message bought more trust than any feature.
Builds, on unpublished drafts, and shows its work. Nothing goes live without the client's review.

The part that makes it work: what the AI is banned from doing

This is the boring paragraph every scammy "AI money" video skips, and it's the actual load-bearing wall:

It cannot accept contracts. I approve each one, awake, with my own eyes.
It cannot touch money. No purchases, no payouts, nothing.
It cannot publish or delete anything irreversible - on my accounts or a client's site.
It cannot exaggerate. Written rule: only real, verifiable work gets cited. No invented experience, ever. When a subreddit banned one of its too-tidy comments as "AI slop" - fair call - that lesson went into the rulebook instead of into a workaround.

The judgment stays mine. The hours stop being mine. That's the entire trick.

The receipts, plainly

11 proposals sent over ~5 days. 2 contracts won. Both from the "fresh + investigated" pattern. Both landed during my night.
First job: diagnosed and fixed a WooCommerce checkout, 60% faster, verified with A/B/A tests. Paid, five stars. The review specifically praised that I "actually took the time to investigate" before proposing - the investigation my agent did at 3 PM the client's time, my 4 AM.
Second job: accepted this morning, escrow funded, first deliverable shipped for review ahead of the 24h promise.
Total so far: small. Three figures, not five. I'm building a review base with deliberately small fixed-price jobs, and I'd rather show you real small numbers than fake big ones.

So is it "passive income"?

Honest answer: it's not passive - it's leveraged. Client work still needs a human who owns the judgment. What changed is brutal and simple: the parts of freelancing that used to punish a solo operator - response speed, timezone coverage, pre-proposal research depth - now run without me. I do minutes of decision-making per day on top of the actual craft.

And while you read this, it's running. The patrol fires again within the hour. If a client messaged twenty minutes ago, they already have their answer.

The scam version of this story sells you "money without work."
The real version is better: work without waste, around the clock, with your name on nothing you wouldn't sign awake.

Want the exact system? I packaged the whole night shift - the patrol-loop skill, the screening criteria, the proposal playbook, the failure-modes doc, and the rulebook template that keeps contracts and money human - as the Night Shift Kit for Claude Code. It's built from this real operation, not theory.

I also write up the technical side of these jobs - like cutting a WooCommerce checkout's load time by 60% by removing an optimization plugin. If your site feels slow: I measure before I touch anything, even before you hire me.

Is your WordPress host the real bottleneck? How to tell in 10 minutes, with numbers

NOGUCHILin — Mon, 13 Jul 2026 12:43:25 +0000

Everything below is measured on real sites, not quoted from marketing pages. Affiliate disclosure at the end.

Half the "why is my WordPress slow" advice on the internet says install a cache plugin. The other half says change your host. Both are sometimes right - and you can tell which one applies to you in about 10 minutes of measuring. Here is the exact process I use in client audits.

Step 1: Measure TTFB on three kinds of URLs

TTFB (time to first byte) is the part of load time your front-end can never fix. Run each of these 3-5 times:

curl -s -o /dev/null -w "%{time_starttransfer}\n" https://yoursite.com/

A static file - /readme.html exists on almost every WordPress install and bypasses PHP entirely. This is your server's floor.
A cacheable page - your homepage.
An uncacheable page - cart, checkout, or any logged-in page. This is your PHP + database reality.

Step 2: Read the pattern

readme.html fast (<200ms), homepage fast, checkout 1.5s+? Your host serves cached HTML fine, but every dynamic request pays full price: plugin init, database, no object cache. This was exactly the shape of a WooCommerce client I worked with recently - checkout TTFB was 3.3s on shared hosting.
Everything slow, even readme.html? The server itself (or its location) is the bottleneck. No plugin will fix this.
TTFB fine everywhere but the site still feels slow? Your problem is front-end (images, JS, fonts) - do not migrate, fix the pages. I wrote up how I audit that.

Step 3: Check what your host actually lets you use

Two questions decide whether "optimize in place" is even possible:

Is Redis (or any object cache) available? On the client project above, the answer was no - the plan simply did not offer it. Every uncached request rebuilt everything from MySQL.
Is OPcache actually on? Verify it - do not assume. (My first hypothesis on that project was "OPcache is off". It was on. Measuring beats guessing in both directions.)

If the answers are "no / can't", you have found a structural ceiling. Cache plugins stacked on top of that ceiling can even make things worse - on that same client, a popular optimization plugin's cache-check overhead was costing 3 seconds per checkout, and removing it cut load time by 60%.

What a healthy baseline looks like (measured)

To have a fair reference point, I spun up a stock WooCommerce store on Cloudways (managed WordPress hosting - affiliate link, disclosure below) and measured it from the other side of the Pacific:

URL type	Result
Homepage (cached)	TTFB 0.6-0.7s (including ~180ms of trans-Pacific latency)
Cart (uncacheable)	TTFB ~0.9s
Lighthouse mobile	99 out of the box

No tuning, no extra plugins - server-side caching, Redis and OPcache just exist by default. That is the point: the shared-host client could not get uncacheable pages under 2.3s even after real optimization work; a managed baseline starts around 0.9s before any work at all.

The honest decision rule

Front-end problems (images/JS/fonts) → fix the pages, don't migrate. Cheaper and faster.
Dynamic pages structurally slow + no object cache available → migration buys you more than any plugin can. Budget $14-30/month managed vs $3-8 shared.
If you do migrate: script-check every old URL for 301 integrity, or your rankings pay for the speed.

Disclosure: the Cloudways link above is an affiliate link. I only recommend it because I measured it myself - the numbers in the table are mine, not theirs.

The biggest fix for this slow WooCommerce checkout was removing an optimization plugin (-60%, measured)

NOGUCHILin — Mon, 13 Jul 2026 04:13:28 +0000

This is a real diagnosis for a real client. The site, niche, and anything identifying are deliberately left out. Every number is measured, not estimated.

TL;DR

A client's WooCommerce checkout took 6-8 seconds. A default theme dropped it to 1-2s, so "it's the theme" seemed obvious. It wasn't that simple.
My first hypothesis (PHP OPcache disabled) was wrong, and I told the client so instead of quietly finding a different smoking gun.
Profiling split the cost three ways: ~58% plugin/WooCommerce init, ~14% a synchronous API call, ~22% page-builder rendering. I told the client further plugin cleanup would be worth "a few hundred milliseconds."
That expectation was wrong too - in the good direction. Controlled A/B/A tests found one plugin whose deactivation took checkout from 4.6-4.7s to 1.68-1.73s (-60%). It was a performance optimization plugin.
Total silver bullets sold: zero. Total plugins removed: one - an optimizer.

The setup

Client's report: checkout takes 6-8 seconds on their WooCommerce store (heavyweight theme + WPBakery page builder). They'd already tried the obvious things - upgraded hosting, removed some plugins, simplified the checkout page. Still slow. Their own test: switch to a default WordPress theme, checkout drops to 1-2 seconds. Switch back, 6-8s again.

That test is genuinely useful data. It rules out "it's the network" and points hard at something in the theme/plugin stack. But "the theme is slow" isn't a diagnosis - it's a direction to start digging.

First hypothesis, and why I dropped it

My first read: PHP's opcode cache (OPcache) disabled, forcing the server to recompile a large theme + page-builder codebase on every request. It fit the symptoms, and it's a real, common cause on cheap hosting.

I said as much to the client, then went to actually check.

It wasn't that. OPcache was on and working. I could have quietly moved on and let the client believe "OPcache was the fix" once I found something else. I didn't, because the whole point of a paid diagnosis is that it's actually the reason, not a plausible-sounding one. Saying "my first theory was wrong, here's what's actually happening" costs a little credibility in the moment and buys a lot of it over the relationship.

What I actually did

Cloned the live site to a private staging copy (nothing touches production during diagnosis), then used Query Monitor to break down where page-generation time was going, plus temporary custom timers around suspect hooks.

[ ] Clone to staging, never touch production during diagnosis
[ ] Profile with Query Monitor: hook timings, query count, memory
[ ] Add temporary timers around suspect init/render stages
[ ] Rule things out explicitly (OPcache, Redis) - measure, don't assume
[ ] Test plugin changes as A/B/A with repeats, not A/B once
[ ] Only ship a fix once it's measured

Ruling things out matters as much as finding the cause. Redis? Not available on that hosting plan at all (just an unused client library). Another plausible-sounding fix, closed off with one command instead of a paragraph of speculation.

What the time actually was

Stage	Share	What's really happening
Plugin / WooCommerce init	~58% (~3s)	Every active plugin runs its setup code on every request - combined weight, not one villain
Synchronous API call	~14% (~0.7s)	A payment-gateway status check firing on every checkout load; it only needs to run occasionally
Page-builder rendering	~22% (~1.1s)	Theme + page builder assembling the checkout form

The API call was the first clean win: a read-only status check, safe to cache briefly. Shipped immediately for ~0.2s. Small, free, zero-risk.

Based on the profile, I told the client the remaining plugin audit would be worth "a few hundred milliseconds, not a miracle." I put that expectation in writing. Keep that sentence in mind.

The twist: the optimizer was the bottleneck

The client greenlit a controlled plugin test on staging. Method: deactivate one suspect, measure checkout 3x, reactivate, measure again (A/B/A), so a hosting hiccup can't masquerade as a result.

Suspect #1 (a checkout-flow plugin): no measurable difference. Deactivating it would have been a guess dressed as a fix.
Suspect #2: WP-Optimize - checkout went from 4.6-4.7s to 1.68-1.73s. Minus 60%, reproducible across all three A/B/A rounds, with the payment form still working.

Why would a performance plugin cost 3 seconds? Its page-cache layer still runs its checking/processing logic on pages that can never be cached - cart and checkout are dynamic by definition. So on exactly the pages that were hurting, it contributed pure overhead. The site also had a second caching plugin for the same job, so the two overlapped.

I had to go back to the client and say my written estimate of "a few hundred milliseconds" was wrong by an order of magnitude. Being wrong in that direction is pleasant, but the lesson is the same as with OPcache: the profile tells you where to dig, only the controlled test tells you what's true.

Production results after shipping both fixes: server response time went from 3.3s to 2.35s on the live checkout (the remaining gap vs staging is the structural cost below). The client tested it live and released the milestone the same morning.

What's still slow (the honest part)

The remaining ~2s is not a bug. It's WooCommerce + a page-builder-heavy theme + a normal-sized plugin stack, all initializing on every request, on shared hosting where Redis isn't available and PHP workers are limited. That gets better with structural choices - a leaner theme, fewer always-on plugins, or hosting where object caching actually exists - not with another patch. If your host doesn't offer Redis at all (as here), that's not something any plugin can fix. A managed WordPress host like Cloudways gives you Redis + OPcache out of the box - I spun up a WooCommerce store on it and measured 0.6-0.7s TTFB on cached pages, ~0.9s on the uncacheable cart page, and Lighthouse mobile 99, from the other side of the Pacific (affiliate link, disclosure below).

There's no "install this plugin and get 2 seconds." If someone tells you there is, ask for the before/after numbers, not the promise. Sometimes the numbers will surprise you - this time the 2 seconds came from uninstalling one.

Takeaways

A theme-swap test is good evidence, not a diagnosis. It tells you where to look, not what's there.
Say the wrong hypothesis out loud, then check it anyway. Twice, in this case - OPcache (wrong villain) and "a few hundred ms" (wrong ceiling).
Performance plugins are plugins. They have per-request overhead like everything else, and on uncacheable pages a page cache is all cost, no benefit. Two caching plugins doing one job is a smell.
A/B once is an anecdote; A/B/A three times with a working payment form is a result you can ship.
Ship the small safe win immediately. Scope the structural conversation separately - and honestly.

Disclosure: the Cloudways link above is an affiliate link. I only link to it because it solves the exact hosting limitation described in this post, and I tested it myself before recommending it.

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?utm_source=devto&utm_medium=article&utm_campaign=the-on-page-seo-problems-you-cant-see

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.