La folie Javascript

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 !

30 commentaires

  1. et surtout, ne pas compiler avec les infos debug, ça alourdi inutilement ;o)
    il faut compiler impérativement le javascript pour chaque navigateur et chaque OS, comme ça, c’est plus optimisé. On aura vraiment tout lu …

  2. faut voir qui dit des idioties. Là, on parle d’optimisation de code, et de vérifications de syntaxe, en version labs qui plus est. Ce n’est pas de la compilation. Je ne vois pas ce qui te permet de dire que ce n’est pas ce que l’auteur voulait dire.
    En tout cas, à ma connaissance, à ce jour, il n’existe pas de compilateur javascript.

  3. pour être plus précis dans ma réponse, il existe des outils pour optimiser ton javascript, mais ton serveur web enverra toujours du texte au navigateur. C’est le navigateur ensuite qui eventuellement compilera ton script pour l’executer

  4. Et pour finir sur le sujet:

    « De façon parfois un peu abusive, on étend le sens du mot compilateur (présenté ci-dessus comme un traducteur d’un langage de programmation vers des instructions machines) pour l’appliquer à n’importe quel traducteur. Typiquement, toutefois on s’attend à ce que le langage d’entrée, ou langage source, soit de plus haut-niveau que le langage de sortie, ou langage cible. Cette idée de haut-niveau signifie que le langage source contient des construction synthétiques, faciles à comprendre par un homme, tandis que le langage cible exprime des opération élémentaires, faciles à réaliser par une machine. »

  5. Les librairies, et leurs nombreux plugins, y contribuent beaucoup. Plein de fonctionnalité en 1, 2, … 10 scripts, mais tellement facile à installer. Pas vraiment besoin de savoir faire du javascript : un peu de HTML et de CSS, plus une pincé de javascript simplifié pour lancer le tout.

    Il arrive même sur certains CMS, de charger 2 librairies javascript (genre Jquery) car 2 plugins du CMS utilise des librairies différentes…

  6. Je ne voulais pas parler de compilation « native » bien sûr, mais d’outils qui permettent de « compresser », optimiser le code : réduire sa taille, regrouper en un seul fichier, supprimer les fonctions inutiles, …

    Pour info, compilation, cela ne veut pas dire générer du code natif, mais simplement passer d’un langage à un autre.

    Ceci dit, dans ce cas, il ne s’agit effectivement pas de compilation, j’ai corrigé l’article.

    @Jim Harbow> Merci, je pensais effectivement à ce type d’outils.

    @MecaTrouve> Exactement, c’est bien ce type de situation qui a motivé cet article.

  7. Ok, j’admet avoir été trop facilement narquois. Là je suis d’accord. J’en profite pour te féliciter globalement pour la qualité de tes publications.

  8. Bonjour,
    Ce n’est pas un problème lié aux seuls sites de e-commerce. C’est une généralisation.
    D’ailleurs, WordPress est l’exemple même de ce « désastre » avec sa multitude de plugins.
    Un artisans du web prendra le temps de voir ce qui peut être regroupé et codé en dur plutôt que de rajouter des rustines qui finiront un jour ou l’autre par tomber.
    Mais bon, passage obligé du web (certainement), il y a une notion de coût qui prend le dessus sur la qualité : le site est vite fait, (mal fait), à bas coût, le retour sur investissement sera plus simple à réaliser.
    Ça me rappelle les premières années après une « bulle internet » où l’on récupérait des clients dessus de leur premier site 🙂

  9. Ce que vous dites est totalement vrai mais le défaut n’en vient définitivement pas à JavaScript. Une seule chose me chagrine, le titre est racoleur et le client lambda en lisant cet article retiendra 2 choses :
    – Le javascript, c’est mal ;
    – Je me doutais que mon agence m’avait floué, maintenant, j’en suis toujours plus convaincu.
    Dans l’histoire, JavaScript prend pour sa pomme inutilement car c’est le non-souhait d’investir et l’incompréhension massive mais pas générale de ce langage qui est en tort.

    Au passage, en parlant d’optimisation, votre site, bien que pas très long à afficher oublie certaines optimisations de base dont certaines que vous citez vous-mêmes dans cet article. Je pense par exemple aux 9 fichiers de script et inclusions directes de script dans votre entête (erreurs : nombre, compression, position).

    Ceci dit, je retiendrai quand même que vous avez suggéré que la technique devrait être vu un centre d’investissement. On récolte ce qu’on sème.

  10. @MathRobin> Ah, enfin.

    Je me demandais qui serait le premier à dire que mon blog n’est pas un bon exemple ;).

    Javascript n’est pas le seul problème, mais c’est un sujet quand même. Mon idée est de rappeler qu’il ne faut pas inclure de librairie JS à la légère.

  11. Dans le ecommerce aujourd’hui, impossible de se passer de JS… enfin ; impossible, non, disons plutôt que sans Javascript pas de carrousel, pas de panier animé, pas de vérifications des champs de formulaires etc. Bref, on est bien obligés, mais quitte à devoir utiliser Javascript, autant le faire d’une manière optimisée. Donc exit les JQuery (dont, effectivement, il n’est pas rare de trouver plusieurs versions sur le même site + du code supplémentaire) et autres bibliothèques. Il faut donc coder son JS au plus serré, au plus près des besoins pour qu’il soit léger, le plus léger possible.

    Quand au fait de tout placer dans des fichiers externes, c’est bien ce qu’il faut faire, mais pour certains scripts (par exemple un menu) on est obligés d’intégrer directement le code dans la page, pour ne pas perturber l’affichage.

    Concevoir des boutiques en ligne, c’est vraiment une histoire de compromis

  12. Ah bravo ! Votre site charge le javascript comment-reply.js qui n’est pas utilisé !
    Bon, il fait juste 786 Bytes, ca va. Par contre, vous pourriez charger la librairie JQuery depuis google en version minifié, vous gagnerez 50 KB.
    Ce n’est pas comme les fichiers de Facebook. Pour charger un module affichant la trombine de vos «amis», un site peu télécharger jusqu’à 8 fichiers chez Facebook.
    Cette page même, pour afficher «J’aime», a charger un fichier de 48.7 KB !
    Pour info, un bouton google+ c’est pas mieux…
    Ah bah oui, mais pour du fucking social business 2.0, on est prêt à tout !

  13. @François> Oui, complètement. Il ne s’agit bien sûr pas de supprimer JS, mais de faire ça de manière plus pro !

  14. Si on va par là, les optimisations sont nombreuses et impossible à lister ici je pense.
    Le JavaScript est l’un d’un « problème ». Mais ce n’est pas un problème si il est bien utilisé. Comme toute technologie en fait.
    J’ai écris une série d’article sur l’optimisation si ça vous intéresse : http://www.prelude.me/index.php/category/web-performance/
    Chaque proposition est à adapter au projet, à la demande, aux besoins : pas la peine de sortir la Ferrari pour aller chercher du pain 😉

  15. @Prélude> Complètement en phase : les optimisations sont a adapter à chaque contexte. Pour ce blog par exemple, vu qu’il a un contenu très léger et rapide à charger, et qu’il n’y a pas (encore 😉 ) 5000 sessions simultannées, les optimisations sont moins importantes que pour un site ayant une audience forte, avec des pages avec pleins d’images, … Bref, un gros site e-commerce quoi 😉

  16. François, pour travailler comme des pros, il s’agirait d’abord que la communauté technique, mais aussi son entourage, c’est à dire les chefs de projet, les clients et autres, voient JavaScript comme un langage et non comme un scotch voué à tous les bidouillages.
    Je chronique régulièrement autour de JavaScript et le niveau technique général est déplorable. Le copier/coller fait fureur et personne ne prend la peine d’essayer de le comprendre. Pourtant il est simple à apprendre, faut juste s’en donner la peine. En quelques heures les fondamentaux qui manquent à l’essentiel de la communauté peuvent être acquis.

    @ManUtopiK : attention à distinguer 2 choses. Le synchrone et l’asynchrone ne sont pas les mêmes choses. Analytics, Google+ et même le bouton j’aime (il me semble) sont désormais des éléments dits asynchrones. C’est à dire qu’ils sont chargés après le contenu, quand l’essentiel de la page est déjà chargé et que le lecteur peut commencer à lire confortablement. Oui, en soit ça alourdit la page, mais pas dans son chargement initial. Par contre, effectivement, l’usage d’un CDN comme celui de Google est recommandé mais si il en existe d’autres.

  17. @MathRobin> Oui, on est en phase, je constate effectivement un usage abusif du copier – coller « vite fait » sans vraiment prendre le temps d’analyser.

    Après, je pense que la « direction » doit être donnée par les managers. Si on ne donne pas de cap, on a peu de chance d’y arriver 😉

  18. De plus avec l’arrivée du HTML 5 et du mode déconnecté, j’ai peur que le javascript reprenne le dessus par rapport à la rapidité du chargement de la page.

  19. Au dela du poids global que peuvent représenter les scripts s’est le nombre de requêtes qu’il génère.

    Chaque requête est toujours frappé d’un délai de latence et plus vous avez de requêtes simultanées d’un client, plus ce temps de latences augmente.

    Au dela de la compression, la concaténation des scripts est la premières des voies a rechercher, ensuite on compresse.

    Également, il est simple de forcer le client a mettre en cache un bon paquet de fichiers dont les scripts js, c’est pas cher et ca mange pas de pain.

    Après les scripts, il a les feuilles de styles qui peuvent également être concaténées et compressées.

    Les images regroupées dans un sprite qui peut également être optimisé pour trouver le meilleur rapport poids/qualité.

    L’activation des la compression des requêtes en gzip par le serveur est également une façon simple de sauver un peu de bande passante.

  20. @Chrysalide : c’est un bon résumé des précos que l’on trouve dans les plugins YSlow et Page Speed.

    @François : comme tu l’évoques « Pour la plupart des entreprises, la partie technique du site e-commerce est un centre de cout »–> au delà du site, cela s’applique aussi aux équipes.
    Dans pas mal de cas le staff technique est réduit au minimum et les problématiques d’optimisation de script / CSS et consorts passent en second plan.
    D’autre part un budget pubs / market se négocie plus facilement qu’un budget optim technique -> C’est plus sexy

  21. @Eric : Effectivement ces préconisations sont présentes dans les plugins d’aide a l’optimisation mais si on en juge du niveau d’optimisation de bon nombre de sites internet à ce jour, il est bon de les rappeler car des sites de ecommerce avec une homepage avec un temps de chargement ahurissant, il y a un paquet.

    et il n’y a pas pire qu’un client qui attend que qu’une page se charge.

  22. Manque de temps (ie, délais), code « à l’arrache » laissé en héritage équipe par équipe, manque de considération/confiance de la part des décideurs dans les équipes front-end, font que l’on se retrouve avec ce genre de problème.

    Mais ce n’est que la partie visible de l’iceberg, celle qu’on inspecte sous firebug et qu’on subit directement à l’utilisation du site ; du côté serveur, invisible, c’est la même histoire.

    Il n’y a *aucun* problème avec JavaScript en soit -même pas de problème à charger une dizaine de fichiers .js, du moment que c’est parfaitement controlé.

    Pour moi, tout est un problème de design (dans le sens pur, pas dans le sens de la maquette photoshop), pas de vision d’ensemble, globale, pas de direction, pas de concept : juste une succession d’idées et d’envies contradictoires ajoutées les unes par dessus les autres, une évolution basée sur l’ajout perpétuel de fonctionnalités tape-à-l’oeil et de complexité.

    Le tout dans une course contre le temps qui ne laisse jamais sa place au travail bien fait.

    Avant d’être un échec technique, c’est la faillite intellectuelle des décideurs qui entraînent la lourdeur des pages de sites d’e-commerce 😉

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *