DEV Community: Cody Wang

Why every platform's pages score badly on PageSpeed — and why "score" is the wrong thing to look at

Cody Wang — Tue, 20 Oct 2026 10:11:50 +0000

I've spent the last few years doing performance work on Next.js, Prismic, Shopify and WordPress builds. This is what I've learned about why the numbers refuse to agree — and which ones I actually report.

The question I get on almost every project

A client once asked me: "why are our scores so low?"

The site felt fast. It looked fast. My own Lighthouse run on my laptop said 98.

PageSpeed Insights said 71.

Neither number is wrong. But two things nobody had told them:

Those two tools do not measure the same thing.
The score is not a property of their site. It's a reading — taken on one machine, on one network, at one moment.

That second point is the one I now lead with.

1. What you are actually measuring

Local Chrome Lighthouse and PageSpeed Insights differ in four ways at once:

Network. Local: your broadband, often partly cached. PageSpeed: fixed Slow 4G.
CPU. Local: your own machine. PageSpeed: 4× CPU throttling.
Cache. Local: easy to keep warm. PageSpeed: cold start, every run.
Geography. Local: usually close to the CDN. PageSpeed: Google's lab → your host, so worse TTFB.

Same page, 98 and 71. The gap isn't a bug in either tool — it's four variables changing together, and only one of them is your code.

What I do: when I report a number, I say which tool and which profile produced it. A number without that context isn't information.

2. Three ways I've watched people measure it wrong

Testing the dev server. npm run dev is uncompressed and running a hot-reload loop. I have seen a mobile score around 52 on a page that sits in the 80s in production. That's not a baseline, it's noise.

Testing in a browser you've already visited. Your cache is absorbing costs your visitors will pay. Incognito, cache disabled — or don't trust the result.

Testing a deployment that's already been replaced. You fixed the code, but the URL you tested is the previous build. This happens constantly with preview deploys.

What I do: before I touch anything, I write down the tool, the profile, the URL and the build. Half of all "performance regressions" I've been asked to fix turned out to be one of these three.

3. Why every platform fails

I work across four stacks, and they break in different ways. But they share one root cause:

Each of these platforms lets code you did not write run on your critical path.

Shopify — third parties dominate the score. On a Shopify store the theme is rarely the problem. Booking apps, review widgets, chat, heatmaps, pixels — they inject at runtime and they own the main thread.

Here is the clearest example I have. A booking app pulled jQuery from a Google CDN. On a weak connection that request was slow or failed outright, and the button sat on "Loading…" forever. The fix wasn't in the app. It was in the theme:

self-host jQuery in the theme and load it early on product templates
preconnect to the app's CDN
disable the sticky add-to-cart that was covering the modal on mobile
fix the modal's z-index and mobile scroll lock

And the reproduction mattered more than the fix: that missing button only appeared when you navigated from a collection page into a product page on a weak network. Testing the collection page alone proves nothing.

What I do: on Shopify I test the page where the script actually injects — not the page that's convenient.

WordPress — plugin sprawl. Email, gift cards, forms, payments: each brings its own front-end JavaScript and CSS, and the stack adds up faster than anyone expects. Caching is a trap too — logged-in, cart and checkout pages usually bypass it, so I measure both states and say which one I'm reporting.

Next.js and content sites — three repeat offenders. The same asset downloaded twice (a mobile-only and a desktop-only <img> of the same file); a CSS background-image that only becomes discoverable after the stylesheet parses; too much JavaScript in the first-load packet.

What I do: on content sites I ask one question first — is the LCP element discoverable in the initial HTML? In most of my slowest cases, it wasn't.

4. Where the points actually are

Approximate Lighthouse 10 performance weights:

TBT — about 30%. The main thread is blocked by long tasks.
LCP — about 25%. The largest element paints late.
CLS — about 25%. The layout jumps.
FCP — about 10%. First contentful paint.
SI — about 10%. Visual completeness.

TBT plus LCP is more than half the score. When I'm asked to "fix performance", I work on those two and I say so out loud. Spending a week on FCP and Speed Index is working on 20% of the problem.

And I do it on mobile. Desktop scores look fine and hide all of it.

5. Two things that still surprise people

A solid background colour is not FCP. First Contentful Paint needs actual content — text, an image, a gradient, an SVG. Paint a page with one background colour and it has no first contentful paint at all, however good it looks.

font-display: optional can win you CLS and LCP — on a fast connection. On a slow one, the entire visit stays in the fallback font. To the client that isn't a trade-off I chose; it looks like a bug.

6. The uncomfortable part I now say early

Here is a real chain from one project, in order:

Local broadband Lighthouse: up to 98
PageSpeed Insights, mobile: 71–75
Temporary image downsizing: ~91 — rejected by the client as blurry
High-quality imagery restored: settled at 82–85

