Sous les 3 secondes pour l’affichage d’une page on est quand même bien rapide. C’est assez confortable. Mais c’est quand même mieux d’être dans les 50% de sites les plus rapides que faire parti des plus lents…

Les pubs… Une vraie plaie. Sans compter le marqueur Xiti comme tu dis, mais aussi le bouton feedburner…

Une exemple avec la page d’accueil d’ADNPC :
Cache navigateur vide : 4,90s
Cache navigateur plein : 2,68s (cad mes images, js et css sont en cache dans le client)
Donc, moins les 400ms de la requête de la page (qui met que 180ms à se générer, soit dit en passant…), ça veut dire que les pubs et autres babioles me coûtent 2,20s !

J’ai optimisé à fond le temps de génération de page (cache par partie…), le reste était accessoire (juste expire & gzip, ça joue déjà beaucoup).

Mais il y a des trucs, on peut pas jouer dessus. Comme tu dis, pour les pubs, on peut pas faire autrement. On peut se dire que quand les visiteurs sont fidèles, les bannières sont en cache chez eux, ils se tapent juste les appels pour les stats…

Sinon, à mon avis, Google prend déjà en compte le temps de chargement de la page dans son algorithme, et depuis longtemps. S’ils nous montre la courbe dans les stats d’indexation, c’est pas pour rien. Après, depuis récemment, ils nous montre une courbe avec le temps “overall” (ie avec les images, les js…), donc à mon avis, c’est pas pour rien non plus…

Nil, un proxy ne devrait pas me faire gagner beaucoup de temps. Memcached à déjà fortement réduit le temps de construction des pages dynamiques. De plus je ne voudrais pas ajouter une couche de cache sur du cache.

Cool. Merci pour ton retour d’expérience bien détaillé. Une mine d’or pour moi et je pense que je vais mettre en œuvre le mod_expires sur cbanque.

Pour info, cbanque (lui aussi sur un serveur avec disque SSD) est plus rapide que 59% des sites (d’après Google Webmasters) avec une moyenne de chargement de 2,4s. Une moyenne obtenue avec de nombreuses pages sans accès direct à SQL.