RootsLabs

More than a tool ! GitHub Google+ LinkedIn RSS

Optimiser son site WordPress chez OVH

Progi1984 - Commentaires (18)

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.

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.

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.

Documentation : Wikipedia

Utiliser un domaine libre de cookie (a.k.a. cookie-free domain)

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

1. Olivier, le 11 octobre 2013 à 18:16

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 🙂

2. Progi1984, le 12 octobre 2013 à 09:42

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

3. RootsLabs » Optimiser ses fichiers statiques, le 18 novembre 2013 à 10:30

[…] un site web, de nombreux points sont à optimiser : le code PHP, la partie serveur et les fichiers statiques. Ces fichiers sont ceux qui sont rarement modifiés et sont mis en cache […]

4. Simon @DigiTold, le 24 janvier 2014 à 09:54

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/
# 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 –

5. Progi1984, le 9 février 2014 à 15:00

@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

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.

6. efiga, le 15 juillet 2014 à 20:10

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

7. Progi1984, le 16 juillet 2014 à 10:28

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

8. efiga, le 17 juillet 2014 à 12:55

@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

9. Progi1984, le 26 juillet 2014 à 12:38

@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 ?

10. darknote, le 4 novembre 2014 à 16:21

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

11. Progi1984, le 7 novembre 2014 à 10:36

@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 : rootslabs.net a pour enfants http://www.rootslabs.net et statics.rootslabs.net mais http://www.rootslabs.net n’a pas de lien avec statics.rootslabs.net).
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.

12. mesmes, le 10 février 2015 à 15:24

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

13. elo, le 18 février 2015 à 10:13

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.

14. elo, le 18 février 2015 à 10:14

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.

15. RootsLabs » Optimiser son site WordPress toujours plus, le 14 septembre 2015 à 10:00

[…] article précédent sur l’optimisation WordPress m’avait laissé un gout de défi dans la bouche avec un “Page Speed Grade” à […]

16. Ggive, le 27 janvier 2016 à 13:33

Bonjour,

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

D’avance merci

17. Progi1984, le 28 janvier 2016 à 13:53

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

18. Darknote, le 28 mai 2016 à 17:47

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.

Ajouter un commentaire

Commentaire :