Quel constructeur de site web offre la meilleure performance?

Les constructeurs de sites web (ou éditeurs WYSIWYG de sites) font partie intégrante du web d'aujourd'hui. Pourtant, ces outils sont souvent critiqués pour la lourdeur du site ainsi généré.

Aujourd'hui, on sait tous qu'un site lent vous coute des clients! Personne n'aime attendre et la moitié des visiteurs commencent à abandonner dés lors qu'un site met plus de 4 secondes a charger.

Dans cet article, je teste la vitesse de chargement pour les créateurs de sites principaux tel que Wix, Webflow ou encore Wordpress, mais quelques autres outsiders. J'ai a chaque fois du creer un site équivalent (même mise en page, même images, même rendu)

La mesure de la performance

Le tableau suivant montre les résultats de mes tests. Les sites y sont classés par taille à télécharger. Néanmoins le score lighthouse aurai été une métrique tout aussi intéréssante intéréssante pour le classement.

Le résultat

Site BuilderScore LHFCPSILCPTTICPUSize
Webflow802.10s3.10s4.20s4.21s643ms420Kbs
Wix771.72s3.02s5.02s5.04s1.451ms700Kbs
GoDaddy632.30 s3.02s3.93s7.02 s3.77s783 KB
Webnode483.75s4.92 s9.05 s6.26 s2.21s855 KB
Wordpress.com342.65s4.88s5.54s15.9s9.46s878 KB
Weebly393.40s6.74s7.33s7.40s3.74s996 KB
SquareSpace312.09s8.29s8.79s6.97s3.56s994 KB

Explications des métriques:

Score LH: représente le score LightHouse. LightHouse est un outil de Chrome de mesure de la performance d'un site web. Le score est globalement représentatif de la performance d'un site web et pourrait servir d'unique comparatif. J'ai inclus d'autres métriques car l'algorithme exact pour la mesure de ce score est difficile a trouver et donc il est possible que ce score soit biaisé ou injuste dans certains cas.

FCP: First Contentful Paint, le temps avant que le contenu soit rendu dans la fenetre du navigateur.

SI: Speed Index, le temps avant que la page n'atteigne son rendu visuel final.

LCP: Largest Contenful Paint, le temps avant que la page n'atteigne son status final, même si les derniéres modifications n'on pas modifié le rendu.

TTI: Time To Interactive, le temps avant que la page ne devienne interactive. C'est a ce moment que la page devient utilisable par l'utilisateur.

CPU: Le temps CPU, c'est a dire le temps utilisé a parser et éxécuter le code sur la machine cliente

Size: La taille des ressources à télécharger depuis le réseau (sans cache, tout inclus)

Review et interprétations

Avis sur Webflow

Avec une taille de document de seulement 2Kb, le chargement est plutot rapide. Il y a deux ressources bloquantes en JS et CSS, chacune ayant besoin d'une connection a un nouveau domaine. L'image viens ensuite un peu plus lentement car chargée depuis le style CSS mais l'ensemble reste correct niveau rapidité (4secondes environ).

Avis sur Wix

Wix charge plutot rapidement (environ 4s). On se rend compte que le contenu charge en premier et l'image ensuite. Wix charge beaucoup de javascript (66requétes pour 2secondes d'éxécution). Je n'ai pas trouvé de ressources bloquantes au rendu, a part le document html de base. Ce document en revanche pése pas loin de 100 KB ce qui explique la rapidité toute relative du chargement.

Avis sur GoDaddy

Le site sur GoDaddy contient plusieurs scripts qui sont bloquants. C'est dommage car on perd quelques secondes ici. Par contre l'image est intégrée en version basse définition dans le code html, ce qui rend son temps de chargement instantanné du point de vue de l'utilisateur. C'est un excellent point et seul cet outil propose ce type de feature.

Avis sur WebNode

Sur Webnode, aucun rendu n'est affiché pendant 4 secondes, puis tout apparait d'un coup!

En étudiant leur solution, on se rend compte que la totalité du code CSS est chargé de maniére synchrone via des @import, ce qui bloque le rendu totalement jusqu'a ce que tout le CSS soit chargé. On notera aussi que le CSS et les images sont placées sur un domaine à part, ce qui rend la page encore plus lente car une nouvelle connexion doit être initiée avec ce domaine.

A leur place, j'utiliserai le même domaine pour le CSS, mais je laisserai les images sur leur autre domaine histoire de paralléliser un peu et de gagner un peu de temps.

Avis sur Wordpress

Wordpress est relativement rapide a charger. On obtient la page en 4 secondes et l'image en 6, ce qui est franchement pas mal.

Par contre, la page prend une 15aine de secondes à devenir 100% chargée. Cette lenteur est dûe aux 355 requétes (oui oui! 355!) faites vers des domaines de tracking ou de publicité! On sent bien que la piorité ici n'est pas la rapidité...

Avis sur Weebly

Weebly est relativment lent. La page met 4 secondes a charger, et l'image n'apparait que 5 secondes plus tard. L'affichage lors du chargement inspire la lenteur au visiteur et le fait paraitre encore plus long qu'il ne l'est réellement! Les blocs de la page apparraissent en premier, puis le texte, et enfin les images.

Il serait possible d'optimiser le premier rendu en utilisant le code css: font-display: swap afin de ne pas bloquer le rendu pendant que la police charge. Mais il faut croire que les dévellopeurs chez eux n'y ont pas pensé et laisse le soin a leur utilisateur (non technique) de rajouter cette directive.

C'est dommage car avec ce simple changement, le premier rendu tombe a 2 secondes.

Avis sur SquareSpace

Squarespace fait partie des plus lents, mais avec la particularité que le contenu textuel s'affiche ultra rapidement, mais le reste se fait désirer.

A l'usage, on se rend compte que la moindre image prend des heures à charger! Il faut 4 secondes pour avoir le contenu mais 9 secondes avant d'avoir l'image!

En étudiant leur code, on découvre que les images ne sont pas inclues dans le html fourni. Le navigateur doit d'abord télécharger et éxécuter un script JS avant de commencer a charger la moindre image. C'est une décision d'architecture plutôt... intéréssante... on va dire...

Tags:

Qu'avez vous pensé de cet article?