Feature/stop with svg sprites

[firestar300]

À la suite du We Love Speed 2023, une des nombreuses recommandations de la web perf était d'arrêter d'utiliser les sprites (anciennement PNG et actuellement SVG). Charger un sprite de SVG assez lourd pour n'afficher au final que quelques icônes sur une page n'est pas oufissime.

C'est pourquoi dans cette PR, je vous propose d'arrêter la génération de sprites SVG et d'utiliser les fonctions the_icon() et get_the_icon() pour afficher les SVG en plain.

Les SVG générés dans le dossier dist possèdent la classe icon, les attributs aria-hidden="true" et focusable="false".

En attente de voir vos retours.

[Rahe]

Tu as du matériel à lire là dessus ? J'ai cherché pas mal de fois mais je n'ai jamais trouvé le benchmark etc. mais rien de concluant.

[herewithme]

source: le CTO de Fasterize au We Love Speed
il a évoqué HTTP2

[firestar300]

@Rahe

Le top 10 des perles webperf — Stéphane Rios — We Love Speed 2023

Voir aussi cet article : https://cloudfour.com/thinks/svg-icon-stress-test/

[Rahe]

Ok, mais ça ne compare pas les perfs entre les 4-5 méthodes.
Je check la vidéo.

[Rahe]

Bon son arugmentaire : "on a du http2 ne faites plus de sprites" me semble léger quand même.
Tu peux faire un bench avec les 2 techniques sur la même base ?

• Sprite
• Fichier seuls

En HTTP2.

[Rahe]

Hey,

J'ai fait des ptits tests de mon côté :

• https://devnico.beapi.space/test-svg/ : fichiers individuels
• https://devnico.beapi.space/test-svg/index2.php : un sprite

Au final, la différence se situe sur le temps du premier print significatif.
fichiers : tôt
sprite : plus tard

Type	FCP	LCP	Taille	DomcontentLoaded
Sprite	0,2	0	641Kb	79ms
Fichiers	0,31	0,31	908Kb	401ms
Sprite 3G - CPUX4	1,0	0	641Kb	0,91s
Fichiers 3G - CPUX4	0,73	0,373	908Kb	1,38s

On a donc des performances moins bonnes en cache vidé, un temps de chargement plus lent et un poids plus important.

Cependant en sprite, l'interface "pop" au lieu d'avoir fichier par fichier qui peuvent être optimisés en http2 on a un payload.

Il faut aussi souligner qu'une fois les fichiers en cache, la version fichier par fichier est plus rapide : 140ms en fichiers en moyenne vs 260ms en sprite en moyenne.

Les fichiers peuvent aussi être lazyload fichiers par fichiers, là où le sprite ne peut pas être évité.
Le preload/fetchpriority peut aussi entrer en jeu permettant de preload quelques icônes en haut de page, laissant la possibilité d'avoir un plsu petit payload pour les fichiers.

A la lumière de tout ça, j'aurai tendance à faire du fichier par fichier aussi.
Mon exemple n'est pas "représentatif" car on a une page avec 84 icônes mais ça permet de grossir les résultats.

Qu'en pensez-vous ? :)

[herewithme]

Je pense que tu pourrais faire un article sur le blog de BE API avec tes tests :)

[francoistibo]

TODO : report de la configuration SPF de @ptesei sur cette PR ?

[francoistibo]

pb soulevé par @n-langle : on perd les classe pour les viser directement. solution de contournement, on utilise un wrapper.

[francoistibo]

20.11 : acter si on part sur des SVG inline ou des Sprites (ou un mix des 2)

[Rahe]

Partir sur un mix des deux pratiques :

1. Pour les icônes "d'interface" utiliser un sprite
2. Pour les icônes contribuées en plus : utiliser les fichiers + le sprite rendu disponible dans le selecteur d'icônes

[firestar300]

pb soulevé par @n-langle : on perd les classe pour les viser directement. solution de contournement, on utilise un wrapper.

Fonctionnalité ajouté dans 4a2e0fa.