So I say this at the start of the project now:

With "no quality loss, no structural change" as a hard requirement, a mobile score rarely locks at 90.

Something has to give: bytes, motion, or images. My job is to tell you which one I'd give up and what it costs. If nobody agrees on that, we will argue about the score forever — and the score is the one number that depends on the machine it was measured on.

7. What I report instead

I stopped treating the score as the goal. It's an environment-dependent reading.

Page weight and LCP are properties of the page itself. They travel. They are the same whether Google or I run the test. So those are what I measure, and I show before and after, taken back to back on the same machine.

A score tells you how one machine on one network felt about your page.
Page weight and LCP tell you what your page actually is.

8. Three checks you can run yourself

DevTools → Network → Img, then reload. Find the largest image. Compare the file's real width with the size it's displayed at. If the file is 2–3× bigger than the slot, that's your first win — and it's usually the cheapest one.
Run Lighthouse mobile three times and report the median. Never a single run. A single run is a coin flip.
Search your HTML for two <img> tags pointing at the same file. That's a duplicate download, and it costs nothing to fix.

The one-line version

Measure production, not your dev server. Make the LCP element discoverable and single-request. Keep first-load JavaScript and fonts off the critical path. Remember a solid colour isn't FCP. Test Shopify apps on the page they actually load on. And agree the quality trade-off before you promise anyone a number.

I build and fix content-driven front-ends — Next.js, Prismic, Shopify and WordPress — and I measure the result instead of asserting it. If you want to know whether your site is actually slow, or just being measured badly, run it through prismicaudit.com and send me what it finds.

An AI cleanup deleted 8 lines of CSS. The build passed. The signboard vanished.

Cody Wang — Tue, 20 Oct 2026 09:20:39 +0000

A few weeks ago I asked an agent to tidy the token layer of a restaurant template. It did exactly what I asked. One theme block had eight custom properties that looked unused: three wood tones, one border shade, one inset shade, and three paper tones for a signboard face. Nothing in the React code referenced them by name. The agent deleted all eight and reported "removed unused variables."

The build passed. Typecheck passed. No console error. The page still rendered.

The hand-painted A-frame sign at the top of the page — the one element a customer would actually photograph — was now a blank, transparent rectangle. Every gradient on it resolved to nothing.

Why nothing caught it

CSS custom properties are strings. var(--wood-2) with no definition is not a syntax error; it's invalid at computed-value time, so the property falls back to unset — usually transparent.
TypeScript doesn't read CSS. ESLint doesn't know your design tokens. Neither does the bundler.
Lighthouse is happy. Zero errors, zero warnings. The page is still "accessible" and still "fast."
"Unused" had been judged by grepping the TSX. The tokens were consumed in a different language — inside linear-gradient() and layered box-shadow.

Here's the shape of what disappeared, from the theme block:

[data-theme="estuario"] {
  --wood-1: #8b5a2b;  --wood-2: #6e4320;  --wood-3: #a67c52;
  --wood-border: #5c3a1e;  --wood-inset: #3d2412;
  --board-face-a: #f3ebe0;  --board-face-b: #e8dcc8;  --board-face-c: #d9c9b0;
}

Eight lines. The sign was built from all eight.

What I changed in my process

The token layer is additive-only. Deleting from it requires a human diff review, even at eight lines.
Every change ships with before/after screenshots of the section it touched, at 390px and 1440px — not a screenshot of the homepage.
I review by blast radius, not diff size. Those eight deleted lines touched every surface on that page. A 300-line new component touches one section.
Before any deletion, the agent has to say what consumes it, with a grep across CSS, TSX, and JSON. If it can't produce that, it doesn't delete.

The part that generalizes

Agents are strong at additive work and unreliable at cleanup, because cleanup requires knowing the blast radius — and the blast radius is precisely what isn't in the file being edited. A deletion is a claim about the whole repo. Most of the time nobody checks that claim.

So my rule is boring: additions get reviewed by tests, deletions get reviewed by eyes. Build passing means nothing here — it passed the whole time the sign was gone.

If you're shipping sites with agents, the review is the product. The 17 templates I've shipped all clear the same gates — zero console errors, no horizontal overflow at 390px, 7:1 contrast, no external image domains — and not one of those gates would have caught this. Only the screenshot did.

Live pages: https://slice-templates-pool.vercel.app/

The broader build, and why the constraint is verification rather than generation speed: https://dev.to/amazong110/i-built-17-nextjs-homepage-templates-heres-the-part-ai-cant-do-389h

I built 18 Next.js homepage templates. Here's the part AI can't do.

Cody Wang — Tue, 20 Oct 2026 09:02:41 +0000

