Guide SEO: optimiser les performances côté serveur

On va rentrer dans les techniques avancées d’optimisations d’un serveur web avec pour but de faire décoller la vitesse de vos pages et vos performances serveur.

On a déjà vu dans l’article précédent l’intérêt d’avoir un site rapide et quelques notions ( cache, compressions, entête d’expiration,..) qui seront ici développés . On va se focaliser sur les serveurs apache qui représentent 61% des serveurs web mondiaux, d’après w3techs . Ceci dit, la plupart des recommandations sont transposables sur IIs ou nginx en adaptant le code.

Modifier le .htaccess ou  pas

Le fichier .htaccess sert à modifier la configuration de votre serveur sans avoir à toucher au fichier de configuration principal.
Il se trouve à la racine de votre site, vous pouvez facilement y accéder via un logiciel ftp puis le modifier avec un éditeur de texte. Renseignez vous avec votre hébergeur le cas échéant.

Exemple de fichier .htaccess: 

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Le # sert à mettre la ligne en commentaire. Le reste c’est juste des règles de réécriture pour wordpress.

Le souci avec le fichier .htaccess

Le fichier .htaccess est lu à chaque requête par votre serveur. Si il comporte peu de lignes, les ressources serveur engagées sont minimes mais réelles malgré tout.

En revanche, si votre fichier .htaccess est trop chargé, les bénéfices que vous obtiendrez en le modifiant, seront partiellement perdus par le traitement demandé par le serveur.

Si vous êtes sur un serveur mutualisé vous n’avez pas le choix, c’est le seul moyen pour modifier votre configuration serveur. Mais rassurez vous, les astuces qui vont suivre, comportent que peu de lignes de code et vous obtiendrez des bénéfices sur la rapidité de vos pages. Attention tout de même à optimiser vos règles de redirection.

Si vous avez un serveur dédié, que je recommande vivement, le mieux est de modifier directement la configuration serveur sur le fichier de configuration de votre virtual host (Vhost). En effet, lorsque votre serveur web est lancé, il charge ses fichiers de configuration en mémoire et toutes les règles sont appliquées directement. C’est plus rapide de passer par le vhost que de passer par l’appel du fichier .htaccess.

Modifier votre Vhost

La configuration de votre serveur se situe normalement dans un fichier qui ressemble à ca :
etc/apache2/sites-available/votresite.conf

Et Il commence par la ligne : <VirtualHost xxx.xxx.xxx.xxx:80>

Si vous avez un serveur dédié, que vous avez des lignes dans votre fichier .htaccess, il est très simple de transposer ces lignes vers le virtual host.

Exemple avec les règles de base de réécriture sur wordpress

<Directory /home/votresite/public_html>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</Directory>

Dans les deux cas, je vais donner les modifications à effectuer pour le .htacess et le vhost.

Activer la Compression

La compression sert à réduire le temps de réponses des requêtes http. J’en ai déjà parlé dans l’article précédent, mais il faut éviter les fichiers déjà compressés comme les .jpg ou les .pdf. On active la compression uniquement pour certains types de fichiers.

Fichier .htaccess

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE application/font-woff text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript
</IfModule>

Fichier vhost

<Directory /home/votresite/public_html>
AddOutputFilterByType DEFLATE application/font-woff text/html text/plain text/xml text/css text/javascript application/javascript
</Directory>

Je répète le « Directory » simplement pour indiquer que la règle doit se trouver dans le répertoire de votre site. Votre fichier fait déja mention de cette ligne « directory », il suffit donc de placer le reste du code à l’intérieur.

Le chemin vers votre site est à modifier également en fonction de l’emplacement physique de votre site sur votre serveur.

Personnaliser le cache avec les entêtes d’expiration

