Le web est ma passion, son développement mon métier. A travers ce blog, je partage mon regard de jeune entrepreneur sur les nouvelles technologies.

Lectures recommandées
Derniers articles
Rechercher

Optimisons Wordpress – Partie 2

Note : Ce billet a été rédigé par Aurelie. Elle est notamment à l’origine de cette 2eme version d’ilonet, basée sur un Wordpress décortiqué et optimisé.

Je vous rappelle le contexte, je me suis proposée pour écrire une petite série de billets sur l’optimisation de Wordpress. En analysant les sources du moteur de blogs, et en bidouillant un peu, j’ai en effet réussi à accélérer son chargement d’environ 27 fois. Et même si cela est plus difficile à quantifier, ces modifications ont aussi un impact important sur la charge du serveur : le blog consomme moins de ressources, donc le serveur est capable d’accueillir plus de lecteurs.

Lors du premier article, je vous présentais les petits trucs à astuces, à mettre en œuvre en premier lieu. Ces modifications ne touchaient que le cœur de Wordpress. Aujourd’hui, elles touchent également à la configuration du serveur. Cela signifie qu’il est souhaitable d’être administrateur du serveur en question ! Notez que je détaille les commandes pour une distribution Linux Debian Lenny, mais qu’elles sont facilement adaptables pour les autres distributions.

Utiliser le cache Wordpress

Je vous propose ici un cache super puissant. Oubliez les extensions qui vous promettent la lune, sans jamais tenir leurs promesses. Intelligent, ce système de cache place en effet les objets les plus utilisés en mémoire vive. C’est-à-dire qu’ils seront accessibles en une fraction de millisecondes, difficile de faire plus rapide !

Pour cela, vous devez au préalable installer Memcached sur votre serveur Web. Sous Linux Debian, utilisez simplement la commande suivante :

aptitude install memcached php5-memcache

Puis redémarrez votre serveur Apache :

/etc/init.d/apache2 restart

Si vous désirez vérifier que tout s’est bien déroulé, créez une page phpinfo.php contenant le code suivant :

<?php
    phpinfo();
?>

En l’appelant depuis votre navigateur Internet (comme Google Chrome ou Firefox), une rubrique memcache doit être affichée dans la page.

Pour activer le cache Wordpress, vous devez ensuite définir la constante WP_CACHE dans votre fichier wp-config.php, en y insérant la ligne suivante :

define(‘WP_CACHE’, true);

Enfin, récupérez le contenu de ce fichier, puis enregistrez-le sous le nom object-cache.php dans le dossier wp-content/.

A partir de maintenant, l’ensemble du cache Wordpress est persistant, et sauvegardé en mémoire vive. Vous devrez obtenir une nette amélioration.

Utiliser le cache navigateur

Chaque navigateur possède un cache qui leur est propre. Cela lui permet d’éviter de recharger continuellement des images ou fichiers statiques, sans raison. Encore faut-il le prévenir que ce sont des fichiers statiques !

C’est notamment le cas pour l’ensemble de vos images ou feuilles de style CSS. Nous allons donc installer et utiliser le très bon module Apache expires, et le configurer pour mettre un cache de 10 jours sur toutes les images et fichiers CSS.

Pour cela, sous Linux Debian, commencez par créer un fichier nommé expires.conf, dans le dossier /etc/init.d/apache2/mods-available/, contenant les lignes suivantes :

ExpiresActive On
ExpiresByType text/css "access plus 10 days"
ExpiresByType text/javascript "access plus 10 days"
ExpiresByType application/x-javascript "access plus 10 days"
ExpiresByType application/javascript "access plus 10 days"
ExpiresByType image/x-icon "access plus 10 days"
ExpiresByType image/png "access plus 10 days"
ExpiresByType image/gif "access plus 10 days"
ExpiresByType image/jpeg "access plus 10 days"
ExpiresByType image/jpg "access plus 10 days"
ExpiresByType application/x-shockwave-flash "access plus 10 days"

Ensuite, pour activer ce module, tapez la commande suivante :

ap2enmod expires

Puis redémarrez Apache :

/etc/init.d/apache2 restart

Et ensuite ?

Comme dit dans le précédent article, pour ne pas rendre ces manipulations totalement imbuvables, j’ai décidé de les répartir sur plusieurs petits articles.

Le programme des prochains articles est donc : configuration complète d’Apache, configuration du serveur de base de données MySQL et mise en place d’un cache lourd (via l’installation et la configuration d’un proxy).

L’ordre de ces articles n’est pas anodin : les premiers vous présentent les solutions les plus rapides à mettre en place, tandis que le dernier (sur le cache lourd par proxy) vous détaillera la solution ultime que j’ai pu trouver (à elle seule, elle vous permet de diviser le temps de chargement par 20 au moins).

Tags : , , , , , , , .

Pingbacks

Les news incontournables Geek de la semaine -39- [w] dit :

[...] Ilonet : Optimisons Wordpress – Partie 2 [...]

Les liens de la semaine #5 - Apwn.fr [w] dit :

[...] Ilonet : Optimisons Wordpress – Partie [...]

BlOg'X Office 51 : petit medley du Web | Autour du Web [w] dit :

[...] Optimisons Wordpress – Partie 2 [...]

Chronik Web #12 Sélections des meilleurs liens de la Blogosphere Francophone pour la semaine du 12 au 18 Avril 2010 | webochronik [w] dit :

[...] Ilonet : Optimisons Wordpress – Partie 2. [...]

Les liens de la semaine #6 - Apwn.fr [w] dit :

[...] Ilonet : Optimisons Wordpress – Partie [...]