I spent the last few weeks building 18 homepage templates for Next.js. Seventeen industries — law, dental, barbering, architecture, jewellery, veterinary, cafés, boutique stays, pilates studios, residential contractors — not 18 recolors of the same hero.

I used AI heavily for all of it. Here is what it was genuinely good at, and the three places it kept failing.

What it's good at: scaffolding. Section skeletons, Tailwind classes, responsive breakpoints, alt text, the boring 60%. A layout that used to take an afternoon takes forty minutes.

What it can't do — one: decide what the page is arguing.

Every homepage makes a claim. A law firm's page argues "we are careful." A salon's argues "you will feel good walking out." AI will happily generate a hero for both and make them look identical. I had to write the claim down first, in one sentence, or the output was decoration.

Two: spacing is a judgment, not a value.

AI produces py-16 everywhere because it's safe. A page where every section has the same rhythm reads as a template — which is exactly what buyers are trying to escape. Half my time went into rhythm: a tight block after a large one, a quiet section before the CTA.

Three: it breaks things it wasn't asked to touch.

Ask for one section, get eight files changed. In one case a "cleanup" removed a CSS variable and silently killed a decorative element. It built fine. Type-checked fine. I only caught it by screenshotting before and after on a phone.

So my workflow is boringly manual: read the diff, change one file, screenshot at 390px, repeat. Agents write fast; the review is the work.

Every template has to clear the same gates before I ship it: zero console errors, no horizontal overflow at 390px, text contrast at least 7:1, no external image domains. Boring checks, and they're the reason the templates are usable rather than just pretty.

If you're using agents for frontend, the constraint isn't generation speed anymore. It's how fast you can verify.

I wrote up one specific failure from that build — an agent "cleanup" that deleted eight CSS variables and made a signboard disappear while every check stayed green: https://dev.to/amazong110/an-ai-cleanup-deleted-8-lines-of-css-the-build-passed-the-signboard-vanished-19ii

The live pages (and the source) are here: https://slice-templates-pool.vercel.app/

The link buried in your dropdown is costing you twice — once in clicks, once in search

Cody Wang — Sat, 17 Oct 2026 02:26:21 +0000

Every navigation bar is an argument about what matters. Most of them are made by accident.

I worked on a site where one section — a genuinely useful one, with real content behind it — sat two levels down. You had to hover a top-level item, wait for a panel, and find it in a list of eight. Nobody had decided that page didn't matter. It just ended up there, the way things do.

I moved that one link out of the dropdown and into the top bar. Same label, same page, same design system, same week.

That single move did two jobs at once. One is the obvious one — people finally see it. The other is quieter and most people never connect it: it changes what your site tells Google about that page. If you only think about the first, you're leaving half the value on the table.

Why a buried link doesn't get clicked

Three things change when a link leaves a dropdown, and only one of them is about "visibility."

1. A dropdown is not scanned, it's avoided. People read a horizontal nav in a single sweep, left to right, in well under a second. A dropdown demands a deliberate action — hover or tap, wait, then read a new list — before the user knows whether the payoff exists. That's a cost paid on speculation. Most people decline.

2. A list of eight flattens everything inside it. In a dropdown, your item is one of eight peers. No hierarchy, no emphasis, no visual weight — a line of text among lines of text. On the top level, it inherits the bar's salience and becomes one of four or five things the site is about.

3. Position is a claim about importance. Users infer priority from placement, because that's how every interface they've ever used works. Putting something in the top bar tells them it's a main line of the business without a word of copy. That inference does most of the work — which is why the same link in the same font performs completely differently one level up.

Notice what's missing from that list: the label. If the label had been the problem, moving it would have fixed nothing.

And on phones it's worse. A hover dropdown becomes a tap, a tap becomes a full-screen accordion, and the user has left the homepage before they've seen your section at all.

What the client actually gets

The section stops being a secret. This is the whole point. A page nobody can find isn't a page — it's a URL. Moving it up is the cheapest way to turn an asset you already paid for into something that earns.

A shorter path, and shorter paths convert. The move removes one deliberate decision between a visitor and the thing they came for. Every extra step in a journey is a place where people leave, and a dropdown is the step with the worst attrition.

A positioning statement that costs nothing to make. Putting something in the top bar tells every visitor, on every page, that this is part of what the business does. That's brand work, and you get it for the price of a menu edit.

A mobile experience that isn't broken. On small screens a deep item can be three interactions away. Promoting it often fixes mobile discovery without a redesign.

And a decision that forces the question. A nav bar is zero-sum — the top level fits four or five items and then it doesn't. So promoting one thing means something else steps down. That's not a downside; it's the useful part. It forces you to answer, out loud, what this business is actually selling. If you can't answer it, the nav was never the problem.

Why this also helps search — and why almost nobody says so

Here's the part that gets skipped. When you move a link into the sitewide top bar, you're not just changing what humans see. You're changing what your site tells a crawler on every single page.

