Les fichiers .htaccess vous permettent de modifier rapidement la configuration de votre serveur Apache et d’ajouter des règles et directives en fonction de différents paramètres pour des répertoires spécifiques.
C’est un peu la boîte à outils des SEO puisque c’est via ces fichiers que les règles de réecriture et les redirections 301 en tout genre sont configurées.
Mais ils peuvent devenir un obstacle à la vitesse de chargement, qui a son importance comme vous le savez, pour Google, ses crawlers, et les internautes de manière plus générale.
Fonctionnement des fichiers .htaccess
Il y a un élément important à bien retenir: les fichiers .htaccess ne sont que des extensions du fichier de configuration Apache, le fichier de configuration étant apache2.conf ou httpd.conf en général. Ils fournissent une méthode pour modifier la configuration du serveur pour les répertoires dans lesquels ils se trouvent.
Le problème est que les règles présentent dans les fichiers .htaccess sont parcourus pour chaque fichier, il y a donc un accès disque à ce fichier pour chaque requête sur le serveur.
Cela peut être d’autant plus pénalisant quand le fichier contient des vérifications sous la forme de RewriteCond (conditions pour lesquelles des règles de réecriture s’appliquent).
Pour chaque appel de fichier, Apache va vérifier la présence d’un fichier .htaccess dans tous les répertoires: Si j’appelle l’URL suivante http://www.yapasdequoi.com/blog/wp-content/themes/edeco/uploads/yapasdequoinommerunfichier.png, Apache va d’abord vérifier la présence ou non d’un fichier .htaccess dans les répertoires
– /uploads
– puis /edeco
– puis /themes
– puis /wp-content.
et dès qu’il en trouve, il applique les directives qu’il contient
Un schéma sera probablement plus clair:
Les directives de configuration d’un fichier .htaccess s’appliquent au répertoire dans lequel le fichier .htaccess se trouve, ainsi qu’à tous ses sous-répertoires (sachant qu’il peut y avoir des fichiers .htaccess dans les répertoires de niveau supérieur). Les directives sont appliquées selon l’ordre dans lequel elles sont rencontrées. (source Tutoriel du serveur HTTP Apache : fichiers .htaccess)
Ainsi, les directives d’un fichier .htaccess situé dans un répertoire particulier peuvent écraser les directives se trouvant dans des fichiers .htaccess situés à un niveau supérieur dans l’arborescence des répertoires. Et ces dernières peuvent elles-mêmes avoir écrasé des directives d’un fichier .htaccess situé à un niveau encore plus haut, ou dans le fichier de configuration du serveur principal.
Vous l’aurez compris, cela peut s’avérer assez gourmand en terme de ressources.
Comment ne plus les utiliser?
Les éléments ci-dessous ne concerne que ceux d’entre vous qui ont accès aux fichiers de configuration du serveur Web. Dans le cas d’un hébergement mutualisé, les fichiers .htaccess sont très utiles puisqu’il est bien souvent impossible d’accéder aux fichiers de configuration du serveur Apache, que ce soit hôtes virtuelles ou httpd.conf.
Si vous avez un serveur dédié, il est donc préférable de placer vos règles de réécriture et autres directives directement dans les fichiers de configuration: apache2.conf, httpd.conf ou hôtes virtuelles généralement placées dans le dossier /etc/apache2/sites-availables.
Les sections de configuration Apache
Les directives des fichiers de configuration peuvent s’appliquer au serveur dans son ensemble, ou seulement à des répertoires (Directory), fichiers (Files), hôtes (VirtualHost). Vous allez donc pouvoir placer vos règles de réécriture directement dans la section
Exemple:
<Directory "/var/www/monsite1"> AllowOverride None RewriteRule ^ancienne-url.html$ /nouvelle-url.html [R=301,L] </Directory>
La directive AllowOverride None indique à Apache l’absence de fichiers .htaccess pour le répertoire /var/www/monsite1 dans notre cas: cela évite au serveur d’aller chercher la présence ou non d’un fichier .htaccess dans l’arborescence de ce répertoire pour chaque requête, et améliore donc les performances du serveur.
Il ne faut pas oublier de relancer Apache: c’est aussi l’intérêt d’utiliser directement les fichiers de configurations Apache (apache2.conf, httpd.conf ou vhosts) car les directives qu’ils contiennent sont chargées directement au démarrage du serveur puis montées en mémoire.
Le gain de performances
Edit du 19/09/2012
Suite à une discussion avec @Gwaradenn qui trouvait qu’il manquait à cet article un comparatif sur les performances entre les deux solutions présentés ci-dessus (avec et sans htaccess), je me suis décidé de faire un petit benchmark afin de savoir dans quelle mesure ces fichiers pouvaient impacter la vitesse de chargement d’un site.
Mon fichier de configuration contient des directives relatives à l’utilisation du plugin WP-Supercache, les règles de réécriture de WordPress par défaut ainsi que quelques redirections 301 et un peu de cloaking.
J’ai utilisé l’outil Apache Benchmark afin de tester les performances de mon site (sur le port 8080 comme j’ai Varnish en frontal) en faisant un test de 30 secondes avec 5 requêtes concurrentes:
#ab -t 30 -c 5 http://www.yapasdequoi.com:8080/
Voici les résultats du test:
[table “7” not found /]Les chiffres parlent d’eux mêmes:
– Deux fois plus de requêtes/secondes ont pu être effectuées sans .htaccess pendant la durée du test à savoir 30 secondes (367.89 [#/sec] contre 708.04 [#/sec]) soit un total de 21242 requêtes (11038 requêtes seulement avec un htaccess…)
– Le temps moyen par requête est presque divisé par deux (7.062 [ms] contre 13.591 [ms])
En cas de pic de trafic, la présence de la directive AllowOverride None soulagera votre serveur et lui permettra non seulement de traiter les requêtes plus rapidement mais aussi de réduire les temps de réponses.
Merci encore à Karim qui m’a bien guidé pour ce test. A ce sujet, un petit lien vers sa nouvelle société 6IX IT – audit de données personnelles ne fait pas de mal!
Conclusion: Les fichiers .htaccess c’est bien, mais seulement quand on ne peut pas faire autrement!;-)
Je suis d’accord avec toi sur le fond.
Après, comme souvent, ce que tu gagnes en performances d’un côté, tu le perds en souplesse et en convivialité, et quand tu compares ce que tu gagnes en microsecondes pour la lecture de ton .htacccess par rapport au temps de chargement de ta page, tu te demandes quand même si cela vaut la peine quand tu interviens souvent dedans.
Mais chacun est juge.
Oui effectivement, ça peut s’avérer moins souple. Mais quand il s’agit d’un fichier .htaccess avec de nombreuses conditions et règles de redirection en tout genre, cela me parait plus pertinent de placer l’ensemble de ces éléments directement dans le fichier de configuration en désactivant AllowOverride: ça soulagera le serveur 🙂
L’amélioration du temps de chargement devient essentielle, et notamment avec l’utilisation croissante des smartphones. L’utilisation d’un design responsive est alors une bonne bonne solution pour un chargement front-office optimal. De plus en plus de thèmes WP Responsive voient d’ailleurs le jour 🙂
0.001 seconde de gagner sur 10 000 000 d’affichage c’est qd même du temps machine, y’a pas de petites économies…
🙂 c’est surtout au niveau des process Apache qui risquent d’être moins « CPUphage » que je donne ces infos. ça reste des accès disque supplémentaires.
J’avoue que la galère la plus fréquente pour ma part est liée aux multiples 301 faites lors d’une méga refonte de site. Et là, quand tu as 2000 URL à rediriger correctement ou plus, bonsoir la tronche du htaccess qui fait 5 bornes de long !
Le .htaccess c’est bien pour commencer, notamment parce qu’il existe beaucoup plus d’exemples et de tutos sur le net que pour les configurations des vhosts Apache. Le passage au vhost amène à pas mal de cheveux arrachés, il existe plusieurs petites différences dans la syntaxe.
Mais une fois la transition effectuée, fini le .htaccess et quelques microsecondes de gagnées ainsi qu’un serveur plus rapide dans son ensemble. En plus ça permet de se moquer de ses confrères ensuite.
@Sylvain
si tu fais une mega refonte d’un site et que tu connais les règles de réécriture précédente, rien ne t’interdit de t’en resservir pour faire les 301, cela évite d’en écrire 2000 😉
D’accord avec toi sur le principe bien entendu – surtout quand on se retrouve avec des fichiers long comme le bras lors de revamping. C’est souvent malheureusement notre seul acces qui nous est laisé a nous pauvres consultant en referencement par les equipes techniques … ou alors c’est souvent le chemin pris par ces meme equipes car – c’est plus facile, rapide et moins cher…
Passer le .htaccess dans le httpd.conf entraine des complications dans la mesure où un référenceur ne sait pas forcément administrer un serveur apache et donc ne serait pas où trouver le bon fichier.
Ce n’est pas très compliqué c’est sur mais çà nécessite un accès SSH donc ce n’est pas dédié à tous le monde.
Mais d’un autre coté, si on cherche à faire de l’optimisation à ce niveau c’est que le besoin est là et donc les moyens doivent être apportés.
En tout cas je ne savais pas qu’on pouvait optimiser à ce niveau la.
Et du coup par exemple, on pourrait mettre le code du .htaccess d’un wordpress dans le httpd.conf et normalement par la suite on aurais plus besoin de toucher au httpd.conf si ?
Oui, tu pourrais tout à fait mettre le contenu du .htaccess de WordPress dans le httpd.conf sans avoir à y retoucher par la suite! Par contre, comme certains plugins de « cache » par exemple tentent de modifier le fichier .htaccess (ex: Wp Supercache), cela implique de placer les directives de ces plugins directement dans la configuration du serveur également…
Bonsoir,
J’aurais une question au sujet des redirections 301 depuis le fichier htaccess dans le cas d’une refonte de site. Voit-on des effets négatifs importants en termes de référencement : baisse du nombre de visites? Je dois rediriger 600 adresses d’un seul tenant sur un e-commerce qui dispose d’un référencement de trois ans et je crains la perte du travail effectué.
Merci de vos réponses 🙂
Une baisse de trafic peut intervenir les premières semaines. L’essentiel étant de rediriger « page à page » les URL les mieux positionnées, et les autres vers les pages les plus proches (listing articles, page catégorie). Les erreurs 404 doivent être surveillées de très près après la migration. Quelques jours de 404 avec un plan de redirection non fonctionnel peut s’avérer très pénalisant. Mon meilleur conseil serait de lire quelques uns de ces articles sur le déroulement d’une bonne migration SEO: http://www.scoop.it/t/migration-seo
N’ayant que du mutualisé, cela ne me concerne pas encore. Mais c’est toujours bon d’apprendre ce genre d’astuces, bien que niveau configuration de serveur, j’ai encore beaucoup de choses à apprendre car je n’y connais rien.
Faut dire que je ne gère que pour le moment des petits sites, donc mes .htaccess ne sont pas bien long…
Tu l’as enfin fait, super. 😉
Tu as déjà fait un test grandeur nature pour observer le gain réel ?
Voilà qui est fait, article updaté!
Cela peut s’avérer interessant si le fichier contient de nombreuses règles de réécriture, il serait interessant de connaître le gain de temps de chargement entre les deux techniques.
Voilà une explication précise ! c’est certain que tout se complique aujourd’hui on veut gager du temps et des ressources. A propos de l’utilisation d’un design responsive, cité plus haut, si un jour tu peux nous expliquer un peu la mécanique de ce genre de système, cela peut-être très utile je crois.
Le problème c’est que tous les serveurs ne tournent pas sous apache, je pense notamment à certains gros site qui sont sous IIS par exemple. Quelqu’un aurait un retour pour ce type de config ?
Effectivement, il y a aussi des serveurs sous Microsoft IIS. Je ne connais pas très bien IIS mis à part le fait que la réécriture peut se fait via le module ISAPI Rewrite qui est compatible avec Apache également: http://www.isapirewrite.com/. Il faudrait creuser pour voir la manière dont s’implémente ce programme sur le serveur, mais je ne peux pas t’en dire plus, désolé!
Bonjour,
cet article est excellent, je ne savais pas et ça peut être très pratique.
Exemple, nous qui utilisons le Framework Php Symfony dans nos développements, il y a des règles .htaccess systematiques, alors une méthodes intéressante serait d’appliquer ces règles directement dans la config Apache comme vous l’avez proposé, puisque c’est toujours la même.
Nous sommes bien d’accords, ça accélère SEULEMENT si la directive AllowOverride est à None ?
Merci 🙂
Oui nous sommes bien d’accord, ça accélère SEULEMENT si la directive AllowOverride est à None (dans le cas contraire, chaque répertoire sera exploré pour chaque requête + accès disque au fichier .htaccess)
Au niveau des benmarks, ton disque est un dd à plateaux ou un SSD ?
Je pense qu’avec un SSD, l’écart doit être moindre.
Somme toute, sur le fond, si tu interviens peu dans ton .htaccess, ça peut le faire, par contre, si tu dois recommencer à chaque mise à jour de plugins, c’est pas top…
Salut Aymeric,
Avant toute chose, j’ai été très honoré de te rencontrer lors de l’ApéroSeo de mardi soir, ça fait toujours plaisir de voir les gens en réel. 😉
Benchmark très intéressant effectivement !
J’ai pour habitude de travailler sur du .htaccess puisque j’ai rarement eu l’opportunité d’avoir à gérer un hébergement dédié au sein de ma clientèle.
Je prend donc bonne note de ta préconisation quant à l’utilisation direct du httpd.conf !
Petite question au passage : Est-ce que cela vaut le coup selon toi de bloquer certains « referer » pour éviter le spam ? N’est-ce pas une perte de temps et de ressources le cas échéant ?
Merci Mister.
Hello Nicolas,
Ravi également de t’avoir rencontré IRL;) N’hésite pas à passer aux prochains #aperoSEO.
Concernant le blocage de certains referers, je ne pense pas que ça soit trop pénalisant. C’est surtout l’enchaînement de trop nombreuses règles et redirections qui risquent de faire chuter les performances: fichier .htaccess de plusieurs Ko…
Je confirme et j’appuie tes dire mais dans certains cas, on a souvent pas trop le choix que de passer par un fichier htaccess chez certains clients.
Reste que dans le cas d’un immense nombre de redirections 301, on peut utiliser un autre intermédiaire via PHP qui permet de ne pas surcharger le htaccess :).
Après, je pense aussi que certains htaccess mériterait d’être retravaillé. On peut y trouver parfois de vieilles règles obsolètes qui font gonfler la taille du fichier.
Je viens d’apprendre pas mal de choses la. Moi qui ne suit pas technique, je dois dire que tout était clair, je vais faire attention à ce que je mets dans mes htaccess désormais !
C’est technique, mais interressant. C’est étonant je ne pensais pas que le htaccess pouvait autant consomé en temps de réponse !
Surement gourmand en ressource, mais il reste indispensable pour le bon référencement !
Faire de bonnes règles reste essentiel donc 🙂
Alors là… En voyant le titre et l’intro de l’article je me suis dit que j’allais lancer un commentaire de contestation… et j’ai gardé ça en tête jusque le bench (je crois d’ailleurs qu’il a été ajouté après non ?). Et là j’ai pris une claque. Je ne pensais sincèrement pas qu’il pouvait y avoir une différence. Pour des sites à fortes charges et surtout qui utilisent plusieurs serveurs, c’est très intéressant !
Merci pour le partage.
Oui, le test a été réalisé dans un deuxième temps. C’est vrai que c’est plus significatif avec des chiffres pour appuyer la théorie;-)
Merci pour les conseils !
C’est l’occasion pour moi de dégraisser le mammouth car j’avoue que je n’y suis pas toujours allé avec le dos de la cuillère question htaccess (notamment lorsque j’ai décidé de supprimer les tags d’un de mes sites et que j’ai créé une redirection par tag pour ne pas perdre le jus)…
Il y a juste un passage que j’ai relu plusieurs fois, n’étant pas sûr de comprendre : « Les éléments ci-dessous ne concerne que ceux d’entre vous qui ont pas accès aux fichiers de configuration du serveur Web. »
C’est plutôt l’inverse : les éléments en question ne concernent que les gens qui ONT accès. Enfin bref, j’imagine que c’est juste une coquille !
Bonsoir Guillaume, oui tu avais bien compris! c’est corrigé, merci;)
Je n’avais même pas idée de la capacité des htaccess à réduire les performances du site. Super article très complet. J’ai du boulot qui m’attend demain ! Est-ce qu’une structure de dossier plus ‘lean’ peut être une alternative à la méthode proposée pour améliorer les performances ?
On apprend de bien belles choses sur ce blog.
Super article technique.
Je ne savais pas du tout que le site était crawler dans chaque dossier pour trouver un fichier .htaccess =_=
Comme certains ont pu le dire, le problème avec un site sous WordPress, ce sont les plugins. Certains modifient le fichier .htaccess de la racin et d’autres en ajoutent dans le dossier wp-content (ex : plugin de BackUp BDD).
Pour un site fait avec un framework comme SF2 ou ZF2, c’est vraiment intéréssant.
Par contre, je risque de poster une question con, mais au lieu de modifier le httpd.conf et de mettre AllowOverride None et toutes les directives de notre ancien fichier .htaccess, pourquoi ne pas mettre AllowOverride None dans le fichier .htaccess de la racine du projet ? Ca ne fonctionnera pas ?
non, ça ne fonctionne pas pour une raison très simple. Pour que ta directive dans le .htaccess soit lu par Apache, il faut que AllowOverride soit à All dans la conf principale, et ça n’ aucun intérêt puisque dans ce cas, tous les répertoires seront parcourus!