Performance Web

Personne n'aime un site lent

Analyser la performance Web à l’aide d’un graphique en cascade “waterfall”

Si vous êtes un habitué de la performance Web, vous avez sûrement remarqué à quelques reprises des graphiques tel que celui affiché un peu plus bas.  Les graphiques en cascade “waterfall chart” sont utilisés pour diagnostiquer les problèmes de performance.

Si vous vous souciez de la vitesse de chargement de votre site, vous devez avoir au moins une compréhension élémentaire des graphiques en cascade.

Qu’est-ce qu’un graphique en cascade?

Un graphique en cascade est un diagramme qui représente les données qui sont générées de façon cumulative et séquentielle. Un graphique en cascade spécifique à la performance vous permet de voir les requêtes qui se produisent entre un navigateur et un serveur pour permettre à l’utilisateur de visualiser une page Web.

Chaque requête, qu’elle soit HTML, Images, CSS, JavaScript ou bien une redirection sont représentés par leur propre ligne dans le graphique. Le graphique indique le moment où chaque ressource est appeler à partir du serveur jusqu’à son téléchargement et son rendu dans le navigateur.

Pratiquement tous les outils de mesure de la performance génèrent des graphiques en cascade. Si vous êtes un nouveau à cette notion, vous pouvez créer votre propre graphique très facilement en entrant une URL dans WebPagetest. Certains autres outils comme Pingdom vous donnent ce graphique plus rapidement, mais ils ont toutefois un peu moins précis.

Comprendre un graphique en cascade

waterfall-basic

Start Render : Indique que le contenu commence à s’afficher dans le navigateur de l’utilisateur. Attention, cela ne signifie pas que le contenu affiché est important ou qu’il s’agit simplement de publicité.

Document complete : Le temps nécessaire pour la plupart des éléments de la page à s’afficher dans le navigateur. Aussi connu comme “Load Time” ou temps de chargement. Cette donnée est calculée en mesurant le temps que prend l’événement “window.onload()” à être déclenché. Elle est utilisée comme unité de mesure grossière de la performance d’un site. Ce n’est pas nécessairement un indicateur fiable pour connaitre le moment où une page devient utile.

Fully loaded : Représente le moment où toutes les ressources de la page, y compris les ressources externes qui ne sont pas visibles, ont chargé et que le processus est terminé.

waterfall-101

DNS Lookup

Cette requête permet de résoudre l’adresse IP liée au nom de domaine demandé pour s’y connecter.

Comment optimiser cet élément : Vous ne pouvez pas faire grand-chose pour optimiser les requêtes DNS et il ne devrait pas y avoir de problème sur la plupart des sites.

TCP connection

Cette barre indique le temps de connexion TCP/IP afin de lancer le téléchargement de chaque fichier. Il est difficile d’accélérer la connexion TCP. Vous contrôlez toutefois le nombre de connexions.

Comment optimiser cet élément : Si chaque requête de votre tableau possède une barre orange, c’est que vous avez un problème. Vous pouvez résoudre ce problème en poussant vos développeurs à utiliser ce qu’on appelle keep-alive afin de réduire le nombre de connexions TCP.

Negociation SSL

Je ne veux pas entrer dans les détails ici. Sachez seulement que les requêtes TLS obligent des aller-retour serveur supplémentaires. Ce qui prend forcément du temps.

Comment optimiser cet élément : Le même principe que les connexions TCP s’appliquent ici. Si chaque requête de votre tableau possède une barre violette, c’est que vous avez un problème. Vous pouvez résoudre ce problème en poussant vos développeurs à utiliser ce qu’on appelle des connexions persistantes afin de réduire le nombre de négociations TLS.

Time to first byte ( TTFB )

Probablement la donnée la plus importante pour votre SEO. Le TTFB est une mesure qui est utilisée comme indicateur de la réactivité du serveur. Cela correspond au temps avant la réception du premier octet pour une requête.

Comment optimiser cet élément : Plusieurs facteurs peuvent affecter le TTFB. La connexion Internet de l’utilisateur. La charge de travail que votre serveur doit effectuer avant de répondre à la requête et la distance entre le serveur et l’utilisateur.

Recommandations:

  1. Implémenter une solution de caching. Cette solution est absolument obligatoire pour améliorer la réactivité de votre site.
  2. Utiliser un CDN pour rapprocher les ressources de l’utilisateur.
  3. Réduire le nombre de ressources. En effet, vous devriez concaténer vos ressources CSS / JavaScript et utiliser les sprites d’images.

