C'est pas ouf d'après Google.
Je crois que notre browserlist est trop tolérant, je vais tester autre chose.
@etienneJr on a un gros boulot à faire pour accélérer le rendu de la carte. C'est limitant pour la perf SEO.
J'ai fait quelques trucs dans une PR que je mets en ligne, mais la carte ça restera le truc problématique. Bon c'est pas cata non plus hein ;)
image
J'ai tenté de supprier l'élément Meteo, qui est le LCP, mais ça change rien : le titre du lieu devient alors le LCP à 2 secondes.
Or le LCP global est de 11 secondes, et sur l'écran on voit que seule la carte MapLibre bouge entre les deux derniers rendus : les icônes apparaissent.
Donc j'en conclus qu'il faut accélérer le rendu Maplibre
Bon j'en ai marre de la logique que j'ai introduite pour l'asynchrone /bulk. Je vais le passer en local.
@etienneJr j'ai découvert que pour une fiche lieu comme un restau, la route /bulk était appelée 20 fois pour un chargement neuf de l'app, sans cache.
Haha 😅
Corrigé ici :
#1377
En échange, quand on travaille sur les icônes, il faudra faire bun run pack-icons à chaque changement.
Il reste encore pleeeeeein d'optims à faire.
Par exemple, suite à la traduction des tags cuisine dans la liste des noeuds similaires, la page fait 200 appels à https://dev.cartes.app/api/tag-translations?tags=***
https://cartes.app/?allez=Mirlitantouille|n1302023838|-1.6855|48.1115#18/48.111586/-1.685454
J'observe également que les tuiles semblent peu rapides. C'est vrai que j'ai jamais optimisé la fourniture des pmtiles !
J'ignorais que le navigateur par défaut ne peut faire que 6 connexions simultanées à un serveur. Nos pmtiles saturent donc serveur.Cartes.app et les translation tags saturent cartes.app ! À corriger.
@laem wrote in #1366 (comment):
la route /bulk était appelée 20 fois pour un chargement neuf de l'app, sans cache
Bah c'est bizarre ça, pourquoi le cache n'est pas utilisé ? Tu parles juste du cas d'un bot de SEO ou du cas général de n'importe quel utilisateur ? Je me souviens qu'on en avait parlé il y a qq mois, tu m'avais dit que c'était pas grave car c'était mis en cache du navigateur, et je crois bien avoir vu après coup que c'était le cas.
@laem wrote in #1366 (comment):
En échange, quand on travaille sur les icônes, il faudra faire bun run pack-icons à chaque changement.
OK c'est noté pour le dev en local (et faut que je mette à jour le wiki). Quid pour la prod : c'est fait automatiquement à chaque déploiement ou pas ?
@laem wrote in #1366 (comment):
Nos pmtiles saturent donc serveur.Cartes.app
Je pensais que les appels qui n'ont plus lieu d'être (par exemple une tuile d'un niveau de zoom précédent si on a zoomé très vite) étaient annulés pour éviter de charger des trucs inutiles. Ce qui devrait donc libérer les connexions. C'est parce qu'on appelle plusieurs pmtiles différents ? C'est vrai que si on est dans le coin d'une tuile, ça fait 4 appels par fichier...
@laem wrote in #1366 (comment):
J'ignorais que le navigateur par défaut ne peut faire que 6 connexions simultanées à un serveur
C'est un paramètre réglable par le site web ? Ou seulement par l'utilisateur ?
@laem wrote in #1366 (comment):
Donc j'en conclus qu'il faut accélérer le rendu Maplibre
Est il possible d'identifier que c'est un bot de référencement qui consulte, pour lui envoyer une carte minimale ? (pas d'icônes, pmtiles spécifique hyper léger,...)
OK c'est noté pour le dev en local (et faut que je mette à jour le wiki). Quid pour la prod : c'est fait automatiquement à chaque déploiement ou pas ?
Oui, au bun install. J'ai MAJ bun lourdement d'ailleurs sur la prod.
Bah c'est bizarre ça, pourquoi le cache n'est pas utilisé ? Tu parles juste du cas d'un bot de SEO ou du cas général de n'importe quel utilisateur ? Je me souviens qu'on en avait parlé il y a qq mois, tu m'avais dit que c'était pas grave car c'était mis en cache du navigateur, et je crois bien avoir vu après coup que c'était le cas.
Oui, mais un bot de SEO et puis les nouveaux utilisateurs vont se taper 15 chargement du même fichier, plusieurs MO ! C'est parce que les requêtes sont lancées en parallèle, avant que le cache ne soit rempli ! Logique, mais subtil.
C'est un paramètre réglable par le site web ? Ou seulement par l'utilisateur ?
Seulement sur le navigateur. Donc n'y comptons absoluemnt pas ^^
Est il possible d'identifier que c'est un bot de référencement qui consulte, pour lui envoyer une carte minimale ? (pas d'icônes, pmtiles spécifique hyper léger,...)
Non, Google depuis 10 ans fait tout repérer les diff entre ce qu'on lui sert, et ce qu'on sert aux utilisateurs. Et vu que Google a le contrôle sur 70 % des navigateurs dans le monde, il sait tout.
@laem wrote in #1366 (comment):
Par exemple, suite à la traduction des tags cuisine dans la liste des noeuds similaires, la page fait 200 appels à https://dev.cartes.app/api/tag-translations?tags=***
https://cartes.app/?allez=Mirlitantouille|n1302023838|-1.6855|48.1115#18/48.111586/-1.685454
Je me rappelle plus si c'est exactement dans ce cas précis mais j'avais remarqué que y'a un cache qui ne sert presque pas car les données d'entrée i.e. la clé est unique et donc ne sert veritablement uniquement qu'au refresh. J'avais commencé à ameliorer ça sans le finir car l'api etait pas evidente 🫤
Je verrais si je peux finir...
Et puis je me demande si ce genre de ressources ne pourrait pas etre egalement stockées dans le localstorage. Je ne suis pas sûr que ça evolue beaucoup...
Quand on charge ce lieu, la carte se met d'abord au zoom par défaut, puis zoom sur le lieu. C'est lent : ça implique de télécharger les tuiles haut niveau inutiles. Ça pourrit notre score de perf Google.
Sûrement facile à corriger, je regarde.
https://cartes.app/lieu?allez=Le Beaujolais d'Auteuil|n989286977|2.2607|48.8486#15/48.8486/2.26071540
image
@laem wrote in #1366 (comment):
Quand on charge ce lieu, la carte se met d'abord au zoom par défaut, puis zoom sur le lieu.
Il arrive qu'on fasse un flyto pour déplacer la carte. Peut-être pas dans ce cas là mais par exemple dans la recherche d'itinéraires. Et si la destination est loin, l'expérience n'est pas bonne. A mon avis, on pourrait améliorer en calculant la distance et mettre l'effet "flyto" uniquement si la distance est courte, sinon désactiver l'effet pour charger directement la destination.
@laem wrote in #1366 (comment):
https://cartes.app/lieu?allez=Le Beaujolais d'Auteuil|n989286977|2.2607|48.8486#15/48.8486/2.26071540
2 petites améliorations liés à ce lien à faire:
A mon avis, on pourrait améliorer en calculant la distance et mettre l'effet "flyto" uniquement si la distance est courte, sinon désactiver l'effet pour charger directement la destination.
C'est déjà le cas via l'option maxDuration, non ?
2 petites améliorations liés à ce lien à faire:
Oui mais rien à voir avec le ticket présent :p, chaque chose en son temps.
Je vais corriger ce problème de position initiale, c'est pas trivial mais j'ai l'idée. C'est important pour les moteurs de recherche et donc pour nos utilisateurs qui utilisent cartes.app pour la première fois, sans compter les autres.
Voilà grâce à !1401 c'est bien mieux, pas de zoom par défaut initial, mais Google ne le voit pas du même oeil, étrange.
Bon sur une fiche sans image, on a clairement quelque chose qui foire car la page semble prête en quelques secondes, ce qui est très cool, alors que Google dit 10 secondes. On voit que sur les captures, rien ne bouge sauf les derniers éléments de la carte comme le marqueur et les icônes... donc le canvas continue d'évoluer, et on dirait que Google attend la fin des changements.
OK je crois que je pige mieux. Les tests sont faits avec une émulation d'un Moto G, donc un vieux téléphone, soit avec les options "processeur 4x plus lent" et "connexion 4G lente" de l'onglet "performances" de chrome. Et alors là en effet, je retrouve la lenteur, les deux premières captures de pagespeed doivent représenter les 10 secondes de LCP !
Donc il faut qu'on réduire la charge réseau, car avec proc / 4 et réseau illimité, le LCP est de 10 secondes. À l'inverse, ça donne 10 secondes, quelle que soit la rapidité du processeur.
C'est ça qu'il faut qu'on optimise, la charge réseau : la carte, Google ne semble finalement pas trop s'en soucier !
J'ai bien fait de persévérer : l'analyzer marche enfin.
C'est fort en enseignement : le module Panoramax à lui seul fait presque deux fois l’entièreté du code propre à cartes.app.
Je pensais l'avoir relégué à un chargement fainéant, mais non. Ouch.
De même pour ATProto, et idem pour MapLibre. Ce dernier, on pourra pas passer outre, mais ses 500 ko compressés m'étonnent, bundleophobia parle plutôt de 250.... Turf est aussi très gros avec 130 ko compressés.
500 ko compressés m'étonnent
La dernière version fait en effet 260Ko
https://github.com/maplibre/maplibre-gl-js/releases
je vois que le nouveau format MapLibre Tiles est vachement plus léger que les MVT qu'on utilise. Mais je ne sais pas si tilemaker le gèrera un jour ...
https://github.com/maplibre/maplibre-tile-spec?tab=readme-ov-file#comparing-with-mvt
Ah c'est super intéressant. Car le poids des tuiles et le temps de décompression se fait clairement sentir par l'utilisateur (pas par Google donc). Si Tilemaker ne le fait pas, est-ce que Protomaps ne pourrait pas le faire ? On a une étape de clustering après la génération des pmtiles par Tilemaker.
Ça en parle en décembre ici .
https://github.com/protomaps/PMTiles/pull/596#issuecomment-3594523300
Et ici sur Tilemaker, une conversation très contradictoire https://github.com/systemed/tilemaker/issues/856
Dans tous les cas il faudra qu'on teste une étape de conversion après génération.
C'est bizarre, j'ai beau essayer de faire du lazy-loading de Panoramax, next bundle analyzer me l'affiche. J'ai l'impression qu'il plante, car en inspectant le navigateur, ce qui est réellement téléchargé, je vois bien moins de données. À suivre...
Dans !1401 j'optimise le chargement des composants : StyleChooser, AddComment (Bluesky), TransportMap etc. sont chargés en fainéant. Le Map est séparé du bundle principal. Etc :)
Est-ce qu'on aurait pas interet, pour certaines dépendances assez volumineuses qui sont mises à jour moins souvent que cartes.app est déployé, de ne pas les bundler et d'utiliser un CDN (genre https://www.jsdelivr.com/ )?
Comme cela, elle serait normalement déjà dans le cache du navigateur après une 1ère utilisation (ce qui n'améliorerait sûrement pas la métrique Google mais surement l'UX utilisateur).
Je ne suis pas un expert js et j'aimerais ton point de vue sur cette idée (surtout que a priori avec react les dependences sont plutôt gérées avec un gestionnaire de dépendance)...
Oui il faudrait étudier les gains d'un CDN partagé pour l'utilisateur à sa première connexion. Mais c'est une décision assez lourde en conséquence, parce que qui dit mise en cache, dit mise en commun entre plusieurs sites, et donc tous les problèmes de vie privée qui vont avec. Donc je suis peu motivé pour l'instant.
Quand on sera à l'international, ça aura plus d'intérêt car les CDN permettent aussi de servir le tout depuis un serveur plus proche. Mais on peut facilement faire des fichiers maison servis via CDN sans jsdelivr & co.
Le seul cas pas optimisé, c'est quelqu'un qui aurait chargé maplibre v5.15 sur un autre site avant d'arriver sur cartes.app. Mais concrètement aujourd'hui, dans le périmètre français, je pense qu'on doit être un des plus gros sites à proposer MapLibre, et surtout sa dernière version quasi en temps réel 😅
Voilà, une petite dernière optimisation sur les icônes du menu rapide qu'on chargeait en double par rapport aux icônes de la carte. Ça en fait un paquet, d'optimisations. Je vais m'arrêter là, !1401 est déployée sur https://dev.cartes.app, n'hésitez pas à la tester !
en raison de #1369 j'imagine que tes optimisations n'ont pas concerné indoor= ? Tu penses que c'est négligeable ?
Faudrait mettre à jour ce ticket avec les même analyses aujourd'hui suite à !1401 et autres optimisations.
Et clôturer si on estime qu'on peut plus faire mieux ?
Oui il reste encore plein de choses à faire.
Pour moi l'une des meilleures optimisations qu'on doit faire, c'est de commencer à charger les infos du lieu contenues dans les tuiles, en attendant qu'Overpass réponde. Quand ce dernier va bien et que la 4G est bonne, c'est instantané. Quand c'est pas le cas, ça casse l'expérience alors qu'on pourrait déjà zoomer sur le lieux et en afficher le nom.
Exemple pratique : là je viens de taper "Paris", et cliquer sur le résultat. Photon nous donne déjà les coordonnées ! Donc le zoom pourrait être immédiat. Les informations complètes d'OSM n'étaient pas très intéressantes ici.
@laem wrote in #1366 (comment):
je viens de taper "Paris", et cliquer sur le résultat. Photon nous donne déjà les coordonnées ! Donc le zoom pourrait être immédiat.
Sur ce genre de cas, c'est la géométrie de la relation qui alourdit fortement la réponse overpass, non ?
Mais à part ça oui très bonne idée d'utiliser les coordonnées présentes dans photon.
Oui c'est possible. Mais là tu vois en bonne 4G et/ou photon dispo, c'est presque instantané de taper Paris et de le charger.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?