Closed koteezy closed 4 years ago
Also, I must say that when we specify one language - everything works well, but, unfortunately , we do not have one language, we have a lot of languages.
Each translation has a size from 13 to 16 KB.
Nuxt.config.js
i18n: {
locales, // 95
defaultLocale: 'en',
lazy: true,
langDir: 'lang/',
},
Update:
Damn, I specified one language with lazy: true - and the picture is about the same. 1000MS.
This is interesting but I'm not sure why that measurement by Lighthouse is so slow and if it makes sense.
I'm also working with ~12KB JSON translation files and I'm seeing some ridiculously bad times in lighthouse for it:
That javascript file basically has a one JSON.parse
call and when I extract that code and run it in the console it seems to take 0 ms...
While, it surely would be slower during page loading (and also my testing is with a simulated mobile device) I'm not sure if it should be that slow...
In General, why not add an option that will add JSON with translations inside the HTML page, similar to ExtractCss.
At least when it comes to the "script evaluation" (which is the bottleneck here), it shouldn't really matter much if it's in the main HTML (in a script
element) or in an external JS file. External JS file adds an overhead of an extra network request but shouldn't have any effect on how long it takes to evaluate the code.
BTW. According to the Internet (or v8 engine), parsing JSON object (like happens here) should be more efficient than parsing a JS object - https://v8.dev/blog/cost-of-javascript-2019#json So it should be as efficient as possible already when it comes to the code.
Alright, i found something, looks like the main problem is count of routes:
helpers/routes.js
if i replace
locales = getLocaleCodes(locales)
to
locales = ['en']
the speed will increase hundreds of times.
With 95 languages, nuxt generating 1995 routes.
Do nuxt support thing like delayed loading routes, or something like that, for avoiding that?
Large number of routes does affect performance, see https://github.com/nuxt-community/i18n-module/issues/690 .
But I'm not sure that's directly related to the lighthouse issue because in my project I don't have that many translations nor routes (18 translations and 11 routes in total since I'm using no-prefix strategy).
I left only 2 locales, and run lighthouse several times, and got 60/80% on mobile, but when i make some changes in plugin.main.js
Namely, adding JSON right to DOM, for avoid unnecessary ajax request
if ( process.server ) {
await beforeNuxtRender( async ( {nuxtState} ) => {
await loadLanguageAsync( context, finalLocale );
nuxtState.i18n = app.i18n.getLocaleMessage( finalLocale );
} );
}
And get it in loadAndSetLocale
method
if ( process.client && initialSetup ) {
app.i18n.setLocaleMessage( newLocale, nuxtState.i18n );
}
The performance has increased, to 90/95 for mobile, for web sometimes i get 100.
I've tried that.
It has improved performance by a few points only (from 48 to 52 or so).
And as expected, the "Script Evaluation" time that was attributed to the lang file has now moved to the *.app
bundle. So Lighthouse attributing all that slowness to the lang file is not really accurate.
To conclude:
BTW. I don't want the solution that is based on the store to be the main one. This core functionality of this module should be functional even without the store.
It makes sense to have the default locale in the main bundle already. Should improve the case when the client's locale matches the default one.
Exactly! But, in which repository should we create an issue for that idea? Nuxt, Vue-router?
And as expected, the "Script Evaluation" time that was attributed to the lang file has now moved to the *.app bundle. So Lighthouse attributing all that slowness to the lang file is not really accurate.
Maybe a good use case for user timings? That way it's easy to find how longi18n
really took to evaluate in perf tools like lighthouse.
https://web.dev/user-timings/ https://developer.mozilla.org/en-US/docs/Web/API/User_Timing_API/Using_the_User_Timing_API
Exactly! But, in which repository should we create an issue for that idea? Nuxt, Vue-router?
It's this module that is responsible for loading lang files. And I can use this issue to fix it.
Sounds good.
Maybe a good use case for user timings? That way it's easy to find how long
i18n
really took to evaluate in perf tools like lighthouse.
Nuxt is in the best position to do that itself. It would be important to then know metrics for all internal components and all used modules. If I would just implement it for this module, you would know that for example, this module takes 100ms to run but you still wouldn't know where the remaining 2900ms is spent.
So it would make sense to create a feature request for Nuxt, if there isn't one already.
@koteezy Thanks for your suggestion from https://github.com/nuxt-community/i18n-module/issues/815#issuecomment-667551063 . I have initially mistaken it as using store but nuxtState
is not store so it's perfectly fine to use it. I've implemented that in #823
With v6.13.3 there should be no extra network requests to fetch the languages on initial load.
I don't think it will make a big improvement but it's a good step.
Since those were the issues mentioned in here, I think this can be closed now.
@rchl Thanks you! How about large number of routes? (comment) Did you think is possible to load on client only user's language, or something like this?
@rchl Thanks you! How about large number of routes? (comment)
There is already an issue #690 for that so we don't need to keep a separate one.
Did you think is possible to load on client only user's language, or something like this?
No, the issue is with initializing VueRouter with a large number of routes. It's an issue that affects both server and client performance. It's a fundamental issue in VueRouter and I'm not planning on doing any hacky workarounds for it.
Got it. Thanks anyway!
Hi. Google says that the script for loading languages on mobile devices is very slow. 1.5 seconds, while the main application is 400ms, how i can fix that?
In General, why not add an option that will add JSON with translations inside the HTML page, similar to ExtractCss.