Parlez de performance de sites web à un ingénieur standard, le voilà déjà tentant d’optimiser son code PHP ou son code Java, et de lancer des sondes sur son serveur de bases de données. Oh, c’est important et des fois l’applicatif est vraiment mal fait, mais généralement ce n’est pas ce qui pose problème, mais alors pas du tout.
La mesure
J’ai donc repris les chiffres de vendredi dernier et j’ai tenté de mesurer combien de temps est pris par cette page HTML principale. Je compte le temps de la requête, la latence, le temps de génération de la page, et le temps de téléchargement du code source.
Voici mes résultats :
| Site | Page HTML | Chargement complet | % |
|---|---|---|---|
| TF1 | 88 ms | 5,0 s. | 1,8 % |
| AlloCiné | 58 ms | 4,0 s. | 1,5 % |
| 329 ms | 4,6 s. | 7,2 % | |
| Skyrock | 36 ms | 3,7 s. | 1,0 % |
| France Telecom | 3,5 s | 10,1 s. | 34,7 % |
| Free – portail | 43 ms | 4,4 s. | 1,0 % |
| Google – résultats | 165 ms | 0,24 s. | 68,8 % |
| Yahoo! France | 552 ms | 1,8 s. | 30,7 % |
| Daily Motion | 204 ms | 2,4 s. | 8,5 % |
| Le Monde | 50 ms | 7,9 s. | 0,7 % |
| Amazon France | 930 ms | 3,7 s. | 25,1 % |
| MSN France | 168 ms | 0,9 s. | 18,7 % |
Le cas France Telecom
Encore une fois, le temps pour France Telecom est pris en comptant les redirections sur la page d’accueil, et on voit ici bien pourquoi. Ces redirections plombent complètement le site puisqu’elles représentent 3,6 secondes, sur un total de 10 secondes. C’est délirant, et sans justification aucune vu la simplicité qu’il devrait y avoir dans un système de redirection de pays comme celui ci.
Sans ses redirections on arrive à 90 milli secondes sur un total de 6 secondes environ, donc un poids relatif de la page d’accueil inférieur à 2%.
Les deux catégories
Ce qui m’intéresse c’est deux choses :
Tout d’abord on voit que les seuls qui ont une page d’accueil significative sont ceux qui ont déjà travaillé et optimisé le côté client, et qui s’en sortent avec des performances bonnes ou honorables. Bref, avoir un bon rapport contenu / poids total est un bon critère de réussite.
Ensuite on voit que dans les autres, la page d’accueil, son poids, et le temps pour la générer, n’ont quasiment aucune influence significative sur le temps de chargement subit par l’utilisateur. Ce n’est clairement pas ça qu’il faut optimiser et vous pouvez laisser votre ingénieur et ses micro optimisations applicatives de côté (sauf si vous êtes à France Telecom).
La conséquence
Le temps de génération de la page représente une part infime, et il vaut mieux gagner 5% dans le reste du chargement que de gagner 50% sur le temps de génération de la page principale. La chance c’est que non seulement c’est plus rentable mais c’est aussi plus facile. Souvenez-vous, smushit c’est 10 minutes de travail pour une efficacité bien plus importante que ça.
Bref, travaillez sur le côté client, le retour sur investissement est bien plus important, bien bien plus.
Je confirme votre dernier paragraphe, je viens de passer une petite demi-heure à optimiser mes images via smushit et je n’en reviens pas de l’optimisation de la rapidité lors de la navigation sur mon prochain site!
Merci pour vos articles en tout cas, et, indirectement, mes visiteurs vous remercient aussi 🙂
Il faudrait toutefois un peu tempérer cet article. Si je suis ok avec la trame générale, il ne faut pas non plus le prendre comme une incitation au « porki code ». Des pages php mal codées, des requêtes sql mal faites, une mauvaise utilisation des ressources côté serveur et c’est vite celui-ci qui est saturé.
A ce moment là ce n’est plus tellement le temps de chargement des pages qui est affecté mais la capacité même du serveur à les servir.
Je suis actuellement à la recherche d’un nouveau job, et je parle lors de mes entretiens d’optimisation web, côté client. C’est fou comme les gens ont du mal à comprendre! Ils sont bornés et me parlent d’optimisation SQL, php… Irrécupérable! 😉
@kaps: Ah, on parle là de deux « performances » différentes.
L’optique de ce blog c’est parler de ce que ressent l’utilisateur, parce que c’est finalement ce qui importe. On parle donc temps de chargement, affichage de la page, réactivité, etc.
Derrière, de ton côté, que ça soit performant ou pas chez toi c’est une question d’investissement en temps et en nombre de serveurs. Il y a déjà beaucoup de ressources sur ce sujet, je n’en ajouterai pas une de plus.
Je commence à en parler aux designers chez nous des problèmes de perf. Ça ne passe pas encore très bien mais j’y travaille 🙂
Pour rire, allez voir http://www.adobe.com/products/flash/