Optimiser son site WordPress chez OVH

22 juillet 2013 - 683 mots - wordpress

Suite à une discussion avec des visiteurs de mon site, mon site semblait lent à l’affichage. Je me suis donc décidé à passer à une étape d’optimisation.

Pour cela, j’ai utilisé l’outil GTMetrix : gtmetrix.com permettant de calculer les performances d’un site en fonction des recommandations de Google PageSpeed et Yahoo YSlow.

Avant l’optimisation

Avant de mettre en place toute optimisation, j’ai fait un rapport de performance sur GTMetrix, dont voici la copie d’écran :

optimisation_avant

Pendant l’optimisation

Mise en place du cache

En première étape, nous allons mettre en place du cache au niveau de WordPress. Pour cela, j’utilise comme plugin WP Super Cache.
Après une installation, puis une mise en place de la plupart des paramètres recommandés par WP Super Cache, le site semble déjà plus rapide.
Après vérification, le temps de chargement de la page passe de 7.32 sec. à 2.95 sec.

Activer la compression GZip

Chez OVH, l’astuce passe par une modification du .htaccess du site WordPress.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
##### GZIP Compression
# Commenter la ligne ci-dessous si plantage
# php_flag zlib.output_compression on
# Filtre
SetOutputFilter DEFLATE
# Vieux navigateurs
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0678 no-gzip
# No IE
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Images : pas de compression
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
# Proxy
Header append Vary User-Agent env=!dont-vary

Pour tester le support GZip de votre site, vous pouvez utiliser ce lien : http://www.gidnetwork.com/tools/gzip-test.php.

Désactiver les ETags

Les balises ETag permettent dans les requêtes HTTP de vérifier si le document a été modifié, alors que nous gérons déjà un cache via WP Super Cache. Supprimer ces ETags supprimera de la bande passante. Nous modifions de nouveau le fichier .htaccess du site WordPress.

1
2
3
##### Desactivation des ETags
Header unset ETag
FileETag none

Ajouter des en-têtes Expires

Le header Expire indique à votre visiteur que certains types de fichiers sont mis en cache, sans avoir à vérifier une nouvelle version auprès du serveur (donc requêtes en moins).
Nous modifions de nouveau le fichier .htaccess du site WordPress.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
##### Headers Expires
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 2 days"
  ExpiresByType image/jpg "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/gif "access plus 1 year"
  AddType image/x-icon .ico
  ExpiresByType image/ico "access plus 1 year"
  ExpiresByType image/icon "access plus 1 year"
  ExpiresByType image/x-icon "access plus 1 year"
  ExpiresByType text/css "access plus 1 year"

  ExpiresByType text/html "access plus 2 days"
  ExpiresByType application/xhtml+xml "access plus 2 days"

  ExpiresByType text/javascript "access plus 1 month"
  ExpiresByType application/javascript A2592000
  ExpiresByType application/x-javascript "access plus 1 month"
</IfModule>

Documentation : Wikipedia

Les composants statiques telles que les fichiers CSS, JavaScript et les images sont demandés au serveur avec des requêtes contenant les cookies. Interroger un sous-domaine ou un autre serveur supprimera ses cookies des requêtes et allégera ainsi l’échange avec les serveurs.

Dans le cas où votre nom de domaine est du style rootslabs.net, créer un sous domaine statics.rootlabs.net ne solutionnera pas car il héritera des cookies du domaine parent. La solution reste dans ce cas d’utiliser un autre nom de domaine, si vous en avez un à votre disposition.
Par contre, si votre nom de domaine principal est du style www.rootslabs.net, alors le sous domaine statics.rootlabs.net sera parfait.

Après l’optimisation

Après toutes les optimisations que l’on vient de voir, on a réussi à passer le poids de la page de 328Kb à 187Kb (soit une amélioration de 48%), et le temps de chargement de 7.32s à 4.04s (soit une amélioration de 45%).

optimisation_apres

Conclusion

Optimiser son site peut paraître du temps perdu. Mais ce « temps perdu » optimisera vos sites pour toutes vos visiteurs dont ceux sur mobile qui apprécient de se promener sur une site rapide (à charger et à afficher). L’optimisation permet d’améliorer le retour visiteur à court et moyen terme.

[2014-02-09 14:00] Ajout d’un lien pour tester le support de GZip.

Commentaires

Olivier
Olivier

Bonjour,
Merci pour cet article.

Concernant un site WordPress sous OVH, quand tu parles de modifier le .htaccess,
Est-ce que cela concerne le htaccess directement à la racine du serveur, ou bien celui dans le répertoire WordPress ?

Merci 🙂

11 octobre 2013 à 18:16


Progi1984
Progi1984

Bonjour, Merci du commentaire.

Pour le fichier .htaccess, il doit être mis à la racine du site.
Ainsi, si votre site domain.tld est placé dans le dossier « www » et que votre blog (domain.tld/blog) est dans « www/blog », le htaccess doit être mis dans le dossier « www ».

Bonne journée

12 octobre 2013 à 09:42


Simon @DigiTold
Simon @DigiTold

Bonjour Progi1984,

De mon côté, les codes pour compression GZip, les Etags et les en-têtes font planter OVH et mettent mon site en erreur 500.

A l’adresse suivante, j’ai trouvé un code qui fonctionne pour moi : http://blog.adminrezo.fr/2012/05/accelerer-un-site-apache-ovh-perso-par-compression-gzip/

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# Compression Deflate  
SetOutputFilter DEFLATE

# Navigateurs non compatibles  
BrowserMatch ^Mozilla/4 gzip-only-text/html  
BrowserMatch ^Mozilla/4.0[678] no-gzip  
BrowserMatch bMSIE !no-gzip !gzip-only-text/html