Vous parlez de cet article sur votre blog ? Faites un trackback.

17 commentaires

Julien Guyomard [w] dit :

Encore une fois, merci à toi Aurelie pour ce second article. En attendant la suite avec impatience. :)

Netsky [w] dit :

Merci c’est très bon tout ça vite la suite ;)

421stores dit :

Tiens, j’avais loupé cette série de billet. Ce genre de conseils sont toujours sympa, d’autant qu’ils sont plutôt bien expliqués.

Par contre, il y a d’autres choses à faire au niveau du cache, pour optimiser Wordpress : utiliser le cache MySQL notamment, ou ajouter un cache PHP. Le cache MySQL fournit un très bon résultat : il faut savoir que sur une application dynamique, c’est bien souvent le serveur de base de données qui rame le plus. L’optimiser est donc une bonne idée.

Camille [w] dit :

@421stores : clairement mais WP est souvent en cause. MySQL, à la base, n’est pas lent. C’est surtout WP et sa sur-couche de plugins qui font que la plupart du temps, y’a beaucoup trop de requêtes par page… Dans certains codes générés par WP, le nombre de requêtes est affiché et c’est assez impressionnant : on passe facilement de 20 à 150… Normalement, on ne doit pas faire appel à la base de données en permanence, surtout pour un blog où les données sont essentiellement du contenu (donc une mise en cache est de rigueur).

Parce que les plugins sont codés un peu n’importe comment et il me semble aussi que le moteur de WP a fait son temps. Au lieu de recoder un noyau solide et performant, l’équipe de développement préfère en mettre plein la vue avec des nouvelles fonctionnalités.

Cela dit, l’article est bien. :) C’est bien de montrer aussi les défauts de WP, les bloggeurs ont tendance à voir que les cotés positifs de son interface et de ses fonctionnalités.

High-Tech [w] dit :

Pour la gestion du Cache : il y a l’excellent plugin WP Super Cache qui permet une gestion assez fine du cache de WordPress et évite ainsi de solliciter trop la base de données.

Nous utilisons le couple Nginx / Apache avec Nginx en frontal qui renvoie directement les pages statiques générées par le plugin.

Jem' dit :

Est-il possible de faire ces améliorations sur un hébergeur de sites mutualisé ?

421stores dit :

@Camille :

Je suis d’accord, MySQL n’est pas la source du problème à proprement parler. C’est l’utilisation que Wordpress en fait qui peut poser problème. Cependant, MySQL reste le goulot d’étranglement en général, c’est là que ça coince. Du coup, je pense que ça peut être utile, aussi, de profiter du cache que MySQL propose de base. Non ?

Aurelie [w] dit :

@Netsky : Merci

@421stores : Tu as raison. Il est nécessaire de configurer correctement MySQL, notamment pour activer le cache, mais aussi pour s’adapter au mieux aux besoins de Wordpress. Ces étapes seront abordés en partie dans le prochain article (en fait, l’idéal est de recompiler une partie de MySQL, mais je doute que j’entrerai dans ces « détails » ici ;) )

@Camille : Les plugins sont en tord, mais la base de Wordpress aussi, en effet. En fait, le code a clairement plusieurs années dans les pattes, et ces concepteurs refusent clairement de le revoir. Car le revoir totalement, c’est aussi condamner certains plugins, qui ne pourront alors plus fonctionner.

@High-Tech : Excellent, je ne suis pas si certaine. Il reste relativement lourd et fait travailler le disque dur à outrance. En fait, c’est mieux que rien, mais j’obtiens des performances bien plus élevées avec le système de proxy, que je détaillerai dans mon dernier article.

Aurelie [w] dit :

@Jem : Oups, j’avais loupé ton commentaire.

Sur un hébergeur mutualisé, tu peux déjà appliquer toutes les modifications évoquées dans mon précédent billet : elles ne touchent que l’application.

Par contre, pour utiliser le système de cache Wordpress, tu as besoin d’avoir Memcache installé sur la machine. Je ne connais aucun serveur mutualisé qui propose une telle option.

En revanche, pour le cache par navigateur, c’est peut être possible. Pas de manière aussi élégante que décrite dans le billet, mais en utilisant le fichier .htaccess. Attention cependant, ce n’est pas facilement réalisable chez tous les hébergeurs ! Mais certains permettent d’ajouter les règles données ci-dessus dans un .htaccess, pour contrôler directement la date d’expiration des fichiers statiques.

Alain dit :

Très bel article, merci. Vivement la suite.

421stores dit :

J’aurais même tendance à dire que, sur un hébergement mutualisé, le cache navigateur est peut être plus important que sur du dédié.

Ce que je veux dire, c’est que les offres mutualisées sont généralement limitées par leur bande passante. Une fois le quotas dépassé, c’est fini, le site est coupé. Or, si le cache est activé sur le navigateur, les images et autre « gros fichiers » statiques ne seront pas téléchargés à chaque fois. Donc il y a beaucoup d’économies de bande passante. Donc le site n’est pas coupé (ou du moins, il est coupé moins vite).

Didier Sampaolo [w] dit :

Salut Aurélie,

Je ne sais pas exactement où tu veux en venir avec le Squid, j’attends de voir avec impatience. Pour les fichiers statiques (dont images) que tu as déjà envoyées sur un sous-domaine différent, tu peux utiliser des Nginx (ou un lighttpd, mais je préfère le premier) qui consomme beaucoup moins de RAM que ce bon vieil Apache. Enfin, j’attends de voir ta solution, on comparera si nécessaire…

En tout cas, bravo pour ces premiers articles et à bientôt pour la suite !

Laisser un commentaire

Balises HTML autorisées : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>