mobile phone smartphone

En tant qu’éditeur.rice de site web, vous avez la main sur son contenu, son architecture, son design… Et même si vous mettez en place toutes les optimisations webperf et bonnes pratiques, les conditions de navigation de vos internautes ne dépendent pas de vous (device et réseau, notamment).
Explorons l’un des risques que représente le JavaScript pour les temps de chargement sur les mobiles peu puissants, avec un retour d’expérience de Jean-Pierre Vincent, Consultant expert webperf.

L’épineux problème des temps de chargement sur les mobiles d’entrée de gamme

“L’excès de JavaScript dégrade fortement l’expérience de navigation sur un site mobile, et je constate que personne ne pense à vérifier les performances sur tous les devices - encore moins ceux d’entrée de gamme. Pourtant ce sont les premiers à être bloqués si les JS ne sont pas optimisés”, déplore Jean-Pierre Vincent.

Lors d’un travail d’amélioration des temps de chargement et de l’UX pour un site d’assurances, l’une des priorités a été de s’atteler à l’optimisation des JS. Le bundle (soit l’ensemble des fichiers JS) représentait alors 1,3 Mo à charger (1,82 s avec un Galaxy Note 3 en 4G, par exemple) et 4,2 Mo à exécuter (1,29 s d’évaluation + 367 ms d’exécution).

Javascript chargement webperf

Connaissance client.e : dis-moi quel est ton device, je te dirai comment tu navigues

Au préalable, le parc mobile des utilisateur.rice.s du site a été observé à la loupe pour mieux connaître les contextes de navigation les plus représentatifs.

Les résultats de cette étude ont montré que, en dehors des 51 % de l'ensemble des visiteur.se.s qui disposent d’un iPhone ou d’un iPad, 30 % ont un smartphone d’entrée de gamme qui peut même être très vieux. C’est une part du trafic non négligeable pour qui l’expérience de navigation doit être la plus fluide possible !”, ajoute Jean-Pierre Vincent.

mobile javascript répartition webperf

A la lumière de ces informations, la mise au régime des fichiers JS s’est déroulée en deux étapes.

JavaScript : opération “Dégraissage et Division”

Phase 1 : dégraisser le bundle JS

L’analyse du bundle a permis d’identifier précisément les points faibles - ou plutôt, les lourdeurs. 

Voici une liste non exhaustive des actions de dégraissage entreprises : les SVG ont été sortis du bundle (et ne sont même jamais chargés sur mobile), le build est passé en mode “production” ce qui déclenche d’autres optimisations dans des librairies comme React, les outils de build et les 10 plus grosses dépendances ont été mises à jour puis optimisé.e.s (Babel, Polyfill, coreJS, momentJS, D3, GSAP, Ramda, Request…)...

Les fichiers sont alors passés de 3,8 Mo avec un temps d’exécution de 1,17 s à 973 Kb pour un temps d’exécution de 200 ms sur un téléphone Samsung Galaxy Note 3 !”, commente Jean-Pierre Vincent.

bundle javascript webperf

Phase 2 : diviser pour mieux régner

La 2ème étape a consisté à diviser les fichiers pour les charger plus rapidement. Initialement, il y avait un seul bundle par page / route et par module. 

En découpant les bundles, chaque page contient dorénavant entre 2 et 4 fois plus de fichiers, mais qui, ensemble, pèsent 2 à 4 fois moins lourd.
Le temps d’évaluation (parsing) est alors divisé par 2 voire 3, et le code s’exécute d’autant plus tôt. Voici un exemple sur une page React avant/après les optimisations, avec une connexion mobile en Inde. On repère l’affichage du pop-in d’acceptation des cookies qui marque la fin de l’exécution des scripts sur la page : les modules React en arrière plan s’affichent 2 fois plus vite qu’avant (et ce dans tous les pays).

Optimiser vos JS en vaut la peine, tant pour le confort des mobinautes que pour vos performances marketing et business.

Pour exemple, voici la variation de CA que l’un de nos clients a pu observer sur son site marchand après l’optimisation des JS, répartie par systèmes d’exploitation. Les barres représentent le CA pendant les soldes pour l’année 2019, et le trait vertical indique le CA réalisé l’année précédente, soit avant les optimisations.

CA OS webperf

Les performances et l’UX sur les téléphones Android ont été tellement été améliorées lors de cette optimisation que le CA a plus que doublé d’une année à l’autre, pour dépasser le chiffre généré sur iOS !

En conclusion, pour procéder à des optimisations efficaces, vous avez besoin de vous poser les questions suivantes en amont : quels mobiles ? Quelle connexion ? 

Et surtout, pensez bien à les tester sur les mobiles qui correspondent à ceux de vos utilisateur.rice.s qui ne sont pas toujours équipés des modèles dernier cri les plus performants.

Ce cas pratique est extrait d’une présentation de Jean-Pierre Vincent sur la webperf en 2019, disponible ici en pdf (et en vidéo chapitrée). Il y aborde également :

  • L’optimisation des polices : formats Eot,Woff, Woff 2, subsetting et hébergement des fonts, stratégie d'affichage ;
  • La compression des images et des vidéos : formats (JPG, SVG, PNG, GIF…) et types de compression, chargement à la demande et responsive ;
  • Les Third Parties : tests A/B, dépendances, pubs, trackers… comment les inclure ;
  • HTTP/2 : de la théorie à la pratique, l'utilisation de PUSH et les optimisations possibles.

Vous souhaitez en savoir plus sur les optimisations webperf,
et comprendre comment Fasterize peut vous aider à les automatiser intelligemment ?


Découvrez nos fonctionnalités

 



Warning: count(): Parameter must be an array or an object that implements Countable in /nas/content/live/fasterizeblog/wp-content/plugins/slickquiz/php/slickquiz-front.php on line 59
Hello SMX Paris !