Augmenter la performance d’un site internet

Dieu est dans les détails

Pourquoi accélérer le chargement d’une page internet ?

Amélioration du nombre de pages vues

Plus votre site sera lent, moins vous aurez d’utilisateurs. La navigation étant fluide, l’utilisateur prend le temps de chercher le contenu qui l’intéresse. Un site au chargement lent créera rapidement un sentiment de frustration, qui poussera l’internaute à aller voir ailleurs.

Amélioration des taux de conversion

L’augmentation du taux de conversion correspond à l’augmentation de la réussite de votre site (nombre de ventes, prises de contacts, d’inscriptions… )

L’utilisateur est plus sensible au contenu. Il est rassuré par l’environnement dans lequel il évolue. Le temps de chargement étant réduit, le temps attribué à accomplir son dessein augmente.

Google run test where they concluded a 500ms increase in page load time on Google led to 20% less traffic and revenue.

Marissa Mayer (Currently VP of Location and Local Services at Google)

Augmentation du chiffre d’affaire des sites marchand.

Le temps c'est de l'argent

Le nombre de page vues augmentant, mécaniquement les chances que l’utilisateur aboutisse à son objectif d’achat augmentent aussi. Certaines études montrent que l’effet est aussi positif sur l’activation des bannières publicitaires.

Amazon ran A/B tests where they delayed the page speed in 100ms increments and found that “even very small delays would result in substantial and costly drops in revenue”. According to Kohavi and Longbotham (2007) every 100ms increase in load time decreased sales by 1%.

Greg Linden (ex Senior Manager & Principal at Amazon.com)

Suffisamment vite

Il faut charger plus vite que l'entendement

Sensation de vitesse

Selon une étude de Miller en 1968 :

  • 0.1 seconde est la limite de perception d’une action instantanée.
  • 1 seconde c’est la limite de latence qu’un utilisateur peu accepter sans avoir la sensation d’être interrompu. Au-delà il souhaite que la procédure soit plus rapide.
  • 10 secondes, à partir de ce seuil l’utilisateur est persuadé que l’ordinateur est planté.

Ces chiffres sont toujours d’actualité. Les ingénieurs travaillant sur les interfaces tactiles s’appuient sur des données similaires.

Ce qu’il faut retenir c’est que l’utilisateur doit pouvoir accéder à son contenu en moins d’une seconde. Au delà nous perdons sa confiance.

Vite par rapport à quoi, à qui

La course à la vitesse peut être gourmande en temps de travail et en coût pour le client final. Il est important de définir avec précision les objectifs de performance à atteindre. Sans quoi ça peut devenir une course onéreuse.

  • Petit projet : chargement < 3s
  • Grosse société : visuellement chargé < 1s
  • Société intermédiaire : …

Ce qui est important c’est que les temps de chargement soient inférieurs aux concurrents du client. Mais on ne parle pas ici de millisecondes de différence. On parle d’une différence perceptible. Une règle est simple à retenir : Faites au moins 20% mieux. Donc, si le plus rapide des concurrents affiche son site en 5 secondes le client doit avoir un site qui s’affiche en 4 secondes. L’utilisateur percevra clairement la différence.

Qu-est ce qui doit aller vite ?

Deux points sont importants et à prendre en compte. L’un est technique et nécessite principalement des actions côté serveur. L’autre point est plus ergonomique et s’appuie plus sur l’intégration du front.

La réception des données

La configuration du serveur doit être optimale. de nombreuses configurations sont possibles et doivent être adaptées au besoin du site. Il n’existe pas de configuration idéale, par contre il existe une solution adaptée aux contraintes clients (pécuniaires et objectifs). En aucun cas la configuration du serveur palliera à une mauvaise conception du site internet. Voici un aperçu des bonnes pratiques :

  • peu de fichiers
  • des fichiers légers
  • les entêtes d’expiration
  • compression GZIP
  • … (et plein d’autre)

La perception du chargement

Le chargement des données est une chose. mais ce qui est important, c’est à quel moment l’internaute à l’impression que le site est chargé.

compare_progress

