Performance de l'appli Web

laem

🇬🇧 Performance 🇬🇧

Some say that Web maps cannot be swift. Indeed, cartes.app is currently slower than Organic Maps when you dezoom the map. Our mobile drawer component is also a bit more laggy.

I'm convinced we can optimize all that and approach parity. Here are some ideas.

React performance

• [x] Test https://github.com/kristiandupont/react-geiger

I did not find any evident lag.

Maplibre performance

• Iterate on reducing the load of our tiles / our maplibre style.

There's no simple way to do that (I asked the team here) : you have to try and learn by deactivating some layers and see

• well at least, load lazily the non-main styles

• for high zooms, reduce the size of the bathymetry data

Interface js load

• reduce the size of the bundle. We can probably move some local data to APIs for instance
  • check how heavy terradraw is. Load it lazily if needed.

Done in !1401

⌚️4 days

1. laem

   • perf : quand on zoom sur une ville depuis la France, le composant Content et le Map sont re-rendus des dizaines de fois ! Ce n'est pas très intensif comme calculs, mais ça reste inutile. Il semblerait que React Compiler n'arrive pas à automatiquement mémoïser plusieurs paramètres. Ça ne me semble pas être la mer à boire, on peut investiguer ça.

   Comment by @altonss :

   cartes.app is indeed a bit slow, especially when moving the map, and reloading missing tiles/data is very slow. This is a bit related to /documentation/tickets/218, but the general performance of the website should be improved to ensure a smooth experience, and not to await too much loading :)

2. laem

   Je viens de tester cartes.app sur un téléphone de dernière génération : c'est parfaitement fluide. Vraiment impressionnant, je n'aurais jamais cru. Ça montre une chose simple : si l'expérience est lente sur un téléphone, c'est que ce dernier n'arrive pas à tenir la charge imposée le rendu GPU de la carte, ou par les re-rendus React.

   C'est bon à savoir, même si ça ne doit pas conduire à négliger le sujet de la perf, sans WebGPU on ne pourra pas le résoudre entièrement.

3. laem

   Demo of the good performance of the app on a last generation smartphone. This is a good achievment, that should not make us forget lower-end phones of course. But the Web has some intrisic limits.

4. laem

   Pour debugguer le mobile : 916f10aa3556c96c4fe7efd5ece395e8b1259932

5. laem

   J'ai fait des tests sur un Fairphone 5. Il s'avère qu'a priori, c'est bien un souci de performance du GPU car le nouveau fond "arbres" est très fluide.

   Donc il va falloir osculter nos tuiles pour réduire les calques trop complexes. cc @etienneJr Si ça se trouve, on a un ou deux calques qui ralentissent tout le reste. Mais je n'ai pas trouvé d'outil facile pour tester ça à l'échelle.

6. etienneJr

   ah oui, j'ai déjà des idées ! Et aussi pour le style standard. J'ai remarqué des trucs bizarre l'autre jour, par exemple qu'il affiche encore h3-landcover aux zooms élevés en surzoomant à mort dans la tuile z9. Je peux investiguer ça.

7. etienneJr

   @laem wrote in https://codeberg.org/cartes/web/issues/218#issuecomment-10083060:

   le nouveau fond "arbres" est très fluide.

   en y repensant : ça n'est pas un bon test car il utilise comme source l'ancien trees.pmtiles hyper léger et non planet.pmtiles. Donc tu gagnes aussi sur le chargement des tuiles

8. etienneJr

   @laem wrote in https://codeberg.org/cartes/web/issues/218#issuecomment-10083060:

   Donc il va falloir osculter nos tuiles pour réduire les calques trop complexes.

   Etant donné cartes/serveur#96 je parierai sur la couche de données landcover. C'est la plus grosse donc a priori celle avec le plus de points à calculer. Et puis les suivantes les plus lourdes, on ne peut pas trop s'en passer : transportation et transportation name.

   Après, si on doit garder telle couche de données, mais en en masquant certaines couches de rendu, ça devient compliqué à investiguer en effet.

