[Question]: Update performance comparison to `@nuxtjs/i18n` version `10.6.0`

[BobbieGoede]

❓ Question

Hi! The performance comparison in the docs appears to be based on @nuxtjs/i18n v10.1.x (the catalog pins ^10.1.2). The perf criticism was fair, and the releases since then have focused on exactly that, v10.6.0 should be much closer on build time and memory usage especially.

Could you re-run the benchmarks and update the comparison when you have time? 🙏

[s00d]

Hey @BobbieGoede — thanks for the ping, and fair call on the old numbers.

Really solid work on the 10.x performance line. The old harsh figures people still quote from marketing/docs were from the ~10.1 era, and they no longer reflect where @nuxtjs/i18n is today. 10.6 is a big step forward.

What we re-ran

• Catalog is already on @nuxtjs/i18n ^10.6.0 (resolved 10.6.0) for the benchmark fixtures.
• Same suite: test/performance.test.ts.
• Fresh write-up: Performance Test Results (source).

Build comparison (same fixtures, same suite)

“Before” = last published report while the catalog was still on the older 10.1.x line (~68s / ~8.1GB in performance-results.md history; marketing pages quoted the even harsher ~82s / ~9GB snapshot).
“Now” = re-run against @nuxtjs/i18n@10.6.0.

	Build time	Peak RSS (build)
@nuxtjs/i18n before (~10.1)	~68s (marketing ~82s)	~8.1 GB (marketing ~9.1 GB)
@nuxtjs/i18n 10.6	~15.8s	~2.1 GB
plain Nuxt baseline (same run)	~11.3s	~1.1 GB

So build time and peak RSS improved a lot vs that older report — roughly ~4× faster and ~4× less peak memory. The old “~82s / ~9GB” story is outdated. Great progress.

Stress / RPS (same fixtures, same suite)

Same Artillery + Autocannon profile as in performance-results.
“Before” = report before the 10.6 catalog refresh (history). “Now” = @nuxtjs/i18n@10.6.0.

	Artillery RPS	Artillery avg latency	Stress peak RSS	Autocannon RPS (10c/10s)	Autocannon avg latency
@nuxtjs/i18n before (~10.1)	~26	~992 ms	~890 MB	~12	~783 ms
@nuxtjs/i18n 10.6	~195	~709 ms	~521 MB	~88	~113 ms
plain Nuxt baseline (same run as 10.6)	~273	~430 ms	~369 MB	~164	~60 ms

Runtime under load also improved a lot for @nuxtjs/i18n (~7–8× Artillery/Autocannon throughput vs the older report, lower peak RSS). Gap to plain Nuxt is much smaller than before — you still have some headroom on RPS/latency vs the plain Nuxt baseline on these fixtures, but night-and-day vs ~10.1-era numbers. (Landing-page marketing still quotes an older ~51 RPS story; the report above is the one we trust.)

There's still room for @nuxtjs/i18n to improve further on these fixtures:

• Build is still a bit slower / heavier than the plain Nuxt baseline on this run (~15.8s / ~2.1GB vs ~11.3s / ~1.1GB).
• Server bundle size still leaves you some headroom vs the plain Nuxt baseline — not a final verdict, just what this suite shows today.

Heads-up: optimizeMessageBundling + Nitro serverAssets

Noticed you ship static locale messages via Nitro serverAssets (baseName: 'i18n') in src/nitro.ts / readI18nAsset — smart for keeping messages out of the compiled JS graph when N is small (locale files).