Your navigation is your strongest internal anchor text. Every page on the site now links to that section with the same words. That repetition is one of the clearest topical signals you can send about what a page is about. If the item lived under a generic label — "More", "Resources", "Solutions" — the anchor text it inherited was generic, and so was the signal. Give it a top-level label that matches what people actually call the thing, and the signal sharpens on every page at once. This is the single most underrated reason to promote a link, and it costs nothing.

Crawl depth is a budget. Search engines don't crawl every URL equally often; pages linked from every page of the site get re-crawled more regularly than pages three levels deep. That matters for two practical reasons: new content gets discovered and indexed sooner, and changes you make to an existing page get picked up faster. A buried section can sit with stale titles and old copy in the index for weeks because nothing is prompting a re-crawl.

It makes the hierarchy legible. A sitewide link communicates "this is a top-level part of this site." That's a structural statement, and structure is one of the few things about your site you fully control. Pages that are one click from everywhere tend to earn internal recognition — including, sometimes, sitelinks under your main result in search. Google decides those, not you, but it can only choose from what your structure makes obvious.

And there's a trap worth checking this week. Plenty of dropdown menus are built so the links only exist after JavaScript runs — the markup is generated on hover. If that's your menu, a crawler that doesn't execute scripts sees nothing at all, and the section is invisible to search even though a human can reach it. The test takes ten seconds: open the page, view the raw HTML source, and search for the link's text. If it isn't there, your navigation is smaller than it looks.

Two honest caveats. Moving a link up does not, on its own, move rankings — it improves discoverability and strengthens internal signals, and those compound over time. And none of this fixes a page that doesn't deserve the traffic. Promotion buys attention; the page has to be worth it.

When not to move it

If the page is thin, if it's a legal page, if it's a campaign that ends next month, or if promoting it means demoting something that actually pays the bills — leave it where it is. A top bar with nine items is worse than a dropdown, because then nothing is important.

The rule I use: the top bar should contain the things you'd say out loud if someone asked what the business does. Everything else can live one level down and still be found.

The two-minute check

Open the page. Is it reachable from the top bar in one action?
View the raw HTML and search for the link's text. If it's not in the source, crawlers may not see it either.
Count the items in your top bar. More than five means the argument about what matters has already been lost.

If you want a second opinion on your navigation, tell me what's in your top bar and what's one level down. I'll tell you which one I'd move, which one I'd cut, and which one is invisible to search without you knowing.

If you'd rather have someone look at it directly: this is the kind of thing I do for a living — prismicaudit.com. Tell me what's in your top bar and what's one level down, and I'll tell you which one I'd move and which one I'd cut.

What is this site actually built with? Three checks and 13 signals

Cody Wang — Tue, 13 Oct 2026 06:09:05 +0000

What is this site actually built with? Three checks and 13 signals

When you inherit a site — or want to change your own — the first thing you need is not the code. It's what the thing is built with.

Because the stack decides what is possible afterwards.

Whether you can change it at all. A WordPress site's heading font might live in one theme setting. On Webflow you may not even get the HTML. A headless CMS means editing a content model.
Whether the images can be saved. WordPress serves from /wp-content/uploads/, Shopify from cdn.shopify.com, Prismic from images.prismic.io — and each pipeline takes a different set of transform parameters. Miss the pipeline and you don't know what to tune.
Cache and render strategy. Headless leans on CDN caching for API JSON and an HTML shell; classic PHP leans on full-page and object caches; hosted builders give you the fewest knobs.
Whether you can touch the code. Some platforms give you a panel. Some give you everything.

In one line: identify the platform first, then optimise. The other order wastes your time.

Three checks

Check 1: View source, then search it

Open the page → Ctrl+U (Cmd+Option+U on Mac) → search the HTML for the vendor name you suspect.

The distinction that matters: if the name only shows up in body copy or a comment, it proves nothing. What counts is the name appearing inside a src, href or data- attribute — that is a resource the browser was told to load.

A concrete example: you search for prismic and find it inside a <p> tag. That site may just have published an article about Prismic. But if it appears in src="https://images.prismic.io/...", that is hard evidence.

So the question is never "is this word here" — it is where the word appears.

Check 2: Read the response headers, especially the cookies

Open dev tools → Network → reload → click the first document request. Look at:

x-powered-by, x-generator, server
the names inside set-cookie — the most valuable of the lot

Why are cookies stronger than meta tags? Because meta tags are written by a human, cookies are issued by the platform. A cookie called wp-settings-1 or _shopify_s is the platform introducing itself.

⚠️ One trap: CDNs strip headers. Put Cloudflare or Vercel in front and a lot of the original headers are simply gone. So "I don't see it" is not the same as "it isn't there". It's one vote, not a verdict.

