Impact de la latence réseau

Après avoir parlé hier des stratégies d’optimisation, parlons rapidement de ce qu’il y a à gagner. Je me concentre sur la stratégie la plus fréquente : tenter de regrouper nos ressources dans des gros fichiers globaux.

Pour l’exemple, j’ai arbitrairement utilisé le blog de Frédéric de Villamil. La page semble assez rapide à charger. Concrêtement, de chez moi, je met environ 500 ms à charger les composants internes (je ne compte donc pas le tag Google analytics et les images Flickr).

Sur ces 450 ms je charge :

  • 82 ms pour la connexion initiale et le téléchargement du fichier HTML ;
  • 19 ms pour la feuille de style ;
  • 96 ms pour 4 fichiers javascript ;
  • le reste vient des 9 images, chargées avec deux fils de téléchargements parallèles.

En soit il n’y a rien d’extraordinaire mais cela fait tout de même un total de 15 ressources à télécharger.

L’impact de la latence

Pour chaque ressource à télécharger je subis la latence du réseau, c’est à dire le temps d’acheminer ma requête jusqu’au serveur puis le temps que sa réponse traverse les câbles pour atteindre ma machine. 

Frédéric utilise une machine sur un réseau très proche du mien. Un aller-retour met donc 12 ms à s’exécuter, ce qui est extrêmement peu. 15 ressources à télécharger c’est 15×12 = 180 ms, soit tout de même 40% de mon temps d’attente.

Si on regarde de plus près, les 4 fichiers javascripts sont génériques. Si je les concatène pour en faire un seul, je gagne d’un coup 3 aller-retours, soit 60 ms (13% de mon temps d’attente).

En allant un peu plus loin, les images de fond pour l’entête et le pied de page pourraient être regroupées en un sprite CSS vertical. Les autres images de mise en page pourraient être regroupées en un sprite horizontal.  Sur 6 images de mise en page (il y avait deux images de contenu), nous réduisons à deux fichiers. Le gain est de 50 ms (11% du temps d’attente).

Avec ces réductions, c’est un total de 110 ms qu’on peut épargner aux navigateurs, soit 25% du temps de chargement de la page. Non seulement la page finira de s’afficher 25% plus vite, mais en plus l’affichage débutera bien plus tôt : le chargement de nos fichiers javascript bloquait l’affichage de la page. 60 ms de gagné à cet endroit, c’est une page qui débute son affichage 60 ms plus tôt.

L’ordre de grandeur des gains

Les chiffres mentionnées semblent minimes, et ils le sont. Mais un chargement de près de 500 ms c’est un chargement qui est ressenti par le visiteur. Permettre de débuter l’affichage plus vite et finir plus rapidement le téléchargement de toutes les images, c’est un vrai ressenti de « site rapide » pour l’utilisateur. Quelle que soit la valeur absolue, quand vous dépassez 250 ms, 25% de gain c’est visible.

Ces chiffres sont minimes aussi parce que j’ai pris un cas presque idéal : peu d’images dans le graphisme, et un serveur avec une liaison presque directe vers mon fournisseur d’accès Internet. La latence avec le serveur est plus souvent de l’ordre de 30 à 60 ms, parfois plus. Même Google et Yahoo sont à un peu plus de 30 ms de de chez moi.

Si le serveur de frédéric avait une latence de 40 ms au lieu des 12 ms, mon navigateur aurait mis un peu plus d’une seconde à tout afficher. Il commence à y avoir un vrai sentiment d’attente de la part de l’utilisateur (imaginez si votre téléviseur mettait ce temps là à réagir).

Nos petites optimisations simples à faire auraient épargné presque 280 ms : plus d’un quart de seconde. Là aussi cela se verra pour l’utilisateur, surtout si ça veut dire que la page commence son chargement plus vite.

Publié par edaspet

Plus d'informations sur mon profil en ligne

7 réponses sur « Impact de la latence réseau »

  1. « Si je les concatène pour en faire un seul, je gagne d’un coup 3 aller-retours, soit 60 ms »

    Ah non!. Tu n’as aucune idée de ce que tu gagnes ici, c’est purement théorique. Le serveur peut réagir totalement différemment avec des téléchargements de fichier plus gros (en bien comme en mal), c’est impossible à prévoir. Un effet pervers que ca peut avoir, par exemple, est ce chaque connexion au serveur dure plus longtemps: en cas de grosse bourre, genre un passage sur digg/slashdot, ca pourrait risquer de bouffer un à un tous les slots du serveur HTTP, rendant le site indisponible. Gaffe, donc 🙂

    Ca fait partie d’une masse de trucs ce que je voulais dire mais que j’ai eu la flemme d’écrire sur ton premier post: il faut faire très attention à la théorie, on ne peut jamais prévoir exactement ce qui peut se passer. Quelquefois, une optimisation parfaitement logique, faisant gagner un max de perfs en théorie, peut complètement tout casser…

  2. Même si les images sont téléchargées en parallèle, et même si les connexions sont déjà ouvertes en keep-alive, on gagne quand même un aller-retour réseau à chaque fichier en moins.
    Ce qu’éventuellement on ne gagne pas (et que je n’ai pas compté ici), c’est l’établissement de la connexion tcp, qui peut prendre parfois du temps.

  3. @mat:
    Sur ce genre de taille, je doute que je serveur réagisse tellement différemment. Même lui sera moins chargé avec une petite requête (car elle reste petite) que deux très petite.

    Reste que oui, comme pour ton commentaire précédent, il y a plein de facteurs. Il n’y a pas de solution universelle, mais je peux dire sans risque ici que le gain sera sensible. Les cas exceptionnels ou cas spéciaux existent, mais cela ne m’empêchera pas de publier des solutions qui auront toutes les chances d’être vrai dans la grande majorité des cas.

Les commentaires sont fermés.