Closed mateuszwrobel closed 1 month ago
Can you please provide a minimal reproducible example... that change (https://github.com/i18next/i18next-http-backend/pull/152) only adapts the ways on how a network error is logged and passes the retry indication for i18next to retry on such an error case... I'm really interested to know how your setup is and how that change influences it... //cc @nycruslan
I suspect, your original issue is somewhere else... Probably for v2.6.1 i18next tried to fetch some resources, but failed and did not retry... => this was fast until the i18next.init call ends, but you had no translations loaded... probably you lazy loaded translations afterwards... And with v2.6.2 i18next tries to fetch some resources, but fails and is doing retries, for a couple of times... => this is slower until the i18next.init call ends... By default i18next retries 5 times with a retry timeout of 350ms... You may want to change those options in your i18next.init() call...
i18next.init({
// ...
retryTimeout: 350,
maxRetries: 5,
// ...
})
Yeah, setting up maxRetries
to 1 makes cold start faster. Thanks for a pointing that out. I'm not that familiar with i18next stuff. I'll try to find what's wrong in our code, because it's strange.
🐛 Bug Report
After updating to 2.6.2 there is increase in cold start for an app for 1,6s to 9-12s.
It seems like "Improve network error detection across browsers" introduces issue on cold start. Without this new check there were no callback calls, now there are. It's slowing down first load considerably. We are currently reverting to 2.6.1.
Can you consider other approach for solving network error detection?
Your Environment