One gotcha we hit hard on larger catalogs (especially after moving to the Nuxt 4.4 / current Nitro stack): in production, serverAssets are not “just files on disk”. Nitro turns each asset into a lazy raw: import, and the nitro:raw plugin embeds it as a JS module in the server Rollup graph (see also Nitro’s own note that assets are bundled with the server, and the long-standing pain with many assets in nitrojs/nitro#1833). Cost scales with file count × size — build RSS and Nitro time climb fast once the matrix gets big (page × locale, or fat JSON trees). Dev stays cheap (fs driver); the hit shows up on nuxt build.

What we switched to on Node after that: stop registering serverAssets for payloads, copy the same JSON tree the client already fetches into public/<apiBaseUrl>/…/data.json, and SSR with plain readFile next to .output/server — same URLs, no raw: modules in the Nitro graph. Edge still needs an embed (no durable FS), so we keep serverAssets only there and prefer a compact source mode.

For reference (what we ended up with, not a product pitch):

• v3.24.0 notes — Node SSR from public/, no Rollup raw:
• payload-source.fs.ts — readFile reader
• module.ts nitro:config — Node → fs alias; Edge → serverAssets only

Your locale-count case is usually much smaller than a full page×locale matrix, so optimizeMessageBundling can still win. Just flagging the Nitro raw: path if anyone starts stuffing lots of message files into serverAssets and suddenly sees multi‑GB Nitro builds after 4.4.

Docs

• The detailed report above already reflects v10.6.
• Our homepage / Performance Guide summary blocks still quote the old marketing numbers — I’ll refresh those so they match current results and don’t misrepresent @nuxtjs/i18n.

If you have preferred 10.6 flags for a fair “best case” on these fixtures (preload / lazy / etc.), happy to re-run with that and note it in the methodology.

[BobbieGoede]

Thanks for the quick re-run 🙏

The plain Nuxt baseline is the number that stands out to me: 5.37s in the previous report, 11.30s now, on the same fixture. Build CPU usage roughly halved across all three fixtures compared to the last run while the baseline's stress results barely moved, so I suspect the build phase of this run was starved (thermals, other load, node 20 to 22, hard to say) rather than Nuxt getting 2x slower. The run also has plain-nuxt building slower than i18n-micro, which shouldn't be possible since it's the same app minus the module and minus 12MB of translations, my guess is plain-nuxt pays the cold caches as the first build of the suite. A warmup build or medians over a few runs would clean that up, as it stands the "vs plain Nuxt" deltas mostly measure build order.

I'm also not sure the code/translations split matters for a project, total output is what gets deployed either way. And if it does matter, the report reads a bit selectively: our translations show as 0 B because isTranslationFile doesn't match our content-hashed chunks/raw/*.mjs files, so ~13MB of message data is counted as code, and there's a chart for the code comparison (where that misclassification favors micro by 13.86MB) but none comparing translations, where micro's 12.69MB would sit next to our "0 B". Counting everything under chunks/raw/ as translations should at least fix the numbers.

While we're at it, would you consider a less synthetic fixture? Two locales with ~92k keys each (ru.json is 269 bytes, so it's effectively en + de) is not a shape I've ever seen in a real project, projects that big usually have the opposite proportions, something like 10+ locales with a few thousand keys each. The current fixture mostly measures how each module moves 16MB of JSON around, which I doubt is the comparison most readers are looking for.

Cost scales with file count × size — build RSS and Nitro time climb fast once the matrix gets big

I appreciate the callout, build memory is where the remaining gap is and I'll be exploring this to close it further. From what I can tell total size dominates at the counts we produce (one asset per locale file) and file count only starts to hurt in the thousands, but worth a look.

If you have preferred 10.6 flags for a fair "best case" on these fixtures

Defaults as-is are fine, that's what most users get.

[s00d]

Thanks for the detailed follow-up — useful notes.

On the 11.30s plain-Nuxt baseline

Agreed that jump is not “Nuxt got 2× slower overnight”. Between runs the stack moved (Node, Nuxt, and the bench harness itself). I treat single-run build times as a rough signal, not a lab-grade number. Cold-cache / build order effects are real; I don’t read small deltas as regressions.

Ideally I’d run each fixture 3–5 times and publish medians. That burns a lot of wall time on this suite, so today I still use one pass for orientation and ignore noise-level differences.

On the fixture shape (2 locales × huge key sets)

I hear you that real projects often look more like 10+ locales × fewer keys. I’m leaning the other way for my goals: keep (and likely grow) the stress — more locales, more data — because packing the fixture to the max is how I catch degradations and leaks early. For me these performance runs are less a marketing scoreboard and more a regression radar; oversized inputs make that sharper.

I’ll probably push locales toward 10+ and keep adding more signals to the report rather than thinning the dataset.

On code vs translations (isTranslationFile)

Fair point on content-hashed chunks/raw/*.mjs landing in “code” for @nuxtjs/i18n. I’ll revisit the classifier and try to make the split more accurate (and surface translations / total more clearly next to code). Not claiming that for this comment’s numbers — follow-up when I re-run.

Defaults-as-is for 10.6 is noted — thanks.

[s00d]

Follow-up: bench harness + new report

Took the feedback and reworked the suite a bit.

What changed

• Moved off the old Vitest performance test → CLI: pnpm test:performance / pnpm -C scripts cli performance.
• Each fixture is run 3 times in a row (A×3 → B×3 → C×3), numbers are means — less noise from cold cache / order.
• Bundle split is a bit fairer: chunks/raw/ (and matching locale chunks) count as translations, not app code. The old “v10 translations: 0 B” was a classifier bug.
• Default profile is lighter/more realistic knobs: 4 locales, ~10k index leaves (--locales / --keys still tunable).

Full write-up: performance-results (@nuxtjs/i18n@10.6.0, Nuxt 4.5.1, Node 22).

Mean of 3 (default profile)

	Build	Code	Peak RSS (build)	Artillery RPS	Autocannon RPS
plain-nuxt	5.32s	1.53 MB	~810 MB	~109	~65
@nuxtjs/i18n 10.6	8.34s	2.16 MB	~1.8 GB	~143	~72
i18n-micro	5.34s	1.74 MB	~1.1 GB	~275	~162

On this profile micro still leads under load; build gap vs 10.6 is smaller than the old marketing story.

Caveat (important)
This is one profile. Push --locales / --keys up and everyone gets slower / heavier — more JSON, more I/O, more Nitro work. Past a point the deltas shrink and you land back near the “old” ugly numbers (big catalogs punish all approaches). Treat the table as a mid-size default, not a universal ranking.

Happy to re-run with a profile closer to what you care about if you want different knobs noted in the methodology.

[BobbieGoede]

Thanks for reworking the harness and updating the report so quickly, the 3-run means, the classifier fix and the new default profile cover everything I raised, and more! 🙏

The new numbers set a great target, you're still ahead under load and on build memory, and I think a bit of friendly competition here is only good for users of both modules. I'll keep working on perf on our side to close the gap further 💪

[s00d]

@BobbieGoede Opened a Nitro PR that should partially address the large serverAssets build cost (opt-in embed: "inline" | false, default raw: unchanged): nitrojs/nitro#4507