Test de vitesse, gzip et localisation du serveur

[techron]

Il est relativement difficile de percevoir la différence entre 2, 3, ou 4 secondes du temps de chargement d'une page (du temps de résolution DNS, du temps de connection... jusqu'au dernier octet de la page incluant tous les objets). A partir de 5 secondes, le temps commence à être appréciable et c'est encore plus problématique pour les basses connexions encore présentes dans certains pays.

Comme Google tient compte depuis peu de la vitesse de chargement des sites, voici un exemple de deux mesures du temps de chargement de l'index d'un forum français vbulletin-ressources.com (autorisation de l'admin d'utiliser ces données) dont le serveur est localisé sur la côte-est canadienne, temps mesuré depuis l'Europe (Amsterdam) et depuis la côte-est des États-Unis (Ashburn en Virginie).

1) Temps de chargement depuis Amsterdam (un temps/ping comparable si mesuré depuis la France): 4.2 secondes

Start time (GMT) 2010-06-09 10:05:30
Download time 4.2 s
Connects 7
Requests 149
Documents total size 969 856 B
Headers total size 52 900 B
Compressed objects 1
Compressed bytes 109 943 B
Average compress ratio 14 %
Effective compress ratio 89 %
Average download speed 2 075 Kbit/s
Effective download speed 2 298 Kbit/s


2) Temps de chargement de la page depuis Ashburn en Virginie (ping à peu près équivalent à celui du datacenter de vb-fr): 1.49 s

Start time (GMT) 2010-06-09 10:39:31
Download time 1.49 s
Connects 7
Requests 149
Documents total size 969 988 B
Headers total size 52 901 B
Compressed objects 1
Compressed bytes 109 855 B
Average compress ratio 14 %
Effective compress ratio 89 %
Average download speed 5 524 Kbit/s
Effective download speed 6 117 Kbit/s

Outil de mesure utilisé: http://site-perf.com/

Ce facteur 3 à 4 fois plus lent ou rapide selon le côté de l'Atlantique où la mesure est effectuée, a été l'objet hier d'un fil chez WHT: http://www.webhostingtalk.com/showthread.php?t=954526&highlight=location

Il serait intéressant de refaire ces mesures aux heures de pointes communes (1:00hr, heure de Montréal, 19:00 hr de Paris) à l'aide du même outil de mesure http://site-perf.com/ , outil qui mesure aussi le taux de compression gzip.

En espérant que cela puisse vous être utile,
Bonne journée

[Julia41]

protocole https not supported
Bon, sinon ça m'a l'air pas mal

[jcaron]

Le résultat est assez normal: la latence est bigrement plus élevée, donc vu le nombre de requêtes, ça prend forcément plus de temps (149 requêtes réparties sur 7 connexions ça fait en moyenne 21 requêtes d'affilée, donc avec une latence d'environ 100 ms A/R sur du transatlantique, ça fait plus de 2 secondes de plus, le résultat est donc tout à fait normal).

De nos jours je ne pense pas que les "heures de pointe" changent grand chose si tu n'es pas dans une contrée particulièrement reculée.

Conclusion:
1. Réduire le nombre de requêtes (agréger les fichiers CSS et JS, utiliser des sprites...). 149 requêtes c'est beaucoup!
2. Faire en sorte que tout ça soit mis sérieusement en cache (Expires etc.) pour les prochaines fois
3. Essayer de paralléliser les requêtes en utilisant des noms de domaine différents (mais ça augmente le nombre de requêtes DNS, et ça peut poser des problèmes pour le SSL, donc il y a un juste milieu à trouver)
4. Réduire la latence en utilisant un serveur près de tes utilisateurs, ou, s'il sont un peu partout, en utilisant un CDN. Rien qu'en balançant les fichiers statiques (CSS, JS, sprite et autres images) sur un CDN tu dois pouvoir réduire considérablement le temps de chargement. CloudFront est ton ami

Le fait de gzipper va surtout aider pour les utilisateurs avec des connexions un peu moins rapides, y compris les liaisons 3G etc.

Tout ça est déjà conseillé par les extensions comme PageSpeed et Yslow...

Jacques.

[vitalizo]

Salut,

question peut etre bete mais je manque de connaissance dans le domaine,
33 connections pour 33 requetes, ca veut dire quoi ?

[jcaron]

Une connexion, c'est une connexion TCP. A l'intérieur d'une connexion TCP, on peut faire plusieurs requêtes HTTP les unes à la suite des autres (sous certaines conditions).

L'avantage de faire plusieurs requêtes dans la même connexion, c'est que ça permet d'éviter le temps que ça prend à établir (et à fermer) une connexion TCP (1 à 1.5 A/R pour l'établissement de la connexion), et ça peut alléger le serveur aussi. C'est encore plus sensible en SSL où il y a beaucoup d'"overhead" à chaque connexion.