Check 3: Compare against a site you already know

The same platform leaves the same shape on every site that runs it: the same asset host, the same path prefixes, the same admin endpoints.

That is the whole reason CMS detection works at all — not guessing, but shape matching.

A single keyword → maybe a false positive
Keyword + matching host + matching path → that is confirmation

13 signals worth memorising

WordPress: /wp-content/, /wp-includes/, /wp-json/, the wp-emoji-release script, wp-* cookies
Shopify: cdn.shopify.com, cdn.shopifycdn.com, /cdn/shop/, Shopify.theme in page scripts
Wix: static.wixstatic.com, static.parastorage.com, the inline viewer model JSON
Squarespace: static1.squarespace.com, Static.SQUARESPACE_CONTEXT
Webflow: website-files.com, website-images-assets.com, data-wf-* on <html>
Prismic: images.prismic.io, /prismic-assets/, slice markers, prismic-toolbar
Contentful: images.ctfassets.net, assets.ctfassets.net
Sanity: cdn.sanity.io, the project id referenced in page scripts
Ghost: /ghost/, /content/ paths, ghost-* meta tags, the Ghost admin SDK
Drupal: /sites/default/files/, drupalSettings, the X-Generator response header
Joomla: /media/jui/, /media/system/, /components/com_
Craft CMS: the CRAFT_CSRF_TOKEN cookie, /cpresources/
Strapi: a /uploads/ path together with an api. host or /api/ JSON endpoints

A real example

Let's practise on a site everyone knows: the TechCrunch homepage.

In the source, these two lines are decisive:

<link rel="https://api.w.org/" href="https://techcrunch.com/wp-json/" />
<script src="https://techcrunch.com/wp-includes/js/dist/i18n.min.js?ver=..." id="wp-i18n-js"></script>

/wp-json/ and /wp-includes/ are WordPress-only paths, and they sit inside href and src — the browser genuinely loads them.

In the response headers it is even more direct:

x-powered-by: WordPress VIP <https://wpvip.com>
link: <https://techcrunch.com/wp-json/>; rel="https://api.w.org/"
server: cloudflare

x-powered-by names the platform outright, and the link header hands you the REST API address.

Note that last line: server is cloudflare, not the origin. That is the "CDNs strip headers" problem in the wild — with a CDN in front, you see one layer less.

The two most common mistakes

Mistake one: finding the brand name in body copy and calling it done.

Documentation sites, comparison posts and job ads list several vendors at once. None of that is proof of an install.

Mistake two: concluding from a single signal.

Plenty of sites sit behind Cloudflare. Cloudflare is a CDN — it says nothing about which CMS runs underneath.

The right approach is to read the signals in layers:

Vendor-specific hosts (strong) > path prefixes (strong) > cookies (strong)
Response headers (medium — CDNs strip them)
Brand strings in page copy (weak)

If you'd rather not check by hand

Paste the URL into prismicaudit.com/tools/cms-checker. It runs 100+ detectors across CMS, frameworks, hosting, CDN and third-party scripts, and lists the raw evidence behind every hit — not just a yes/no.

I care about giving evidence rather than verdicts, because you should be able to check the answer yourself.

The checks described here work on any site. Vendor names are used only to describe identification fingerprints; this tool is not affiliated with any of them.

AI can generate a Shopify section that looks fine, not one you can edit

Cody Wang — Sun, 04 Oct 2026 09:01:03 +0000

A theme I was reviewing had a section that would not move. You could pick it up in the theme editor, drag it, and it would return to its original position. Nothing in the console, no error in the editor. The section rendered correctly on the storefront.

The cause was one attribute. The section had id="hero-1" in its markup instead of {{ section.id }}. Shopify uses that value to tell one section instance from another, so two instances of the same section had the same ID, and the editor could not keep track of which one you were dragging. Replacing the hardcoded value with {{ section.id }} fixed it.

That theme came from an AI tool. The four issues below are the ones I keep finding in themes built this way. Two of them show up as bugs in the editor, two of them show up months later.

1. Hardcoded IDs in the section markup

Liquid sections need {{ section.id }} for their identity. A hardcoded value works while there is only one instance of the section on the page. Add a second one, or duplicate the section into a template twice, and both render with the same ID. The storefront still looks right. The editor stops behaving predictably.

2. Missing presets

Sections that merchants should be able to add need a presets array in the schema. Without it, the section renders wherever it is already placed in a template, so it passes a visual check. It never appears in the Add section menu.

The same applies to {{ block.shopify_attributes }}. Without it on a block, the block renders but cannot be selected in the editor, so merchants cannot change its settings or reorder it.

Both of these only appear when someone tries to edit the theme. That is why they survive a review, a screenshot check, and a demo.

3. CSS inside the section markup

