Change 753876 had a related patch set uploaded (by Santhosh; author: Santhosh):

[mediawiki/extensions/UniversalLanguageSelector@master] Improve the loading time of ULS language selector by fetching modules early

https://gerrit.wikimedia.org/r/753876

In T299202#7621743, @gerritbot wrote:

Change 753876 had a related patch set uploaded (by Santhosh; author: Santhosh):

[mediawiki/extensions/UniversalLanguageSelector@master] Improve the loading time of ULS language selector by fetching modules early

https://gerrit.wikimedia.org/r/753876

This patch tried to load the required modules on mouseover on trigger. It is a slight improvement by saving the time between a mouse over and click. There may be furhter opportunities to improve it by expanding the mouseover area or even trying aggressive ways to load the modules much earlier.

Since language selector is a prominent interaction element on the screen, particularly in new Vector, it would be nice if we don't have this annoying load delay.
@Jdlrobson Do you have further ideas to improve the performance?

it would be nice if we don't have this annoying load delay.

@Jdlrobson Do you have further ideas to improve the performance?

Seems like a good starting point to me.
Another approach would be to render /something/ while it loads.

We have the languages in the HTML so we could render an intermediate screen like so:

[search for a language]
Loading suggested languages...

We could then load the search code in the background. That wouldn't be functional but would give the impression something is happening.

In addition to this we do have the list of all languages in the page. So we could potentially show something. The thing I'm not sure about is how you'd transition from that something to suggested languages.

e.g.

If doing that you'd need to be careful about retaining scroll in the case the user begins using unsorted.

When a search is performed the unsorted section would disappear.

The delay is to fetch the code required for ULS. The performance is better in Chrome because unlike Firefox, it can cache the ResourceLoader modules. T235852

Can you elaborate in what scenario you experience this delay?

We don't disable module caching in any browsers. What we disable in Firefox is an extra layer we developed on top of the browser cache, which can improve cache use in certain situations where we know something that the browser doesn't.

When a large feature like VE loads, or when lazy-loading ULS, the list of modules that ULS asks for doesn't vary by page for a given user. Whether this is cache hit in the Network tab, or in localStorage should make little difference. (There is actually some evidence that in Chrome, use of localStorage may be slowing us down. We also skip localStorage in Safari and Chrome in some cases.)

ULS loads from cache in Firefox.

The localStorage layer mainly has an impact when calling loader.load() on different web pages (full reload in between) with a different but overlapping list of modules. In that scenario, localStorage can effectively pluck out some of the dependencies you loaded on a different page view for a different feature and re-use them here. This is great, but for VE/ULS etc the browsers cache works optimally already without our help (Read more).

Can you elaborate in what scenario you experience this delay?

Whether this is cache hit in the Network tab, or in localStorage should make little difference.

True, the localstorage access was only used when I checked "disable cache" button in dev tools. I should have mentioned that. So, in normal cases, localstorage should not make any difference. Just for record, sharing screenshots below

Scenario 1: Page has been visited earlier and the language tools were accessed earlier

Article: https://ml.wikipedia.org/wiki/പാലക്കാട്
Logged in: True, Browser dev tools opened, Caching allowed.
Page accessed, cleared the network tab in browser dev tool. Just clicked on the languages icon.
Screenshots given below.

Chrome 97	Firefox 96

In Chrome, there is nothing to download. Language selector opens instantly. RL modules are access from browser storage(not from cache). SVG icons are not downloaded.
In Firefox, cache is used for RL modules. Network requests were required for svg icons. Took about 200ms for that. But that does not block opening language tools

Scenario 2: If language tools were never accessed before in the browser, there is no cache, network requests are needed for the ULS RL modules in first time click. That is what the patch primarily tries to improve.

@Krinkle I'm the one who brought this up in the Language engineering Telegram group, which prompted @santhosh to create this task.

I have disabled the language selector thing for sitelinks (instead preferring to always show the full list), but the times I have tested it with incognito mode, that has usually worked well, with no particularly noticeable delay.

Where I'm having trouble though, is the language selector on Translatewiki's [[ translatewiki.net/wiki/Special:Translate | Special:Language ]], as well as the "general" language selector on multilingual wikis like Commons and Wikidata (the one that appears next to your username). When measuring with the browser console's "Performance" tab yesterday, it took approximately 160 seconds (!) from clicking the button until anything being clickable (the box first loads with the suggested languages, but loading the rest of the languages makes the whole browser tab idle).

I'm on Firefox 92.0 on Ubuntu, FWIW. I tested in Edge 95.0 for Ubuntu as well just now, and the one on Special:Translate took 15 seconds to open. Much better there, but still quite noticeable.

Change 753876 merged by jenkins-bot:

[mediawiki/extensions/UniversalLanguageSelector@master] Improve the loading time of ULS language selector by fetching modules early

https://gerrit.wikimedia.org/r/753876

In T299202#7625676, @jhsoby wrote:

Where I'm having trouble though, is the language selector on Translatewiki's [[ translatewiki.net/wiki/Special:Translate | Special:Language ]], as well as the "general" language selector on multilingual wikis like Commons and Wikidata (the one that appears next to your username).

@jhsoby I noted a recent significant performance improvement (maybe early 2024, or lately 2023), did you also notice it?

Yes, it's much faster for me now. On Special:Translate, a box opens immediately when I click it (preloaded with the last 9 languages I've used), but I can't interact with that box until all languages have loaded, and that took ~5 seconds when I tried just now. So there's still a noticeable delay, but it's much better than it was when this bug was first opened.