⚡ Lazy-load heavy components on FE, on-demand locales, and per-font stylesheets by balazs-szucs · Pull Request #1193 · stumpapp/stump

balazs-szucs · 2026-05-30T19:07:00Z

Cuts initial JS payload by ~50% (4050 kB to 2039 kB gzipped).

The app was eagerly loading a lot of weight that most users never need on boot, e.g., 32 locale JSON files, the full @emoji-mart dataset + renderer, and a markdown parser.

Changes are as follows:

MarkdownPreview and @emoji-mart/react are code-split via React.lazy(); emoji data fetch gated on isOpen
32 locale JSONs replaced with import.meta.glob; only en-US is eager, rest load via loadLocaleResources
resolveLocale normalizes raw browser strings (fr, zh_CN) to a valid AllowedLocale, replacing a silent bad cast (At least I think so? I was getting weird errors)
EPUB reader injects only the selected font's stylesheet instead of a monolithic fonts.css

As for ResizeObserver added guard against post-teardown resize calls, it was giving also some headaches, not quite certain if I caused it somehow but 🤷‍♂️

…lesheets

# Conflicts: # apps/web/vite.config.ts

balazs-szucs · 2026-05-30T21:25:27Z

I made this a draft, as I think, something stinks here. I'll take second/third look at this. May be nothing. Just a gut feeling.

balazs-szucs · 2026-05-31T11:49:10Z

So, what tripped me up the maths vs my older precompress PR, so did some digging:

State	Old PR	This PR	Difference
Uncompressed (Main bundle)	5.16 MB (~5,283 kB)	2.31 MB (2,309.48 kB)	~56%
Gzipped (Main bundle)	806 kB	713 kB	~11.5%

So, yeah this is more like 12% percent improvement not 50%. Still, good? I think? I guess compression does not scale as the non-compressed file goes, so lot of resource that were cut off are exactly the stuff that were well compressed, hence why does does not bigger gains. So, in other words: lazy loading them shrinks the raw file dramatically, but their contribution to the compressed size was already minimal. GZIP "hid" the cost of those resources before, so deffering them doesn't move the needle as much post-compression. Probably locales files, i think, that contained huge amount formatting/whitespaces etc, so those are very well compressed. (best guess)

Apologies for the confusion.

… path imports

balazs-szucs · 2026-05-31T12:42:53Z

../dist/assets/hina-mincho-japanese-400-normal-CLxaJXTw.woff2 1,424.40 kB

That seems like a very hefty thing to be pulling in. There should be a more lightweight option, i think.

(I am defo not suggesting dropping it, rather finding more suitable way to get the fonts.)

…d directory

aaronleopold

Thanks for working through this! I had some comments throughout.

So, yeah this is more like 12% percent improvement not 50%. Still, good? I think?

Yeah I think 12% is a good improvement, but based on what I saw I am worried that the improvement might be more artificial than practical (e.g., waterfall navigation from lazy loading routers).

aaronleopold · 2026-05-31T18:01:50Z

+const localeLoaders = import.meta.glob<{ default: Translation }>([
+	'./locales/*.json',
+	'!./locales/en-US.json',
+])


This will likely break expo. import.meta.glob is a vite API, right? Not all apps in the repo are using vite, so if we want to lazily load things we will need another mechanism for doing so

I'll double check, I am afraid I did not think to test with expo. So whether this is breaking for it, i would need check.

Apologies.

aaronleopold · 2026-05-31T18:09:54Z

 	resources,
 })

+export const resolveLocale = (inputLocale?: string): AllowedLocale => {


I'm a little conflicted about this function, at least for some of it. I think it might be overly defensive, really. I'm of the mentality that breaking fast will be easier to catch, e.g. if someone's navigator returns a locale which we don't support I'd rather bake in support for it than not realize it isn't working as expected.

That may be, i think this is fine? I think the fallback to en-US is fine, most of (if any) problems are logged well enough, at the end of the day, I do not think this should cause any harm.

On the client, I think we would want to avoid throwing/failing on principle.

For the pt, i think you are right, i'll push commit when I am at PC again.

aaronleopold · 2026-05-31T18:12:15Z

+	const languageMatch = LOCALES.find((locale) =>
+		locale.toLowerCase().startsWith(`${languageCode}-`),
+	)


There are locales which could be matched here, but we'd only ever return the first. A bit of a guessing game (e.g. if my navigator passed just pt it would flow thorugh here to pt-BR when I might actually want pt-PT).

aaronleopold · 2026-05-31T18:13:07Z

+	const normalizedInput = inputLocale.replace('_', '-').toLowerCase()
+	const exactMatch = LOCALES.find((locale) => locale.toLowerCase() === normalizedInput)
+	if (exactMatch) {
+		return exactMatch
+	}


This feels redundant, did you observe a locale which came through in this format?

aaronleopold · 2026-05-31T18:16:56Z

 		}