9. etienneJr

   Ah ! mais ! c'est tellement plus fluide sur mon ordi du boulot que sur mon ordi de la maison ! Il est plus récent, il doit avoir un meilleur GPU.

10. laem

    en y repensant : ça n'est pas un bon test car il utilise comme source l'ancien trees.pmtiles hyper léger et non planet.pmtiles. Donc tu gagnes aussi sur le chargement des tuiles

    Oui mais c'est le but. Certes les tuiles sont très légères, donc ça aide au téléchargement et au décodage, mais ensuite le zoom est très fluide. Ça permet d'évacuer une lenteur globale de l'app react / de l'encart mobile / etc.

11. etienneJr

    OK compris, tu voulais, pour un besoin de dev, pouvoir tester l'app sans le ralentissement du rendu du fond de cartes.

    Mais au delà, pour l'utilisateur, tu voudrais : a. un mode léger (pour le réseau) avec un style ET des tuiles spécifiques ? b. un mode léger (pour le CPU) avec un style simple MAIS les tuiles actuelles ? b. qu'on optimise le mode standard actuel en simplifiant le style ?

12. laem

    a. un mode léger (pour le réseau) avec un style ET des tuiles spécifiques ?

    Oui idéalement, mais c'est pas encore d'actualité.

    À court-terme, je dirais plutôt b oui.

    Mais pour revenir au test que j'ai fait récemment sur un vieux téléphone, c'était un Fairphone 3, qui a un GPU vraiment nul. Pas sûr qu'on soit si mauvais déjà aujourd'hui en fait, c'est juste qu'on peut pas cibler les vieux téléphone avec MapLibre.

13. laem

    For maplibre performance, this might help us, it's new :)

    https://maplibre.org/maplibre-gl-js/docs/examples/display-performance-metrics/

14. laem

    OK, I've implemented it in our app in 6806cfbdd, but now I don't really know what to do. But yes, map rendering performance looks like it goes down to 0 fps frequently.

    

15. laem

    • optimize Overpass requests
      • deploy our own overpass instance instead of the common, already overloaded, openstreetmap-fr instance
      • compress the nginx responses
      • restrict usage to our requests https://codeberg.org/cartes/web/issues/2041
16. laem

    About

    for high zooms, reduce the size of the bathymetry data

    Idea : add MapTiler's Bathymetry, that are perfectly similar to ours (same source), to the map and compare the rendering time. To determine if their's is more optimized, or if it's just the data that's too dense.

17. laem

    OK, match !

    Maptiler's

    3,98 Mo and 5,6 s

    Ours 2,85 and 4,42 s

    Testing on a closer zoom in the Pacific ocean gives no better result to MapTiler's.

    So it look like our version is not heavier, though it may have rendering artifacts, that would be caused by the too different sea background ?

    Of course the possibility of downscaling them remains, for a generic map. But it may not be that easy.

18. etienneJr

    et si on appliquait la bathymetry seulement sur le fond plein air ?

19. laem

    et si on appliquait la bathymetry seulement sur le fond plein air ?

    Je trouverais ça dommage, je trouve ce fond magnifique et super instructif. Par contre on pourrait en utiliser une version plus légère sur le fond normal.

    Gardons en tête que sur 90 % de l'usage quotidien, on est sur terre, et même sur les zones côtières on n'affiche qu'une fraction des données de cette source :)

    C'est plus pour l'effet démo du globe que c'est dommage qu'il pompe autant.

20. laem

    Not striclty related to map performance, but we're trying to come back to the upstream react-modal-sheet in #2062 to benefit from the recent updates to this lib.

21. laem

    Good news : maplibre just landed a perf optimisations for texts with halo. We use them a lot.

    GPU performance optimization: Render halo and glyph in a single pass (-40% Time Reduction) (#7436) (by @xavierjs)

    There are other optimizations as well.

    https://github.com/maplibre/maplibre-gl-js/releases