In our Blazor Web App (InteractiveAuto), the WebAssembly client takes about 7 seconds after each F5 before the application can be used, even with the browser cache already filled. Almost all of this time is spent in the browser, not waiting for the server. We measured the startup and split it into the steps below.
| Step | Time | |---|---| | Module localization texts (20 to 29 languages per module) | ~2.0 s | | Module registration and Autofac container | ~1.3 s | | Static asset list sent to the client (resource-collection.js) | ~1.2 s | | API descriptions of the static proxies (generate-proxy.json) | ~0.9 s | | Layout, menu, toolbar and first page | ~0.9 s | | Application configuration and localization requests | ~0.7 s | | Total | ~7.1 s |
Taking as an example the step with the largest weight in the table above, the module localization texts (~2.0 s): when a module's texts are used for the first time, the WebAssembly client loads the files of every language that module ships, which is between 20 and 29 languages per ABP module. Because each F5 restarts the client, this repeats on every F5.
Our application has only two languages configured, pt-PT and en. As we understand it, the only other languages ABP needs are the fallback cultures used to resolve a text: the parent culture (pt) and the default culture of each resource. Since switching language reloads the page, the remaining languages appear to be loaded but never used.
- Why does the client need to load all languages of each module, instead of only the languages configured in the application?
- If there is no specific need, could the client load only the configured languages and their fallback cultures? Or is there already a supported way to do this?
Thank you.
1 Answer(s)
-
0
In ABP Blazor WASM/WebApp, the client-side localization is resource-based and module-based, and each module typically embeds a set of JSON files for many cultures under its virtual file system (VFS). When the WASM client decides it needs a given localization resource, it pulls the resource’s JSON files exposed by the host. That’s why you see “module localization texts” as a big chunk of startup time, and why it repeats on each F5 (because the WASM runtime/app is restarted and re-initializes its localization store).
ABP’s localization fallback rules are indeed culture-based (requested culture → base culture → default culture, etc.). Those fallback rules are documented, but they do not imply the framework will only download those cultures; it only implies how a key is resolved once the relevant dictionaries are present.
So, your understanding of fallback is correct, but the current loading strategy is not “download only what’s required for fallback”.As of the verified ABP docs available here, there is no documented/supported option that tells the Blazor WASM client to “only download the cultures configured in the application + fallbacks” for module-provided virtual JSON localization files. (So there’s no officially documented switch I can point you to that changes this behavior in 10.7.)
Practical mitigations you can apply without changing ABP internals:
- Reduce the number/size of shipped localization JSONs in your own application/modules (obvious, but it’s the only fully supported lever).
- Prefer server-provided localization where possible (in a WebApp, SSR happens first; WASM then fetches configuration/culture afterwards). This doesn’t eliminate the need for client localization entirely, but it can reduce what must be ready before first interaction, depending on your UI structure.
- Measure whether you are loading localization resources earlier than necessary (e.g., during module init rather than on-demand at first use). If you can defer certain modules/components, you may defer their localization cost as well.
For the other startup costs you listed (resource-collection.js, generate-proxy.json, etc.), those are separate pipelines (static asset discovery and dynamic proxy metadata). The “load everything each F5” characteristic is normal for an Interactive WASM app because the browser refresh restarts the app; caching helps network, but not parsing/processing/DI initialization time.
Sources (validated)
- https://abp.io/docs/10.7/framework/fundamentals/localization
- https://abp.io/docs/10.7/framework/fundamentals/url-based-localization
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
Markdown supported.Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)
