Rappelez-vous, c’était il y a quelques années. Une page de 500 kilo-octets avec quelques images mettait plusieurs secondes à s’afficher dans votre navigateur. Il fallait en effet un bon moment pour télécharger les données et permettre l’affichage des contenus.
Heureusement, depuis quelques années, c’est Disneyland. Toutes les agences sont en haut débit. Tous les acheteurs de sites sont connectés en haut-débit. Le monde est en haut-débit. Les navigateurs affichent les données de plus en plus vite. C’est la fête.
Dans les agences, le dernier responsable qualité Web ayant prononcé la phrase : « dis-donc, 700 kilo-octets, tu ne crois pas que c’est un peu beaucoup» a été lapidé au milieu de l’open-space.
Donc, t’as compris : le poids des pages, on s’en tape complètement.
Et le contexte mobile?
Que les usagers mettent plusieurs secondes à télécharger les pages sur les mobiles n’a aucune importance, de toute façon, tu comprends : on va bientôt avoir la 4G et même la 5G. Pas vrai ?
De toute façon, le nombre de G dans une connexion mobile évolue proportionnellement au nombre de lames sur les rasoirs. Ainsi, il existe des chances non négligeables que je puisse me connecter en 6G en me rasant avec un rasoir à 7 lames. C’est le progrès. Cela dit, il faut faire attention, car si les choses continuent à évoluer de la façon actuelle, il va sans doute rester possible de se raser avec un pauvre rasoir de loser à 2 lames (mais dans d’atroces souffrances), mais il risque d’être rapidement très difficile de naviguer avec un téléphone en 3G.
Bref, vous l’aurez compris, et ce n’est pas nouveau, nous avons un peu tendance à oublier l’importance fondamentale du poids de nos pages.
Mais ce n’est pas le plus grave.
Charger la mule
Quand bien même nous aurions pensé à optimiser le poids des pages, nous avons de plus en plus tendance à oublier l’importance d’autres paramètres :
- Le temps de chargement des feuilles de style (et de moults préprocesseurs et options)
- Le temps de chargement des scripts (Javascript, interactions et autres cochonneries…)
- Le temps de traitement des scripts et CSS (le temps de calcul et d’affichage des cochonneries sus-mentionnées)
Oui, pour afficher les pages du côté des usagers, il ne faut pas seulement télécharger la page HTML en elle-même, il faut également télécharger et traiter plein d’autres choses qui ont également un impact sur le temps nécessaire pour que la page soit utilisable…
Et là, en ce moment, c’est la folie. Les développeurs, designers, chefs de projets en agences ont des navigateurs de compétition, avec des machines de compétition, et ils développent des sites de compétition. No limit.
Le client réceptionne le site : wow. C’est magnifique. Sur mon navigateur de compétition, avec ma machine de compétition, c’est fabuleux, ça bouge de partout, c’est jeune c’est frais ça gigote. Vendu.
Pour peu que le pauvre usager final soit équipé d’un navigateur un tout petit peu moins à jour, un profil Firefox un tout petit peu chargé, ou une machine un tout petit peu moins puissante, et là, chez lui ça rame. Manque de pot, cet utilisateur de votre site est généralement assez important dans votre stratégie. Quand il n’est pas content, vous n’allez pas tarder à avoir des problèmes.
Et le délai de mise en service ?
Alors, voilà, en quelques années, nous avons amélioré la qualité des connexions. Assez logiquement, nous avons soit maintenu soit augmenté la quantité de données à télécharger. Le problème, c’est que le temps d’affichage des pages est toujours assez mauvais.
Avant, une page HTML mettait longtemps à se télécharger, mais une fois affichée une page était immédiatement manipulable. Maintenant, la page commence à s’afficher très vite, mais elle met un temps fou à devenir manipulable. Nos machines doivent travailler pour calculer les pages. Le délai de mise en service auparavant dû à du téléchargement est maintenant dû à du calcul. C’est ce que je résumais l’autre jour dans un tweet :
Quelques précautions
Pour la qualité perçue par l’utilisateur, le délai de mise en service des pages évolue trop peu. Il faut arrêter la course. Il faut que nous nous mettions au régime. Alors pendant que bat son plein la course aux fonctionnalités, à l’interaction, à l’effet « Wow », je vous propose quelques règles de bon sens :
- Faites maigrir vos pages, vos css, vos scripts, tout ce que vous pouvez ;
- Surveillez la nature et le poids des contenus proposés par vos prestataires et partenaires, notamment des régies publicitaires. Certains sites deviennent totalement inutilisables à cause de ce type de contenus mal conçus ;
- Si certains contenus, scripts ou contenus publicitaires ou autres ralentissent trop les pages, imposez des bonnes pratiques à vos prestataires. Dans le cas contraire, imposez quand même des bonnes pratiques à vos prestataires ;
- Méfiez vous des professionnels du Web, et notamment ceux qui travaillent dans le domaine du design et de la communication. Ce n’est absolument pas leur faute, mais pour être productifs, ils ont souvent besoin de machines très puissantes. Ils ont tendance à oublier la réalité de l’équipement et des connexions des utilisateurs. Il ne faut pas les en blâmer, mais il est de votre devoir de rester vigilant ;
- A chaque fois que c’est possible, optimisez les ressources et concentrez-vous sur ce qui vous fait vivre ou accélère vraiment les pages et les processus transactionnels ;
- Mettez en application la checklist Opquast ;
- Si vous faites du responsive design, anticipez également les contraintes liées aux connexions en contexte mobile ;
- Il est certes essentiel d’être compatible avec le dernier navigateur, de proposer les contenus les plus immersifs possible, de suivre les dernières tendances, mais pour tout ce qui impacte l’expérience utilisateur, il est souvent intéressant de rester un peu en retrait ;
- Laissez vos concurrents proposer des pages qui mettent un temps fou à s’afficher, se planter dans les grandes largeurs et récupérez leurs clients.
Quant à moi je vous laisse je vais balayer devant ma porte. Certains de nos propres services mériteraient un bon régime.
On est certes à l’ère du Haut-Débit, mais il ne faut pas oublier ceux qui se partagent un débit pourri de 1Mo aussi. Ca existe encore…
Je retourne faire mon ménage.
Ces mêmes experts du web qui conspuaient les sites en Flash au prétexte que ça prenait toutes les ressources machines et que ça mettait 10 ans à s’afficher. Les voilà qui refont les mêmes erreurs… D’aucuns diront que la comparaison n’a pas lieu d’être, le combo CSS/HTML/JS est bien plus fréquentable ^^ Lapidez-moi !!
Qu’importe, on a oublié la performance au passage.
J’en profite pour ajouter un point à ton exemple. Je bosse dans un gros organisme où nos connexions web sont soumises au bon vouloir de passerelles diverses et variées : proxy, pare-feu, anti-virus. Les pages trop riches en JS mettent bien plus de 2mn à se charger complètement (quand elles ne sont pas simplement bloquées quelque part dans le tuyau). Ami développeur, pense à ces contraintes :p
Bref, le JS c’est comme le foie gras, ça fait rêver mais ça se suffit à petite dose, sinon bonjour l’indigestion.
C’est pour ne jamais oublier cela que je pratique le « test sur la vieille croûte » : http://www.nicolas-hoffmann.net/sou…
Il n’est même pas question de tester sur des vieux navigateurs, mais juste de tester dans des conditions pourries ! 🙂