temps de chargement d’un site internet
TweetEmailSharebar TweetEmail Poursuivant mon enquête technique pour comprendre pourquoi ce blog est lent à se charger, j’ai trouvé l’outils rudimentaire mais gratuit : OctaGate SiteTimer. Son principe est simple : on lui donne le nom de la page à tester, par exemple http://www.coteboulevard.com. Depuis un site externe (qui donc ne dépend pas votre liaison ADSL), [...]
Poursuivant mon enquête technique pour comprendre pourquoi ce blog est lent à se charger, j’ai trouvé l’outils rudimentaire mais gratuit : OctaGate SiteTimer.
Son principe est simple : on lui donne le nom de la page à tester, par exemple http://www.coteboulevard.com. Depuis un site externe (qui donc ne dépend pas votre liaison ADSL), l’outil charge la page et tous les éléments de la page (images, scripts permettant d’afficher les vidéos,…). On obtient alors un graphique qui nous dit combien de temps est nécessaire pour afficher chaque élement, et in fine la page complète. Cette mesure est instantanée et peut varier au cours du temps. Elle a le mérite de mettre en évidence un certain nombre de choses, quand on a envie de regarder la technique…
Sur côté boulevard, par exemple, la page (le texte et mise en forme HTML) est assez "lourde". Le chargement des éléments graphiques (images,…) ne commence qu’après le chargement de cette page, soit au bout de 2 secondes.
Sur ma page, j’ai énormément de petits éléments graphiques. Chaque élément est chargé rapidement mais comme ils ne sont pas tous chargés en parrallèle, plus il y a d’éléments, et plus le temps total est long.
J’ai également 5 images qui demandent 2,5 secondes de chargement. C’est beaucoup pour si peu. Ce problème peut être dû soit à la taille des images, soit à un problème de dimentionnement de la liaison de l’hébergeur sixapart (déjà épinglé ici). Ces images sont de taille relativement réduite, 20 à 30 Ko, ce qui me parait très acceptable. Le temps mis pour charger ces images vient donc de mon hébergeur.
En fin de chargement, on voit un tas de chargements. Ils correspondent à la mise en page (le thème ou template) fournie par mon prestataire (typepad). Ces chargements me coutent 3 secondes. J’en déduits qu’une mise en page plus sobre me permettrait de gagner en performance.
Contrairement à ce qu’on aurait pu penser, le temps de chargement de mon blog dépend peu des petits outils (widgets) que j’ai ajouté pour afficher les flux feedburner, la comunauté MyBloglog, criteo, etc…
Au total, ma page s’affiche en 10 à 16 secondes quand celle de monorléans s’affiche en 4,5 secondes, que fansolo s’affiche en 6,5 secondes. Si ça vous amuse, choisissez votre site préféré et lancez le test. Si vous avez du mal à interpreter les résultats, dites-le moi, on le fera ensemble. Pour le fun, sachez que google.com s’affiche en 0,6 secondes et laredoute.fr en 60 secondes 
Alors liaison de l’hébergeur ou contenu de la page ? Les deux mon capitaine ! Nous avons vu dans un précédent article que Sixapart avait une liaison internet moins bonne que d’autres hébergeurs (pourtant gratuits). Nous voyons là que moins j’ai d’éléments à charger, et moins je sollicite l’hébergeur. Plus j’ai d’éléments à charger et plus c’est long. Pour m’amuser, j’ai fait des tests des sites des blogueurs de l’agglo qui sont hébergés comme moi chez Sixapart. L’un est capable d’afficher sa page en 7s, l’autre en 30s. Différence ? Le nombre d’éléments chargés
J’ai donc plusieurs pistes :
- changer d’hébergeur (ça m’embêterait, j’y suis attaché)
- changer l’ergonomie de mon blog pour que le template soit plus simple, comprenne moins d’éléments et soit donc plus rapide à charger
Prochainement, donc, côté boulevard va donc devoir changer de look, sniff
A lire aussi :
Posté par Miguel
le 21 juil 2007. inséré dans Web/Tech.
Mots-clefs :blogs, page html, temps de reponse, temps reseau
Generated Sun, 22 Jul 2007 22:22:21 GMT by http://www.sixapart.com (squid/2.6.STABLE6)
.
Comme tu peux le voir Sixapart utilise Squid (heureusement), tu n’auras par conséquent jamais le même temps d’accés selon l’expiration du cache, fréquence de visites, des dates de dernière modification basé sur l’en-tête HTTP « Last-Modified », blahh.. plein de facteurs en faite
OctaGate est endormi, ou quoi ? Il n’a pas l’air disponible, en tout cas depuis ce dimanche matin…
Pour SixApart, le problème est quand même que c’est une boîte située à San Francisco. Donc peu étonnant qu’il y ait un ralentissement !
désolé pour le plantage d’Octagate, c’est un article que j’avais préparé depuis plusieurs jours. C’est je jour où il parait, que le site est planté
Pour San franscisco, je crois que c’est sans rapport : le problème n’est pas d’arriver chez Six Apart mais sur le réseau de sixa Apart (voir l’article http://www.coteboulevard.com/2007/07/lenteur-typepad.html)
Pour Squid, je ne connais pas, peut-être fo0 peut-il être plus explicite parce que je ne comprend pas tout, là…
Oh la la la la…
Mon site est tellement long à charger que le octagate machin-bidule il a planté !
Mon pauvre blog n’est que 28ème blog politique ce matin… 351 d’autorithy technoratruc et rank 11,416…
Pas terrible…
Résumé Squid
Bon pour dégrossir la chose, ton navigateur interroge d’abord le proxy squid (de facon transparente pour ton navig.) avant d’aller aux serveurs (donc dans le réseau de six-apart),afin de ne pas surchargé le réseau .Dans la pratique Squid gére les requetes en un seul processus E/S, il conserve les données les plus fréquement demandé,et si les données sont présentes et suffisament à jour, il les restitue en lieu et place du serveur http hébergeant le « vrai » site.Plus fort il a le rôle de serveur mandataire, je m’explique:
-Miguel va sur monorleans.com
-Squid laisse passer la requete car il n’a pas les données en cache.
-fo0 va sur monorleans.com et remercie Miguel d’avoir mis en cache le site.
Cqfd: Fo0 accédera plus rapidement aux données que Miguel, car mes requêtes seront retournées par Squid.
Je rappel Squid est une solution OpenSource fiable et qui a fait ses preuves pom pom pom.
Sufisament vulgarisé ?
Impec fo0. Je connaissais de nom mais je ne savais pas ce que ça faisait.
Je connais l’offre de la société Akamai (utilisée par windowsupdate et les grands sites de VPC). Ils font à peu près la même chose a 3 détails prets :
- Les serveurs akamai sont directement sur les coeurs de réseaux des opérateurs : la ligne internet de l’entreprise n’est donc plus utilisée. Aux clients FT, c’est le serveur FT qui répond, aux clients neuf, c’estle serveur neuf qui répond, pas mal
- Les serveurs sont capables de détecter qu’une page dynamique est en fait une page statique qui varie selon un paramètre et qui peut donc être mise en cache.
- La solution est payante (tu paies Akamai au lieu de payer ton fournisseur). la différence, c’est que tu ne paye akamai que quand tu l’utilise alors que tu paie habituellement le fournisseur d’accès même si tu n’utilise que 10% de la capacité les 3/4 du temps
Tiens en parlant d’Akamai !
AKAMAI TECHNOLOGIES INC. [NSA-affiliated IP range]
Cambridge MA
66.77.68.0 – 66.77.69.255
ns1.jsv.qwest.net [208.44.134.25]
ns1.ewr.qwest.net [208.45.144.25]
ns1.iad.qwest.net [216.207.84.25]
ns1.bur.qwest.net [208.45.146.25]
La NSA a faim de block en ce moment.
Sinon je connais le systeme des pages « Akamaized »
Miguel > Si-si, San Francisco a son importance, puisque le site a bien l’air d’être stocké là-bas : lorsque l’on fait un traceroute (« tracert » sous Windows) vers http://www.coteboulevard.com et son IP, il y a ralentissement au début, passage systématique par Londres pour ensuite traverser l’Atlantique (212.73.207.33 vers 4.68.109.131), puis on arrive à 204.9.176.19 (qui est aussi à San Francisco) avant d’être sur Côté Boulevard.
@Gille: à partir de neuf, j’ai (voir http://www.coteboulevard.com/2007/07/lenteur-typepad.html) :
30 ms sur chaque tronçon puis
9 30 ms 31 ms 30 ms globalcrossing-118184-prs-b2.telia.net [213.248.
71.122]
10 182 ms 183 ms 212 ms SIX-APART-LTD.ae0.402.ar2.PAO2.gblx.net [64.210.
19.210]
11 182 ms 183 ms 183 ms ve102.core1.tme.sixapart.com [204.9.176.19]
12 185 ms 186 ms 186 ms 204.9.177.195
Tu peux me donner ton tracert parce que pour moi ça rame à partir d’adresses sixapart (France/US, je ne sais pas, je n’ai pas vérifié)
@fo0 « systeme des pages « Akamaized » : ça consiste bien à rendre les pages compatibles avec akamai ?
Bah les chiffres sont quasiment les mêmes : ralentissement au même instant, avec 15 à 20 ms de moins au total.
(sept ou huit demandes dans le vide, puis…)
040 ms te-3-4.car1.Paris1.Level3.net [212.73.207.33]
039 ms ge-1-2.core1.Paris1.Level3.net [4.68.109.131]
039 ms glbx-level3.Paris1.Level3.net [4.68.127.98]
194 ms so5-0-0-2488M.ar2.PAO2.gblx.net [67.17.93.109]
195 ms SIX-APART-LTD.(…).gblx.net [64.210.19.210]
196 ms ve102.core1.tme.sixapart.com [204.9.176.19]
195 ms 204.9.177.195
Note : j’ai essayé un traceroute sur kyxar.fr et ça a… bloqué le site ! Décidément… Par contre visualroute.visualware.com se débrouille toujours aussi bien, mais ne trace qu’en démarrant des States.