On parle de % visuel et non plus de Kb/s !. >Dans l’exemple ci-dessus, le site fait le même poids dans les deux configurations. Seule la construction du site diffère. Dans le premier cas les données nécessitant l’affichage du site sont situés dans les premiers 14ko, dans le second cas la structure ne se soucie pas de cette contrainte. Pour un chargement rapide il est nécessaire que les données à afficher soient chargées avant les données qui ont moins d’impact sur l’affichage.

Page Speed Index

Le réel ressenti de vitesse de chargement est le page speed index qui se calcule ainsi :

image

Ce qui se résume par : toutes les 100ms on mesure le % visuel restant à charger jusqu’au chargement complet, puis on fait la somme de ces mesures. Plus le chiffre est bas, mieux c’est. Voici les deux schémas des sites illustrés ci-dessus.

Chargement visuel non optimisé

image

Sur 12 secondes de chargement, le contenu s’affiche au bout de 11s

Chargement visuel optimal

image

Sur 12 secondes de chargement, le contenu s’affiche au bout de 0.5s

Que nous dit Google ?

Les directives de Google

Nous venons de voir ce à quoi doit aspirer un site internet. La mise en œuvre va s’avérer fastidieuse. Google nous met à disposition toute une suite d’outils, qui peuvent nous assister dans la mise en place de votre site. D’autres sites proposent des services complémentaires pour aller plus loin. Ces outils vous permettront de vérifier le bon respect des rêgles d’intégration, la répartition des temps de chargement …

Règles relatives à la vitesse

Éviter les redirections vers la page de destination

Les redirection de page ne sont pas recommandées. Les liens pointant vers des url générant des 301 et 302 ne sont pas recommandés. Cela ralenti le temps d’arriver à la page de destination.

  • Excellent : exemple.com bénéficie d’une conception Web adaptative (« responsive web design »), aucune redirection n’est nécessaire
  • Correct : exemple.com -> m.exemple.com/accueil
  • Mauvais : exemple.com -> www.exemple.com -> m.exemple.com -> m.exemple.com/accueil

voir les recommandations

Autoriser la compression

Activer la compression permet de compresser les données qui transitent du serveur vers le poste utilisateur. Cette fonctionnalité réduit de manière significative les fichiers texte (css, html, js, jusqu’à 80%)

  • Apache : utilisez mod_deflate.
  • Nginx : utilisez HttpGzipModule.
  • IIS : configurez la compression HTTP.

voir les recommandations

Améliorer le temps de réponse du serveur

Derrière cette recommandation d’apparence anodine, sa mise en œuvre requiert une configuration aux petits oignons du serveur. Il faut configurer les services tels que apache, php, mysql de manière a obtenir de bonnes performances, mais sans oublier la prise en compte du traffic.

voir les recommandations

Exploiter la mise en cache du navigateur

Code de retour

Lorsque qu’un utilisateur demande un fichier sur un site, le serveur commence par retourner un code d’entête. Voici les principaux à connaître :

  • 200 : OK : Requête traitée avec succès
  • 301 : Moved Permanently : Document déplacé de façon permanente
  • 302 : Moved Temporarily : Document déplacé de façon temporaire
  • 304 : Not Modified : Document non modifié depuis la dernière requête
  • 403 : Forbidden : Le serveur a compris la requête, mais refuse de l’exécuter. Cela signifie généralement que l’authentification a été acceptée mais que les droits d’accès ne permettent pas au client d’accéder à la ressource
  • 404 : Not Found : Ressource non trouvée
  • 410 : Gone : La ressource est indisponible et aucune adresse de redirection n’est connue
  • voir tous les autres

Un code 200 signifie que le fichier à bien été redistribué, alors qu’un code 304 signifie que l’internaute n’a pas besoin de recharger le fichier. Celui dans le cache navigateur est encore valable.

Validité des ressources

Pour définir la validité d’une ressource, il faut spécifier des entête d’expiration Expires Header et Cache-Control: max-age. Ces en-têtes définissent la période durant laquelle le navigateur peut utiliser les ressources mises en cache sans vérifier si une nouvelle version est disponible sur le serveur Web.

