Étude des performances

[bruhnild]

Constat

Lors de la navigation sur certaines pages Geotrek-Rando V3 (exemple : https://pagespeed.web.dev/analysis/https-gtr3demo-ecrins-parcnational-fr-information-10-Des-refuges-pour-une-nuit-en-famille-dans-le-Parc-national-des-Ecrins/4njnbksivj?form_factor=mobile)](https://pagespeed.web.dev/analysis/https-gtr3demo-ecrins-parcnational-fr-information-10-Des-refuges-pour-une-nuit-en-famille-dans-le-Parc-national-des-Ecrins/4njnbksivj?form_factor=mobile, Lighthouse met en avant un poids important du JavaScript chargé initialement. Cela nuit aux performances, notamment sur mobile.

Une analyse du bundle (ANALYZE=true yarn build) a permis d’identifier plusieurs pistes concrètes d’optimisation :

Analyse du bundle

rando3D.js (600 Ko)

• Chargé asynchrone uniquement à la demande (lors du clic sur "Voir la randonnée en 3D").
• Peu d’impact immédiat sur le temps de chargement initial.
• Optimisation non prioritaire pour l’instant, à revoir plus tard.

App.js (_app-9e46332496513d8f.js) (> 1 Mo)

Ce fichier est chargé systématiquement, quel que soit le point d’entrée.

Compression SVG

La compression SVG est faite côté front et pour cela la bibliothèque SVGO embarque CSSO et CSS-tree soit les 3 plus gros paquets du bundle.

• Ces bibliothèques sont utilisées pour la compression SVG à la volée côté client.
• Or, elles pèsent lourd et peuvent être retirées du bundle si le traitement est effectué en amont, côté Geotrek-admin.

Gain constaté : taille du bundle divisée par plus de 2 sans ces librairies.

Proposition :

• Déplacer la compression/optimisation SVG côté Geotrek-admin, lors de l’upload.

• Avantages :

  • Empêche l’upload de fichiers SVG malformés.
  • Réduction de la taille des fichiers SVG stockés et transférés.
  • Amélioration des performances côté GTR (pas de traitement JS à la volée).
  • Bundle JS plus léger et plus rapide à charger.

Sentry (et Semver)

• En supprimant également Sentry, le poids chute encore davantage.
• Pas envisagé à ce stade (utile en production), mais cela met en évidence le coût en performance.

i18n

• La bibliothèque i18n utilisée est également assez lourde.
• Il pourrait être pertinent de la remplacer par une alternative plus légère, mais cela nécessite un travail d’étude et d’évaluation.

Propositions concrètes d’amélioration

1. Déporter la compression SVG côté Geotrek-admin.
2. Supprimer SVGO / CSSO / css-tree du bundle Geotrek-rando.
3. (optionnel) Étudier une alternative plus légère à i18n.
4. Documenter les dépendances "coûteuses" et leur usage pour arbitrages futurs.