Plug-ins de réseaux sociaux à la noix et performances

Plug-ins de réseaux sociaux à la noix et performances (le 4 septembre 2015)

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é.

Une Waterfall

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. :)

Permalien :

Flux RSS des commentaires de ce billet : https://www.nicolas-hoffmann.net/rss/commentaires.php?id_news=1671

5 commentaires

Posté par David FF le 05/09/2015 à 8:37:00
Oui j'avais déjà remarqué que ces plugins étaient lourds mais je ne savais pas qu'il l'étaient à ce point !
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.
Posté par fvsch le 05/09/2015 à 10:00:09
Et les plugins qui gèrent le partage sur moult réseaux, tels que ShareThis, ne sont pas mieux.

Au boulot j’ai commencé à réfléchir à des grilles indicatives de "lourdeur" de différents éléments et fonctionnalités d’une page web, pour pouvoir communiquer avec les graphistes, les chef-fe-s de projet et les client-e-s. De la même manière que certains outils de reporting de performance web permettent de fixer un «budget de performance» avec des seuils chiffrées (en centaines de Ko, en secondes…), on pourrait évaluer une maquette ou même un wireframe à partir d’une telle grille (en points de "lourdeur"), et fixer des seuils à ne pas dépasser.

C'est une idée comme ça, compliquée à mettre en œuvre, et pour l’instant on n’a pas avancé dessus (de toute façon on a zéro process pour que le dev front participe à la conception, grrrr).
Posté par Geoffrey le 05/09/2015 à 10:59:03
Hello,

Même constat il y a de cela quelques années, du coup j'avais développé <a href="http://wordpress.org/plugins/juiz-social-post-sharer">Social Post Sharer</a> pour le cas d'une utilisation sous WordPress.
Mêmes les compteurs sont optionnels et fabriqués pour un chargement asynchrone.

Merci pour ton article !
Posté par Nico le 13/09/2015 à 6:06:28
@David @Geoffrey : j'avais aussi pris l'habitude de ne plus intégrer ces boutons ainsi, et là j'avais voulu réessayer (faute de temps et en me disant que ça ne pourrait pas être aussi horrible). Bien mal m'en a pris.

@fvsch : au boulot, ils savent qu'il ne faut pas prononcer le mot Addthis devant moi, sinon je hurle. (sourire)

L'idée est intéressante, il faudrait la creuser.

> zéro process pour que le dev front participe à la conception

Ça c'est un gros problème : impossible de maitriser la qualité si on n'est pas dans la chaine au début.
Posté par Nicolas le 24/09/2015 à 19:12:53
Il faut surtout éduquer le client (ou soi-même) : est-ce que les boutons de partage sont :
1) indispensables : combien de % de visiteurs vont cliquer sur le bouton de partage, 1%, 0,1%. On va donc provoquer le chargement de 300ko de données pour une fonctionnalité très peu utilisée
2) utilisables dans leur forme prémachée par les réseaux sociaux : est-ce utile de charger le nombre de partages ? est ce qu'un fichier JS est réellement la bonne solution ? On peut très bien charger un icone dans notre police d'icone pour facebook et twitter et créer un bouton avec très peu de ressources.

Pour les sites que j'édite la réponse était la dernière (sourire)

Ajouter un commentaire









L'option « Se souvenir de mes informations » utilise un cookie, elle ne sera pas effective si vous les avez désactivés.

Les balises HTML ne seront pas interprétées, il est donc inutile d'en mettre. Par contre, les sauts de lignes de votre commentaire seront pris en compte, ne mettez donc pas de <br />, le site s'en chargera. Bien sûr, un commentaire vide ne sera pas ajouté !

L'auteur (autrement dit moi) n'est pas responsable des éventuelles fautes d'orthographe dans les commentaires.
Tout propos raciste et/ou insultant sera supprimé sans préavis. Les commentaires hors de propos destinés à faire de la pub pour des sites seront également supprimés sans ménagement.

Je vous prie de me pardonner, j'ai énormément de mal à lire le "langage" SMS, il n'est donc pas du tout interdit de s'abstenir de l'utiliser. Qui plus est, vous avez sûrement un clavier digne de ce nom et pas celui d'un téléphone portable. Ne vous gênez pas pour utiliser l'option "Prévisualiser" si vous voulez vous relire avant de poster, je vous en remercie d'avance !

Cet article a été écrit par Nicolas Hoffmann.

Ce site est la propriété de Nicolas Hoffmann.
Tous droits réservés, les textes du blog sont publiés sous licence CC BY-NC-SA.