Après cette courte pause estivale pour ce blog, c’est reparti pour une rentrée. Et je ne résiste pas au plaisir de partager quelques chiffres qui m’ont bien choqué.
J’ai récemment mis en ligne un site de concours photo pour les HUG. Outre le fait que c’est mon premier site en .photo
, j’ai eu le temps de faire quelques tests vite faits au moment de la mise en ligne, cette dernière s’étant très bien passée. Précisons que je n’étais pas dans une quête de performance absolue, plus de simple curiosité.
Cela fait plusieurs conférences et autres articles que je vois qui indiquent de bien différer le chargement et l’exécution des scripts non critiques. Je me disais que ça ne pouvait pas être si terrible que cela sur le site dont je vous parle. Il n’y a qu’un script de partage et un script qui indique les « J’aime » (idiot innocent que je suis).
J’avais posé le script officiel de Facebook sans plus d’optimisations. Je lance une analyse… le document complete (page affichée) et le document fully loaded (tous éléments chargés) sont quasi-équivalents, mais le tout me semble plutôt lourd (+ de 700ko). Je suis un peu surpris, le site en question me semblait assez léger (hormis deux grosses images et un fichier JavaScript, rien de bien méchant). Le Speed Index est plutôt bon : vers 1500 (plus c’est bas, meilleur c’est, la moyenne étant à 4500).
Je décide de juste différer le chargement et donc l’exécution du script de Facebook, quand le DOM est prêt (grosso modo, la page sera construite, elle chargera ce script non prioritaire seulement à ce moment). Je relance les tests dans la même configuration (depuis l’Angleterre avec une bonne connexion), et là… grosse surprise !
Le résultat est là : affichage du site avec un chargement différé.
Le document complete est à 307ko et le document fully loaded est à 710ko ! En clair, ces deux boutons et leurs fonctionnalités ne pèsent pas moins de plus d’une fois le poids complet du site. Le Speed Index chute à 1327. Le site s’affiche en moins de 2,5 secondes, ce qui est plutôt satisfaisant.
Je ne sais pas pour vous, mais moi, je trouve cela choquant. Surtout à l’heure où l’on se plaint d’avoir des sites lourdingues, là c’est un peu fort de café.
De rage, je bricole en vitesse pour que ces boutons ne se chargent pas du tout sur le mobile. Je fais un essai avec une connexion moins performante sur mobile avec cette « petite » optimisation, le verdict tombe : 170ko (ce qui me semble très raisonnable), temps d’affichage correct. Je n’ose pas imaginer si je n’avais pas fait cette optimisation.
Un rapide test qualité sur Dareboost achève de m’engrincher au sujet de ce plug-in : les problèmes remontés viennent aussi de ce plug-in. Grmlbmlbmlb…
Je sais que la plupart de mes clients n’y pensent pas (et même certains s’en foutent complètement), mais pour de bon que ça m’interpelle. Ok, on peut me taxer de râleur à propos des réseaux sociaux. Il n’en reste pas moins qu’un tel impact sur la performance d’un site est bien trop important pour qu’on l’ignore.
En tout cas :
- il va vraiment falloir évangéliser auprès de nos clients sur le coût qu’ont ces plugins mal dégrossis qu’ils nous réclament sans même savoir pourquoi.
- Utiliser des solutions beaucoup plus légères comme Simple Sharing Buttons, et ne pas céder à la facilité des plug-ins officiels.
- Ou mieux… s’en passer.
La dernière option me plait bien. :)
Pour ma par je ne les utilise plus, fais un lien direct de partage (comme Simple Sharing Buttons). Et quand j'ai besoin d'afficher les vus, j'utilise l'api php de facebook/twitter.