La webperf c’est du business.
On le ne répétera jamais assez mais avoir un site qui “rame” fait fuir vos utilisateurs ou clients potentiels. La vitesse de chargement ne devrait pas être une “feature” comme les autres, c’est celle que tout le monde devrait mettre en premier. Vous pouvez avoir le réseau social de 3ème génération ou l’offre qui tue, s’il faut attendre 3 secondes sur chaque page, on zappe !
La webperf a un impact sur votre business, tout simplement. Chez Fasterize, les premiers tests qu’on a fait chez un voyagiste en ligne montrait sur 2 mois des taux de transformation en hausse de 20%. Plus récemment, environ 10% de gain sur le taux de transfo d’un site de vente privée. Cela donne quand même à réfléchir non ?. Qui passerait à côté de même 2, 5 ou 10% d’augmentation de taux de transformation sans rien toucher à son site ?
La webperf c’est de l’organisation.
Faire un site rapide n’est pas qu’une affaire de technique. Faire un site rapide est une affaire de technique, garder un site rapide est une affaire d’organisation.
Dans ma précédente expérience de CTO chez RueDuCommerce.com, nous avons constamment travaillé à faire que le site soit le plus rapide possible. Mais dès que l’on mettait en place des opérations “commandos”, 6 mois plus tard, il fallait recommencer.
Pourquoi ?
Parce que concaténer 3 fichiers à la main et les déployer, c’est facile. Mettre en place le système qui concatène les CSS de tous les templates du CMS maison en fonction d’une page donnée, c’est plus compliqué.
Parce que minifier, c’est facile en ligne de commande. Le faire manuellement avant chaque mise en prod, c’est barbant.
Parce que demander à son graphiste/webmaster/intégrateur de mieux compresser ses images, c’est facile. Mettre en place le système qui les compresse avant de les envoyer en production, c’est plus compliqué.
Parce que décider de faire un sprite une fois, on a l’impression d’être au top et c’est facile. Maintenir un sprite c’est compliqué, à fortiori plusieurs. Combien de fois j’ai vu des sprites2.png, sprites2_new.png cohabiter avec le bon vieux sprite.png …
C’est humain, si ce n’est pas automatisé, personne ne veut répéter sans cesse une opération fastidieuse.
Et ça vaut aussi bien pour les dévs que pour l’exploite ou l’admin sys. Configurer un apache pour qu’il ait les bons headers de cache et la bonne config Gzip, ok, facile.
Répliquer ça sur 10 serveurs, hum, ça peut être long et fastidieux.
Propager ces configs lors de migrations, idem, ça peut être source d’erreur.
Parce que réduire de 10, 20 ou 30% le temps de chargement c’est facile par rapport à un instant donné.
Suivre ce que ça donne dans la durée, tout de suite, ça demande plus d’investissement …
Organisation = automatisation = usine de dév
Bref, vous l’avez compris, la webperf c’est d’abord de l’automatisation. L’automatisation ça prend du temps à mettre en place.
Chez Fasterize, l’automatisation est une de nos valeurs fondamentale. Et souvent nous pensons que nous ne sommes pas une énième solution technique un peu siouxe, un cache, un Varnish, etc …. Non, nous sommes une solution d’automatisation de la webperf. Nous sommes un des composants de votre futur usine de dév !
Et vous ? Comment êtes vous organisés pour produire de la webperf ? Avez vous automatisé la création de vos CSS, la compression de vos images, vos sprites ? Votre mise en prod nécessite combien d’étapes ? Si vous avez des exemples pour illustrer, on est preneur !
