The API result includes time taken by each aid:

definition: 0
definitiondiff: 0.006
documentation: 0.005
gettext: 0
inotherlanguages: 0
insertables: 0
mt: 0
query_aggregator: 0.06
support: 0
translation: 0.003
ttmserver: 13.348

So it's clearly the translation memory. For tech news this is a known issue. See T101236#4514784 for example.

This bug does not only affect the translation suggestions. As you can see on the video, it also affects the buttons ‘$var’ that helps you to insert variables and HTML blocks by clicking or using Alt+figure. It also affects the message documentation. (And maybe the diffs for obsolete translations, I don’t remember.) All those things appear together.

So the original title ‘Translations aids are slow to load’ was right.

If translation memory is the only element which is slow, then it would technically be good to make the others things appear directly, and the translation memory would be the only long thing to load.

Potentially related, reported by Omotecho here:

I guess the issue appeared not too long after you cleaned up translation memory and translation task has speeded up tremendously, I am more than happy to work as ever, and thought I will ignore this ”small stone in my shoe” forever.

Then, well, any office works are slacked, and pondered if it is easy-enough to solve the issue, while everybody is working remote and maybe small task is enjoyable. Of course, no haste. Please do put it away if you need to stretch out too much, we are all cautious not to overflow wifi stream.

• Device, OS:

I am using Safari, desktop view, on iPhone6S. iOS 13.3.

• Issue:

Translation is not suggested on right pane.

• Where issue occurs: Link below. Translations:Tech/News/2020/14/2/jp

• How issue persists:

After I work and save other target/small window and return to that link, even the blue letters on the right pane disappears so no function to load translation suggestions or /qqq file.

• Similar case:

Translations:Tech/News/2020/14/5/ja
While the same happens initially, when I finish any other target and come back, it’s all normal and links to translation memory.

• Temporary solution:

C&p manually from past issue.

• Link to the problem: [https://meta.wikimedia.org/w/index.php?title=Special:Translate&showMessage=Tech%2FNews%2F2020%2F14%2F2&group=page-Tech%2FNews%2F2020%2F14&language=ja&filter=&optional=1&action=translate]

Just wished to point that this problem occurs specifically with THIS message, in every languages.

Besides, the automatic API request ever failed, but if I manually send the same API request, I always receive a response. Strange.

After fixing T249906: Translation memory suggestion page sources are sometimes duplicated, I see that the response time has gone to about 8 seconds from the 13 seconds seen earlier.

This helps a bit, but does not really solve the issue. The issues happens when you open the first message, or some other message out of order with slow translation memory query. It does not happen if you translate in sequence, because we preload the results for the next message.

It has been suggested to slow translation memory results separately, but given that we have the preloading that hides this issue, and we can't really know beforehand when a request is slow, and the desire to avoid the contents changing multiple times, I am thinking the added complexity is not going to be worh it, especially if we can further improve the translation memory speed and set lower timeouts.