Marqueur de version

Les en-têtes Last-Modified et ETagpermettre respectivement de définir la date de création d’un fichier et un marqueur unique mis à jour à chaque changement du fichier. Ces données permettent au navigateur de définir si un fichier a été modifié ou non.

voir les recommandations

Réduire la taille des ressources

Avant de réduire la taille des ressources, il faut en réduire le nombre. Le nombre de requêtes simultanées effectuées sur un même serveur est limité. Donc 100 fichiers de 1Ko mettront plus de temps qu’un ficher de 100ko.

  • éviter les JS superflus
  • compiler les SVG dans des webfonts
  • faire des sprites avec les images
Réduction du poids

voir les ressources

Optimiser les images

Il est recommandé d’utiliser les paramètres suivants :

  • jpg progressif compression < 70
  • png 8bits ou 8+8bits (jamais de 24bits)

Dans tous les cas un passage dans imageOptim / pngquant est important, Photoshop ne suffit que rarement.

Optimiser la diffusion des ressources CSS

On oublie ce que l’on a appris à l’école :

  • Dans le head on écrit inline le CSS nécessaire au chargement de la ligne de flottaison. Un cookie permettra de n’afficher ce contenu Style qu’une seule fois par utilisateur (après les CSS seront en cache)
  • On place les CSS externes en pied du head (certain préconisent de le mettre dans le pied de page, d’autres le chargent même en Ajax)
  • Ne pas intégrer les URI volumineux (ormis pour les typos avec une gestion du cache via JS et un chargement différé)

voir les recommandations

Afficher en priorité le contenu visible

Le chargement se passe en trois grand temps :

  • chargement du contenu
  • chargement de l’aspect / ergonomie / interactions
  • chargements des données tiers (publicités, vidéos, tags … )

Le but du jeu est que le contenu s’affiche le plus rapidement possible. Pour ça il faut que les premiers 14ko contiennent les données nécessaires pour afficher votre contenu visible.

voir les recommandations

Supprimer les fichiers JavaScript qui bloquent l’affichage

Les fichiers javascript vont en pied de page, le nombre de fichier doit être très limité. Il faut fuir les librairies volumineuses. Jquery est une superbe boite à outils, mais pas forcément nécessaire. Il est possible de mettre un peu de JS inline dans le head, mais cela peu plomber les temps de chargement.

voir les recommandations

Utiliser des scripts différés

<script defer src="my.js">

Les scripts différés sont chargés comme d’habitude, mais leur contenu est exécuté juste avant le DOMContentLoaded, et ce en respéctant l’ordre du DOM.

Utiliser des scripts asynchrones

Cet attribut est spécifique à HTML5.

<script async src="my.js">

Les chargement asynchrones permettent de charger des scripts différents en parallèle mais surtout de les éxecuter dans disctinction d’ordre ou de priorité. Donc il ne faut pas faire ça :

<!-- Don't do it -->
<script src="jquery.js" async></script>
<script src="plugin.jquery.js" async></script>

Leur contenu est exécuté après le DOMContentLoaded

Règles relatives à l’ergonomie

Éviter les plug-ins

L’utilisation d’un plugin, aussi bon soit-il peut engendrer les situations suivantes :

  • « Plugin manquant, voulez vous l’installer ? »
  • « Plugin nécessaire, voulez vous l’activer ? »
  • « Ce site requiert l’utilisation de XXXXX, faire confiance à ce site ? »

Des questions qui requièrent des réponses, et qui brisent la navigation / l’utilisation. Et pour peu que vous vouliez installer le plugin, c’est une rupture de 1 à 5 minutes le temps de l’installation.

Configurer la fenêtre d’affichage et adapter la taille du contenu

Il faut adapter le contenu au support, sur les petits écrans, inutile de charger des visuels immenses ou des typos lourdes et illisibles. Et bien évidement, ne chargeons pas ce que l’on ne voit pas … c ‘est la moindre des choses.

Astuces : une balise img est systématiquement chargée, alors qu’un div avec un background-image peu afficher une image adaptée à la taille d’affichage ou tout simplement ne rien charger du tout.

