beapi-frontend-framework
beapi-frontend-framework copied to clipboard
BeAPI
Feature/stop with svg sprites
À 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.
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.
@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/
Ok, mais ça ne compare pas les perfs entre les 4-5 méthodes. Je check la vidéo.
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.
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 ? :)
Je pense que tu pourrais faire un article sur le blog de BE API avec tes tests :)
pb soulevé par @n-langle : on perd les classe pour les viser directement. solution de contournement, on utilise un wrapper.
20.11 : acter si on part sur des SVG inline ou des Sprites (ou un mix des 2)
Partir sur un mix des deux pratiques :
- Pour les icônes "d'interface" utiliser un sprite
- Pour les icônes contribuées en plus : utiliser les fichiers + le sprite rendu disponible dans le selecteur d'icônes
pb soulevé par @n-langle : on perd les classe pour les viser directement. solution de contournement, on utilise un wrapper.
Fonctionnalité ajouté dans https://github.com/BeAPI/beapi-frontend-framework/pull/347/commits/4a2e0fa191019562377967b05a48398511adf4ed.