Content download

Représente le temps qu’il faut pour chaque ressource de la page avant d’être complètement téléchargé.

Comment optimiser cet élément : Si votre site possède trop de longues barres bleues,  vous devez réduire la taille des ressources par la minification et la compression.

Conclusion

N’hésitez pas à utiliser les graphiques en cascade pour diagnostiquer les problèmes de performance de votre site et concentrez-vous sur les éléments suivants:

  • La ligne verticale “Star render” doit être affichée le plus rapidement possible.
  • Réduire le nombre de lignes.
  • Réduire le nombre de barres oranges ( TCP Conection ).
  • Réduire le nombre de barres violettes ( SSL Negociation ).
  • Réduire la longueur des barres vertes ( TTFB ).
  • Réduire la longueur des barres bleues ( Content download).

La vitesse de chargement est une donnée dépassée

Il y a quelques jours, je participais à un Hangout sur Google+ à propos de performance Web. Le sujet était “Comment mesurer le temps de chargement”. Plusieurs outils, tels que Pingdom Tool, que j’utilise très souvent d’ailleurs, ont été présentés rapidement. La présentation était toutefois limitée strictement au temps de chargement. Or ce n’est absolument pas un bon indicateur de vitesse. Il y a d’autres variables à prendre en compte.

Qu’est-ce que la vitesse de chargement?

En résumé, le temps de chargement est une donnée métrique qui est calculée en mesurant le temps que prend l’événement “window.onload()” à être déclenché.

Dans le passé, le temps de chargement était un très bon indicateur de la rapidité d’un site. De nos jours, la complexité des sites à exploser et de ce fier uniquement au temps de chargement pour mesurer la vitesse serait une erreur. Les outils de partages, les widgets, le défilement infini et les systèmes de commentaires externes sont de bons exemples de la complexité grandissante des pages Web.

Introduction à l’indice de vitesse (speed index)

L’indice de vitesse est calculé en prenant le progrès visible de la page et en calculant une note globale pour la rapidité à laquelle le contenu est affiché. Normalement, un indice de vitesse se situe entre 1000 et 10 000. Les petits nombres sont meilleurs.

D’après vous, quel site est le plus intéressant? Sachant en fait, que les deux sites ont un temps de chargement de 4 secondes.

Indice de vitesse

Pour le site numéro #1, le visiteur peut commencer à lire et à interagir avec le site dès la première seconde. Tandis que le site numéro 2 est accessible à l’utilisateur seulement à la quatrième seconde. Les deux sites ont pourtant le même temps de chargement. Voyez-vous la différence?

C’est exactement le constat qu’un lecteur m’a transmis dans les commentaires d’un article:

Bonjour, pourquoi lorsque je test cette page (l’article) sur pingdoom il me renvoi 2 secondes alors que j’ai l’impression que votre site est instantané ?

Alors, la page en question est effectivement chargée en un peu plus de 2 secondes. Par contre, l’indice de vitesse est de 800, ce qui signifie un chargement visuel en 800 millisecondes.

Les visiteurs de votre site n’ont rien à faire de ce qu’il y a dans votre bas de page et de la liste de vos suiveurs Twitter. Un visiteur veut trouver l’information qu’il veut, et ce, le plus rapidement possible. Pour cela, vous devez optimiser votre site pour le “Critical rendering Path”. C’est à dire, optimiser votre site de façon à prioriser le contenu et les éléments qui se trouvent au-dessus de la ligne de flottaison “above the fold”.

Conclusion

À mon avis, quand il s’agit de performances Web, nous devrions nous concentrer sur la rapidité avec laquelle un visiteur est en mesure de commencer à interagir avec le site. Le plus vite ils peuvent commencer à interagir le mieux ce sera.

Alors, la vitesse de chargement est toujours aussi importante pour vous?

Vidéo complémentaire

Paul Irish à la conférence Front End Ops Conf 2014 qui présente l’indice de vitesse.

Comment exploiter la mise en cache du navigateur pour Google Analytics

ga

Pour améliorer la note de ce site dans PageSpeed Insights, il ne me restait plus qu’à optimiser Google Analytic.

Il est malheureusement impossible d’optimiser les en-têtes d’un fichier hébergé à l’extérieur de son serveur. Qu’à cela tienne, j’ai donc décidé d’héberger moi-même Google Analytics.

1. Copier le script sur votre serveur