L'inconvénient, c'est que toutes les requêtes dans une même connexion sont normalement forcément les unes après les autres (on attend de recevoir la réponse à une requête avant de pouvoir envoyer la suivante). Donc quand on a beaucoup de requêtes à faire, on peut préférer les faire en parallèle dans des connexions différentes. Mais la plupart des browsers limitent le nombre de connexions simultanées (total et vers le même site), donc ça ne sert à rien de faire une requête par connexion, elles seront quand même au moins partiellement sérialisées, et on y perdra le temps d'établissement de la connexion TCP.

Il faut donc trouver un compromis entre les deux. 1 connexion et 33 requêtes ce n'est pas forcément terrible, mais 33 connexions pour 33 requêtes, c'est vraiment pas terrible. L'idéal étant d'avoir beaucoup moins de requêtes (normalement on peut s'en tirer avec 1 page + 1 css + 1 js + 1 sprite + quelques autres images non spritées + JS externes genre Analytics, Adsense, etc, en général 10-15 requêtes).

Jacques.

[techron]

4. Réduire la latence en utilisant un serveur près de tes utilisateurs...

C'était le but de ce message.

Les CDN commerciaux (Akamai et cie) sont très chers (plusieurs dizaines d'euros par mois).

Les CDN gratuits, j'ai fait une recherche pour en insérer un dans le plugin WP Total Cache et je n'ai rien trouvé excepté Coral... Si quelqu'un en connait (gratuit ou pas très cher), je suis preneur.

[vitalizo]

merci jcaron

[carmin]

J'ai trouvé le sujet à travers le chercheur, car j'ai eu quelques problèmes avec la vitesse de connexion et peut-être ici je peux trouver un bon conseil. Dernièrement elle ne marche pas très bien et tous les test de vitesse faits me donnent des résultats différents, donc je ne sais pas duquel me guider au moment de savoir quelle est ma vitesse réelle de connexion, salut.

[Haroeris]

les tests de connexions ne sont souvent pas fiables.

Essayes en plusieurs et fais une moyenne

J'ai trouvé le sujet à travers le chercheur

Pas mal

[Zecat]

Salut jacques,

J'ai fait un test avec : site-perf.com et ca me donne cela :

Test new york

Start time (GMT) 2010-08-05 13:24:58
Download time 1.11 s
Connects 6
Requests 28
Documents total size 104 169 B
Headers total size 5 220 B
Average download speed 780 Kbit/s

Test ashburn

Start time (GMT) 2010-08-05 14:08:33
Download time 1.55 s
Connects 6
Requests 25
Documents total size 100 902 B
Headers total size 4 713 B
Average download speed 543 Kbit/s

Test amsterdam

Start time (GMT) 2010-08-05 13:33:25
Download time 2.1 s
Connects 6
Requests 26
Documents total size 101 799 B
Headers total size 4 882 B
Average download speed 410 Kbit/s

Note c'ets le meme site et la meme page home mais comme elle est dynamque, elle bouge un peu entre chaque test. (le site est hebregé au canada cote ouest)

C'ets bien joli tous ces chiffres mais il faut en retenir quoi ? bon / pas bon ?

[jcaron]

Ca me paraît tout à fait décent comme performance (à compléter avec les tests de Page Speed, YSlow, etc.), mais la grande question est: où sont tes clients? S'ils sont pour la plupart en Europe, il vaut mieux mettre les serveurs en Europe, tu y gagnes en latence et donc en temps de chargement.

Au delà, tu peux probablement encore réduire un peu le nombre de requêtes et de connexions (Page Speed et YSlow te diront probablement la même chose), mais probablement pas beaucoup.

Jacques.

[techron]

Les résultats 4.2 et 1.49 secondes, donnés dans le premier message, ne sont plus valides. Le forum qui est y cité est retourné en France sur un serveur de PlanetHoster après avoir transiter un bref moment chez Hosteur.

@+

[Zecat]

Ca me paraît tout à fait décent comme performance (à compléter avec les tests de Page Speed, YSlow, etc.), mais la grande question est: où sont tes clients? S'ils sont pour la plupart en Europe, il vaut mieux mettre les serveurs en Europe, tu y gagnes en latence et donc en temps de chargement.

Au delà, tu peux probablement encore réduire un peu le nombre de requêtes et de connexions (Page Speed et YSlow te diront probablement la même chose), mais probablement pas beaucoup.

Jacques.

Non le site is en english only et la cible est à travers le monde avec actuellement 60 % pour les usa. Merci jc pour ton commentaire éclairé.

[jcaron]

Tu peux y gagner un peu en le mettant aux US ou en utilisant un CDN, mais je pense que le gain va être marginal.

Jacques.

[Zecat]

Oui la le jeu en vaut pas la chandelle pour gagner des pouiemes de milliseconde ... d'autant plus que vu mon niveau en english, avant que je m'aventure sur une interface heberegeur en anglais ... Ou à la rigueur si c'ets un cpanel que je connais déjà