Si, au début, Javascript est arrivé discrètement, pour « égailler » un peu les pages, aujourd’hui, c’est un vrai feu d’artifice !
Bien souvent, les sites chargent plus de 15 scripts, qui représentent souvent plusieurs centaines de Ko.
Sans oublier le code javascript ajouté directement dans les pages…
Le résultat est que les pages sont lourdes : lourdes à charger, et lourdes à exécuter.
En fait, bien souvent, on importe des librairies, et on en utilise une petite sous partie.
Quel dommage, surtout quand on connait l’importance d’avoir des sites qui répondent vite…
Comment en est on arrivé là ?
En fait, c’est une dérive, largement encouragée par pas mal de boites du secteur.
Je m’explique.
Pour la plupart des entreprises, la partie technique du site e-commerce est un centre de cout, pas un centre d’investissement (dommage 😉 ).
Dans un tel contexte, l’ajout de fonctions au site est toujours une négociation difficile.
La parade ? Le Javascript !
Les boites viennent vous voir, et vous explique que leur solution est « non intrusive », et qu’il suffit d’ajouter « un petit script de rien du tout ».
Et ça marche ! En quelques heures, le site a intégré une nouvelle fonction, et cela n’a presque rien couté en intégration…
Mais voilà, tout cela à un prix : le « petit code javascript » inclus un autre fichier, bien plus gros, qui lui même fait appel à des fonctions externes… et la page a pris 20, 30% de temps de chargement en plus, sans compter les bugs « qui viennent avec » parce que certaines fonctions sont incompatibles, les unes avec les autres.
Tout cela se corrigera avec le temps, quand la qualité deviendra un critère de performance (ce qu’il est vraiment !).
La qualité, cela doit aller jusqu’au bout, jusqu’au contenu qu’on envoie sur le poste du client.
Le pire, c’est qu’il n’est pas très compliqué de faire le ménage là dedans : compiler regrouper les fichier javascript, supprimer les fonctions inutiles, compresser tout ça… Et gagner de précieuses secondes en temps de chargement !