Commentaires sur : Comment optimiser les performances d’un site Internet

Par : EoN

EoN — Thu, 14 Aug 2008 13:47:15 +0000

Super les conseils de Yahoo!.
Moi aussi j’ai fait récemment un petit résumé : optimisation des sites web et accélération d’affichage des pages .

Par : Stéphane

Stéphane — Fri, 28 Mar 2008 09:32:23 +0000

En fait Godefroy, les ingénieurs de Yahoo! se sont particulièrement intéressés à la notion de vitesse ressentie par l’utilisateur. Toutes ces optimisations au niveau de la partie cliente permettent donc d’améliorer grandement l’expérience utilisateur. Bien sûr, une optimisation côté serveur est indispensable, mais a priori plus technique et plus compliquée à mettre en place. Donc peut-être vaut-il mieux se focaliser dans un premier temps sur la partie cliente avant de travailler sur l’optimisation de la partie serveur.

Sinon pour l’hébergement, je suis d’accord avec toi Domi : c’est un vrai casse-tête !

Par : Samir

Samir — Wed, 26 Mar 2008 16:38:11 +0000

Merci bcp pour ce billet très enrichissant qui aidera sûrement bcp de webmasters

Par : Domi

Domi — Wed, 26 Mar 2008 10:30:02 +0000

Après l’étude sur la montée en charge et l’optimisation des performances j’attends avec impatience un article sur “comment trouver le bon hébergement sans investir tout ce qu’on a pas encore gagné” ! ;o)
Les bons hebergements existent mais sont rares et hors de prix.
Partant de ce constat ou faut-il faire des concessions ? ( Le raid5 ? la SLA ? la fréquence des sauvegardes ? La qualité du dialogue avec le fournisseur ? … )

Par : Godefroy (aka Skreo)

Godefroy (aka Skreo) — Wed, 26 Mar 2008 07:47:02 +0000

@Thomas: donc on est bien d’accord Je fais aussi attention au poids des images, css, et js, et j’utilise parfois des sprites. Mais je voulais aussi dire que si tu as un wysiwyg comme tinyMCE qui te charge 300 ko de js réparti en 15 fichiers (avec les plugins) ainsi que toutes les icônes qu’il utilise, il y a d’autres priorité que de remplacer 3 icônes par un seul fichier en sprites.
Pour m’attarder sur tinyMCE, je l’utilise, et j’ai passé pas mal de temps à modifier son code pour rassembler tous les plugins, l’adapter au reste de mon code, et tout compresser (optimisation+gzip) en cache.

Par : Thomas

Thomas — Wed, 26 Mar 2008 02:31:16 +0000

Au fait, merci pour l’article!

Par : Thomas

Thomas — Wed, 26 Mar 2008 02:30:34 +0000

Pas d’accord avec le dernier commentaire. En fait, cela dépend grandement du type d’application que tu développe.
Je développe depuis plus d’un an une application entièrement en GWT. Elle est très lourde, une seule page, fortement Ajaxée et complexe. De plus, c’est une application qui est utilisée toute la journée par les utilisateurs (ils se connectent le matin et se déconnectent le soir). Et bien, si j’arrive à gagner ne serait-ce qu’un round-trip, je suis heureux. Si j’ai 10000 utilisateurs (cas d’utilisation) qui font une requête en trop, ça me bouffe ma bande passante (et ça me coute potentiellement du fric), ça ralentis mon appli côté client (une connexion bouffée) et donc, la performance perçue par le end-user peut s’en ressentir.

Rassembler 50 icones dans un seul sprite, c’est divisé potentiellement par 50 le nombre de requêtes à ton serveur. C’est pas négligeable lorsque l’on sait que le truc qui bouffe le plus les ressources côté client, ce sont les requetes HTTPs. Et comme le dit je ne sais plus qui, la requete HTTP la plus rapide est celle qui n’a pas lieu. Avec GWT, la mise en place de sprite passe par la classe ImageBundle (la création des sprite est automatique).

J’ajoute à cela la minimisation des fichiers Javascript ET du fichier CSS. C’est peut-être quelques kilo-octects, mais encore une fois, c’est toujours cela de gagné (Avec EC2, tu paye à la bande passante).

La bonne gestion du cache côté client est bien évidemment très importante. Dans le cadre de GWT, il faut penser à cacher à minimum 1 an les fichiers *.cache.html (dans le header de la réponse HTTP). Si le fichier change entre temps, GWT changera automatiquement le nom et le navigateur récupèrera le nouveau fichier (pas besoin de se prendre la tête comme Yahoo avec les noms à changer soit-même).

Enfin, et dernier point important. Il ne faut pas oublier que Javascript est bien sympa mais il est très facile de se retrouver avec des fuites mémoires de partout (surtout sous IE). Donc, regardez les bonnes pratiques pour éviter de tomber dans les pièges. Car, une application qui fuit, c’est une application lente et désagréable à utiliser (j’aime pas voir mon firefox monter à 300 meg en plus)

Et bien entendu, tout cela ne fera que cacher la misère si le code serveur est pourri. De toute façon, dès que le nombre d’utilisateur augmentera, on verra très vite le serveur se casser la gueule et les temps de réponse augmentés de manière exponentielle.

Pour conclure, je dirai que chaque optimization est bonne à prendre, mais la plus insignifiante, qu’elle soit au niveau du client, du serveur Apache, du serveur Mysql/Oracle, des connecteurs, du système d’exploitation, du disque dur, voir plus.

Thomas

Par : Godefroy (aka Skreo)

Godefroy (aka Skreo) — Tue, 25 Mar 2008 20:18:07 +0000

C’est intéressant, mais je pense que certaines optimisations sont totalement négligeables si on a pas très bien optimisé certains autres aspects, à savoir la structure des bases de données (clés primaires, index, requêtes optimisées..), un code php propre et bien structuré également, et une framework javascript légère.
Le plus important est vraiment l’optimisation côté serveur, tu peux me croire ^^ Car les problèmes de lenteur proviennent presque toujours du manque de ressources serveur, dues le plus souvent à un code très peu performant… Il faut par exemple penser aux systèmes de cache, et à faire les tâches lourdes (comme le comptage des stats) par cron au lieu de les exécuter à chaque chargement de page.

Par : eMeRiKa

eMeRiKa — Tue, 25 Mar 2008 07:22:26 +0000

Un atelier de Paris Web 2007 était également consacré à cette question avec une grosse partie sur l’optimisation du frontend. J’en ai fais un petit résumé dans un article http://www.affinity-web.org/lanews-51.php