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.jsdownloads 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.csmain. - 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 theHttpClient.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 foras="fetch"preloads to match a CORS-enabled fetch. Even for same-origin, Blazor'sHttpClientsends 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 thewasm-toolsworkload, anddotnet workload restorein 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.