voir les recommandations

Ce que nous dit pas (explicitement) Google.

Nous devons être drastique sur les données qui sont chargées par l’internaute, et pour cela une page ne doit contenir que son contenu. Tout ce qui est annexe (descriptif des autres articles, bannières pub, fonctions alternatives …) seront chargées après. Clairement il faut utiliser Javascript pour arriver à ces fins (sans oublier l’alternative <noscript>).

Comment ils font ?

Comment font-il ?

www.leboncoin.fr (index speed = 897)

c’est codé comme des cochons, ce qu’il faut retenir, c’est que le contenu se charge en deux temps :

  • temps 1 : le html qui contient ce qui doit impérativement être affiché.
  • temps 2 : le javascript rajoute les publicités quand la page est construite.

Les images qui s’affichent en rollover sont préchargées en JS et nons en sprite, ce qui permet de temporiser leur chargement.

  • pas de typo personnalisée
  • de nombreux outils de mesures (xiti, cedexis … )
  • pas de jquery
  • pas de librairie

Les performances serveur et l’utilisation d’un CDN et la pauvreté du contenu offre des temps de réponse très bons.

www.smashingmagazine.com (index speed = 1299)

Une page html de 15ko contenant les CSS nécessaires à l’affichage de la page dans son entête ( head ). Les CSS complet du site sont chargés en JS une fois la page chargée pour la mettre en cache. Au second passage sur le site, ce sont les CSS mis en cache qui remontent. une alternative dans une balise noscript est aussi en place. Une fois le contenu chargé, le site charge les données secondaires (analitycs et publicités) puis tertiaires (librairie pour la colorisation syntaxique des exemples de code).

  • Pas de Jquery,
  • Pas de zoom image
  • Pas de player vidéo embarqué
  • 1 seule librairie : PRISM.js
  • seulement 51 requètes
  • les petites images sont directement embarquées dans le CSS
  • les typos sont directement incluses dans le CSS

Ce qu’il faut retenir

Ce qui prend du temps à créer prendra du temps à charger.

less is more

Contenu :

  • Donner la priorité au contenu. Certains s’appuient sur le mobile first pour définir ce qui est l’essence du contenu de la page. Le reste est affiché en décalage dans le temps.

Composition :

  • Standardiser ses mises en pages. Cela ne signifie pas avoir des écrans homogènes, mais des compositions identiques.
  • Le contenu est plus important que la structure (et en plus c’est plus sympa à faire)
  • Une bonne gestion du contenu ne nécessitera pas de module Javascript (popin, slider, tabs, accordéons …).

Graphisme :

  • Réduire les codes graphiques : Les icones sont longues à créer et sont souvent là pour palier à un soucis de hiérarchie de l’information ou du contenu.
  • Bien mesurer l’impact des typos. Multiplier les fonts alourdit les temps de chargements, leur quantité doit bien être mesurée.
  • Plutôt que de faire une bibliothèque de pictos, ou des fonds, ou des dégradés ou des matières, valoriser les contenus et les message.

Intégration :

  • Regrouper les ressources par ordre d’importance et usage
  • Respecter les 3 temps d’affichage
    1. Contenu
    2. Interface
    3. Autres (services tiers ou annexes)
  • Respecter le temps de chargement visuel.
    1. Viser d’abord un index speed haut, puis un chargement rapide des données

Serveur :

  • Mettre du cache partout ! Et bien le gérer.
  • Gérer le cache des données qui n’en ont pas (celles de service tiers par exemple)
  • Prendre en compte les remarques de Google dans les limites financières qu’elles impliques (surtout vis à vis du CDN)
  • Gérer une bonne optimisation des images.

On ne charge que le nécessaire

  • Content first ! éventuellement Mobile first
    1. On définit ce qui est primordial
    2. On affiche que ce contenu
    3. On ajoute les contenus annexes

Erwan Sabourin – Septembre 2014

  • sources
  • https://developers.google.com/web/fundamentals/performance/
  • https://developers.google.com/speed/docs/insights/rules
  • www.smashingmagazine.com/2014/09/08/improving-smashing-magazine-performance-case-study/