-		if (!data) {
+		if (isOpen && !data) {


I don't see much value here, if you are on a route which has an emoji picker then IMO it should fetch the emojis before you open it. I think the provides a better UX, but maybe I am missing something.

Also, though, long term we won't be fetching emojis in this way so I don't feel too strongly.

Also, though, long term we won't be fetching emojis in this way so I don't feel too strongly.

That would a huge update, (in terms of UX) but I am afraid I did take a look at this already, and emoji land seems to be a... Bit more complicated than I had realised, hence I think updates to this is fine. (It is probably bulky change when/if somebody gets to this.). I am not attached to this particular change.

aaronleopold · 2026-05-31T18:33:11Z

+				const renditionWithManager = rendition as Rendition & {
+					manager?: { stage?: unknown }
+				}
+				if (!renditionWithManager.manager?.stage) {
+					continue
+				}


Curious about this one, was this something observed/corrected during runtime? I won't nitpick epubjs changes too much because I am eager to just eventually replace it with readium, but curiosity won 😄

aaronleopold · 2026-05-31T18:35:58Z

Same remarks here as with the markdown preview

aaronleopold · 2026-05-31T18:42:48Z

+						if (id.includes('lucide-react')) {
+							return 'vendor-lucide'
+						}


We don't reach this because we would have matched id.includes('react') above, right?

aaronleopold · 2026-05-31T18:43:50Z

+			output: {
+				manualChunks(id) {
+					if (id.includes('node_modules')) {
+						if (id.includes('react') || id.includes('scheduler')) {


Many packages will include react in the name, right?

In practice, they are not that big :)

So, i think it should be just fine.

I think my point was really in the same vein as this above, that it could falsely match packages (like lucide-react)

aaronleopold · 2026-05-31T18:47:42Z

I don't disagree with manual chunking in general, but I think maybe things might be a bit higher fidelity if we compare more complete paths instead of just substrings. E.g.

rollupOptions: { output: { manualChunks(id) { const path = id.replaceAll('\\', '/') if (!path.includes('/node_modules/')) return if (path.includes('/node_modules/lucide-react/')) return 'vendor-lucide' if (path.includes('/node_modules/@tanstack/')) return 'vendor-tanstack' // ... etc ... if ( path.includes('/node_modules/react/') || path.includes('/node_modules/react-dom/') || path.includes('/node_modules/scheduler/') ) { return 'vendor-react' } }, }, }

balazs-szucs · 2026-05-31T22:31:31Z

Yeah I think 12% is a good improvement, but based on what I saw I am worried that the improvement might be more artificial than practical (e.g., waterfall navigation from lazy loading routers).

I redid the benchmark now its 626.23 kB so -22.3%, I think some of more commits after I made my initial comment improved it significantly.

In practice, I feel like this should be an improvement, BUT a "hard to measure" improvement though. Lot of the chunking improvement will manifest themselves with caching/etc improvement, that is not necessarily easy to get a good measurement on.

Anyways, last 8 commit, I think addressed everything.

balazs-szucs added 3 commits May 30, 2026 20:27

Lazy-load heavy components on FE, on-demand locales, and per-font sty…

07d3e5b

…lesheets

Merge branch 'nightly' into chunk-tsconfig

7712a5a

# Conflicts: # apps/web/vite.config.ts

Cache normalized font to avoid redundant calculations in EpubJsReader

cc5ab4f

balazs-szucs marked this pull request as draft May 30, 2026 21:24

balazs-szucs marked this pull request as ready for review May 31, 2026 11:49

More bundle splitting via lazy loading, manual chunking, and granular…

acc1a12

… path imports

balazs-szucs and others added 3 commits May 31, 2026 14:46

Extract query logic into standalone files for library and series scenes

e672be8

Enable emptyOutDir in Vite build configuration to ensure a clean buil…

05f7327

…d directory

Merge branch 'nightly' into chunk-tsconfig

1b98042

aaronleopold reviewed May 31, 2026

View reviewed changes

balazs-szucs added 8 commits May 31, 2026 21:47

Optimize manual chunking logic in vite config

1727524

Directly import scene routers in app router

8dead96

Remove lazy loading from read more component

a198a18

Remove redundant i18n vite env file

b9ca356

Fix locale provider cancellation guard

ee17144

Refactor i18n configuration and locale matching

4da934c

Remove lazy loading from markdown editor

f14cf7e

Fix date-fns en-US dynamic/static import conflict

0ec9bde

Uh oh!

Conversation

balazs-szucs commented May 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

balazs-szucs commented May 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

balazs-szucs commented May 31, 2026

Uh oh!

balazs-szucs commented May 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aaronleopold left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

balazs-szucs commented May 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

balazs-szucs commented May 30, 2026 •

edited

Loading

balazs-szucs commented May 30, 2026 •

edited

Loading

balazs-szucs commented May 31, 2026 •

edited

Loading

balazs-szucs commented May 31, 2026 •

edited

Loading