# Fichiers à ne pas compresser (car déjà compressés)  
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip dont-vary  
SetEnvIfNoCase Request_URI .(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary  
SetEnvIfNoCase Request_URI .(?:pdf|avi|mov|mp3|mp4|rm)$ no-gzip dont-vary

# Proxies  
Header append Vary User-Agent env=!dont-vary

Aussi, un site pour vérifier si votre compression GZip est bien active : http://www.gidnetwork.com/tools/gzip-test.php

Enfin, utiliser un CDN gratuit tel que CloudFare peut aussi améliorer les perfs. Et le plugin JetPack permet également de mettre ses images sur un CDN (Photon).

Selah –

24 janvier 2014 à 09:54


Progi1984
Progi1984

@Simon @DigiTold :
Merci pour votre retour. Personnellement, mon .htaccess fonctionne sur un hébergement mutualisé de type Perso.

Seuls actuellement cette partie de code diffère

1
2
SetEnvIfNoCase Request_URI .(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI .(?:pdf|avi|mov|mp3|mp4|rm)$ no-gzip dont-vary

Peut-être était ce le module « mod_expires.c » qui n’est pas activé pour Apache ?

Merci pour le lien. Je l’ajoute à l’article.

J’acquiesce pour le CDN. Je viens de voir que le CDN de OVH était fourni, je ferais ptet un article pour la mise en place.

9 février 2014 à 15:00


efiga
efiga

bonjour
j’aime bien ton article .
mais je veux pas utiliser WP Super Cache, comment je peux activer etags ? pour compenser WP Super Cache.

15 juillet 2014 à 20:10


Progi1984
Progi1984

@efiga : Le but est plutôt de désactiver les Etags afin d’économiser de la bande passante.

16 juillet 2014 à 10:28


efiga
efiga

@progi1984 j’ai eu un problèm j’ajoute des articles ,mais n’aparaissent pas dans mon navigateur a cause du cache ,beh j’ai suprimé la mise en chache du fichier text/html , mais le mm problèm
le bande passante est illimité,
une autre question j’utilise le dns anycast de ovh , est ce que cloudflare est mieux que le mien

17 juillet 2014 à 12:55


Progi1984
Progi1984

@efiga : Je suis désolé, mais tu vas arriver au bout de mes compétences sur WP SuperCache.

As tu activé le timeout du cache ? Pour la mise, as tu utilisé les options recommandées ? As tu essayé sans CDN ?

26 juillet 2014 à 12:38


darknote
darknote

Bonjour,
il y a mieux que le plugin WP Super Cache, le plugin WP Fastest Cache.
Déjà WordPress soit être installé par soi,
il ne faut SURTOUT PAS prendre le MODULE d’OVH !!!!

Je n’ai pas compris l’histoire du cookie, que doit on ? Ajouter un code dans .htaccess ?
Et que notre site est à la racine, pas d’autre nom de domaine, on doit créer un sous domaine ?
Merci

4 novembre 2014 à 16:21


Progi1984
Progi1984

@darknote : Je confirme, je préfère installer que d’utiliser les modules installables d’OVH.

Un cookie est rattaché à un nom de domaine (et à ses enfants : lefevre.dev a pour enfants http://www.lefevre.dev et statics.lefevre.dev mais http://www.lefevre.dev n’a pas de lien avec statics.lefevre.dev).
Donc si ton domaine est http://www.xxx.xxx alors tu peux mettre tes statics sur statics.xxx.xxx mais si ton domaine est xxx.xxx, alors tu ne pourras pas utiliser les sous-domaines vu qu’ils sont liés par le même cookie : il faudra alors utiliser un CDN ou un autre domaine.

7 novembre 2014 à 10:36


mesmes
mesmes

Bonjour
merci pour cet article, j’avais peur que ça me retourne une erreur 500 comme Mr Simon, mais heureusement il m’a rien retourné + mon site a grimpé de class D jusqu’à class B selon gtmetrix.com

au plaisir de vous lire
mesmes

10 février 2015 à 15:24


elo
elo

Au niveau du cache, il faut au contraire les activer !
Je n’utilise pas WordPress (je programme mon site moi-même) et j’ai fait des tests plus poussés : les Etags utilisent le cache du navigateur sans appeler le site. Au niveau performance, il n’y a pas mieux puisqu’aucun appel serveur.

18 février 2015 à 10:13


elo
elo

Au niveau du cache, il faut au contraire activer les ETAGS !
Je n’utilise pas WordPress (je programme mon site moi-même) et j’ai fait des tests plus poussés : les Etags utilisent le cache du navigateur sans appeler le site. Au niveau performance, il n’y a pas mieux puisqu’aucun appel serveur.

18 février 2015 à 10:14


Ggive
Ggive

Bonjour,

Cet article est-il toujours compatible avec wp super cache et OVH aujourd’hui en 2016 ?

D’avance merci

27 janvier 2016 à 13:33


Progi1984
Progi1984

@Ggive : Je confirme car je l’utilise toujours et je suis toujours chez OVH.

28 janvier 2016 à 13:53


Darknote
Darknote

Bonjour,
Pardon mais pas d’accord avec Elo, il faut désactiver les Etags

– ETags (Entity Tags) sont un mécanisme que les serveurs Web et les navigateurs utilisent pour déterminer si le composant dans le cache du navigateur correspond au serveur d’origine. Etags sont ajoutés pour fournir un mécanisme de validation des entités qui est plus flexible que la date de la dernière modification. Un ETag est une chaîne qui identifie de manière unique une version spécifique d’un composant. Les limites de ce format est que la chaîne est cité. Le serveur d’origine spécifie ETag du composant en utilisant l’en-tête de réponse ETag.

28 mai 2016 à 17:47


Laisser un commentaire

Merci. Votre message a bien été enregistré.