Les entêtes d’expiration permettent de personnaliser le comportement du cache navigateur de vos visiteurs en fonction des éléments présents sur la page. Vous précisez ainsi que tel élément (JS, css, jpg,etc…) n’a pas besoin d’être retransmis car il est suffisamment récent. C’est surtout utile pour les ressources statiques et/ou qui changent peu souvent.

Sur Apache, avant de rentrer ces quelques lignes ci-dessous, il faut que le module mod_expires soit activé.

Sur IIs7, il faut aller sur IIS manager et pour plus de détails, c’est par ici

Fichier .htaccess

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType text/html "access plus 2 days"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 days"
</IfModule>

Fichier Vhost

<Directory /home/votresite/public_html>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType text/html "access plus 2 days"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 days"
</Directory>

Cache-control

De la même manière, la cache-control (mod_headers.c) permet de contrôler le temps que doit rester un élément en cache. Mais ça vient en doublon des délais d’expirations qu’on vient de voir. Vous pouvez utilisez une des deux solutions mais Google lui-même recommande d’utiliser les entêtes d’expiration qui sont plus largement accepté par les navigateurs.

Last-modified et code 304

C’est une entête envoyée via des requêtes GET conditionnelles entre le serveur web du site et le navigateur. C’est d’ailleurs supporté par n’importe quel navigateur y compris les crawlers Google (Googlebot) et Bing (Bingbot). Du coup, cette entête a un intérêt non seulement pour l’utilisateur mais aussi directement pour les moteurs de recherche et notamment dans le cadre de l’optimisation du crawl de googlebot, point très important en SEO.

Pour expliquer rapidement son fonctionnement:

• Lorsque un document est demandé une première fois par un navigateur (ou un crawler, c’est presque pareil finalement), le serveur web renvoie une entête « last-modified » avec la date de la dernière modification.
• Lorsque un document est demandé une deuxième fois, Googlebot par exemple, ajoute à sa requête une entête « if-modified-since » avec la dernière date qu’il connait gràce au « last-modified ».
• Si le document n’a pas changé depuis le « if-modifed-since » , le serveur envoie un code 304 « not modifed » sans le document. Google va donc utiliser la dernière version qu’il connait. Et surtout, cette requête GET conditionnelle est plus rapide à charger par googlebot que la réponse complète.
• Si le document a changé, c’est à dire que le nouveau « last-modified » est supérieur au « if-modified-since », alors le serveur répond normalement avec un code 200 et le document qui va avec.

Pour que cette entête soit active, sur Apache, il faut que le module mod_cache soit activé et sur IIs reportez vous à cette page.

Pour les ressources dynamiques ou même statiques d’ailleurs, on peux aussi renvoyer un code 304, depuis le code de la page. Ça peux être utile pour des pages qui changent rarement, qui génèrent peu de visites et sur lesquels google passent beaucoup de temps de crawl « inutilement » (ratio crawl/visites faible). On optimise ainsi le crawl de googlebot. (une petite astuce SEO, c’est cadeau)

Désactivez le Etag

Le Etag est un identifiant unique attribué à une élément et qui est modifié à chaque changement de cet élément. Mais Il a la même fonction que last-modified et vient donc en doublon.

Lorsqu’un navigateur charge une deuxième fois une même page:

• Si le Etag est identique, le serveur renvoie un code 304 qui signifie que l’élément n’a pas changé et dans ce cas, le navigateur va charger l’élément en cache.
• Si le Etag est différent, dans ce cas le serveur renvoie un code 200 et le navigateur va charger la dernière version provenant du serveur.

Les problèmes avec le Etag , c’est que bien souvent, en fonction de votre configuration serveur, il est regénéré anormalement même si le fichier n’a pas changé. Du coup, ça réduit fortement la mise en cache des navigateurs.

Le plus sûr c’est de le désactiver:

Fichier .htaccess

Header unset ETag
FileETag None

Fichier Vhost

<Directory /home/votresite/public_html>
FileETag none
<Directory>

Augmenter la mémoire de PHP