Pour commencer, créer un fichier JavaScript sur votre serveur, comme par exemple, “analytics.js”. Puis copier la totalité du fichier disponible à cette adresse google-analytics.com/analytics.js et coller le dans votre nouveau fichier.

2. Changer votre code Google Analytics

Voici le code par défaut de Google Analytics:

<script>
 (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
 (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
 m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
 })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

 ga('create', 'UA-xxxxxxxx-1', 'auto');
 ga('send', 'pageview');

</script>

Vous devez changer le chemin actuel ‘//www.google-analytics.com/analytics.js’ pour celui sur votre serveur.

Voici le résultat pour mon site:

<script>
 (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
 (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
 m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
 })(window,document,'script','<?php echo get_bloginfo("template_directory"); ?>/js/analytics.js','ga');

 ga('create', 'UA-xxxxxxxx-1', 'auto');
 ga('send', 'pageview');

</script>

3. Vérifier le fonctionnement

Rendez-vous dans la section “Temps réel” de Google Analytics pour vérifier si votre code de suivi fonctionne toujours.

4. Automatiser la mise à jour du fichier (Optionnel)

C’est bien beau tout ça, mais si Google fait des modifications à son script, nous n’aurons pas les mise à jour.

Vous pourriez copier/coller le script régulièrement, mais ce n’est pas vraiment une option valable…enfin pour moi.

Voici un script PHP gracieuseté de Tips4php pour automatiser cela.

// script to update local version of google analytics script

// Remote file to download
$remoteFile = 'http://www.google-analytics.com/ga.js';
$localfile = '/var/www/example.com/static/local-ga.js';

// Connection time out
$connTimeout = 10;
$url = parse_url($remoteFile);
$host = $url['host'];
$path = isset($url['path']) ? $url['path'] : '/';

if (isset($url['query'])) {
  $path .= '?' . $url['query'];
}

$port = isset($url['port']) ? $url['port'] : '80';
$fp = @fsockopen($host, '80', $errno, $errstr, $connTimeout );
if(!$fp){
  // On connection failure return the cached file (if it exist)
  if(file_exists($localFile)){
    readfile($localFile);
  }
} else {
  // Send the header information
  $header = "GET $path HTTP/1.0\r\n";
  $header .= "Host: $host\r\n";
  $header .= "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6\r\n";
  $header .= "Accept: */*\r\n";
  $header .= "Accept-Language: en-us,en;q=0.5\r\n";
  $header .= "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n";
  $header .= "Keep-Alive: 300\r\n";
  $header .= "Connection: keep-alive\r\n";
  $header .= "Referer: http://$host\r\n\r\n";
  fputs($fp, $header);
  $response = '';

  // Get the response from the remote server
  while($line = fread($fp, 4096)){
    $response .= $line;
  }

  // Close the connection
  fclose( $fp );

  // Remove the headers
  $pos = strpos($response, "\r\n\r\n");
  $response = substr($response, $pos + 4);

  // Return the processed response
  echo $response;

  // Save the response to the local file
  if(!file_exists($localFile)){
    // Try to create the file, if doesn't exist
    fopen($localFile, 'w');
  }

  if(is_writable($localFile)) {
    if($fp = fopen($localFile, 'w')){
      fwrite($fp, $response);
      fclose($fp);
    }
  }
}

La seule modification à apporter est de changer le chemin d’accès de la variable “$localfile”. Attention: de prendre le chemin absolut de votre serveur.

$localfile = '/var/www/bulledev.com/wp-content/themes/bulledev_v7/_/js/analytics.js';

5. Créer un Cron Job (Optionnel)

Pour terminer, il est possible de configurer un Cron Job dans votre Cpanel, avec WordPress ou bien d’utiliser simplement un service externe comme Setcronjob qui s’occupera d’appeler votre script une fois par jours/semaine, c’est comme vous voulez.

Mise à jour (6 juin 2016)
Il est maintenant possible d’utiliser l’extension Host Analytics.js Locally qui fera tout cela pour vous automatiquement.

Règle de vitesse: Optimiser la diffusion des ressources CSS

Cette règle se déclenche dans Google PageSpeed Insights lorsqu’une ou plusieurs feuilles de style sont détectées. Le navigateur doit attendre le chargement complet de toutes les feuilles de style avant d’afficher quoique ce soit à l’utilisateur. C’est pourquoi, par l’optimisation de vos ressources CSS, vous pourriez améliorer la vitesse de votre site Web.

Continuer la lecture