Overview page network improvements

[benjaminpjones]

The ui/overview api is getting a little heavy, and the reason is largely fields that aren't being used. As an example, I have a sizeable but not-unheard-of number of ongoing games (23 correspondence) and it is now taking almost a second to download the data held at ui/overview. I suspect this is because the data is 761kB compressed (>4MB uncompressed). For a rough estimate of how much data actually gets displayed, the resulting HTML ends up being less than 40kB.

The top 3 fields by size account for 97% of the payload:

• active_games.json.player_pool 51.36%
• active_games.json.rengo_teams 35.85%
• active_games.json.moves 10.59%

It is possible that ~these fields~active_games.json can just be removed since much of the same data comes via socket connections. If not totally removed, I still believe we can send this data in a much more compact manner.

Screenshots

[anoek]

Yeah I think we can, I'm checking with the mobile devs to see if they use this endpoint at all how it is, if they do I'll just create a new endpoint for the web UI that doesn't include the game data.

[BHydden]

a sizeable but not-unheard-of number of ongoing games (23 correspondence) and it is now taking almost a second to download the data 

23 you say? I wonder how long /overview takes to load for @Sofia-mal haha

[benjaminpjones]

This endpoint is very similar to players/%%/full, and last I checked that one was about 11s for @Sofia-mal's page 😂

[dexonsmith]

As noted in #2455 (the incoming dup), parts of these data are used to seed the sort-by-clock (to avoid "lively" animations as gobans shuffle around while the sockets connect). However:

• The clock data is only a small part of the JSON. No need to send the rest of it.
• We could have the backend send the games in the correct order for sort-by-clock. This might take some processing though (and I don't love the idea of having to sync between the client and backend here).