Many generated sections include a <style> block in the section itself. This works, and it has two costs. The rules reload on every page where the section appears, and when two sections define the same selector, the result depends on load order rather than on which file owns the style. Shopify's {% stylesheet %} tag handles this: one request, deduplicated, scoped to the section.

The same pattern shows up in responsive rules. Generated sections often contain the desktop layout and skip the breakpoint at 750px, so the section tests clean at 1440px and breaks on a phone. For a store where most sessions are mobile, that is the layout that matters most.

4. Code that disappears on theme update

When a theme update is published, Shopify keeps the merchant's settings and template edits and leaves custom code alone. Code that sits outside the theme's own structure can be missing from the new version. This is the expensive one, because the merchant ends up with a feature that has no readable source and no one who remembers how it was built.

What Shopify says about this

Shopify's theme support page lists AI-generated theme blocks among the customizations its support team will not troubleshoot. That means the merchant has no support path if the person who wrote the code is unavailable.

The requirements for listing a theme in the Shopify Theme Store set a higher bar than "it renders":

Average Lighthouse performance of at least 60 and accessibility of at least 90, measured on the home, product, and collection pages, on desktop and mobile, with real content in the sections.
Original code. Themes derived from Dawn or Horizon are not eligible as new submissions.
No fake urgency components such as countdown timers or low-stock counters.

Those requirements apply to the official store. Themes sold elsewhere are not reviewed against them.

A five-minute check for any theme

Open the theme editor on a page that has your sections and try to move one to a different position.
Check whether the section appears in the Add section menu.
Open the store on a phone, add a product to the cart, and complete the flow to the cart page.
Press Tab through the page and confirm you can see where focus is.

If the section does not move, does not appear in the menu, breaks on mobile, or the focus indicator is missing, the theme needs work before a merchant can rely on it.

How I build sections

I built a theme for pet stores with 44 sections and 20 page templates. Each section uses {{ section.id }}, ships with presets, includes {{ block.shopify_attributes }} on its blocks, and keeps its CSS in a stylesheet tag.

Before release I loaded the home, collection, and product pages at six widths from 375px to 1440px and checked for horizontal overflow, broken images, dead links, and keyboard traps. No horizontal overflow at any width. Touch targets measured at 24x24 or larger to meet the WCAG 2.5.8 minimum, which required resizing six link styles that were initially smaller.

None of that is visible in a screenshot. It shows up when the merchant changes the store themselves.

hreflang said English, canonical said Chinese. Google believed the canonical.

Cody Wang — Wed, 30 Sep 2026 02:55:00 +0000

I'm Cody Wang. I build and optimise Prismic, SvelteKit and Next.js sites, mostly for clients in New Zealand and for Chinese brands going international.

Last week I put a small SEO audit tool online. Most of the week went into the unglamorous half of launching: making sure search engines could actually read what I'd built. I found one bug that had quietly removed half the site from the index, and it took me three days to spot because every single page looked fine on its own.

What the site is

It's a detector. You paste a URL, it tells you what the site is built with and lists the fixable problems.

Two languages, one URL, language in a query parameter:

/tools/cloudflare          Chinese (default)
/tools/cloudflare?lang=en  English

66 URLs, all server rendered. The content is in the HTML, no JavaScript required.

What I was telling Google

Here's the head of the English page for the Cloudflare detector:

<html lang="en">
<title>Cloudflare Detector — check if a website uses Cloudflare</title>
<link rel="canonical" href="https://prismicaudit.com/tools/cloudflare">
<link rel="alternate" hreflang="zh-Hans" href="https://prismicaudit.com/tools/cloudflare?lang=zh">
<link rel="alternate" hreflang="en" href="https://prismicaudit.com/tools/cloudflare?lang=en">
<link rel="alternate" hreflang="x-default" href="https://prismicaudit.com/tools/cloudflare">

Look at the canonical. The English page is declaring that its real URL is the Chinese one.

So I was saying two contradictory things on the same page. hreflang says the English version lives at ?lang=en. The canonical says the canonical version lives at the bare URL, which serves Chinese. When those two disagree, Google follows the canonical. The English page becomes a duplicate of the Chinese page, and 1,600 words of English copy I wrote for English searchers gets folded into a page in a language those searchers can't read.

The cause was dull. My head builder took lang as its first argument and used it for the <html> attribute, the title, the description, the structured data, the font stack. Then it built the canonical out of the path alone, because that line was written before the language switching existed and nobody updated it when the language switching arrived. One argument that got passed in and never used, on every page of the site.

How I noticed

Not from a dashboard alert. There isn't one for this.

Search Console showed 199 impressions and 8 clicks across four weeks. Four of the five pages that earned a click were ?lang=en URLs. The Chinese pages, which were the canonical targets, were picking up scraps.

