Ce blog est sur son propre serveur depuis maintenant quelques mois, mais pour autant je souffre toujours de lenteurs pour l’envoi des pages. Pourquoi cela ? Plusieurs raisons : le poids de la page, le contenu (contenu externe, images a aller chercher ailleurs, etc), mais surtout la méthode de création de la page. Et à ce niveau, il y a plusieurs possibilités. Je vais tenter d’en citer trois (qui ne sont peut-être pas les seules), pour lesquelles je vous demande de ne pas hésiter à me corriger si j’écris des erreurs.
Trois méthodes, donc. Quand vous appelez une page, c’est Apache qui reçoit d’abord votre requête. En fonction de l’URL :
- Soit l’URL correspond à un fichier de la racine (ou à un fichier dans l’arborescence des fichiers du site), auquel cas Apache renvoie au client ce fichier.
- Soit l’URL ne correspond a aucun fichier, auquel cas Apache « lance » WordPress, qui se charge de lire l’URL, et :
- voit que la page est déjà générée (auquel cas il renvoie la page générée),
- soit la page n’est pas encore générée, auquel cas il la génère et l’envoie.
Je me suis inscris hier au service Mon.itor.us, qui… monitore sur la durée le temps de réponse d’une page. Je l’ai configuré pour qu’il enregistre les différents temps de réponse de ma page d’accueil. Au moment où je me suis inscrit sur le service, la page d’accueil était celle fournie par le cache WordPress (issu du plugin WP-SuperCache). Donc théoriquement, c’est déjà une page cachée, mais le temps de réponse est malgré tout de 1,4 seconde en moyenne, ce qui est une honte. Rappelez-vous bien que ceci n’est que le temps de réponse de la page (le fichier HTML), c’est à dire sans inclure tous les temps supplémentaires de chargement des différents CSS, images et autres fichiers de scripts. Donc 1,4 secondes, c’est un temps minimal.
Et au final, Google Site Performance me dit :
On average, pages in your site take 10.7 seconds to load (updated on Dec 31, 2009). This is slower than 94% of sites.
Quand on sait que Google a déjà commencé à intégrer des paramètres de temps de réponse dans sa stratégie de calcul du pagerank, il y a de quoi avoir peur.
Pour prendre un exemple « neutre », un serveur optimisé a un temps de réponse moyen de… 0.1 seconde. Ouille ! Donc j’ai décidé de prendre les choses en main, et n’ayant pas le temps de faire d’autres billets dans la journée d’hier, j’ai généré le fichier index.htm avec le code source de la page d’accueil, fichier que j’ai placé à la racine de mon blog. Comme il y a une priorité du .htm sur le .php (qui gère normalement le site), c’est donc le index.htm qui est servit au client quand il demande la page d’accueil.
Au final, le processus est différent : là, Apache envoie directement le fichier, sans interpréter une seule ligne de PHP. Et le temps de réponse n’est pas le même : je suis descendu à 0.2 seconde en moyenne ! (ou 0.05 seconde sur l’Europe, mais je n’arrive pas à constater ces résultats par ailleurs). Donc c’est mieux.
Or, comme la page d’accueil de mon blog n’est pas celle qui est la plus lue, je me suis dit que je pourrais faire la même chose avec les autres pages. Je l’ai fait, et j’ai constaté la même évolution dans le bon sens. Mais plutôt que de générer un .htm à chaque fois, j’ai décidé, pour chaque page du blog, de reprendre directement les pages générées par le plugin SuperCache de WordPress (stockées dans wp-content/cache ), et de les mettre à la racine du site (afin qu’elles soient traitées par Apache, sans utiliser de PHP).
Mon seul problème est donc que c’est une manipulation qui doit être faite à la main. Du coup, il me manque un moyen de changer le répertoire configuré pour wp-SuperCache, et de le mettre à la racine, comme ça SuperCache génèrerait son cache à la racine, sauf que celui-ci serait récupéré et utilisé directement par Apache, sans passer par le blog.
Et les contenus dynamiques ?
Les pages du blog contiennent une certaine quantité de contenu dynamique. Notamment les commentaires. Or, les commentaires de chaque billet ne sont pas directement stockés dans le fichier de la page, mais en fait ils viennent de Disqus, via un fichier Javascript qui les met sur la page. Or, ce fichier JS est différent du fichier de la page, et donc on peut considérer que grâce à Disqus, les commentaires en sont jamais en cache, mais sont toujours dynamiques. Ainsi, même si je copie-colle les fichiers de cache à la racine, le système de commentaire fonctionne toujours parfaitement, même si des gens continuent de commenter (j’ai fait l’essai) !
Les contenus statiques
J’ai remarqué quelque chose, par ailleurs, c’est que les contenus statiques peuvent être envoyés avec un temps de réponse extrêmement faible, quand ils sont hébergés sur un serveur qui est fait pour ça. Seul bémol : il faut trouver le serveur, et cela fait une requête DNS supplémentaire. Si on néglige la durée nécessaire à la requête DNS, on peut se concentrer sur les serveurs de contenus statiques. Rassurez-vous, Disqus est très bien optimisé, au vu de la vitesse à laquelle ils envoient leurs fichiers (par exemple, les images qui permettent de rendre plus joli le template de commentaires), je suis sûr qu’ils ont un (ou plusieurs) serveur(s) de contenus statiques derrière le domaine media.disqus.com. Mais là n’est pas la question. La question est de savoir comment je peux faire pour héberger les contenus de mon site sur un serveur de contenus statiques, alors que je n’ai à ma disposition qu’un Apache. D’ailleurs, on voit bien la différence entre les fichiers hébergés par Disqus, et ceux hébergés sur « mon » Apache : par exemple via le test de Pingdom (le but est que chaque barre de chargement soit la plus courte possible) :
(Pour ceux qui sont intéressés, la limite entre le jaune et le vers sur chaque barre correspond au début de la connexion. Le téléchargement ne se fait que « pendant » la durée symbolisée par la couleur bleue)
Si vous avez une idée pour le serveur statique, je suis preneur. Je n’ai pas encore trouvé de service d’hébergement d’images que je pourrais utiliser pour mettre les miennes (pas les grosses, juste les toutes petites images qui sont un peu partout sur mon thème), mais je reste ouvert à toute proposition.
Edit : Voilà un schéma du temps de réponse de la page d’accueil encore plus parlant :
Par contre j'ai l'impression que cela pose un problème avec le CSS. Parce que je vois des pages sans mise en page.
Cela me faisait pareil sur mon blog quand j'avais essayé de mettre le plugin Minify.
Ah bon ? Cela m'étonne parce que pour ma part, je ne tombe jamais dessus…
Quelle est ta configuration ? (navigateur, OS) Sur quelle page cela-t-es arrivé ?
Par exemple : http://www.abricocotier.fr/8900-le-nexus-one-so…
ou : http://www.abricocotier.fr/7640-achat-dun-serve…
Ma config : MacOS X 10.6, Safari 4.0.4
Et comme je suis super sympa comme mec voilà une petite capture : http://drp.ly/9HIcg
Bizarre. Je viens de tester ces deux pages sur Firefox 3.5.6 et Chrome 3 (qui tourne sur Webkit, comme Safari), et je n'ai constaté aucun problème.
As-tu eu ces erreurs à nouveau après avoir reloadé la page ?
Apparement droplr n'a pas aimé mon image, voilà un nouveau lien : http://dl.dropbox.com/u/724990/Achat%20d%E2%80%…
Effectivement. Il doit manquer le CSS.
Alors je te préviens, j'étais tout à l'heure en train de faire des modifs d'optimisation du CSS justement, donc il est possible que tu aies appelé une page pendant que le CSS était supprimé 🙁
En reloadant (Ctrl+F5) tu as eu la même erreur ?
Oui j'ai reloader, je viens de tester avec chrome pas de problèmes. Bizarre !
Je pense que la première fois, tu es tombé à un moment où le CSS était manquant (c'était ma faute). Puis après tu as fait un simple reload de la page, mais pas des fichiers associé (c'est la différence entre F5 et Ctrl+F5).
En passant sous Chrome, celui-ci a tout téléchargé (puisqu'il ne partage pas le même cache avec Safari), et donc il n'a pas vu de problème avec le CSS !
Bonne soirée et merci 🙂
Bah disons que sur Mac il n'y a pas de ctrl+f5, mais j'ai vidé le cache et actualisé, mais c'est toujours pareil !
Bon courage !
Salut,
Moi, je te recommande l'installation d'un nouveau serveur web. Moi, j'utilise NGinx, un serveur web léger et TRES performant ! Dès que l'ont veux monter en puissance avec Apache ce dernier engloutis énormément de mémoire vive. NGinx Utilise un complèxe système qui lui permet d'utiliser qu'un seul processus pour toutes les demandes. Qu'il est 1 r/s (requette/seconde) ou 234231 r/s il consomme grosso modo la même quantité de mémoire vive. Ensuite, tu pourrais optimiser mieux le serveur SQL et pour finir, installer XCache (apt-get install php-xcache sous une debian like devrais suffire avec un peu de config). XCache « compile » le code PHP (transforme en byte-code, un peu le principe du Java ou de l'ASP.Net) et le met en mémoire vive. Donc là, niveau performances tu fais x3 ! Aussi tu peux utiliser la compression GZip, NGinx le propose et tu peux réduire le poid de tes pages de 70% ! Dernier point, NGinx a un petit défaut. Il ne supporte pas les .htaccess. Il va donc falloir écrire une petite règle pour l'url rewriting dans la configuration du serveur. C'est très simple et même WordPress.Com utilise NGinx ! Si tu veux de l'aide, tu as mon mail 😉
Merci pour tes conseils.
SAche que j'aimerai bien les suivre, mais je n'ai pour l'heure absolument aucune connaissance en administration serveur (et j'ai honte, j'aimerai vraiment apprendre), et je suis au courant que Nginx est un très bon serveur pour des fichiers statiques, mais je ne sais rien faire de tout cela.
C'est la raison pour laquelle j'ai pris un serveur pré-administré.
J'envisage d'ici fin février d'avoir acquis les rudiments, et donc de transférer le serveur sur un autre dont je maitriserai à peu près tout.
Très bien 🙂 Sinon tu peux faire appel à moi si tu veux que je fasse ton admin serveur 😉 Un petit Kimsufi 750g enverrai la purée avec un blog comme ça !
Salut,
Depuis un moment j'hésite à installer WP-Super-Cache mais j'ai un peu de réticence car quelques questions se posent :
– le script google analytics va toujours être appliqué et comptera les visites malgré que les pages vues seront celles qui sont en cache ?
– concernant les pubs ( blogbang, ebuzzing etc ), celles-ci seront toujours actives et donc comptabilisées si vues/cliquées ?
– mon plugin de compteur de visites ( WP-PostViews ) comptera toujours les pages vues malgré que ça sera les fichiers mis en caches qui seront desservis ?
C'est à peu près les mêmes questions mais j'avoue que je me demande quand même la réponse alors si tu pourrais éclairer ma lanterne 😉
A+
Pour Google oui, c'est du JS. De même pour les pub je pense 😉 Temps que ce n'est pas du PHP. Pour ton plugin je pense pas cependant …
D'accord, merci pour la réponse 😉
Pour WP-PostViews j'ai regardé sur le forum du créateur et visiblement ça fonctionne toujours, les modifications apparaitront seulement quand la page sera régénérée, mais ça c'est logique.
Je confirme ce qu'a dit iMeee :
Google et les différentes pubs, c'est des scripts que tu appelles à chaque affichage de la page chez le client. Que la page soit en statique, on s'en fout, au final c'est le client qui appelle le script, et donc qui l'utilise. Pas de pb à ce niveau.
Pour ton plugin PagesView, pas sûr que ça fonctionne, car il est possible que ce soit une comptabilisation du nombre de fois qu'il y a eu un appel à la BDD. Mais ça peut aussi être un script de tracking en JS a rajouter dans ta page, auquel cas ça fonctionnera comme Google Analytics, et donc on s'en fout si la page est en cache ou non.
Enfin, pour l'affichage des pages vues, oui, là, ça ne se mettra pas à jour :-/
Merci de la confirmation et explications Louis 🙂
Concernant le plugin, c'est du php donc je ne sais pas comment ça va fonctionner , peut être vais-je devoir m'en passer ou trouver une alternative en JS
Oui passer à Nginx aiderait bien. J'ai un tutoriel vidéo à ce propos: http://www.digiprof.tv/categories/nouvelles-tec…
Mais bon, globalement c'est WordPress le boulet, pardon le goulet d'étranglement. Attention avec la mise en cache, y'a des effets bizarrezs avec le contenu dynamique comme par exemple faire des liens vers des articles similaires.
Oui, Nginx est bien, notamment pour mettre le contenu statique. Mais je n'ai pas la main sur mon serveur, donc je ne peux pas encore réaliser cela.
Un vrai bonheur de rapidité votre site !
Après la lecture de ce site (et la découverte de monitorus), je n’ai qu’une chose à dire : bravo ! C’est vraiment agréable d’avoir des pages qui s’affichent quasi-immédiatement.
Bonne continuation,
Jérémy
Bonsoir,
Tout d’abord, un très grand merci à Louis.
J’apprécie l’effort de partage et la clarté de l’explication.
Est-ce que la page actuelle 8844-sur-… est mise en cache statique sur la racine du site comme tu l’a expliqué ?
Je constate sur firebug : poids 19.7KB, et 421ms d’attente de chargement. Ce qui est une bonne performance pour moi, mais n’est pas vraiment du 0.2 s
Es-tu passé dans la marge verte de Google au niveau de la vitesse de chargement après cela ?
Je découvre tout juste ce superbe article, et je vais m’empresser de tester tout cela.
Superbe site. Je m’y abonne.
Re-bonsoir,
Apres avoir fait quelques tests, j’obtiens des résultats très intéressants.
Les regles URL Rewritting de mon wordpress sont les suivantes : /%postname%/
j’ai récemment changer cette configuration. Avant, il y avait les annees et mois et jour. J’ai donc du rajouter ceci a mon fichier .htaccess :
RedirectMatch 301 /([0-9]+)/([0-9]+)/([0-9]+)/(.*)$ http://www.mon-site.com/$4
Pour le test de fichier static à la racine du site, j’a donc placé le répertoire nommé « titre-de-ma-page-url-a-tester » qui contient le fichier index.html généré par WP-Super-Cache.
En chargeant le site à cette page :
http://www.mon-site.com/titre-de-ma-page-url-a-teste/
j’obtiens toujours mon gros fichier de 23.6 KB chargé en 1.04s
Mais en chargeant le site à la meme page sans mettre le dernier slash :
http://www.mon-site.com/titre-de-ma-page-url-a-teste
Là, j’obtiens effectivement le premier fichier plus petit et plus rapide de 248B en 395ms
mais dont le statut est 301 Moved Permanently.
Du coup, il se charge également mon gros vieux fichier de 23.6 KB tout de suite après.
Il y a donc du progrès.
Je n’arrive cependant pas a empécher cette redirection vers le fichier dynamique (meme si supposé static avec WPSuperCache).
Je me suis dis que cela était surement du à la règle que j’ai rajouter sur le .htaccess, mais en la retirant, ainsi que les règles de WP-Super-Cache. J’en arrive toujours à la meme chose.
Si la réponse est que de toute façon tout appel d’url sans le dernier slash redirige toujours vers l’url avec slash. De quel moyen puis-je appelé correctement la bonne page static.
Merci d’avance pour un éclaircissement de votre part !!
@Next: Alors j’avais constaté le 0,2 seconde sur une *bonne* connexion (celle de mon ancien lieu de travail). Mais c’est vrai qu’en fonction de sa connexion, ça peut varier du tout au tout.
@Next: En fait le problème c’est que l’URL sans le / ne match pas avec la règle htaccess d’Apache… Enfin je ne comprend pas exactement, mais j’ai l’impression qu’il te sert d’abord le fichier statique, puis comme il a une 301, il te balance le fichier wpsupercache (ou dynamique). Mais entre temps, il t’as quand même balancé le statique-racine, ce qui fait que tu as une impression de grande qualité dans le chargement. Pour autant, c’est technique avec laquelle je commence à me poser des question, parce que je ne suis pas certain que Google aime beaucoup les 301 (pour le référencement)…
Sachant, comme je le disais dans un billet (je ne sais plus lequel) que de toute façon, si ta règle htaccess est mise dans ton sites-available/ de Apache, normalement ça va aussi vite que si tu le mettait à la raicne, sans pour autant avoir les 301 (en fait, le sites-available/ te permet de « remonter » l’instruction, donc elle est plus performantes, tout en ayant exactement le même effet).
D’après certains tests W3 Total Cache serez plus efficace, je vais donc tester et faire un retour d’expérience et qui sais vous faire changer…
Salut à tous,
Dans la même logique, que pensez-vous du plugin Really Static ? Il permet de convertir son blog en pages statiques qui sont régénérées à chaque modif / commentaire. Est-ce que certains d’entre vous l’aurait déjà testé ?
@création de sites internet annecy: Très bonne idée. Il faudrait que je teste, d’autant plus que ce plugin permet peut-être de se séparer (définitivement) de Apache.
Avez-vous pu tester Really Static finalement ? Ce qui me fait peur est que le plug-in n’a plus été mis à jour depuis décembre 2009…
je suis preneur également des retours sur Really static
Comme exprimé dans les commentaires précédents, faut quand même saluer le bel effort de Louis de nous fournir des éléments vraiment instructifs 🙂