DEV Community: Chetan Sanghani

I built a lint that caught 3 tax-rule lies my manual sweep missed — a pattern-based safety net for hand-maintained SEO

Chetan Sanghani — Wed, 22 Jul 2026 17:13:29 +0000

Three Sundays ago I found seven pages on my site independently asserting something factually wrong about Indian tax law. The .razor sources were all correct. The pre-rendered static HTML mirrors — which is what Google actually indexes — had drifted.

I fixed all seven by hand. I congratulated myself. I moved on.

Then this Wednesday I built a lint to catch the pattern automatically. It surfaced three more identical lies on three completely different pages. My manual sweep had missed them.

Here's what I built, why regex alone doesn't work, and the two-phase pattern that does.

The setup — why drift happens

SmartTaxCalc.in is a Blazor WebAssembly SPA deployed to Cloudflare Pages. Every blog post has two representations:

Pages/Blog/*.razor — the source of truth. Compiled into the WASM bundle. Rendered client-side after Blazor boots.
wwwroot/blog/<slug>/index.html — a static HTML mirror. What Cloudflare serves at page load. What Google indexes. What users see for the first 1-2 seconds before Blazor hydrates.

The mirrors are hand-maintained. No build step regenerates them from the razors. So when I fix a fact in a razor, nothing propagates it to the mirror. The mirror keeps the old, wrong content.

I already had one lint guarding one part of this:

# scripts/lint-title-parity.ps1
# Ensures the razor's <PageTitle> matches the mirror's <title>.
# Runs in CI on every push touching razor/mirror paths.

That catches SEO titles going out of sync. It does not catch anything below the title tag. Every paragraph of body content is on trust.

The Sunday crisis

Running through an editorial integrity audit, I found the same false claim in seven different blog mirrors:

"Section 80CCD(1B) NPS is now allowed in both regimes."

For readers not in India: this is wrong. Section 80CCD(1B) is a ₹50,000 individual NPS deduction that is Old-Tax-Regime-only. The New Regime disallows it. It matters — a taxpayer following that advice would over-claim and face a Section 143(1) intimation.

The razors said the correct thing everywhere: "80CCD(1B) is Old Regime only." Every mirror I inspected asserted the opposite. Seven of them. Independently. No shared component.

Root cause: some earlier session (months ago, before I was on the project) fixed the razors after a Budget-2025 misreading. Never touched the mirrors. Title-parity was 94/0 clean the whole time because titles never changed.

I fixed all seven mirrors in one commit and moved on.

The lint I built this Wednesday

Three days later, still uneasy that I might have missed one, I built a lint.

Naïve attempt: search for the deduction name near "New Regime":

$pattern = '80CCD\(1B\).*(?:allowed|available)(?:.*)?new\s+regime'

Ran it against 100 mirrors. Seventeen violations. All false positives. Every mirror flagged said something like:

"Section 80CCD(1B) is disallowed under the New Regime."

The word allowed is a substring of disallowed. Word boundaries help a little (\ballowed\b), but not enough — real sentences frame this rule in many ways: "not allowed", "not permitted", "only in Old Regime", "cannot claim", "forfeit", etc.

The two-phase pattern that works

The insight: a positive assertion and a negation can share the same lexical proximity. What distinguishes them is context. So don't try to write one regex that captures both.

Instead:

Phase 1: Find suspicious co-occurrences (the deduction name near "New Regime"). Cast a wide net.
Phase 2: For each hit, examine the surrounding ~400 characters. If any safe-indicator word appears (disallow, not allow, Old Regime only, without touching, mistake, cannot, etc.), the sentence is likely correcting the claim, not asserting it. Skip.

Here's the core of the current lint (PowerShell 7):

$forbiddenClaims = @(
    @{
        Name    = '80CCD(1B) claimed to work in New Regime'
        Pattern = '(?:80CCD\(1B\)[^\r\n]{0,120}(?:new\s+regime|new\s+tax\s+regime))' +
                  '|(?:(?:new\s+regime|new\s+tax\s+regime)[^\r\n]{0,120}80CCD\(1B\))'
        Fact    = "Section 80CCD(1B) is Old Regime only. Only 80CCD(2) survives the New Regime."
    }
    # ... more rules
)

$safeIndicators = @(
    '\bdisallow',
    '\bnot\s+allow',
    '\bdoes\s+not\s+(?:allow|permit|apply)',
    '\bold\s+regime\s+only',
    '\bwithout\s+(?:ever\s+)?touching',
    '\bmistake',
    '\bbelieving\s+80CCD',
    # ~20 more
)

function Test-HasSafeIndicator {
    param([string]$window)
    foreach ($ind in $safeIndicators) {
        if ($window -imatch $ind) { return $true }
    }
    return $false
}

foreach ($file in $mirrorFiles) {
    $bodyContent = # ...skip <head>...

    foreach ($rule in $forbiddenClaims) {
        $matches = [regex]::Matches($bodyContent, $rule.Pattern,
            [Text.RegularExpressions.RegexOptions]::IgnoreCase)

        foreach ($match in $matches) {
            $windowStart = [Math]::Max(0, $match.Index - 200)
            $windowEnd = [Math]::Min($bodyContent.Length, $match.Index + $match.Length + 200)
            $window = $bodyContent.Substring($windowStart, $windowEnd - $windowStart)

            if (Test-HasSafeIndicator -window $window) { continue }

            # Real violation. Report.
            $violations += [pscustomobject]@{
                File  = $file.FullName
                Rule  = $rule.Name
                Match = $match.Value
            }
        }
    }
}

Two hundred lines total, including all 4 rules and 30-odd safe indicators.

What happened when I ran it

First run against the "clean" tree (post my Sunday fixes):

Mirrors inspected: 100
Violations: 13

Thirteen? I'd sworn I fixed all of them.

Nine were false positives — sentences correctly stating the rule, plus a few worked-example patterns like "Under the Old Regime with HRA claim you would take home X" (correct, but "HRA" and "New Regime" appeared within 100 chars of each other elsewhere in the paragraph). I extended the safe-indicators list to cover those.

Four were real. Different pages, all mine, all live:

/blog/tax-saving-new-regime/, line 166 (intro paragraph):

"For FY 2026-27, a salaried New Regime taxpayer can still claim Rs 75,000 standard deduction, Rs 50,000 NPS under 80CCD(1B), and an uncapped employer NPS contribution under 80CCD(2)."
/blog/nps-tax-benefits/, line 383 (Bottom Line section):

"…NPS Tier-1 is one of the highest-leverage tax-saving instruments available — especially under the New Regime, where it's the only meaningful retirement deduction left. Contributing the full Rs 50,000 under 80CCD(1B) saves…"
/blog/tax-saving-tips/, line 166 (intro):

"…and Section 80CCD(1B) NPS is now allowed in both regimes. This guide cuts through the noise…"
/blog/section-80c-investments/ — the same class of drift, slightly different phrasing.

I'd manually fixed the other body sections of exactly these files on Sunday. The intros and bottom-lines were on completely different lines. I hadn't caught them because I was grep-searching for the specific phrasings I'd already found. The lint's proximity pattern didn't care about phrasing — it just noticed the semantic co-occurrence.

Same commit that added the lint also fixed the four newly-surfaced lies. Verification loop:

$ pwsh -File scripts/lint-mirror-integrity.ps1
Mirrors inspected: 100
Violations: 0

Why this generalizes

I'm not the only one running a Blazor/Astro/Next.js site with a JS-hydration layer over a static SEO mirror. The exact tech stack varies. The pattern is universal:

Two representations of the same content
Only one is authoritative (the source)
Only the other is what search engines actually see
Sync is manual or "should be automatic but isn't"

The lint doesn't care about the specific technology. It cares about the semantic co-occurrence in whatever HTML the crawler will see.

Adapt it to your own YMYL (Your-Money-Your-Life) content:

Financial: interest rates, tax brackets, deduction limits, loan terms
Medical: dosage claims, treatment eligibility, side-effect statements
Legal: statute-of-limitations, jurisdiction rules, filing deadlines
Coding tutorials: version-specific API claims ("this works in React 17" while React 19 shipped last month)

Each rule is one entry: a co-occurrence pattern and a fact. Safe indicators are shared across all rules. Both are easy to grow — the day I discover another drift class, I add one entry to the $forbiddenClaims array.

What the lint does not do

Deliberate non-goals:

It does not regenerate mirrors from razors. That's a build-step problem, orders of magnitude bigger. The lint just guards specific known-false claims.
It does not use an LLM. LLM-based fact-checking would be more general but expensive and non-deterministic. Regex + safe-indicator words is deterministic, runs in under a second on 100 files, and costs nothing in CI.
It doesn't check the razor sources. Those are the source of truth. If a razor is wrong, the CA reviewer catches it. The lint's scope is: mirrors must not be worse than razors.

Wire it into CI

.github/workflows/lint-title-parity.yml picked up the new job:

mirror-integrity:
  name: Mirror body-content YMYL integrity
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - name: Run lint-mirror-integrity
      shell: pwsh
      run: pwsh -File ./scripts/lint-mirror-integrity.ps1

Path-filtered to razor/mirror/lint-script paths so it doesn't fire on unrelated pushes. Fails the check on any violation.

What I learned

Three things I didn't expect:

My "manual sweep" felt thorough because I'd fixed the specific phrasings I'd found. I hadn't fixed the pattern. The lint caught what I'd missed because it looked for the pattern, not the phrasing.
Safe-indicator words are the harder half. The forbidden-pattern list was five minutes of work. The safe-indicator list has been iterated three times as new false-positives appeared. Every new indicator I add reduces false positives across every rule.
The first run showed me things I didn't want to see. Discovering four more lies after I thought the crisis was resolved was uncomfortable. But it's exactly why the lint exists. If it never surfaced a real violation, it wouldn't be earning its CI time.

The current state

Six rules cover 80CCD(1B), HRA, Section 24(b), plus a MathSolver-schema guard (a Google-validator gotcha I ran into weeks earlier and don't want to accidentally re-introduce).
Safe-indicators list is at 30-odd terms.
Runs in about 400 ms across 100 mirror files.
Zero current violations. Sitting on main as a tripwire.

The lint is short. The insight is small. But it caught real user-facing YMYL bugs that a human editor and a title-parity lint had both missed. That's a fair trade for 200 lines of PowerShell.

If you're running a Blazor / Astro / Next.js site with a similar hydration pattern and want the full script, the SmartTaxCalc repo is public at github.com/chetan00118/IndiaTaxPlanner. The file is scripts/lint-mirror-integrity.ps1.

If you have a YMYL-content-heavy site and no drift guard, this is your polite nudge.

Six directory emails promised me a dofollow backlink. My 40-line PowerShell verifier said otherwise.

Chetan Sanghani — Wed, 22 Jul 2026 16:56:16 +0000

Every few days now, my inbox gets another version of the same email:

"Hi there! 👋 We discovered your product and think it's a great fit. Submit it and get a high-quality dofollow backlink from a trusted domain."

In one evening last week I got six of them. Different brand names, same pitch. And because I'm chasing external-validation signals for an AdSense approval, "dofollow backlink" is exactly the phrase designed to make me click.

I didn't click. I ran a script instead. This post is:

Why "dofollow" is worth verifying at all (and why the standard SEO guidance is now stale)
The two silent-nofollow discoveries that made me build a verifier (Medium, GitHub)
The 40-line PowerShell verifier itself + the header dance to get past bot-detection
The newer trap: sites that actively claim dofollow — and how the claim falls apart when you check the submission funnel, not just an existing listing

What "dofollow" means, and why it moves

Every <a href="..."> on the web is either dofollow or nofollow. Google treats them very differently:

Dofollow (rel doesn't contain nofollow / ugc / sponsored): the source domain vouches for the destination. Passes SEO "link equity." Counts toward the destination's ranking authority.
Nofollow / UGC / Sponsored: the source domain explicitly declines to vouch. Google largely discounts these for ranking. Still fine for referral traffic and brand exposure — just doesn't move the SEO needle.

For an AdSense-approval situation like mine — where the question is "does this site have external validation from real sources" — dofollow domains matter and nofollow domains are decorative.

The catch: platforms shift policies. What was dofollow in 2020 may be nofollow today, and a cached SEO guide from a few years back gives you the outdated answer with total confidence.

Discovery 1: Medium is now `ugc nofollow`

I republished a home-loan article on Medium expecting the author-bio + in-article links to be dofollow (per most 2020–2022 SEO guides). Curl'd the live article:

curl -sL "https://medium.com/@author/article-slug" `
  -A "Mozilla/5.0" | Select-String -Pattern 'smarttaxcalc'

Result on every anchor:

<a class="z rm" href="https://smarttaxcalc.in/..." rel="noopener ugc nofollow" target="_blank">

That rel="noopener ugc nofollow" is Medium's current platform-wide default (rolled out ~2023–2024 to kill SEO spam). Every outbound link on Medium is nofollow now, including your author-bio link.

Discovery 2: GitHub READMEs are nofollow too — even in your own fork

Same day, I forked an "awesome-personal-finance" repo, added my site, and pushed. Standard advice says: "even if the PR isn't merged, your fork's README anchor is a dofollow link from github.com." Curl the rendered README:

<a href="https://mint.intuit.com/" rel="nofollow">Mint</a>
<a href="https://smarttaxcalc.in" rel="nofollow">SmartTaxCalc</a>

Every external anchor on any GitHub-rendered README is rel="nofollow", platform-wide, since ~2020. Even Mint — a heavyweight fintech domain — is nofollow on the upstream repo. Nothing you can do overrides it.

Both discoveries invalidated ~30 minutes of prep in one afternoon. Both would have been caught by a 30-second check before the work.

The lesson: verify the `rel` before you write

Fetch any existing outbound link on the target platform, look at its rel. If it contains nofollow, that's the blanket policy — no author, no article, no PR overrides it. I didn't want to remember to do this manually every time, so I wrote it into my weekly analytics script.

The verifier — 40 lines of PowerShell

The core loop, minus try/catch scaffolding:

$siteHost = ([Uri]$config.siteUrl).Host   # e.g. "smarttaxcalc.in"

foreach ($src in $config.knownReferringUrls) {
    $resp = Invoke-WebRequest -Uri $src -UseBasicParsing -TimeoutSec 20 `
        -Headers $browserHeaders   # see next section for the header set

    # Match every anchor pointing to our host
    $pattern = '<a[^>]*href="[^"]*' + [regex]::Escape($siteHost) + '[^"]*"[^>]*>'
    $anchors = [regex]::Matches($resp.Content, $pattern,
                [System.Text.RegularExpressions.RegexOptions]::IgnoreCase)

    foreach ($m in $anchors) {
        $tag = $m.Value
        $rel = if ($tag -match 'rel="([^"]*)"') { $Matches[1] } else { '' }

        # Dofollow = no nofollow, no ugc, no sponsored in rel.
        # rel="noopener noreferrer" is fine — security attributes, not SEO.
        $isDofollow = -not ($rel.ToLower() -match '\b(nofollow|ugc|sponsored)\b')

        [pscustomobject]@{
            sourceUrl  = $src
            rel        = $rel
            isDofollow = $isDofollow
        }
    }
    Start-Sleep -Milliseconds 500   # polite pause between hosts
}

config.knownReferringUrls is just a list of URLs where you've published or shared a link back — Medium articles, Dev.to posts, forum threads, directory listings, whatever. Output feeds a scorecard row in my weekly insights.md:

| Dofollow referring domains | 1 | ≥ 5 | 🔴 |

The header dance for Cloudflare-fronted sites

A bare Invoke-WebRequest gets 403'd instantly on Medium, Quora, and anything behind Cloudflare. Even -UserAgent 'Mozilla/5.0' isn't enough. This header set gets me through most sites:

$browserHeaders = @{
    'User-Agent'                = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36'
    'Accept'                    = 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8'
    'Accept-Language'           = 'en-US,en;q=0.9'
    'Sec-Ch-Ua'                 = '"Chromium";v="121", "Not A(Brand";v="99"'
    'Sec-Ch-Ua-Mobile'          = '?0'
    'Sec-Ch-Ua-Platform'        = '"Windows"'
    'Sec-Fetch-Dest'            = 'document'
    'Sec-Fetch-Mode'            = 'navigate'
    'Sec-Fetch-Site'            = 'none'
    'Upgrade-Insecure-Requests' = '1'
}

The Sec-Ch-Ua* and Sec-Fetch-* headers are what Chrome sends automatically that a bare HTTP client doesn't. Even with the full set, some sites still block on a TLS-fingerprint check Invoke-WebRequest can't spoof — for those the verifier reports ❓ Unknown (fetch blocked) rather than misclassifying. When it can't confirm, it says so.

The newer trap: when the site emails you claiming dofollow

Discoveries 1 and 2 were silent nofollow — platforms that quietly changed policy. The newer pattern is louder: directory sites that email you promising "a high-quality dofollow backlink from a trusted domain." That's the actual selling point in the pitch.

So I did what the verifier taught me — checked an existing listing on one of these networks before submitting. And here's the twist that makes this worth a whole section: the existing listing checked out. Outbound product links carried:

rel="noopener noreferrer"

No nofollow, no ugc. By the rule above, that's dofollow. Naive verdict: "great, submit."

Then I opened the actual submission form. That's where it fell apart:

The free tier's dofollow was conditional. You got it only if your product hit a top-3 daily ranking (which needs a vote campaign), or you embedded their badge on your site — i.e. a reciprocal link exchange, which is a named Google link-scheme pattern, not a free win.
The "guaranteed dofollow" was a paid tier. Buying a dofollow link is, again, squarely against Google's link-scheme guidelines — the last thing you want pointing at a site mid-review.
The free launch slots were exhausted on every available date. The date picker showed "0 free slots" for every day in range. The paid tier's headline perk? "Skip the free queue." The free path wasn't a path; it was a funnel.

The same operator, it turned out, ran several of these under different brand names and emailed me from each. Live listings looked dofollow; the submission was gated behind a condition or a payment.

The lesson upgrade: verify the funnel, not just a listing

Checking an existing listing's rel is necessary but not sufficient. A network can serve genuinely dofollow HTML on its live pages while gating new free submissions behind:

a ranking condition you can't meet without vote-farming,
a reciprocal-badge requirement (link scheme), or
a paid tier (paid link = link scheme).

So the check I run now has two steps:

Listing check (the script above): does an existing outbound link carry a clean rel?
Funnel check (manual, 2 minutes): open the submit form. What tier grants the dofollow? Is the free tier actually available (slots), or zeroed out to push you to pay? Does "free dofollow" require a badge/reciprocal link?

If step 2 says "dofollow only via payment or reciprocity," the answer is no — regardless of what step 1 showed. A paid or reciprocal dofollow isn't just low-value; it's an active risk if Google is looking at your link profile.

Why this matters more than a one-off check

Platform policies drift one-way, and you find out via ranking drops, not announcements: LinkedIn nofollow ~2016, Twitter 2019, Quora 2022, Medium ~2023–2024, GitHub READMEs ~2020. Any pre-2023 SEO guide is potentially wrong about at least one. And the newer directory-spam layer means the claim of dofollow is now marketing copy, not a fact — the fact lives in the rel attribute and the submission funnel.

Two rules I now live by:

Nobody's claim of "dofollow" counts. The rel attribute counts.
An existing listing's rel isn't the offer. The submission tier is the offer — check it.

Steal the pattern

The verifier runs alongside my GSC / GA4 / Bing / PageSpeed fetches — one script, one double-click, all marketing signals in one place. Two changes to fit your setup:

Point $config.siteUrl and $config.knownReferringUrls at your domain + your list.
For 403-heavy platforms, either add retry logic or just report them Unknown (I do the latter — I already know their policies).

If you're a solo founder shipping links across platforms and hoping some count toward SEO: run the listing check weekly, run the funnel check before every submission, and stop being surprised.

I'm Chetan Sanghani, building SmartTaxCalc.in — a free, browser-based Indian tax + finance calculator platform. Previously wrote about Google's MathSolver JSON-LD validator quirks, dropping mobile LCP under 2s on Blazor WASM, and a self-cleaning Product Hunt teaser banner.

Launching SmartTaxCalc on Product Hunt today 🚀

Chetan Sanghani — Sat, 18 Jul 2026 07:43:26 +0000

Just went live on Product Hunt: SmartTaxCalc — 38 free Indian tax + finance calculators

If you've followed my previous writeups on the Blazor WASM + Cloudflare Pages stack, this is the culmination — 38 tools, 30+ blog articles, all client-side, CA-reviewed, no signup, no data collection.

What's live

Live tools: smarttaxcalc.in — free forever, mobile-friendly, works offline once loaded (Blazor WASM caches locally)
PH launch page: producthunt.com/products/smarttaxcalc — upvotes appreciated 🙏

What I learned (5 quick engineering wins from the build)

LCP preload trick — a 5.6 KB JSON at the tail of Blazor's critical chain was costing 5.5s of "element render delay." One <link rel="preload"> in <head> fixed it.
Getting LCP under 2s on Blazor WASM — six mechanical fixes across a weekend, real commit hashes + before/after numbers.
Self-cleaning PH teaser banner in Blazor — 100 lines, auto-hides after launch date via DateTime.UtcNow < KillDateUtc in OnInitialized. No manual removal.
GSC's MathSolver JSON-LD validator is stricter than Schema.org — learned the hard way that "valid according to schema.org" ≠ "valid according to Google's Rich Results validator."
Medium and GitHub both went nofollow — so I built a 40-line PowerShell backlink verifier that curls each referring page + greps for rel="nofollow". Now runs nightly.

The stack

Blazor WebAssembly on Cloudflare Pages (free tier)
Pre-rendered static HTML mirrors for SEO (crawler sees content immediately, Blazor hydrates on top for interactivity)
No backend — every calculation runs client-side in the browser
No signup, no email capture, no data sent to any server
CA-reviewed by an ICAI-registered Chartered Accountant (Ankitkumar Italiya, membership 644575)
91 razor pages, 91 matching static mirrors, title-parity enforced by pre-commit lint

Total spend to date: ~$0 (Cloudflare Pages free tier + a domain).

Ask

If you're a Blazor dev, Indian expat/NRI, or anyone in the CA/tax space — please:

Upvote on Product Hunt if the tool looks useful
Try it at smarttaxcalc.in — 38 calculators to explore
Reply here with feedback on the tech choices — always curious about how others approach Blazor SEO / CWV / SPA deployment

Also: if there's a specific Blazor architectural pattern you want a deep-dive on (like "how to prerender content that Blazor also renders without double-render CLS issues"), drop a comment. Article #7 in the series is TBD.

Thanks for the support 🙏

One cut my Blazor WASM LCP by 500ms — the invisible file at the end of the critical chain

Chetan Sanghani — Fri, 17 Jul 2026 16:19:20 +0000

Two weeks ago I wrote about getting my Blazor WebAssembly site's LCP under 2 seconds. I thought I was done.

I wasn't.

Last week I ran a fresh PageSpeed Insights audit and saw this:

FCP:  0.3s   ✅ Great
LCP:  3.5s   ⚠️ Needs Improvement
TBT:  2,360ms 🔴 Poor

FCP was 0.3 seconds. Something was painted in under a third of a second. So how was LCP 3.5 seconds? What was the browser waiting for?

The "LCP breakdown" panel in PageSpeed had the answer:

Subpart              Duration
Time to first byte   0 ms
Element render delay 5,500 ms

5.5 seconds of "element render delay." Not download time. Not parse time. Not layout. Something was preventing the browser from painting the LCP element for five and a half seconds after it was ready.

Let me walk through the diagnosis and the three-line fix.

The "Network dependency tree" was the smoking gun

PageSpeed Insights has an under-appreciated panel: Network dependency tree. It shows the critical request chain — every resource the browser had to fetch before it could paint the LCP element.

Mine looked like this (edited for brevity):

Maximum critical path latency: 5,464 ms
Initial Navigation
  https://smarttaxcalc.in       169 ms   14.6 KiB
  /js/site-helpers.js          251 ms    8.7 KiB
  /_framework/dotnet.js         642 ms   17.5 KiB
  /_framework/dotnet.runtime… 740 ms   57.7 KiB
  /data/tax-rules.json       5,464 ms    5.6 KiB   ← ??
  /_framework/dotnet.native…    719 ms   37.9 KiB
  /_framework/dotnet.native…wasm  920 ms  1,155.7 KiB
  ... 40 more .wasm files ...

Notice the /data/tax-rules.json line. 5.6 KB. 5,464 ms wall-clock.

That file is tiny. Downloading it should take a few hundred milliseconds max. Why was the wall-clock 5.5 seconds?

Because the browser was fetching it at the end of the chain, after all 43 .wasm assembly files had finished loading.

Why this happens on every Blazor WASM app

Blazor WebAssembly's boot sequence is roughly:

Browser fetches index.html.
Parses <script src="_framework/blazor.webassembly.js"> — starts downloading.
blazor.webassembly.js downloads and starts running.
It fetches blazor.boot.json (the manifest of runtime + your assemblies).
It fetches all the .wasm files in parallel.
It instantiates the runtime.
It starts your Program.cs main.
Your DI container resolves services, including HttpClient.
Your app's initial render kicks off.
Now any HttpClient.GetFromJsonAsync("/data/tax-rules.json") call runs.

Step 10 sits at the end of the wall-clock, waiting for everything above it to finish.

If your app renders content that depends on that JSON — in my case a tax slabs table that's a large above-fold element — LCP does not fire until step 10 completes.

FCP fires much earlier because the pre-rendered static HTML is painted at step 1. But LCP measures the LARGEST content, and Blazor re-paints the largest content only after step 10.

The fix — three lines in `index.html`

The browser has no idea /data/tax-rules.json is on the critical path until Blazor's runtime asks for it. But we can tell it, using a <link rel="preload"> hint at the very top of <head>.

Here's the diff:

<!-- Preload critical assets -->
<link rel="preload" href="_framework/blazor.webassembly.js?v=..." as="script" fetchpriority="high" />

<!-- NEW: Preload tax-rules.json — end of Blazor's critical request chain -->
<link rel="preload" href="data/tax-rules.json" as="fetch" fetchpriority="high" crossorigin />

<link rel="preconnect" href="https://www.googletagmanager.com" crossorigin />

Three attributes matter:

as="fetch" — matches the HttpClient.GetFromJsonAsync() request that will happen later. Without this, the browser preloads it as the wrong type and skips using the cached copy.
fetchpriority="high" — hints that the browser should start this fetch immediately, not wait until the current parse yields.
crossorigin — required for as="fetch" preloads to match a CORS-enabled fetch. Even for same-origin, Blazor's HttpClient sends CORS-mode requests.

Before / after (real numbers, mobile Lighthouse, Slow 4G throttled)

Metric	Before	After	Delta
FCP	0.4s	0.3s	▼25%
LCP	1985ms	1518ms	▼467ms
Element render delay	5,500ms	180ms	▼97%
Network critical path latency	5,464ms	106ms	▼98%
CLS	0	0	same

The 5,500ms element render delay collapsed to 180ms. LCP dropped 467ms on mobile.

Verified a day later via the PageSpeed Insights API in my nightly analytics fetch — the improvement stuck across measurements.

When this pattern applies

Anywhere in your Blazor WASM app you're doing something like:

// Program.cs or a startup component
protected override async Task OnInitializedAsync()
{
    var config = await Http.GetFromJsonAsync<TaxConfig>("data/tax-rules.json");
    // ...
}

If that JSON blocks the first meaningful render (i.e., the LCP element depends on it), preload it in <head>. The file can be:

A JSON config file
A CSV/TSV data file
A pre-computed lookup table
Any other static resource under wwwroot/ that Blazor fetches during boot

If the file is under 20 KB it costs nothing to preload. If it's larger, weigh the bandwidth cost against the LCP win.

The trap I fell into first — assuming Blazor boot was fixed cost

I spent months blaming Blazor for slow LCP. Every diagnosis started with "Blazor WASM is inherently 3-4 seconds to boot."

That's true in the aggregate. But the aggregate hid the fact that one specific 5.6 KB file was sitting at the tail of the chain, single-handedly adding 3+ seconds to my perceived boot time.

If I'd read the "Network dependency tree" panel two months earlier, I would have shipped this fix in October.

Look at that panel first. Every time.

Anti-pattern — don't preload everything

You get one or two "high priority" preload slots that meaningfully move the needle. If you preload every static asset:

The browser can't prioritise the truly critical ones.
Bandwidth for blazor.boot.json (which is the actual entry point) gets contended.
Lighthouse will flag "Unused preload" audits.

Rule of thumb: preload only resources that would otherwise be at the end of the critical chain — meaning Blazor's runtime asks for them AFTER everything else is done.

Bonus lessons from the same optimization pass

While I was at it, I also tried:

Enabling <RunAOTCompilation>true</RunAOTCompilation> — Cloudflare Pages CI build failed silently ("No deployment available"). Turns out the CI environment ships the base .NET SDK without the wasm-tools workload, and dotnet workload restore in a MSBuild target doesn't pull the emcc + binaryen native binaries. Reverted the same night. If you're on GitHub Actions with proper toolchain, this is worth trying.
Deferring Google Analytics until first user interaction — moved 275ms of gtag.js main-thread evaluation out of Lighthouse's measurement window. TBT dropped ~500ms. Real users still get tracked as soon as they interact.
Disabling Cloudflare Web Analytics beacon — 11 KB + 17ms main thread. Redundant if you already use GA4. Toggle it off in the Cloudflare dashboard under Analytics → Web Analytics.

Combined with the preload fix, my mobile Performance score went from 47 (desktop) → 73 (mobile) with mobile LCP firmly in the "Good" range.

Desktop LCP is still 3.5s though, and that's a longer story — Blazor SPAs replace pre-rendered content on wider viewports differently. That'll be article #6.

If you're on Blazor WebAssembly and your LCP feels stuck, open PageSpeed Insights, scroll to the Network dependency tree, and look at the last line. There's probably a 5 KB file sitting there costing you seconds.

The site: smarttaxcalc.in — a free Indian tax + finance calculator platform. 38 tools, CA-reviewed, all Blazor WebAssembly.

Medium and GitHub both went nofollow — so I built a 40-line PowerShell backlink verifier

Chetan Sanghani — Thu, 09 Jul 2026 17:17:00 +0000

I burned about 30 minutes of work on Monday shipping content to Medium and GitHub in the belief they'd give me dofollow backlinks. Both turned out to be platform-wide nofollow. Both discoveries came from a single curl command that I should have run before the work, not after.

This post is: (1) the two discoveries and why the standard SEO guidance is now stale, (2) the 40-line PowerShell verifier I wrote so I never make the mistake again, and (3) the specific header dance you need to actually get past bot-detection on Medium and Quora.

What "dofollow" means, and why it moves

Every <a href="..."> on the web is either dofollow or nofollow. Google (and other search engines) treats them very differently:

Dofollow (rel doesn't contain nofollow / ugc / sponsored): the source domain vouches for the destination. Passes SEO "link equity." Counts toward how Google decides the destination's ranking authority.
Nofollow / UGC / Sponsored: the source domain explicitly declines to vouch. Google largely discounts these for ranking purposes. Still useful for referral traffic and brand exposure, but doesn't move the SEO needle.

For an AdSense-approval situation like mine — where reviewers look at "does this site have external validation from real sources" — dofollow domains matter. Nofollow domains are decorative.

Now the catch: platforms shift policies. What was dofollow in 2020 may be nofollow today, and cached SEO guides from a few years back get you the outdated answer.

Discovery 1: Medium is now `ugc nofollow`

I republished a Section 24(b) home-loan article on Medium, expecting the author-bio + in-article links to be dofollow (per most SEO guides from 2020-2022). Curl'd the live article:

curl -sL "https://medium.com/@author/article-slug" `
  -A "Mozilla/5.0" | Select-String -Pattern 'smarttaxcalc'

Result on every anchor:

<a class="z rm" href="https://smarttaxcalc.in/..." rel="noopener ugc nofollow" target="_blank">

That rel="noopener ugc nofollow" is Medium's current default — they rolled it out platform-wide around 2023-2024 to kill SEO spam. Every outbound link on Medium is now nofollow, including your author-bio link. Google discounts them all.

Discovery 2: GitHub READMEs are nofollow too — even in your own fork

Same day, I forked an "awesome-personal-finance" repo, added SmartTaxCalc to the list, and pushed. Standard SEO advice says: "even if the PR isn't merged, your fork at github.com/YOUR-USER/awesome-XXX/README.md still has the anchor to your site — that's a dofollow link from github.com."

Wrong, at least since ~2020. Curl the rendered README:

<a href="https://mint.intuit.com/" rel="nofollow">Mint</a>
<a href="https://smarttaxcalc.in" rel="nofollow">SmartTaxCalc</a>

Every external anchor on any GitHub-rendered README is rel="nofollow". GitHub applies this platform-wide to reduce link-farming via repo forks. Even Mint on the upstream repo (a heavily authoritative domain in the fintech space) is nofollow. There's nothing you can do to force it dofollow.

Both discoveries invalidated ~30 minutes of preparation work in the same afternoon. The Medium article was still worth publishing (referral traffic + canonical protection so Medium doesn't outrank the original), but I wouldn't have spent time on the GitHub PR pack if I'd known.

The lesson: curl before you write

Both would have been caught by a 30-second check before the work: fetch any existing outbound link on the target platform, look at its rel attribute. If it contains nofollow, that's the platform's blanket policy — no author, no article, no PR can override it.

But I don't want to remember to do this manually every time. So I wrote it into my weekly analytics script. Every Sunday, along with GSC/GA4/Bing exports, the script now curls every referring URL I care about and reports which anchors are dofollow vs nofollow.

The verifier — 40 lines of PowerShell

The core loop, minus try/catch scaffolding:

$siteHost = ([Uri]$config.siteUrl).Host   # e.g. "smarttaxcalc.in"

foreach ($src in $config.knownReferringUrls) {
    $resp = Invoke-WebRequest -Uri $src -UseBasicParsing -TimeoutSec 20 `
        -Headers $browserHeaders   # see next section for the header set

    # Match every anchor pointing to our host
    $pattern = '<a[^>]*href="[^"]*' + [regex]::Escape($siteHost) + '[^"]*"[^>]*>'
    $anchors = [regex]::Matches($resp.Content, $pattern,
                [System.Text.RegularExpressions.RegexOptions]::IgnoreCase)

    foreach ($m in $anchors) {
        $tag = $m.Value
        $rel = if ($tag -match 'rel="([^"]*)"') { $Matches[1] } else { '' }

        # Dofollow = no nofollow, no ugc, no sponsored in rel.
        # rel="noopener noreferrer" is fine — it's a security attribute, not SEO.
        $isDofollow = -not ($rel.ToLower() -match '\b(nofollow|ugc|sponsored)\b')

        [pscustomobject]@{
            sourceUrl  = $src
            rel        = $rel
            isDofollow = $isDofollow
        }
    }
    Start-Sleep -Milliseconds 500   # polite pause between hosts
}

config.knownReferringUrls is just a list of URLs where you've published or shared a link back to your site — Medium article URLs, Quora answer URLs, Dev.to posts, forum posts, whatever.

Output goes into a CSV (backlink-rel-verification.csv) and — this is where it stops being just a report — feeds a scorecard row in my weekly insights.md:

| Dofollow referring domains | 1 | ≥ 5 | 🔴 |

If Medium ever does switch back to dofollow (unlikely), or a new post I published turns out to be a hidden dofollow win, I'll see it in Sunday's report without doing anything. Same in reverse: if a platform I currently count as dofollow shifts to nofollow silently, the scorecard row updates.

The header dance for Medium and Quora

The naive Invoke-WebRequest -Uri $url -UseBasicParsing gets 403'd immediately on Medium, Quora, and any Cloudflare-fronted site. Even adding -UserAgent 'Mozilla/5.0' isn't enough — they check other headers too.

This is the header set that gets me through most sites:

$browserHeaders = @{
    'User-Agent'                = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36'
    'Accept'                    = 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8'
    'Accept-Language'           = 'en-US,en;q=0.9'
    'Accept-Encoding'           = 'gzip, deflate, br'
    'Sec-Ch-Ua'                 = '"Chromium";v="121", "Not A(Brand";v="99"'
    'Sec-Ch-Ua-Mobile'          = '?0'
    'Sec-Ch-Ua-Platform'        = '"Windows"'
    'Sec-Fetch-Dest'            = 'document'
    'Sec-Fetch-Mode'            = 'navigate'
    'Sec-Fetch-Site'            = 'none'
    'Sec-Fetch-User'            = '?1'
    'Upgrade-Insecure-Requests' = '1'
}

The Sec-Ch-Ua* and Sec-Fetch-* headers are what Chrome sends automatically that a bare HTTP client doesn't. Without them, Cloudflare's bot detection has a very high true-positive rate on your requests.

Even with the full set, Medium and Quora still block on my Windows box — probably a TLS fingerprint check that Invoke-WebRequest can't spoof (curl.exe fails the same way). For those, the verifier reports ❓ Unknown (fetch blocked) rather than misclassifying as nofollow. When it can't confirm, it says so.

What the scorecard actually shows

Running against 6 known referring URLs — 3 Dev.to articles, 1 Medium republish, 1 GitHub Awesome-List fork, 1 Quora answer:

| Source     | Rel                     | Dofollow?               |
|------------|-------------------------|-------------------------|
| dev.to     | noopener noreferrer     | ✅ Yes (x10 anchors)    |
| medium.com | (fetch blocked 403)     | ❓ Unknown              |
| github.com | nofollow                | ❌ No                   |
| quora.com  | (fetch blocked 403)     | ❓ Unknown              |

Unique dofollow referring domains: 1 (dev.to). Both Medium and GitHub, which I thought would boost this count to 3, contribute zero. The Quora and Medium fetch blocks aren't a huge loss — I already know from a prior manual curl (on a Linux box with a different TLS fingerprint) that both are nofollow.

Why this matters more than a one-off check

Two reasons.

One: platform policies drift, and you find out via ranking drops rather than an announcement. LinkedIn made outbound links nofollow around 2016. Twitter went nofollow in 2019. Medium moved to ugc nofollow around 2023-2024. Quora went nofollow-by-default in 2022. GitHub went nofollow on README external links around 2020. The pattern is one-way — platforms don't go back to dofollow. Any pre-2023 SEO guide you're reading is potentially wrong about at least one of these.

Two: if you publish enough content across enough platforms, you lose track. I have 3 Dev.to articles, 2 Quora answers, 34 LinkedIn Company Page posts, 1 Medium republish, and 1 GitHub fork. Manually curling each one every Sunday to check the rel attribute is real work. Encoding it into the analytics script — 40 lines of PowerShell — means it becomes a green/red row on the weekly report, and I only pay attention when something changes.

Steal the pattern

The full script lives in SmartTaxCalc's analytics folder (search for BACKLINK REL-ATTRIBUTE VERIFIER). It runs alongside GSC / GA4 / Bing / PageSpeed fetches — one script, one double-click, all your marketing signals in one place.

Two changes to make it fit your setup:

Change $config.siteUrl and $config.knownReferringUrls to your domain + your list
Depending on your platform mix, you might want to add retry logic for the 403-heavy platforms — I chose to just report them as Unknown because I already know their policies

If you're an indie hacker or solo founder shipping content to multiple platforms and hoping some of them count toward your SEO signal, run this once a week and stop being surprised.

A self-cleaning Product Hunt teaser banner in Blazor WASM — 100 lines, auto-hides after launch, GA4-tracked

Chetan Sanghani — Mon, 06 Jul 2026 15:47:16 +0000

I'm launching SmartTaxCalc.in on Product Hunt on Tuesday, 14 July 2026. It's a 38-tool Blazor WebAssembly tax + finance calculator I've written about here before (the SEO/schema saga, and dropping mobile LCP from 6-8s to under 2s).

The Product Hunt launch algorithm heavily rewards products that arrive with a real coming-soon follower base — day-of upvotes correlate strongly with pre-launch "Notify me" clicks. My PH page started with 1 follower. I had 9 days to get to 50+.

The obvious answer: post on LinkedIn, ask friends, DM your network. All of that has ceilings (you can only ask a favor once). The non-obvious answer that has no ceiling: convert your own organic search traffic into PH followers automatically.

This is the ~100 lines of Blazor code that does that, plus the design decisions I made along the way. It's also self-cleaning — after the launch date, the banner disappears with no manual work required. Steal the pattern for your own launch.

The problem

SmartTaxCalc gets modest but real organic traffic — mostly from Google Search Console impressions on tax-season queries. That traffic is the warmest possible audience for a PH launch (they already found the site, they're in the target demo). But how do you route them to a PH page without:

Disrupting the tax content (they came for a tax calculator, not a marketing pitch)
Cannibalizing the existing tax-season banner (which drives users to /tax-calendar/ — a real retention lever)
Leaving code debt after 14 July (a dead PH banner still on the site in September)
Losing the dismiss preference across page navigations (SPA reality — no page refresh)

Those constraints ruled out a modal, a full-width interrupt, and a "hardcoded remove after launch" approach.

The design

Slim horizontal bar at the top of every page. Sits ABOVE the existing tax-season banner. PH-brand orange, different from the tax-season banner's yellow/red so both are visually distinguishable when stacked. Dismissible per-user via localStorage. Auto-hides after a hard kill date. GA4 events on click + dismiss for measurement.

Structurally, it mirrors the existing TaxSeasonBanner.razor conventions (same DOM shape, same a11y attributes) so the two components have consistent tab-order and screen-reader behavior when both are visible.

The component

Shared/ProductHuntTeaserBanner.razor:

@inject IJSRuntime JS

@if (Visible && !Dismissed)
{
    <aside class="ph-teaser-banner" role="complementary"
           aria-label="Product Hunt launch teaser">
        <div class="ph-teaser-banner-content">
            <span class="ph-teaser-banner-icon" aria-hidden="true">🚀</span>
            <span class="ph-teaser-banner-text">
                <strong>Launching on Product Hunt Tue 14 July</strong>
                <span class="ph-teaser-banner-sub">Follow to get notified when we go live.</span>
            </span>
            <a class="ph-teaser-banner-cta"
               href="https://www.producthunt.com/products/smarttaxcalc"
               target="_blank"
               rel="noopener"
               @onclick="OnCtaClicked">
                Notify me on PH →
            </a>
            <button class="ph-teaser-banner-close"
                    @onclick="OnDismissClicked"
                    aria-label="Dismiss Product Hunt teaser"
                    type="button">&times;</button>
        </div>
    </aside>
}

@code {
    // Kill date: banner stops showing after this instant regardless of dismissal state.
    // 2026-07-14 23:59 IST = 18:29 UTC — one full day AFTER launch so day-of visitors
    // see it, but 07-15 onwards is clean.
    private static readonly DateTime KillDateUtc =
        new DateTime(2026, 7, 14, 18, 29, 0, DateTimeKind.Utc);

    private const string DismissKey = "ph-teaser-dismissed-2026-07-14";

    private bool Visible;
    private bool Dismissed;

    protected override void OnInitialized()
    {
        // Server-side timing gate. If we're past the kill date, don't render at all —
        // no localStorage check needed, no re-render churn, no bytes shipped.
        Visible = DateTime.UtcNow < KillDateUtc;
    }

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender && Visible)
        {
            try
            {
                var dismissed = await JS.InvokeAsync<string?>(
                    "localStorage.getItem", DismissKey);
                if (dismissed == "1")
                {
                    Dismissed = true;
                    StateHasChanged();
                }
            }
            catch
            {
                // localStorage unavailable (private mode, edge cases) — banner just shows.
                // Failing "open" is better than failing "hidden" for a follower-growth tool.
            }
        }
    }

    private async Task OnCtaClicked()
    {
        try
        {
            await JS.InvokeVoidAsync("trackEvent", "ph_teaser_cta_clicked",
                new { launch = "2026-07-14" });
        }
        catch { }
    }

    private async Task OnDismissClicked()
    {
        Dismissed = true;
        try
        {
            await JS.InvokeVoidAsync("localStorage.setItem", DismissKey, "1");
            await JS.InvokeVoidAsync("trackEvent", "ph_teaser_dismissed",
                new { launch = "2026-07-14" });
        }
        catch { }
        StateHasChanged();
    }
}

That's the whole thing. About 90 lines of C# + Razor including comments and whitespace.

Design decisions worth calling out

Kill-date is server-side, dismiss is client-side

The OnInitialized gate runs in Blazor's render tree before any HTML is emitted. After 2026-07-14 18:29 UTC, the whole <aside> never renders — no wasted bytes, no dead DOM, no need for the JS to check anything.

The dismiss check has to be client-side because it depends on the user's localStorage. So it lives in OnAfterRenderAsync and updates via StateHasChanged if the user previously dismissed.

This split matters. If I'd tried to do the kill-date check client-side too, I'd have shipped the banner HTML to every user post-launch, then hidden it with JS — wasteful and briefly visible during hydration. Server-side gate is free.

localStorage key is versioned by launch

private const string DismissKey = "ph-teaser-dismissed-2026-07-14";

The -2026-07-14 suffix means my next PH launch (if I do a re-launch or feature launch later) uses a different key — users who dismissed the July teaser will still see the future teaser. No dismiss-forever bug.

Failing open, not closed

The try/catch around localStorage.getItem:

catch
{
    // localStorage unavailable (private mode, edge cases) — banner just shows.
}

If localStorage throws (Safari private mode, ITP restrictions, some enterprise browsers), we DON'T hide the banner — we show it. For a follower-growth tool, false-positive display beats false-negative hiding.

Kill date uses UTC everywhere

The Cloudflare Pages server runs in UTC. The user's browser could be in any timezone. Blazor WASM runs in the browser but I'm doing the check at component initialization which happens after WASM boots — timezone at that point depends on how Blazor was invoked. Sticking with DateTime.UtcNow + a UTC kill-date instant sidesteps every possible drift.

The CSS — matching existing patterns

.ph-teaser-banner {
    background: linear-gradient(135deg, #ff6b35, #da552f);  /* PH brand orange */
    color: #ffffff;
    padding: 0.5rem 1rem;
    font-size: 0.9rem;
    line-height: 1.35;
    border-bottom: 1px solid rgba(255, 255, 255, 0.15);
}
.ph-teaser-banner-content {
    max-width: 1200px;
    margin: 0 auto;
    display: flex;
    align-items: center;
    gap: 0.75rem;
    flex-wrap: wrap;
}
.ph-teaser-banner-cta {
    background: rgba(255, 255, 255, 0.15);
    color: #ffffff;
    font-weight: 700;
    padding: 0.35rem 0.75rem;
    border-radius: 4px;
    border: 1px solid rgba(255, 255, 255, 0.35);
    min-height: 32px;
    display: inline-flex;
    align-items: center;
}
.ph-teaser-banner-close {
    background: transparent;
    border: 0;
    color: inherit;
    font-size: 1.5rem;
    cursor: pointer;
    padding: 0 0.25rem;
    opacity: 0.75;
    min-width: 32px;
    min-height: 32px;
}
.dark-mode .ph-teaser-banner {
    background: linear-gradient(135deg, #c94820, #a83a1b);
}

Two things worth noting:

32×32 minimum touch targets on the CTA and dismiss button (WCAG 2.5.5 — Success Criterion for touch target size). This is easy to forget on slim horizontal bars where the visual height is smaller. The button padding + min-height: 32px guarantees the tap area meets the standard.

Dark-mode variant because SmartTaxCalc has a full dark-mode toggle. Any new component that ships without a .dark-mode .foo variant looks jarring for the ~30% of users on dark mode.

Wiring into layout

Layout/MainLayout.razor — one line, above the existing tax-season banner:

<header class="app-header">...</header>

@* PH launch teaser — active 2026-07-05 → 2026-07-14 EOD IST *@
<ProductHuntTeaserBanner />

@* Tax-season-aware banner — May-Jul ITR, Dec advance tax, Mar year-end *@
<TaxSeasonBanner />

<main class="main-content">
    @Body
</main>

Stacking order matters. PH banner is time-critical (9-day window), tax banner is a permanent retention CTA. Time-critical goes on top.

The cache-buster gotcha

Cloudflare Pages caches CSS aggressively. Deploying the new CSS with the same filename means returning users don't see the new styles until their browser cache expires (often hours or days).

Every CSS/JS reference on the site uses a query-string version:

<link href="/css/app.css?v=20260705a" rel="stylesheet" fetchpriority="high" />
<link rel="preload" href="/_framework/blazor.webassembly.js?v=20260620j" as="script" />

On any deploy that ships new CSS, bump the v= string. I ran this one-liner to update every static HTML file in the wwwroot mirror:

perl -i -pe 's|app\.css\?v=20260703a|app.css?v=20260705a|g' `
  $(grep -rlE 'app\.css\?v=20260703a' frontend/web/TaxPlanner.Web/wwwroot/)

Skipping this step meant users on returning-visit cache would see the banner in DOM (Blazor renders it) but with no styles — invisible text/button on a normal background. Nothing worse than a launch banner that only works for first-visit users.

The telemetry

Two GA4 events I care about:

ph_teaser_cta_clicked — fires when the user clicks "Notify me". This is the metric that matters. It correlates directly with PH follower growth.
ph_teaser_dismissed — fires when the user clicks the ×. If this is >30% of impressions, the banner is annoying and I should tune it.

I don't track banner impressions separately — Blazor renders it if OnInitialized allows AND the user hasn't dismissed. Impression count = pageview count from GA4 minus ph_teaser_dismissed count minus post-kill-date pageviews.

Realistic conversion math

Here's the funnel math I set targets against:

Daily organic pageviews on SmartTaxCalc: ~50-80 (Indian tax queries)
Percent of pageviews that click Notify me: 2-5% (informed guess; will measure)
Expected daily new followers: 1-4 from the banner alone
Nine days of banner active pre-launch: 9-36 followers
Combined with LinkedIn + personal DMs: target 50+

50 pre-launch followers is the informal PH threshold for "you have a shot at Top 20 of the day." Below 20 and the launch is dead on arrival. Above 100 and you're guaranteed Top 10 barring a bad launch-day thumbnail.

What I skipped

Modal/interrupt version: kills UX for the tax content (users came for a calculator, not a launch pitch)
Cookie banner-style at page bottom: lower click-through, competes visually with the actual cookie consent banner
Homepage-only version: 60% of my traffic lands on deep pages (calculator URLs from Google), not the homepage
Manual removal after launch: not scalable if I do another launch later — kill-date automates the "remove" step

Two takeaways

1. Time-bounded UI needs a self-cleaning mechanism from day one. Every "temporary" banner I've seen without a kill date has ended up living on production long past its usefulness. The kill-date constant is 3 lines of code and saves you a manual removal PR.

2. Convert your own traffic before you buy other people's. LinkedIn ads, PH-influencer shoutouts, upvote-swap groups — all lower conversion than your own site visitors who already trust you. If you're launching anything, this component (or the equivalent in your stack) is the highest-leverage growth code you can ship.

The launch itself

If you use tax calculators or you're a founder / indie hacker who wants to follow the launch curve, click Notify me on our PH page. Launch is Tuesday 14 July 2026 at 12:01 AM PDT (12:31 PM IST).

If this banner pattern is useful, feel free to lift it. Blazor + Razor + a few lines of CSS is all it takes.

About me: I'm Chetan Sanghani — I build SmartTaxCalc, a free CA-reviewed Indian tax calculator platform. This is my third article on Dev.to in the "Building SmartTaxCalc" series. Previous posts:

How I got LCP under 2s on a 38-page Blazor WebAssembly site (Cloudflare Pages)

Chetan Sanghani — Sat, 04 Jul 2026 11:06:06 +0000

I run SmartTaxCalc.in — a free Indian tax calculator platform built as a Blazor WebAssembly SPA on Cloudflare Pages. 38 tools, 20+ blog articles, all client-side. Very static, very cheap to host, easy to iterate.

For the first several months, mobile Largest Contentful Paint (LCP) was 6-8 seconds. That's failing Core Web Vitals by a mile. Every Lighthouse run screamed at me. And every SEO agency told me the same three things:

"It's Blazor. It's slow. Rewrite in Next.js."

Yeah, no. I like Blazor. I've shipped .NET for a decade. I don't want to rewrite for the sake of a Lighthouse score.

So over one weekend I ran a proper performance pass. Six mechanical fixes, six commits, mostly one-liners. By the end of it, mobile LCP was under 2 seconds — well inside the "Good" threshold — on every measured page.

Here's exactly what worked. Real commit hashes, real numbers, and honest notes on what didn't help.

The setup — what "LCP on Blazor WASM" actually means

Blazor WebAssembly is a Single Page Application. The initial HTML is a small shell (index.html) with a <base href="/">, some CSS <link> tags, and a <script src="_framework/blazor.webassembly.js">. That JavaScript downloads the .NET runtime, your app DLLs, and boots the Blazor renderer, which then constructs the DOM.

LCP is measured on the largest content element rendered above the fold. On a fresh Blazor site, that element usually doesn't exist until Blazor finishes booting and renders your first component. So "LCP" and "time-to-Blazor-hydrated" tend to be the same thing.

That said — a well-architected Blazor site with static HTML mirrors (pre-rendered content) can have LCP fire on the static content BEFORE Blazor hydrates, using Blazor purely for interactivity. That's the model my site uses.

So the LCP battle here is really a "get the browser to render the largest text/image element as fast as possible" battle. Blazor still boots, but LCP doesn't wait for it.

Before numbers — Lighthouse mobile, throttled 4G, Moto G4 CPU

Page	Mobile LCP (before)
Homepage	~6.2s
Tax calculator (deep interactive page)	~7.8s
Blog article (mostly static content)	~5.9s

The 6-8s range is what you get when you serve unminified CSS, ship a service worker that races the main thread, and don't preconnect to your CDN edges.

Fix 1: Delete the service worker (commit `910c606`)

The counter-intuitive one.

I originally shipped a service worker in June 2026 to fix a different bug (stale HTML cache after a build-tool migration). The SW's activate handler would detect its own version, unregister itself, and clear all caches. It was a one-time cleanup for existing users who were pinned to the old broken cache.

Two weeks later, every recurring visitor had had that cleanup fire. New visitors didn't need a service worker at all — but I was still registering one on every page load.

// Before — every page did this
if ('serviceWorker' in navigator && location.hostname !== 'localhost') {
    navigator.serviceWorker.register('/service-worker.js?v=cleanup-20260613', {
        updateViaCache: 'none'
    }).catch(function () {});
}

Removing that block saved:

One network request (/service-worker.js)
~50-100ms of post-load main-thread work as the browser evaluates the SW script
One CPU spike that competed with Blazor's own boot

Impact: ~200ms LCP win.

I left the service-worker.js file in wwwroot for now — old bookmarks that had registered the SW will still fetch it and run the self-unregister logic. That's a slow-decay migration, safe to leave.

Fix 2: Removed a version-check IIFE that force-reloaded users (commit `910c606`)

This one hurt when I found it.

Buried in index.html was a small self-invoking function that read a version field from /version.json, compared it to a value stored in localStorage, and if they mismatched, called location.reload(true) — a hard reload.

The intent was noble: force existing users to fetch new HTML after each deploy so they'd never see stale content. But the effect on a first-visit user was:

Browser fetches index.html
Browser starts parsing → hits the IIFE
IIFE fetches /version.json
IIFE reads localStorage, finds no version stored → sets oldVersion = null
IIFE sees null !== '20260620j' → calls location.reload(true)
Browser tears down the entire page and starts over. LCP timer resets.

The first-visit user was silently reloading their own page before LCP could fire. Which meant their LCP was measured on the SECOND load, but the timer count-up started from the FIRST navigation. Result: catastrophic LCP.

Deleted the IIFE entirely. LCP-first-visit dropped by an estimated 2 seconds.

Impact: ~2000ms LCP win on first visits.

Fix 3: Preconnect coverage on 7 pages that were missing (commit `910c606`)

<link rel="preconnect"> and <link rel="dns-prefetch"> don't do anything visible, but on a slow mobile connection they save hundreds of milliseconds by opening DNS + TCP + TLS connections to third-party origins BEFORE the browser actually needs them.

I had preconnect hints on the homepage and some tools, but 7 static HTML mirrors were missing them entirely. Namely:

<link rel="preconnect" href="https://www.googletagmanager.com" crossorigin>
<link rel="preconnect" href="https://pagead2.googlesyndication.com" crossorigin>
<link rel="dns-prefetch" href="https://adservice.google.com">
<link rel="dns-prefetch" href="https://ep1.adtrafficquality.google">

These are the origins my site talks to for analytics + AdSense (site-wide). Without preconnect, the browser has to do the DNS lookup + TCP handshake + TLS negotiation only when the first request to those origins fires — which is AFTER my HTML is fully parsed.

With preconnect, those handshakes happen IN PARALLEL with HTML parsing. On a 4G mobile connection, that's ~300-500ms saved.

Added the four preconnect/dns-prefetch lines to every static HTML mirror. Nothing fancy.

Impact: ~300ms LCP win on cold pageviews.

Fix 4: Cache-buster pattern for CSS/JS (commit `a9255e8`)

Not a direct LCP fix, but a prerequisite for all the others actually reaching users.

If your CSS is at /css/app.css and you update it, browsers and CDN edges will keep serving the old content — because /css/app.css is the same URL as yesterday. Cache poisoning.

Standard fix: append a version query string that changes on every deploy: /css/app.css?v=20260703a. When the version changes, the URL changes, and every cache treats it as a new resource.

Baked this into every HTML mirror:

<link rel="preload" as="style" href="/css/app.css?v=20260703a" fetchpriority="high" />
<link href="/css/app.css?v=20260703a" rel="stylesheet" fetchpriority="high" />
<link rel="preload" href="/_framework/blazor.webassembly.js?v=20260620j" as="script" />

Also added fetchpriority="high" on the CSS <link> — a browser hint that tells Chrome to prioritize this request over async scripts.

Impact: without this, none of the other CSS/JS fixes would deploy reliably. LCP win: indirect but load-bearing.

Fix 5: Cloudflare Brotli edge compression

This one you don't code — you enable it in the Cloudflare dashboard. But it's the biggest single win of the six.

My app.css is 131KB raw. That's not small. GZIP compresses it to ~40KB on the wire (typical text ratio 3:1). Brotli — Cloudflare's default compression for modern browsers — takes it to ~24KB (ratio 5.5:1).

For a slow 4G mobile connection at 1 Mbps effective throughput:

131KB raw = ~1050ms transfer time
40KB gzip = ~320ms transfer time
24KB brotli = ~192ms transfer time

That's a ~700ms LCP win on the render-blocking CSS alone. FREE. Just toggle Brotli in Cloudflare Speed → Optimization.

If you're on Cloudflare and Brotli isn't on, this is your fastest-possible perf win. Zero code changes.

Impact: ~700ms LCP win.

Fix 6: Blazor WASM bundle size — `PublishTrimmed` + linking + InvariantGlobalization

The .NET runtime + your app DLLs downloaded on first visit is normally 3-5MB of WASM. That's a lot for a mobile connection. Three project-file switches shrink it significantly:

<PropertyGroup>
  <PublishTrimmed>true</PublishTrimmed>
  <BlazorWebAssemblyEnableLinking>true</BlazorWebAssemblyEnableLinking>
  <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>

PublishTrimmed — .NET's IL linker strips unused types. Removes everything from mscorlib you're not calling. Typically 50-70% size reduction.
BlazorWebAssemblyEnableLinking — same idea but Blazor-specific.
InvariantGlobalization — removes the ICU globalization data (~1.5MB). Only viable if you don't need locale-aware string formatting. For a tax calculator that runs in one language, safe.

Combined effect on my site: Blazor bundle dropped from ~5MB to ~1.8MB. That's a big deal on first-visit mobile.

Note: this doesn't affect LCP directly IF your static HTML already renders the content (which mine does). But it dramatically speeds up time-to-interactive, which affects INP (Interaction to Next Paint) — the other Core Web Vital.

Impact: 200-400ms INP win + faster hydration.

After numbers — Lighthouse mobile, same throttling profile

Page	LCP (before)	LCP (after)	Delta
Homepage	6.2s	1.84s	-4.36s
Currency converter	7.1s	1.21s	-5.89s
Salary tax guide	5.9s	1.56s	-4.34s
Tax calendar	5.5s	1.55s	-3.95s
HRA calculator	7.4s	1.54s	-5.86s

Every measured page is now under the 2.5s "Good" LCP threshold. Most are under 2s.

The homepage cut ~4.4 seconds from real user-facing render time with 6 commits of mechanical work. No framework rewrite. Blazor is still Blazor.

What did NOT help (I'm being honest)

Not everything I tried worked. Skip these:

Minifying CSS manually. Cloudflare's Brotli already compresses better than any hand-minifier. Diminishing returns.
Lazy-loading below-fold sections with content-visibility: auto. Improved paint but caused CLS (layout shifts) that hurt the CLS Core Web Vital more than the LCP improvement helped.
Removing Google Analytics 4. Yes, GA4 slows things down. No, removing it is not viable for a site that needs to measure user behavior. Async loading is enough — the perf cost is real but small (~50-100ms), and the observability win is huge.
Custom preloading of individual DLLs. Blazor's default boot flow is already tuned. My hand-crafted preloads made things worse.

Two takeaways for anyone doing this

1. Delete more than you add. My biggest wins were removing things — service workers, version-check IIFEs, unused globalization data. Every one of those was "added carefully to fix a specific bug last month" and had turned into dead weight. Audit your legacy carefully.

2. The CDN dashboard is code. Toggling Brotli in Cloudflare beat every code-level optimization I did. Don't skip the "settings you can change without deploying" — they're often the fastest win.

Result

Site: smarttaxcalc.in — free Indian income tax calculator, 38 tools, Blazor WASM on Cloudflare Pages.

Mobile Core Web Vitals: all Good.

Framework: unchanged. Still Blazor.

Total code changed: ~15 lines across 6 commits.

If you're on Blazor WASM and hitting the "just rewrite it" wall from external advice, try the six mechanical fixes above first. Most of them are one-line changes. Blazor is faster than it gets credit for — you just need to stop actively slowing it down.

About me: I'm Chetan Sanghani — I build SmartTaxCalc, a free CA-reviewed Indian tax calculator platform. I write about frontend performance, SEO for JavaScript apps, and building small-team B2C products on .NET. Previous article: Google's MathSolver JSON-LD validator is stricter than schema.org — I learned that the hard way over 4 rejections.

Google's MathSolver JSON-LD validator is stricter than schema.org. I learned that the hard way over 4 rounds of fixes.

Chetan Sanghani — Thu, 02 Jul 2026 16:10:46 +0000

Last week, Google Search Console flagged 10 pages on my Indian tax calculator suite with structured-data errors:

Missing field usageInfo — 10 items
Invalid value in field itemtype — 10 items

The pages all had MathSolver JSON-LD blocks. I had 38 similar blocks across the site. The natural assumption: I made a schema mistake once, and it propagated to all 38 tools.

Four commits and 76 files later, I discovered the real problem — and it wasn't a schema mistake at all.

Here's the full journey, with commit hashes, so you can skip the six hours I spent.

Setup: what the schema looked like

For context, SmartTaxCalc.in is a suite of 38 free Indian tax calculators (HRA, Advance Tax, NRI residency, DTAA, RSU vesting, etc.). Every tool page had a MathSolver JSON-LD block that looked roughly like this:

{
  "@context": "https://schema.org",
  "@type": "MathSolver",
  "name": "Fixed Deposit (FD) Calculator",
  "url": "https://smarttaxcalc.in/tools/fd-calculator/",
  "mathExpression": "maturity = principal * (1 + rate/(4*100))^(4*tenure_years)",
  "isAccessibleForFree": true,
  "inLanguage": "en-IN",
  "mainEntityOfPage": "https://smarttaxcalc.in/tools/fd-calculator/",
  "publisher": {
    "@type": "Organization",
    "name": "SmartTaxCalc",
    "url": "https://smarttaxcalc.in"
  },
  "reviewedBy": {
    "@type": "Person",
    "name": "CA Ankitkumar Italiya",
    "identifier": "ICAI:644575",
    "url": "https://smarttaxcalc.in/reviewer/ankitkumar-italiya/"
  },
  "citation": {
    "@type": "Legislation",
    "name": "Section 80C and Section 194A of the Income Tax Act, 1961",
    "legislationJurisdiction": {
      "@type": "Country",
      "name": "India"
    }
  },
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "Applicable Regime", "value": "Both regimes" },
    { "@type": "PropertyValue", "name": "Applicable AYs", "value": "All AYs" }
  ]
}

Every field maps to a valid schema.org property. citation on CreativeWork (which MathSolver inherits from) legitimately accepts Legislation or CreativeWork. additionalProperty is PropertyValue. spatialCoverage/legislationJurisdiction on Country — all valid per schema.org's own docs.

But Google's validator disagreed.

Round 1: Fix the obvious (commit `32d1a24`)

Hypothesis: The GSC error strings gave me two things to fix.

For "Missing field usageInfo" — Google's MathSolver docs mark usageInfo as required. I hadn't included it. Easy fix:

+  "usageInfo": "https://smarttaxcalc.in/methodology/",

For "Invalid value in field itemtype" — I assumed the citation.@type: Legislation was the problem. Legislation is more specific than CreativeWork; maybe Google's rich-result validator only accepts the broader type in citation slots.

   "citation": {
-    "@type": "Legislation",
+    "@type": "CreativeWork",
     "name": "Section 80C and Section 194A of the Income Tax Act, 1961",
-    "legislationJurisdiction": {
+    "spatialCoverage": {
       "@type": "Country",
       "name": "India"
     }
   }

Applied to all 38 razor files + 38 static HTML mirrors. 76 files, one commit. Deployed. Rich Results Test result: still "1 invalid item detected."

Reasonable step, wrong root cause. Time to peel the next layer.

Round 2: Strip the "obviously invalid on MathSolver" properties (commit `6311067`)

Second hypothesis: some of the fields I kept aren't valid on MathSolver at all, even though they were valid schema.org somewhere.

additionalProperty — checking schema.org more carefully — is defined on Place, Product, QualitativeValue, QuantitativeValue, and StatisticalPopulation. Not CreativeWork. So MathSolver (which extends CreativeWork) shouldn't have additionalProperty even if I want it there.

citation.spatialCoverage: Country — the Country subtype felt exotic; Google's stricter validator might reject it in favor of the plain Place type.

-  "additionalProperty": [
-    { "@type": "PropertyValue", "name": "Applicable Regime", "value": "Both regimes" },
-    { "@type": "PropertyValue", "name": "Applicable AYs", "value": "All AYs" }
-  ]

   "citation": {
     "@type": "CreativeWork",
     "name": "...",
-    "spatialCoverage": {
-      "@type": "Country",
-      "name": "India"
-    }
   }

76 files again. Deploy. Rich Results Test result: still "1 invalid item detected."

At this point I was staring at a MathSolver block with only publisher.Organization, reviewedBy.Person, and citation.CreativeWork as nested types. The same page had a WebApplication block validating fine with Organization + Offer nested. So Organization/Person clearly weren't the problem.

By elimination, the offender had to be CreativeWork in citation. Or the MathSolver @type itself. But I hadn't proven the latter yet.

Round 3: Make citation a plain text string (commit `e642939`)

Third hypothesis: any nested @type at all inside MathSolver's citation gets rejected. schema.org allows citation to accept Text OR CreativeWork — switching to Text kills the last nested @type without losing information.

-  "citation": {
-    "@type": "CreativeWork",
-    "name": "Section 80C and Section 194A of the Income Tax Act, 1961",
-    "alternateName": "..."
-  }
+  "citation": "Section 80C and Section 194A of the Income Tax Act, 1961"

Deploy. Rich Results Test. Same error. "Invalid value in field itemtype."

Now the parsed MathSolver had only publisher.Organization + reviewedBy.Person as nested types — both of which validated fine on the same page's WebApplication block, and both of which are standard CreativeWork-inherited properties.

If a completely spec-clean MathSolver with only unambiguous nested types still fails validation, the problem isn't the schema. It's the MathSolver type itself in this context.

Round 4: Remove MathSolver entirely (commit `64a86db`)

I re-read Google's MathSolver documentation with fresh eyes. The doc opens with:

"Math solver structured data helps users find math solver services in Google Search results."

And later:

"Math solvers help users solve math problems by generating step-by-step solutions..."

Google MathSolver is a feature-gated schema. It's for Wolfram Alpha, Photomath, Symbolab — educational platforms that solve math problems.

A tax calculator suite is not a math solver, no matter how many equations we run.

Google's validator wasn't rejecting a specific field. It was rejecting the eligibility of the entire schema for our use case. The "Invalid value in field itemtype" error was Google's way of saying "this schema doesn't apply here, please stop." I was fighting a feature gate, not a validation bug.

Removed the MathSolver block from all 38 tool razors and 38 static mirrors. 1,861 lines deleted across 76 files.

Rich Results Test result: 0 MathSolver items detected. No error. WebApplication + BreadcrumbList + HowTo all still valid, still eligible for their respective rich results.

The GSC error will clear as Google re-crawls the pages over the next 3-7 days.

The lesson that would have saved me 6 hours

Read the target audience paragraph of any Google structured-data doc before rolling it out at scale.

Google's structured-data docs almost always open with a "who this is for" statement. For MathSolver:

"Math solver structured data helps users find math solver services in Google Search results."

Not "math-related content." Not "sites that display formulas." Math solver services.

I skipped that sentence because I was building tax calculators — of course they involve math. Six hours later I learned that Google's definition of "math solver" is narrower than mine, and its validator enforces the definition rigidly.

Two practical takeaways

1. Feature-gated schemas exist. Detect them early.

Not every schema Google documents is available to every publisher. MathSolver, EmployerAggregateRating, JobPosting, DatasetProperty — these get feature-gated to specific verticals. Even a valid schema fails validation if you're the wrong publisher.

Look for these signals BEFORE implementing:

Docs open with "helps users find [specific type of service]"
Named examples in the docs are all one narrow vertical
Google's rich result gallery for that type shows only 3-5 major players

If any of those signal apply, validate ONE page in Rich Results Test before rolling out the schema to your entire site.

2. "Invalid value in field itemtype" is Google's catch-all rejection.

The error name suggests something specific — a particular @type value in a particular slot. In practice, Google throws this error whenever anything about your schema doesn't match its narrower-than-schema.org expectation.

If you see this error and you're SURE your schema is spec-clean, the answer isn't more schema polish. The answer is: are you using this schema type in a context Google intended it for?

Post-mortem: what I'd change

Locked into a guideline doc (docs/guidelines/content-and-integrity.md in my repo) — never add MathSolver JSON-LD on this site again. Also captured the anti-pattern for future contributors: validate ONE test page in Rich Results Test before rolling any new schema type across all 38 tools.

If you're implementing structured data for a niche use case, budget the "test one page first" step. It's the difference between one file changed and 76 files changed four times in a row.

I'm Chetan Sanghani, building SmartTaxCalc.in — 38 free Indian tax calculators, editorially reviewed by CA Ankitkumar Italiya (ICAI M-644575). Feedback welcome — especially if you've hit similar feature-gate walls with other Google structured data types.

DEV Community: Chetan Sanghani

I built a lint that caught 3 tax-rule lies my manual sweep missed — a pattern-based safety net for hand-maintained SEO

The setup — why drift happens

The Sunday crisis

The lint I built this Wednesday

The two-phase pattern that works

What happened when I ran it

Why this generalizes

What the lint does not do

Wire it into CI

What I learned

The current state

Six directory emails promised me a dofollow backlink. My 40-line PowerShell verifier said otherwise.

What "dofollow" means, and why it moves

Discovery 1: Medium is now ugc nofollow

Discovery 2: GitHub READMEs are nofollow too — even in your own fork

The lesson: verify the rel before you write

The verifier — 40 lines of PowerShell

The header dance for Cloudflare-fronted sites

The newer trap: when the site emails you claiming dofollow

The lesson upgrade: verify the funnel, not just a listing

Why this matters more than a one-off check

Steal the pattern

Launching SmartTaxCalc on Product Hunt today 🚀

What's live

What I learned (5 quick engineering wins from the build)

The stack

Ask

One cut my Blazor WASM LCP by 500ms — the invisible file at the end of the critical chain

The "Network dependency tree" was the smoking gun

Why this happens on every Blazor WASM app

The fix — three lines in index.html

Before / after (real numbers, mobile Lighthouse, Slow 4G throttled)

When this pattern applies

The trap I fell into first — assuming Blazor boot was fixed cost

Anti-pattern — don't preload everything

Bonus lessons from the same optimization pass

Medium and GitHub both went nofollow — so I built a 40-line PowerShell backlink verifier

What "dofollow" means, and why it moves

Discovery 1: Medium is now ugc nofollow

Discovery 2: GitHub READMEs are nofollow too — even in your own fork

The lesson: curl before you write

The verifier — 40 lines of PowerShell

The header dance for Medium and Quora

What the scorecard actually shows

Why this matters more than a one-off check

Steal the pattern

A self-cleaning Product Hunt teaser banner in Blazor WASM — 100 lines, auto-hides after launch, GA4-tracked

The problem

The design

The component

Design decisions worth calling out

Kill-date is server-side, dismiss is client-side

localStorage key is versioned by launch

Failing open, not closed

Kill date uses UTC everywhere

The CSS — matching existing patterns

Wiring into layout

The cache-buster gotcha

The telemetry

Realistic conversion math

What I skipped

Two takeaways

The launch itself

How I got LCP under 2s on a 38-page Blazor WebAssembly site (Cloudflare Pages)

The setup — what "LCP on Blazor WASM" actually means

Before numbers — Lighthouse mobile, throttled 4G, Moto G4 CPU

Fix 1: Delete the service worker (commit 910c606)

Fix 2: Removed a version-check IIFE that force-reloaded users (commit 910c606)

Fix 3: Preconnect coverage on 7 pages that were missing (commit 910c606)

Fix 4: Cache-buster pattern for CSS/JS (commit a9255e8)

Fix 5: Cloudflare Brotli edge compression

Fix 6: Blazor WASM bundle size — PublishTrimmed + linking + InvariantGlobalization

After numbers — Lighthouse mobile, same throttling profile

What did NOT help (I'm being honest)

Two takeaways for anyone doing this

Result

Google's MathSolver JSON-LD validator is stricter than schema.org. I learned that the hard way over 4 rounds of fixes.

Setup: what the schema looked like

Round 1: Fix the obvious (commit 32d1a24)

Discovery 1: Medium is now `ugc nofollow`

The lesson: verify the `rel` before you write

The fix — three lines in `index.html`

Discovery 1: Medium is now `ugc nofollow`

Fix 1: Delete the service worker (commit `910c606`)

Fix 2: Removed a version-check IIFE that force-reloaded users (commit `910c606`)

Fix 3: Preconnect coverage on 7 pages that were missing (commit `910c606`)

Fix 4: Cache-buster pattern for CSS/JS (commit `a9255e8`)

Fix 6: Blazor WASM bundle size — `PublishTrimmed` + linking + InvariantGlobalization

Round 1: Fix the obvious (commit `32d1a24`)

Round 2: Strip the "obviously invalid on MathSolver" properties (commit `6311067`)

Round 3: Make citation a plain text string (commit `e642939`)

Round 4: Remove MathSolver entirely (commit `64a86db`)