That's the tell. Almost everything getting impressions was something I'd told Google to ignore.

You can check this on your own site faster with curl than with any tool:

curl -s "https://prismicaudit.com/tools/cloudflare?lang=en" \
  | grep -o '<link rel="canonical"[^>]*>'

If the canonical that comes back has no lang in it while the page itself is in English, you have the same problem.

The fix

Each language version gets a canonical pointing at itself:

<link rel="canonical" href="https://prismicaudit.com/tools/cloudflare">           <!-- zh -->
<link rel="canonical" href="https://prismicaudit.com/tools/cloudflare?lang=en">   <!-- en -->

The hreflang block stays, except x-default now points at the English version. That one is a judgement call and not a rule. x-default is the page you show when no language matches, so it should be the version your audience actually searches in. Mine is English, so that's where it points. On a site aimed at the Chinese market I'd point it the other way.

The sitemap needed the same treatment. It was emitting one <loc> per path with three alternates, which never put the English URL in the sitemap at all. Now each language gets its own entry, so 66 URLs became 132.

Verifying it

I don't trust "looks right." I wrote a loop that walks every URL in the sitemap and checks the canonical on the English version:

U="https://prismicaudit.com"
curl -s "$U/sitemap.xml" | grep -o '<loc>[^<]*</loc>' \
  | sed -e 's/<loc>//' -e 's/<\/loc>//' | grep -v 'lang=en' | sed "s#^$U##" > /tmp/paths.txt

while read -r p; do
  got=$(curl -s "$U$p?lang=en" | grep -o 'rel="canonical" href="[^"]*"' | head -1)
  [ "$got" = "rel=\"canonical\" href=\"$U$p?lang=en\"" ] || echo "FAIL $p -> $got"
done < /tmp/paths.txt

66 paths, 66 passes, no output. Mobile Lighthouse on a detector page still reads 100 for performance, accessibility, best practices and SEO. The fix didn't cost anything measurable.

What I got wrong while fixing it

The homepage had its own head builder, separate from the page template, so the same bug needed fixing twice. I patched the homepage by running a regex over the already-rendered HTML instead of fixing the template that produced it.

It passes every check I have. It's also fragile in a way I'll pay for later: if the order of those three link tags ever changes, the regex matches nothing, silently, and the bug comes back with no error anywhere. I left a note in the file. Next time I touch that template it goes in the template.

Two head builders and one regex. The actual lesson wasn't about hreflang.

What I still don't know

Whether it worked.

Canonical and hreflang are hints for crawlers. I've changed the hints. Now Google has to come back, re-crawl 132 URLs, and re-evaluate which page is the real one. That takes days to weeks, and until it does, both versions are in a weird state where the signals contradict what Google last saw.

So I'm in the waiting part. Nothing to design, nothing to ship, just checking Search Console every few days to see whether the English URLs start collecting impressions the way they should have been all along.

If you run a multilingual site, the curl loop takes ten minutes. Nothing in a Lighthouse report will ever show you this one.

Six things that keep a site off a perfect Lighthouse score

Cody Wang — Wed, 23 Sep 2026 08:45:20 +0000

I'm Cody Wang. I build and optimise Prismic, SvelteKit and Next.js sites, mostly for clients in New Zealand and for Chinese brands going international.

These six things are ones I've fixed myself, more than once. No theory dump. Just what it looked like, what I assumed at first, what I actually changed, and where the official docs are.

1. Images: alt text, dimensions, file size

The most common one is a missing alt. People either write alt="image" or stuff keywords in there. Both read badly through a screen reader. Alt text describes the picture to someone who can't see it: alt="Dark grey steel garage door after installation, seen from the street". Purely decorative images get alt="" — an empty string, not an omitted attribute.

If editors upload content through a CMS, the template has to cover for them: alt={image.alt || contextFallback}. Don't assume everyone remembers. On one client site I counted 32 images without alt; after the fix, zero.

Docs: https://web.dev/learn/accessibility/images

Second issue is dimensions. Without width and height, the browser doesn't know how much room an image needs. It lays out everything else first, then reflows once the image arrives, and the user watches the content jump. That's where CLS comes from.

<img src="/hero.webp" width="1200" height="630" alt="…" />

Docs: https://web.dev/articles/optimize-cls

Third is file size, and it's the most visible one. A hero exported straight from the design file can land at 527 KB. I once found a star rating icon, an SVG, weighing 123 KB when it should have been about 2 KB.

