Un site qui tarde à charger perd des visiteurs avant même d’afficher la moindre image. Pour accélérer la chose, beaucoup se tournent vers un plugin de cache, avec ses réglages et ses conflits. Il existe pourtant une piste plus directe : le fichier .htaccess, modifiable avec un simple éditeur de texte. En quelques lignes bien placées, on active la compression et on fixe des durées de cache adaptées à chaque type de fichier, sans rien installer.
Activer la compression et le cache sans plugin
Comment expliquer que si peu de sites passent par là ? La réponse tient en partie à la peur de casser quelque chose. Un fichier .htaccess mal écrit peut bloquer un serveur, mais les réglages de compression et de cache comptent parmi les plus simples à poser. Il suffit de garder une copie de l’original et d’avancer ligne par ligne, sans se précipiter.
Franchement, je n’ai jamais compris pourquoi on installe une extension entière pour deux lignes de configuration. Un plugin de cache empile souvent des fonctionnalités dont on n’a pas besoin, et chaque mise à jour apporte son lot d’incompatibilités. La configuration manuelle reste lisible, facile à commenter, et surtout à désactiver d’un simple commentaire si un problème survient.
Avant de toucher au fichier, une sauvegarde s’impose. Le .htaccess se trouve généralement à la racine du site, et certains hébergeurs le masquent dans l’interface. On le récupère via FTP ou le gestionnaire de fichiers. Une fois la copie en lieu sûr, on peut tester chaque modification sans crainte, en sachant qu’un simple retour à la version précédente efface tout problème.
Activer Gzip ou Brotli dans le fichier
Sur un serveur Apache, le module qui s’occupe de la compression s’appelle mod_gzip. Pour l’activer depuis le fichier .htaccess, il suffit d’ajouter la ligne mod_gzip_on Yes. Une fois ce module en marche, la directive AddOutputFilterByType DEFLATE text/html text/plain applique la compression aux fichiers texte comme le HTML ou les fichiers plats. La documentation officielle du module mod_deflate, disponible à l’adresse http://httpd.apache.org/docs/2.2/mod/mod_deflate.html, détaille les options supplémentaires pour ajuster le comportement selon les besoins du site.
Certains hébergeurs activent Brotli à la place de Gzip, plus efficace sur les fichiers volumineux. Pour reprendre un tutoriel clair sur les réglages de cache et de compression, le site daonet.eu propose un exemple commenté pas à pas. On y voit comment articuler les deux mécanismes sans se perdre dans des options inutiles.
On aurait tort de compresser tous les fichiers. Les images JPEG ou PNG sont déjà dans un format compact, les compresser à nouveau consomme du temps pour un gain quasi nul. En revanche, les fichiers HTML, CSS, JavaScript et les polices profitent pleinement de la compression. La directive AddOutputFilterByType se limite donc aux types texte, comme l’indique l’exemple fourni par STRATO.
Des durées de cache qui correspondent aux fichiers
La directive ExpiresDefault fixe une durée de mise en cache par défaut pour tout ce qui n’est pas précisé ensuite. Un réglage courant, repris dans l’exemple de Creative Juiz, la place sur « access plus 7200 seconds », c’est-à-dire deux heures, ce qui évite aux pages modérément dynamiques d’être servies depuis le cache alors qu’elles ont changé entre-temps, sans bloquer une navigation fluide. Pour les images JPEG, la même source conseille une durée plus confortable : « access plus 1 week », soit une semaine. Ces valeurs se posent dans le fichier avec la directive ExpiresByType.
Les types de fichiers à distinguer
Tous les fichiers ne méritent pas la même durée. Ce qui change souvent doit rester frais, ce qui est stable peut rester plus longtemps. La liste qui suit reprend les cas les plus fréquents sur un site classique.
- Les pages HTML se régénèrent à chaque visite, une durée de deux heures évite de servir une version obsolète.
- Les images JPEG, une semaine.
- Pourquoi ne pas réserver plusieurs semaines aux feuilles de style ?
- Les polices de caractères changent rarement.
Certains préfèrent une durée uniforme pour simplifier la maintenance, mais c’est rarement payant. Un fichier HTML gardé en cache trop longtemps peut afficher un contenu qui n’existe plus. À l’inverse, une image qui ne bouge pas mérite une durée plus longue pour soulager le serveur.
Certains navigateurs préfèrent Brotli à Gzip, et le serveur peut négocier automatiquement le format si le module est présent. Dans un fichier .htaccess classique, la compression se limite souvent à Gzip, faute de Brotli activé côté serveur. Rien n’empêche d’ajouter ensuite la directive adaptée, mais autant commencer par ce qui fonctionne partout.
Vérifier que la compression est active
Une fois le fichier modifié, il faut s’assurer que le serveur envoie bien les réponses compressées. Dans les outils de développement du navigateur, l’onglet réseau affiche l’en-tête Content-Encoding: gzip quand tout fonctionne. Si cet en-tête manque, c’est souvent que le module n’est pas activé ou que la ligne n’a pas été prise en compte. Le plus simple, c’est de recharger la page. Ensuite, on compare la taille de la réponse avant et après activation.
Il existe aussi des services en ligne qui testent une URL et listent les optimisations manquantes. Ces outils ne remplacent pas une lecture attentive de la configuration, mais ils donnent un premier aperçu. Si le site est derrière un CDN, la compression peut être gérée à un autre niveau, et le .htaccess n’aura aucun effet. C’est un point à garder en tête avant de s’arracher les cheveux.
Le piège classique, c’est d’oublier de vider le cache du navigateur après modification. On pense que la compression ne marche pas, alors qu’il suffit de forcer un rechargement complet. Une autre erreur consiste à placer les directives dans le mauvais ordre, par exemple en déclarant un type de fichier après la règle par défaut. Dans ce cas, la valeur par défaut écrase la valeur spécifique, et on ne comprend pas pourquoi rien ne change.
Le gain se mesure à l’usage
Régler la compression et le cache à la main demande un peu de rigueur au départ, mais la récompense se voit dès les premiers tests. Le site charge plus vite, le serveur travaille moins, et aucune extension ne vient alourdir l’administration.
On garde le contrôle sur chaque durée, sur chaque type de fichier, et on comprend ce qui se passe en interne. Alors, combien de temps faudra-t-il avant que ce fichier .htaccess devienne le réflexe de chaque nouveau projet ?