Comment se charge votre page ?

Parmi les détails qui font ou défont l’expérience utilisateur d’un site web, je suis convaincu que le chargement d’une page joue un rôle très important. Bien sûr, il faut que votre site se charge rapidement. Mais même en se chargeant rapidement, certains détails peuvent trahir le manque d’attention porté à l’intégration d’un site.

Voici un exemple sur lequel je suis tombé ce week-end. Il s’agit d’un simple article sur Fast Company. Voici une vidéo du chargement sur mon iPad mini.

Chargement d'un article sur Fastcompany.com

Avec un poids total de près de 2 Mo et plus de 150 requêtes, cette page n’est clairement pas un modèle d’optimisation. Un test sur WebPageTest confirme qu’il y a du travail. Mais au delà d’une recherche de performance pure et dure, voici ce qui m’intéresse côté expérience utilisateur.

  1. Au bout d’une seconde, le HTML est bien chargé et le <title> de la page s’affiche dans l’onglet du navigateur. C’est plutôt rassurant pour l’internaute et ça confirme que la page est bien en train de charger, et que le serveur n’est pas en rade.
  2. Il faut ensuite attendre la troisième seconde avant de voir quelque chose s’afficher à l’écran. Mais tout ce que l’on peut voir, ce sont des couleurs de fond qui laissent imaginer la présence de texte. Parce que le site utilise des polices « non-standard » appelées en CSS, aucun texte ne sera affiché tant qu’elles ne sont pas chargées. Et parce que le site en charge 25 (oui, vingt-cinq), il va falloir patienter un petit moment avant de pouvoir lire quoi que ce soit. Ce qui est dommage, puisque si le site utilisait des polices standard, je pourrais déjà être en train de lire l’article pendant que le reste de la page se charge.
  3. À quatre secondes, je vois apparaître le logo du site et la catégorie de l’article (« Technology »). Mais surtout, je vois un énorme encart avec une barre de chargement apparaître en haut de l’écran. Si j’avais déjà commencé à scroller dans la page, ça provoquerait un énorme saut, me faisant perdre le fil de ma lecture. Mais bon heureusement, comme je ne peux toujours rien lire, je reste bien sagement en haut de page en attendant que ça charge.
  4. Au bout de six secondes, alléluia, les polices sont chargées. Je peux enfin commencer à lire l’article pour lequel j’étais venu à la base. À noter au passage que le chargement des polices déclenchera un changement de taille dans les hauteurs de ligne, provoquant à nouveau un saut dans le défilement de la page.
  5. À sept secondes, alors que je commençais enfin à lire l’introduction de mon article, voilà que le bandeau en haut de page a décidé de s’agrandir, comme ça, sans intervention de ma part. Au passage, ça fait donc à nouveau sauter le défilement de la page, me faisant perdre le fil de ma lecture.
  6. À huit secondes, le bandeau en haut de page reprend sa taille initiale, provoquant à nouveau un saut dans le défilement et mon désespoir de pouvoir enfin commencer à lire cet article.
  7. À neuf secondes, le fameux contenu du bandeau de haut de page s’affiche. Et il s’agit d’une image. Une simple image, qui m’a empêché de commencer ma lecture.
  8. À dix secondes, une publicité s’affiche sur la droite, détournant un instant mon regard avant que je ne puisse reprendre ma lecture.
  9. Au bout de quinze secondes, la page est totalement chargée. Je veux enfin commencer à réellement lire cet article, ou utiliser la fonctionnalité « Lecteur » de Safari pour avoir un contenu bien mis en page et adapté à la lecture sur tablette.

C’est plutôt atroce, non ? Et encore, c’est pourtant un large progrès comparé à six mois plus tôt. Quand j’ai écrit « Ta page charge. Ce n’est pas sale.« , le site masquait totalement l’affichage de la page pendant son chargement. Cet exemple semble peut-être exagéré, mais je pense qu’il assez emblématique de ce que l’on rencontre de plus en plus.