I do three things together: convert to WebP or AVIF, serve the size the layout actually uses (a 400px card doesn't need a 2000px image), and let the CDN handle it with something like ?auto=format,compress&q=75&w=800. Also don't lazy-load the hero — give it fetchpriority="high" and lazy-load the rest.

Static assets on one site went from 996 KB to 79 KB.

Docs: https://developer.chrome.com/docs/lighthouse/performance/uses-webp-images

2. Don't load the whole font family

Text goes blank for a second on mobile, and LCP suffers for it.

Usually the entire family is being pulled down at once: four to six weights, plus full character sets. While it downloads, the browser may show nothing at all. Chinese sites hit this hard, since a single CJK font can run into megabytes.

What I do: keep only the weights in use, say 400 and 600; ship woff2 split by unicode-range, so an English page never fetches the CJK file; and set font-display: swap so text appears in the system font first.

On one site that was Roboto at 468 KB plus Raleway at 309 KB, 777 KB total, and after the split 57 KB plus 43.7 KB — 100.7 KB.

Docs: https://developer.chrome.com/docs/lighthouse/performance/font-display

3. Third-party scripts: not whether, but when

Scrolling feels sticky, clicking a button does nothing for a moment. That's usually total blocking time.

GTM, the Facebook pixel, chat widgets — they all load as synchronous JavaScript and compete with your page for the main thread. While it's busy, taps do nothing.

Deleting them is cleanest, but on most client work the tracking scripts are a business requirement and I can't touch them. So I change when they load instead:

['scroll','click','keydown','mousemove','touchstart']
  .forEach(e => addEventListener(e, loadTags, { once: true, passive: true }));
requestIdleCallback?.(loadTags);
setTimeout(loadTags, 3500);

Inject them once the page is idle, or after the first sign of interaction. Nothing is removed and nothing stops reporting. With that change on one site, TBT went from 284 ms to 179 ms.

Worth knowing before you promise a number: changing when a script loads is something you can usually get approved. Removing it is not. Where the tracking scripts stay, mobile performance has a ceiling, and it's not a ceiling you can code your way past.

Docs: https://developer.chrome.com/docs/lighthouse/performance/third-party-summary and https://web.dev/articles/tbt

4. Navigation built from buttons is invisible to crawlers

The audit says Links are not crawlable, which means search engines can't follow your links.

Crawlers read <a href="...">. If your nav is a button with an on:click handler that scrolls the page, it isn't a link as far as a crawler is concerned. Your most important entry points simply don't exist in search.

<a href="/#whatwedo">What we do</a>

You keep the styling and the smooth scroll. Let CSS handle it with html { scroll-behavior: smooth } rather than intercepting clicks in JavaScript.

On one site I counted four real <a href> elements on the whole page; the rest of the navigation was JavaScript. Real links took SEO from 83 to 100.

Docs: https://developers.google.com/search/docs/crawling-indexing/links-crawlable

5. canonical tags and structured data

canonical tells search engines which URL is the source of truth for a piece of content. Parameterised URLs, language variants and leftover staging environments all make it easy for them to treat the same page as duplicates. Structured data (JSON-LD) is what lets results show details like ratings or service areas.

<link rel="canonical" href="https://example.com/page" />
<meta property="og:url" content="https://example.com/page" />

One trap here is worth its own paragraph. In Svelte:

<script type="application/ld+json">{JSON.stringify(data)}</script>

That renders the literal string on the page. Users can see {JSON.stringify(data)} sitting in the markup, because Svelte doesn't evaluate what's inside a <script> element. You need {@html ...}. I found it only because the Facebook pixel logged "Malformed JSON".

So after adding structured data, open the page in a browser and look at what actually renders. Don't trust the source file.

Docs: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls and https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data

6. Contrast and touch targets

When accessibility stalls at 97 or 98, the culprits are almost always color-contrast and target-size.

Light grey text on white looks refined, but WCAG AA wants a contrast ratio of 4.5:1, or 3:1 for large text. Tappable things on mobile need to be at least 24×24 px, and putting them too close together also fails.

Don't judge this by eye. Run Lighthouse once and it tells you the exact values you're missing. Readability beats the elegant-grey look.

On my own site: #a4a4a4 on #f7f7f7 measured 2.85:1, so it became #767676 at 4.54:1. Footer links were 85×20 px and got padding to clear 24 px.

Docs: https://web.dev/learn/accessibility/color-contrast and https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html

Two honest notes

A perfect Lighthouse score isn't the point. The point is that people see your content within three seconds, can tap what they need, and can find you in search. The score is useful only because it turns those feelings into numbers you can work through and verify one at a time.

The longest run I've done was eight rounds to take a mobile score from 61 to 86, and that was with every third-party tracking script left in place. Most sites don't need eight rounds. The first three items above will usually cut the page weight in half.

If you're not sure where your site stands, send me the URL. I'll run it through a tool I built and give you a free diagnosis: why the score is stuck, what's fixable, and which parts are a ceiling set by third-party scripts that no amount of refactoring will move.

Tool: https://prismicaudit.com