Apache : les limites du .htaccess

Le .htaccess est pratique: un fichier par répertoire, pas de restart, le client mutualisé le gère tout seul. Sur un serveur dédié, il est un ralentisseur.

Chaque requête HTTP fait lire Apache tous les .htaccess du chemin, depuis la racine. Pour /var/www/site/blog/article/, Apache lit /var/www/.htaccess, /var/www/site/.htaccess, /var/www/site/blog/.htaccess et /var/www/site/blog/article/.htaccess. Quatre reads disque par requête avant de servir la page.

La solution: AllowOverride None dans httpd.conf et tout ce qui était dans les .htaccess migre dans le VirtualHost. Apache ne lit plus les .htaccess et les directives sont compilées au démarrage.

Le gain: mesuré sur un serveur WordPress avec 3 niveaux de .htaccess, la latence par requête passait de 14 ms à 8 ms. Le reste de la différence, c’est du cache opcode.

Les limites du .htaccess qui restent valables même en mutualisé: php_value et php_flag ne fonctionnent qu’avec mod_php (pas en FastCGI/FCGI), les RewriteRule sont plus lentes que les Alias et AllowOverride All expose des directives qui peuvent faire crasher Apache.

[edit: 2026] AllowOverride None est le défaut d’Apache 2.4+. Le .htaccess reste un outil mutualisé légitime, mais le débat a évolué: les serveurs modernes (nginx, Caddy) n’ont pas de concept de .htaccess du tout. La philosophie est passée de “tout dans le config” à “tout dans le code” (Docker, IaC). Le .htaccess survit parce que le mutualisé survit.