Il est possible de changer la mémoire allouée à PHP  pour un domaine donné en modifiant le fichier :

/home/votredomaine/etc/php5/php.ini

Par défaut il est de 128 Mo, il suffit de rechercher memory_limit et de pousser la valeur à 512M par exemple:

; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit = 512M

Installer et configurer Memcached

Memcached est un cache serveur qui permet de garder en mémoire vive des portions de données, permettre un accès plus rapide et soulager les accès base de données. Il peux également être utilisé pour une meilleure efficacité, en complément de W3 total cache pour WordPress et de ModPageSpeed. On traitera de ces deux programmes dans les prochains articles de la série.

1/ Installer Memcached (serveur dédié)

– Ouvrez un terminal de commande:

sudo apt-get install memcached php5-memcached libmemcached-tools
sudo apt-get install php5-dev php-pear make

C’est possible que des paquets soient déjà installés mais ce n’est pas grave, le système vous dira simplement que les paquets concernés sont déjà installés.

2/ Configurer Memcached

– Ouvrez le fichier /etc/php5/conf.d/memcache.ini
– Vérifier que ces 2 lignes sont bien présentes:

extension=memcache.so
memcache.hash_strategy="consistent"

3/ Augmentez la mémoire de memcached

Par défaut elle est de 64 MB, et vous pouvez l’augmenter jusqu’à environ 1/4 de votre RAM total.

– Ouvrez /etc/memcached.conf
– Cherchez la valeur: -m 64
– Changez la par exemple en: -m 1024

4/ Redémarrez Memcached

Restart memcached  service memcached restart

5/ Tester si ca marche

sudo netstat -tap | grep memcache

Vous deviez voir quelque-chose qui ressemble à ça:

tcp 0 0 localhost:11211 *:* LISTEN 25266/memcach

TTFB (Time To First Byte)

Si après tout ça, votre site ne se charge toujours pas assez vite, pensez à changer d’hébergeur et/ou à prendre un bon serveur dédié. Car au delà de ces optimisations, un point qui joue dans la vitesse des pages c’est le TTFB (Time To First Byte). Le TTFB, c’est le temps de latence entre la demande d’un navigateur vers un site et le début de réponse du serveur de ce site web. Et ce temps dépend de 3 facteurs :

1. Le temps que met que la requête à parcourir le réseau pour aller jusqu’au serveur web
2. Le temps que met le serveur à traiter la requête et à produire une réponse au navigateur
3. Puis, le temps mis par la réponse à se propager à travers le web pour atteindre le navigateur (ou un crawler)

Comme on l’a vu dans l’article précédent, le CDN va agir sur deux de ces points (1 et 3), il va réduire la distance et le nombre de noeuds entre le serveur web et le navigateur, surtout si l’audience du site est internationale.

Il reste donc le point 2. , L’ensemble des recommandations qui sont traitées dans cette série de guides permettent justement de produire des réponses plus rapides et d’optimiser le TTFB : la diminution des requêtes, les systèmes de cache serveur comme memcached, on peux aussi optimiser l’architecture des bases de données, produire des pages moins complexes à générer, etc….

Mais il arrive un moment où le principal facteur limitant c’est le temps processeur et/ou l’infrastructure matériel du serveur. Dans ce cas, la solution c’est de changer de machine et/ou d’opter pour un système de répartition des charges (load / cloud balancing)

Voila, vous devriez avoir un site qui pulse 😉

Le prochain article de la série « performances serveur » devrait surement vous intéresser si vous êtes sous wordpress puisqu’il s’agira d’ Optimiser et sécuriser WordPress .
En attendant n’hésitez pas à commenter cet article et/ou à vous abonner à la newsletter des guides Creapulse.

A propos de Serge Esteves

Consultant SEO / Webmarketing : Techniques avancées en référencement combinées aux leviers du marketing entrant (UX, CRO, analytics, content marketing, ereputation, ..).