Voici quelques observations pour améliorer l’expérience du chargement de son site :

  1. Évitez les polices CSS. C’est le parfait exemple de « c’est joli, mais si… » (en l’occurrence, c’est joli, mais si on est venu pour lire ?). Au pire, si vraiment vous n’aimez pas vos utilisateurs et que vous aimez être pris pour un artiste, limitez-vous à une police. Mais rappelez-vous que vous êtes là pour faire du web, pas du print. Les polices CSS sont de véritables plaies pour l’expérience utilisateur.
  2. Fixez les tailles de ce qui peut l’être. Je n’ai pas poussé en détail pour connaître les raisons du saut de l’image de l’article de Fast Company à la septième seconde. Mais peu importe la raison, c’est une mauvaise raison.
  3. Générez côté serveur ce qui peut l’être. L’image en question de Fast Company aurait sans doute pu être générée d’emblée dans le HTML de la page, évitant ainsi un chargement supplémentaire en JavaScript. J’ai déjà vu des sites marchands qui changeaient côté client les prix des produits. Par pitié ne faites pas ça.
  1. Luc, le

    J’irais pas jusqu’à interdire l’utilisation des typo en CSS.
    PAR CONTRE, je me limite aux titrages et autres textes graphiques (logo, bannières…). Pour le texte courant, je préfère conserver une police web safe. :-)

  2. Jumbef, le

    Les typos CSS pour les éléments comme « titrages et autres textes graphiques (logo, bannières…) » pourquoi pas mais attention. Le contenus doit être affiché en premier puisque c’est pour lui que l’utilisateur affiche la page et tout ce qui se charge (donc s’affiche) après (comme les typos CSS) ne doit plus faire bouger ce contenu donc forcement dans un conteneur de taille connue.

  3. A.nonym, le

    Dans l’absolu, tu as raison : aucune excuse pour un site se chargeant aussi mal.

    Par contre, je ne suis pas tout à fait d’accord avec le contenu des arguments :

    1/ les typos : je ne sais plus qui disait que les typos, c’était 90% du web. Le web, c’est avant tout du contenu, ce contenu est avant tout textuel. Du coup, en terme de rapport poids/utilité, la typo me semble toujours plus pertinente que une ou deux images… Bien sûr il est inutile d’en inclure quinze.
    Au passage j’ai toujours trouvé @font-face mal branlé, parce qu’il encourage mal la mise en cache.

    2/ fixer les tailles, certes. Mais là, sans même vérifier, ça a une gueule de diaporama responsive. Donc bye bye le fixage des tailles. Très chiant ça d’ailleurs. Ou alors faut écrire quelques règles avec des min-height en fonction des largeurs pour « limiter » le problème mais c’est quand même un peu sale.

    3/ là encore, discutable par rapport à l’objectif de l’article. Je suis pas un gros fan de la tendance à la con qui consiste à plus rien faire coté serveur et tout coté client, mais si on part sur une politique consistant à augmenter la vitesse de chargement d’une page, deferer les images (en particulier la suite d’un diaporama) peut avoir du sens.
    Le gros problème, c’est plus l’accessibilité de ces images qui passe à la trappe, mais là encore on peut fournir un fallback en noscript.

    Mon conseil, c’est installer le plugin YSlow et ne pas lâcher le site tant qu’il a pas son Grade A.

  4. Nico, le

    @a.nonym : on peut avoir un grade A sur un site et avoir une page de 2Mo. :p

    @hteumeuleu :
    1) plutôt que de s’interdire les webfonts, autant les charger en lazy-loading : ton site sera lisible avec ou sans. Si je commence à hurler sur les webfonts au taf, je vais m’attirer les foudres de mes graphistes, et ils n’auront pas tort (rien qu’une belle typo fait aussi bien que 50 autres éléments de graphisme sur un site Web). Le jeu, c’est surtout d’être raisonnable.

    2) bien sûr. Typiquement, l’image du bandeau qui rame pour se charger via JS, une simple height dans la CSS aurait limité la casse : on voit qu’il y a un box qui se charge.

    3) pour le côté serveur, c’est à voir : par exemple, SPIP et d’autres CMS font ça très bien, ils moulinent côté serveur une fois, et ont un système de cache qui évite de remouliner pour les suivants. Du coup, ça limite côté serveur et ça ne décharge pas tout sur le front-end. Typiquement, une CSS créée avec une approche mobile-first sera plus efficace sur mobile même si elle inclut tous les styles, y compris ceux desktop.

    Ceci dit, il y a plus simple : faire simple avec peu de requêtes depuis la conception, ça vaut toutes les techniques d’optimisation.

    à+
    Nico