Htaccess : performances et temps de chargement

Publié le 17 juin 2010 Développement WordPress

Le htaccess est un fichier de configuration de votre serveur (pour les serveur Apache), et celui-ci  peut vous rendre énormément service pour les performances de votre site, sur l’expérience utilisateur et sur le référencement naturel. Mais c’est un peu le flou sur la manière de le configurer.

Si vous rencontrez des soucis avec ce code et que vous souhaitez que nos équipes se charge de l’adapter et de l’installer, faites appel à nos services de développement. Voici donc un guide pour coder votre fichier htaccess dans une optique de temps de chargement (expires headers, etags, etc.), ainsi qu’un modèle de ce dernier :

Htacces, performances et temps de chargement
Htacces, performances et temps de chargement

Avant propos

Testez, testez et testez !

Chaque code donné ici permet d’optimiser le fichier htaccess pour accélérer votre site, le sécuriser et réduire la bande passante utilisée.

Mais en fonction de la configuration de votre serveur, les codes peuvent ne pas fonctionner : vous devez absolument tester et adapter chaque code en fonction de vos besoins !

Quelques définitions

Pour mieux comprendre cet article, voici quelques explications. N’hésitez pas à me contredire en commentaire si je me trompe.

  • Htaccess : c’est un fichier de configuration pour un serveur web apache. Si vous ne savez pas sur quel type de serveur vous êtes, demandez à votre hébergeur. La configuration qui est inscrite dedans s’applique au répertoire dans lequel il est placé, ainsi que dans tous ses sous-répertoires.
  • Compression Gzip : c’est un format de compression utilisé pour réduire la taille de vos fichiers, et ainsi accélérer votre site.
  • Serveur Apache : c’est le format de serveur http le plus répandu au monde, et que l’on retrouve dans la plupart des offres d’hébergement pros et grand public.
  • Système de cache : le cache d’un site internet ou d’un programme permet d’accéder à des données ou des pages déjà prêtes, sans avoir à les régénérer ou à les recalculer. Si vos pages sont en cache sur votre serveur, les visiteurs y accéderont beaucoup plus vite.
  • Entêtes et requêtes : il s’agit d’informations transmises entre votre ordinateur et le serveur. Ces informations servent aux deux en indiquant différentes informations : emplacement des fichiers, date de mise à jour, configuration, …
  • CHMOD : un chmod permet de modifier les droits d’un fichier en lecture, écriture et exécution, sous la forme de 3 chiffres (exemple : 777 ou 644). Chaque chiffre donne des droits différents en fonction de l’utilisateur : propriétaire, groupe et publique. C’est un point à étudier en détail pour sécuriser un site.

Compression

Compression Gzip via Deflate

Premier point à faire, activez la compression Gzip des fichiers en sortie de votre serveur.

Cela va accélérer le temps de chargement, et réduire la bande passante utilisée. Attention cependant, car cette compression n’est pas supportée par tous les navigateurs (notamment Netscape) et ne fonctionnera que sur des serveurs apaches 2.x.  Testez donc bien votre site sur plusieurs navigateurs après la mise en place de ce code.

# MOD_DEFLATE COMPRESSION
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/x-javascript application/x-httpd-php
#Pour les navigateurs incompatibles
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
#ne pas mettre en cache si ces fichiers le sont déjà
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
#les proxies doivent donner le bon contenu
Header append Vary User-Agent env=!dont-vary

Compression Gzip via Mod_Gzip

Le code suivant remplace le précédent  mais fonctionne les serveurs apache 1.x qui ne peuvent gérer le mod_deflate (enfin, d’après ce que j’ai compris)…

RewriteEngine on
#Check to see if browser can accept gzip files. If so and we have it - serve it!
ReWriteCond %{HTTP:accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Safari
#make sure there's no trailing .gz on the url
ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$
#check to see if a .gz version of the file exists.
RewriteCond %{REQUEST_FILENAME}.gz -f
#All conditions met so add .gz to URL filename (invisibly)
RewriteRule ^(.+) $1.gz [QSA,L]
<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_keep_workfiles No
mod_gzip_can_negotiate Yes
mod_gzip_add_header_count Yes
mod_gzip_send_vary Yes
mod_gzip_command_version '/mod_gzip_status'
mod_gzip_min_http 1000
mod_gzip_minimum_file_size 300
mod_gzip_maximum_file_size 512000
mod_gzip_maximum_inmem_size 60000
mod_gzip_handle_methods GET POST
mod_gzip_temp_dir /tmp
mod_gzip_item_include file \.html$
mod_gzip_item_include file \.php$
mod_gzip_item_include file \.pl$
mod_gzip_item_include file \.rb$
mod_gzip_item_include file \.py$
mod_gzip_item_include file \.cgi$
mod_gzip_item_include file \.css$
mod_gzip_item_include file \.js$
mod_gzip_item_include mime ^application/javascript$
mod_gzip_item_include mime ^application/x-javascript$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^httpd/unix-directory$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include handler ^server-status$
mod_gzip_item_include handler ^server-info$
mod_gzip_item_include handler ^application/x-httpd-php
mod_gzip_item_exclude mime ^image/.*
</IfModule>

Testez la compression de votre site

En plus des outils connus de Firefox comme Yslow et Firebug, voici deux petits sites pour tester votre compression :

Cache et headers

Expire headers

Le Expire header est un atout de taille. Il permet d’indiquer que certains types de fichiers peuvent rester en cache dans le navigateur du visiteur pendant une durée déterminée, sans que le navigateur n’ait besoin de faire des requêtes pour vérifier la validité du cache. Vous allez donc diminuer drastiquement le nombre de requêtes de votre site.

# BEGIN Expire headers
<IfModule mod_expires.c>
 ExpiresActive On
 ExpiresDefault "access plus 7200 seconds"
 ExpiresByType image/jpg "access plus 2592000 seconds"
 ExpiresByType image/jpeg "access plus 2592000 seconds"
 ExpiresByType image/png "access plus 2592000 seconds"
 ExpiresByType image/gif "access plus 2592000 seconds"
 AddType image/x-icon .ico
 ExpiresByType image/ico "access plus 2592000 seconds"
 ExpiresByType image/icon "access plus 2592000 seconds"
 ExpiresByType image/x-icon "access plus 2592000 seconds"
 ExpiresByType text/css "access plus 2592000 seconds"
 ExpiresByType text/javascript "access plus 2592000 seconds"
 ExpiresByType text/html "access plus 7200 seconds"
 ExpiresByType application/xhtml+xml "access plus 7200 seconds"
 ExpiresByType application/javascript A2592000
 ExpiresByType application/x-javascript "access plus 2592000 seconds"
 ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
</IfModule>
# END Expire headers

Inutile de vous acharner si vos outils indiquent que les expire headers ne sont pas appliqués sur tous les fichiers. Si comme moi vous utilisez le système publicitaire d’Adsense, vous ne pourrez rien y faire…

Cache-control

Le cache control est un complément de l’expire headers, en fonction du serveur que vous avez ou du navigateur utilisé par vos visiteurs. Là aussi, on va déterminer une durée de cache par type de fichier :

# BEGIN Cache-Control Headers
<IfModule mod_headers.c>
 <FilesMatch "\.(ico|jpe?g|png|gif|swf|css|gz)$">
 Header set Cache-Control "max-age=2592000, public"
 </FilesMatch>
 <FilesMatch "\.(js)$">
 Header set Cache-Control "max-age=2592000, private"
 </FilesMatch>
<filesMatch "\.(html|htm)$">
Header set Cache-Control "max-age=7200, public"
</filesMatch>
# Disable caching for scripts and other dynamic files
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
</IfModule>
# END Cache-Control Headers

Les fichiers dynamiques ne sont pas, ou très peu mis en cache (html, php, cgi, …), tandis que le reste est mis en cache pour une longue durée.

La différence entre une cache-control public et private réside dans les proxys. Le paramètre public indique que la mise en cache est pour tout le monde, tandis que private indique que les proxys n’ont pas l’autorisation de mettre en cache.

Le Etag

Ce code permet de désactiver les etags, et donc de réduire encore le nombre de requêtes et votre bande passante utilisée.

Un etag permet de différencier deux versions d’un document ou d’un fichier. Cet Etag est transmis entre votre ordinateur et le serveur lors des requêtes HTTP. Son but est de vérifier si le document a été modifié. Si le fichier est identique, le navigateur utilisera son cache. Mais lors de chaque requête, les informations etags vont être transmises inutilement, surtout si vous avez déjà configuré comme indiqué le reste de votre fichier htaccess.

De plus, sur les serveurs apache, l’identifiant est basé sur la date de dernière modification. Mais si le site est géré par un cluster de plusieurs serveurs, on aura parfois un identifiant différent alors que le fichier n’a jamais été modifié, le tout à cause du etag… (voir sources plus bas)

# KILL THEM ETAGS
Header unset ETag
FileETag none

Et voilà, vous êtes débarrassé une bonne fois pour toute de ces fameux etags.

Sécurité

Protection du fichier htAccess

Nous allons maintenant sécuriser l’accès au fichier htaccess via ce code:

# protect the htaccess file
<files .htaccess>
order allow,deny
deny from all
</files>

Profitez-en pour faire un CHMOD 644 de votre fichier htaccess pour le sécuriser au maximum (vous donnerez ainsi les droits en écriture uniquement à l’admin serveur).

Protection de la lecture des répertoires

Pour éviter que vos visiteurs ne puisse consulter les répertoires qui ne contiennent pas de fichier index, utilisez ce code :

# protection de la lecture des répertoires
 Options -Indexes

Le code Htaccess complet

Et donc le rendu final est :

# MOD_DEFLATE COMPRESSION
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/x-javascript application/x-httpd-php
#Pour les navigateurs incompatibles
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
#ne pas mettre en cache si ces fichiers le sont déjà
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
#les proxies doivent donner le bon contenu
Header append Vary User-Agent env=!dont-vary

# BEGIN Expire headers
<IfModule mod_expires.c>
 ExpiresActive On
 ExpiresDefault "access plus 7200 seconds"
 ExpiresByType image/jpg "access plus 2592000 seconds"
 ExpiresByType image/jpeg "access plus 2592000 seconds"
 ExpiresByType image/png "access plus 2592000 seconds"
 ExpiresByType image/gif "access plus 2592000 seconds"
 AddType image/x-icon .ico
 ExpiresByType image/ico "access plus 2592000 seconds"
 ExpiresByType image/icon "access plus 2592000 seconds"
 ExpiresByType image/x-icon "access plus 2592000 seconds"
 ExpiresByType text/css "access plus 2592000 seconds"
 ExpiresByType text/javascript "access plus 2592000 seconds"
 ExpiresByType text/html "access plus 7200 seconds"
 ExpiresByType application/xhtml+xml "access plus 7200 seconds"
 ExpiresByType application/javascript A259200
 ExpiresByType application/x-javascript "access plus 2592000 seconds"
 ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
</IfModule>
# END Expire headers

# BEGIN Cache-Control Headers
<IfModule mod_headers.c>
 <FilesMatch "\\.(ico|jpe?g|png|gif|swf|gz|ttf)$">
 Header set Cache-Control "max-age=2592000, public"
 </FilesMatch>
 <FilesMatch "\\.(css)$">
 Header set Cache-Control "max-age=2592000, public"
 </FilesMatch>
 <FilesMatch "\\.(js)$">
 Header set Cache-Control "max-age=2592000, private"
 </FilesMatch>
<filesMatch "\\.(html|htm)$">
Header set Cache-Control "max-age=7200, public"
</filesMatch>
# Disable caching for scripts and other dynamic files
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
</IfModule>
# END Cache-Control Headers

# KILL THEM ETAGS
Header unset ETag
FileETag none

# protect wpconfig.php
<files wp-config.php>
order allow,deny
deny from all
</files>

# protect the htaccess file
<files .htaccess>
order allow,deny
deny from all
</files>

# protection de la lecture des répertoires
Options -Indexes

En ce qui concerne mes sources, je ne les ai pas toutes retrouvées… Mon htaccess a évolué au fur et à mesure des mois, et chaque bout de code a été pris à droite à gauche. Dès que je les retrouve toutes, je vous fais signe.

  • Gestion des Etags (Take It Web)
  • Pourquoi ajouter des expires headers ? (Journal de Guillaume)

Si notre htaccess contient des erreurs ou s’il peut être amélioré, dites-le nous.

Article mis à jour le 29 Juin 2010 :

  • Ajout des expires headers pour les favicons
  • Grosse amélioration de Mod_Deflate Compression (merci à RenardDuDezert)
  • Ajout de la protection de la lecture des répertoires (merci à Geal)

Un modèle de fichier htaccess

Vous pouvez aussi télécharger directement ce modèle de fichier htaccess pour l’amélioration des performances et du temps de chargement de votre.

Renommez juste htaccess.txt en .htaccess le fichier avant utilisation.

Daniel Roch

Conférencier, auteur, consultant et expert SEO WordPress, CEO de SeoMix et SEOKEY

154 Commentaires

Jonathan Petitcolas Le 17 juin 2010 à 10h55

Excellent article ! Va falloir que je teste tout ça. Merci beaucoup ! :)

Geal Le 17 juin 2010 à 13h14

Normalement, la partie « protection du fichier htaccess » est deja presente dans le fichier /etc/apache2/apache2.conf:

Ce qui empeche aussi la consultation par le navigateur du fichier .htpasswd

Robin Le 17 juin 2010 à 13h15

Article très intéressant surtout la partie dédié aux Etags que je ne connaissaient pas du tout.

Renardudezert Le 17 juin 2010 à 14h20

Tu peux ajouter les lignes juste apres ta directive :

(a tester bien sur suivant le type d’hebergement).

Sinon pour info, le listing de repertoire n’a pas de rapport avec la protection du .htaccess.

Le Listing de rep sur un serveur apache est du a l’option « Indexes » qui est activee par defaut sur les serveurs apache. Si tu veux empecher le listing de repertoire sur ton site, il te suffit d’ajouter au debut de ton .htaccess :
Options -Indexes

Si je trouve un peu de temps je vais essayer d’ecrire un billet pour demystifier un peu la configuration d’Apache, et donner quelques astuces pour optimiser/proteger son VirtualHost.

Gpenverne Le 17 juin 2010 à 14h45

De même ^ J’ai appris des choses. Merci :)

Julien R Le 17 juin 2010 à 17h33

je pense que tu as un problème d’optimisation avec tes commentaires. Supprime donc les favicon, résoud ton problème d’url d’avatar par defaut qui se duplique, combine tes js et meme insert le dans ton code html si ils sont dynamique, un sous-domain pour les fichiers statics avec le keep alive d’activer et desactiver pour les pages, etc…
regarde : http://www.webpagetest.org/result/100617_4FK/
Tu peux encore en faire des optim ;)

sinon pour revenir sur les Etag, le désactivé sur une page dynamique n’est pas un bonne idée. Par contre pour tous tes fichiers statics tu vas en effet gagner. Le top c’est d’avoir un autre nom de domaine pour ceux ci et la tu configureras ton htaccess pour des fichiers statics.

IBuzzyou Le 17 juin 2010 à 21h33

Excellent récapitulatif pour optimiser son temps de chargement (maintenant un critere de Google), j’avais déjà quasiment tout appliqué sur mes sites mais pas au mieux, merci pour les Expires Headers, E-Tags et les cache control, je n’avais pas correctement configuré la durée, maintenant faut mettre à jour l’ensemble des sites..

Daniel Roch Le 17 juin 2010 à 21h37

Merci encore Renarddudezert. Je teste ça et je met à jour l’article :)

@Julien : je sais, j’ai vraiment pas mal de boulot. Pour les favicon, il faut que je trouve le moyen de les mettre en cache. Pour le CDN avec le sous-domaine, c’est dans les projets. :)

Par contre, j’ai pas trop compris ce que tu entend par url d’avatar par defaut qui se duplique, idem pour le keepalive.

Julien R Le 18 juin 2010 à 0h53

Je t’invite a regarder les images de ta page via l’outil que je t’ai proposé : http://www.webpagetest.org/pageimages.php?test=100617_4FK&run=1&cached=
on y constate tout de suite les images dupliquées :)

Pour le keep alive, ca sert a faire durée une connexion, le top si tu veux que ton site réponde vite, c’est de ne pas avoir de keep alive sur ton domain principal (tes pages donc) et d’en avoir un sur ton sous-domain qui fournie le contenu static. L’interet est de répondre le plus vite possible a une requete sur ta page, après le chargement de celle-ci c’est le sous-domain qui gere.

Daniel Roch Le 18 juin 2010 à 12h56

@Julien R : effectivement, j’ai encore beaucoup de boulot sur mon thème. L’outil est vraiment puissant (presque mieux que GTMetrix ou Yslow). Il ne me reste plus qu’à m’y mettre…

@Geal : donc je supprime les lignes suivantes, ou je les supprime ?

@renarddudezert : tout est mis en place. Je vais attendre deux-trois jours avant de mettre à jour l’article, au cas où cela ne fonctionne plus pour certains visiteurs ^^.

Au fait, j’ai lu ailleurs que je devais aussi ajouter ces lignes pour Internet explorer. C’est utile ?

Ainsi que cette ligne pour les proxys:

Sinon, petite question à tous (qui avez l’air de bien vous y connaître). Je n’arrive pas à appliquer de expireheader à mon favicon. J’ai essayé plusieurs types de ExpiresByType, mais sans succès…

Geal Le 18 juin 2010 à 14h33

Bin tu regardes le fichier apache2.conf, et tu verifies si les fichiers ht* sont inaccessibles pour l’utilisateur

Maxime Le 18 juin 2010 à 18h26

Exécuter toutes les bonnes pratiques de cette article, c’est s’assurer un bon score Yslow ;-)
Quand j’ai mis en place ces techniques sur mon site, j’ai été étonné de voir que la plupart des sites ne sont pas optimisés. C’est pourtant de petites choses en petites choses que l’on améliore performances et expérience utilisateur.

CédricADW Le 20 juin 2010 à 10h45

Voilà un article très complet sur le .htaccess

Je l’ajoute dans ma revue de Web ;)

leelooz Le 22 juin 2010 à 15h27

Très intéressant comme article.
Mais que se passe-t-il par ex. si je modifie un des fichiers .css pour modifier le design ou .js pour ajouter une fonctionnalité (ou une image c’est pareil) ?
« Expire Header » indique qu’il est en cache pour 30 jours et le Etag est coupé donc le visiteur n’aura pas la dernière version avant longtemps ?

Daniel Roch Le 22 juin 2010 à 17h32

Il y a deux solutions :

– Soit tu change l’url de ton thème (auquel cas il va devoir tout recharger)
– Soit tu indiques un identifiant de version, du type *.css1 (mais je n’ai jamais testé cette technique…).

leelooz Le 22 juin 2010 à 19h51

Ouais, la solution semble être de renommer le nom du fichier que l’on souhaite modifier afin qu’il soit bien pris en compte sans attendre 1 mois.

Sinon, je pensais à un truc: par défaut les navigateurs gèrent déjà un cache des fichiers composants un site, donc à moins de vider le cache on re-télécharge pas les fichiers/image chaque fois de toute façon ?
les seules choses qui doivent rester comme « communication » avec le serveur sont les « Etag » pour savoir s’il doit ou non re-télécharger les fichiers

Daniel Roch Le 22 juin 2010 à 21h25

Ce n’est totalement vrai que pour les images.

En général, il va télécharger de nouveaux les fichiers générés à partir de php, les javascript et autres pubs gérées en javascript.

Et s’il ne le fait pas, le reste de cet htaccess va compresser les données.

Un exemple : le nouveau javascript de mon thème pèse normalement 120ko, mais plus que 45ko après compression. ;)

jeans Le 26 juin 2010 à 13h10

Merci, super article très utile!
Grâce à toi j’ai rajouté Expire Headers et Etags. Article qui tombe au bon moment puisque Google annonce prendre encore plus en compte (dans un futur proche) le temps de chargement de nos sites.
Je n’ai pas envie de mauvaise surprise à cause de quelques sec de chargement.
Encore merci!!

Guillaume Le 22 juillet 2010 à 12h19

Excellent article !

J’ai passé de nombreuses heures pour réussir à configurer la compression GZIP pour mon site sans réussite puis je suis tombé par chance sur ton article qui a enfin apporté une solution fonctionnelle à tous mes problèmes.

Merci, tout fonctionne, c’est génial !

Lionel78 Le 10 août 2010 à 11h37

Merci pour cet article, Yslow m’indiquait que mon site n’avait pas de compression Gzip, avec les liens donnés dans l’article, je m’aperçois que la compression fonctionne déjà correctement.
Il ne me reste plus qu’à tester les différentes options, j’espère gagner sensiblement en temps de chargement !

Cédric Le 17 août 2010 à 16h08

Super article !

Je ne trouvais pas comment désactiver les Etags, et j’utilisais un truc bien plus simpliste pour le reste (du coup mon site photo affiche un score entre 91 et 97/100 sur YSlow ^_^)

Sur certains mutualisés il faut par contre demander au support d’activer des fonctionnalités (cas des hébergements Premium chez PHPNET par exemple ; sur leur mutu « normal » tout fonctionne sans aucun soucis)

Lashon Le 29 août 2010 à 16h31

Oui, presque complet ton htaccess. Il manque les lignes essentielles de configurations propres à passer en php5 : http://lashon.fr/wordpress/si-plantage-verifier-forcer-hebergeur-vers-php5-code-htaccess/

Perso j’ai déjà configuré tout ça chez moi sauf les expire headers parce que je modifie encore trop souvent mon thème, ce qui pose un problème. Certain que le cache et l’expiration font gagner encore en optimisation.
Faire gaffe avant d’utiliser le MOD_DEFLATE COMPRESSION, cela dépend de l’hébergeur, comment celui-ci interprète Apache. Chez 1and1 par exemple, pas question de l’utiliser. Il faut alors passer par un fonction php dans son thème.

Puis question hors sujet: je m’aperçois que tu as interdit de voir les blogs des commentateurs de ton Web. C’est un peu à sens-unique et pas très interactif comme démarche…

Daniel Roch Le 30 août 2010 à 9h03

@Lashon : merci pour ces précisions pour le mod_deflate compression. Tu utilises quoi comme alternative php quand tu ne peux pas l’utiliser ?

En ce qui concerne le blogs des commentateurs, je modère beaucoup. Il faut que le blog soit pertinent vis-à-vis des thèmes de SeoMix ou de l’article. Donc pas mal de liens sautent (car le nombre de spammeurs SEO est impressionnant).
Et souvent, c’est un lien par commentaire, donc soit le site, soit un lien publié dans le commentaire.

Lashon Le 30 août 2010 à 11h41

Daniel,
Pour les commentaires je ne parle pas de modération, la modération est normale et ton droit le plus strict (je modère aussi sur mon blog). Je parle du simple fait qu’aucun lien dans le nom de l’auteur qui commente ne soit accessible. Tu fais une grosse bourde car c’est plutôt anti web interactif, pas le jeu du blogging actuel. Le sens unique, tu sais, ça va éloigner beaucoup de tes visiteurs. Enfin tu fais comme tu veux.

Pour ta question de mod_deflate en php, il suffit de mettre en haut de son header :

encore faut-il aussi jouer avec le php.ini, mais c’est une autre histoire

Daniel Roch Le 30 août 2010 à 18h55

@Lashon : merci pour le bout de code php.

Et pour les sites, je ne met que les sites pertinents (adieux sites de casinon, sur les chiens et chats ou sur la cuisine), et ceux où le commentaire tient en plus d’une ligne… je ferais un article sur la question pour mieux en discuter. ;)

zonedevie Le 13 septembre 2010 à 9h31

Très bon article. merci pour toutes ces infos :-)
j’ai pas mal galérer pour trouver l’info sur l’expiration des images !

Philippe Cadu Le 25 septembre 2010 à 10h52

Un grand merci pour cet article , moi qui ne suit pas expert,
– j’ai mis en place progressivement les modifications du Htaccess ,
– avec l’article sur le meilleur plug in de cache , j’ai ajouté DB Cache Reloaded à wp super cache
– avec l’article sur les plug-in à éviter j’en ai supprimer deux ou trois , il n’y a que WP-Cumulus que je garde même si ce n’est pas le top , il est bien plus esthétique que l’horrible nuage de mots clefs .
J’en ai essayé un autre en HTML5 aussi lourd a chargé et fait tourné les processeurs à 60%. (Si vous connaissez un qui efficace et esthétique , je suis preneur)
– Temps de chargement, Temps de réponse serveur, Vitesse, j’ai tout contrôlé avec YSlow
Donc résultat temps d’accès au serveur divisé par deux , temps de chargement divisé par deux .
En page d’accueil, j’ai diminué le nombre d’articles et installé le plug-in WP-PageNavi et la aussi vitesse d’affichage bien plus rapide
Résultats : les visites et le nombre de page en augmentation de 50 % en moyenne suivant l’actualité .

Donc je me répète, un grand merci pour les détails et explications fournies qui permettent à un non-expert Worpress de mettre en application des techniques pointues.
Voilà , je tenais à faire part de mes résultats et de mes encouragements à continuer.

parierenfrance Le 28 septembre 2010 à 20h09

Cet article est excellent et m’a bien aidé. Après avoir passé un bon moment à réduire mon page speed pour des clopinettes, grâce aux implémentations proposées mon site est passé de 76 à 100/100 sur l’outil Page Speed de Google.
Un bémol : Header append Vary User-Agent env=!dont-vary me fait planter le chargement de la page.
Merci

Pierre Aulagne Le 22 octobre 2010 à 10h40

salut

sur mon site, aveec yslow, je n’ai que des A hormis sur :
– Compress components with gzip : F
– add expire headers : F
– Use a Content Delivery Network (CDN) : F
– Make fewer HTTP requests : F

C’est un site sous WP 301 avec le theme Atahualpa chez OVH perso (je débute)

Me conseillez-vous de tester le remplacement pur et simple de mon fichier htaccess par le vôtre SVP ? (je ferai une sauvegarde du mien promis !)

Daniel Roch Le 22 octobre 2010 à 21h05

Toujours faire une sauvegarde avant, mais oui, je te conseille de tester chaque élément de mon fichier htaccess pour accélérer ton site.

Dakine Le 08 novembre 2010 à 23h10

Oh parfait! merci beaucoup ca à répond a 90% de mes questions concernant l’optimisation de ma boutique.

Il en reste une de taille… Sxiste t-il une application capable de faire le ménage dans un fichier .CSS ? Car le miens à subit beaucoup de modifications, le site aussi, finalement pleins de choses y sont à présent complètement inutiles.

Daniel Roch Le 09 novembre 2010 à 10h34

Il faut chercher une application « minify » pour css (Google is your friend).

DJib's Le 09 novembre 2010 à 20h11

Chez l’hébergeur 1&& la compression Gzip n’est pas possible par le .htaccess, il font donc créer un fichier php.ini et mettre le code ci-dessous. Ensuite il faut le mettre à la racine du site.L’outil yslow vous indiquera que qu’il n’y pas de compression Gzip, mais en veraifant sur le site http://www.gidnetwork.com/tools/gzip-test.php , vous verrez qu’elle y est bien (5 pour la compression est le bon compromis).

Daniel Roch Le 10 novembre 2010 à 9h25

Excellent. Merci beaucoup pour ton code Djib’s !

billboc Le 20 décembre 2010 à 18h17

bonjour,

y a t-il un risque que les modifications que j’apporte à un fichier n’apparaissent pas tout de suite avec ces reglages ?

merci

Daniel Roch Le 20 décembre 2010 à 22h09

@Billboc : si tu modifiez le fichier htaccess, les modifications sont immédiates. Soit cela fonctionne tout de suite, soit cela plante l’accès à ton site (mais un accès FTP permet de revenir immédiatement en arrière en cas de soucis)

Billboc Le 21 décembre 2010 à 8h49

Bonjour Daniel,

merci pour ta réponse. En fait ma question n’était correcte.
J’ai pas bien compris le fonctionnement des header et cache control.
Si je fais un changement sur mon blog est-ce que le navigateur va rester sur la version qu’il a en cache ? ou va t-il vérifier qu’il n’y en a pas une nouvelle ?

merci encore une fois pour le beau boulot que tu fais !!

Daniel Roch Le 21 décembre 2010 à 11h08

Oui, le navigateur va garder le cache. Le moyen le plus simple de contourner le problème est de renommer le répertoire de ton thème, ce qui va forcer le navigateur à tout remettre en cache.

billboc Le 07 janvier 2011 à 10h30

salut je viens de mettre un blog privée en ligne
tout fonctionne bien de chez moi
mais les autres membres ne peuvent se connecter en utilisant pourtant les mots de passe qui fonctionnent chez moi ??

est-ce que les astuces citées ci-dessus que j’utilise sur mon blog peuvent être à l’origine de ce problème ?

merci pour ton aide

Daniel Roch Le 07 janvier 2011 à 12h29

@Billboc : normalement, aucun impact. Mais pour t’en assurer, il suffit de remettre le fichier htaccess initial.

Limonade Le 20 janvier 2011 à 22h07

Bonsoir, vraiment excellent cet article!
Je connaisser déjà le Gzip.
Je rechercher des infos pour désactiver les Etags et aussi
gestion du cache en Php.
Je viens de mettre en pratique, ça marche Nikel.
Merci! :)

chevrolat Le 10 février 2011 à 11h51

Bonjour,

J’ai un site qui présente des photos modifiées régulièrement. Elles sont toutes dans le rep : img.
comment puis-je enlever seulement ce répertoire de la gestion de l’expiration et du cache control du reste du site ?

Merci encore par la clarté de ce tuto !
sylvain.

Julien R Le 10 février 2011 à 14h03

@chevrolat
tu dois le gerer via apache => DirectoryMatch pour selectionner ton repertoire et après il faut synchroniser la date de derniere modification du fichier avec le header du cache du fichier « Last-Modified » (n’oublie pas de mettre un must-revalidate qui renvoie du 304 ^^ )

chevrolat Le 10 février 2011 à 17h47

Je crois avoir compris pour directoryMatch mais comment implémenter le header sur un fichier image ?
faut-il passer par demande_img.php appelé dans la source de la balise html img
où ce script modifiera le header avec la bonne valeur ‘last-modified’,
ou y’a t’il un moyen plus ‘automatique’ ?
merci.

julien R Le 11 février 2011 à 9h21

@chevrolat Utilise uniquement apache : mod_include pour recuperer le flastmod et mod_header

Si ca peu aider, Jai trouve un (enorme) article sur htacces :
http://www.askapache.com/htaccess/speed-up-sites-with-htaccess-caching.html

chevrolat Le 11 février 2011 à 11h30

Merci,
je posterai si j’arrive à mes fins…

Philippe Le 24 février 2011 à 10h18

Merci pour cet excellent article !

gestion de crise Le 27 avril 2011 à 20h20

Excellent article pour optimiser la vitesse de son site. Merci beaucoup.

Julien S Le 03 mai 2011 à 10h37

Merci pour cette article !

J’aurais juste deux questions :

1/ Est-ce que cela ne comporte pas de risque de faire de la compression en Gzip ? Est-ce que l’alternative PHP / HTML passe en remplacement si la navigateur ne passe pas ?

2/ Niveau Etag, est-ce qu’on a une estimation du gain de performance ? Ayant un contenu qui s’affiche de façon aléatoire sur mon site, j’ai peur que cela embrouille ma fonction…

Daniel Roch Le 03 mai 2011 à 11h54

@Julien : le fait de mettre en place la compression Gzip ne comporte pas de risque, puisque les données transmises seront toujours au format HTML (mais compressé). Il faut juste savoir si ton serveur le permet ou non.

Concernant les etags, on gagne entre 0.5 et 1 seconde de temps de chargement sur les pages ayant beaucoup de contenu. Normalement, cela ne devrait avoir aucun impact sur tes fonctions aléatoires.

Emmanuel Le 05 mai 2011 à 23h31

Hello, merci Daniel, cela fait un bon résumé des optimisations serveur à effectuer.
J’ai appliqué cela. A voir maintenant que cela va produire. Encore merci. Manu

Julien S. Le 08 mai 2011 à 18h39

Ok merci pour tes réponses, je verrais bine à la longue si ça passe bien ^^

Sinon, y’a aussi 2 lignes pas mal :

Ca permet de personnaliser vos page 403 et 404 !

manu Le 21 mai 2011 à 21h37

Salut, j’ai mis tous le code dans mon htaccess pour mon site d’article qui est très lourd.le chargement des pages est plus rapide mais j’ai un gros soucie.
Je crois que cela ne va pas avec Adsense (si c’est possible).
Je l’avais toute la journée sur le site (le bout de code), résultat rien dans le rapport adsense. Je viens de l’enlever et déjà presque 200 affichage…
Tu as déjà un problème similaire?

Daniel Roch Le 22 mai 2011 à 9h19

Bizarre. J’ai mis ce code dans mon htaccess et tout fonctionne, y compris mes publicités Adsense. Essaie en ajoutant bloc par bloc, pour savoir lequel pose problème. ;)

cob51 Le 28 mai 2011 à 9h25

Des heures à ramer pour pouvoir compresser et optimiser le cache…et enfin je tombe sur le site qu’il me fallait ;-)

Très bien expliqué, mais vu mon niveau je n’ai pas tout saisi,le principale est que ça fonctionne, seul bémol : page speed ne peut plus accéder pour une analyse des performances mais ça fonce d’enfer, c’est peu important

Arkanys Le 09 juin 2011 à 0h52

Bonjour,
Merci pour tous ces bouts de codes pour le HTaccess. Cela m’enlève une bonne épine du pied car j’ai passé beaucoup de temps à tester des codes d’autres sites … et rien ne fonctionnait.
Selon GTmetrix, la page d’accueil (de l’un de mes sites) est passée d’un temps de chargement de 2,09 s à 1,37 s … soit 35% de gains !!

Sarbacanne Le 11 juillet 2011 à 10h09

Question bête, si je bloque le hotlink de mes images (via htaccess), y aura-t-il un impact sur mon référencement? Je gère un site de photographie amateur, et mon site est beaucoup sollicité par Google Image et Facebook, d’où ma question. Quoiqu’il en soit, merci beaucoup pour cet article très complet qui m’aura bien servi! (les etags, je ne connaissais vraiment pas).

Daniel Roch Le 11 juillet 2011 à 14h22

Normalement, cela n’aura aucun impact en référencement, à condition que ton site fasse de jolies liens vers ces images (et donc avec une balise Alt)

Sarbacanne Le 11 juillet 2011 à 15h13

Merci beaucoup, je verrai à l’usage de toutes façons. Ce qui m’inquiète c’est qu’avec un balisage de ce type :

(La balise <a> vers l’image plus grande est pour fancybox)

…et un blocage htaccess de ce type :

…sur Google image lorsque je clique sur une de mes photos, je suis redirigé vers une miniature crée par Google, et non vers l’image d’origine. Et pour ce qui est de facebook, l’image d’article n’apparait plus. Je pense qu’il va me falloir ajouter une liste d’exclusion.

Pour en revenir aux performances du site après modification htaccess, l’actualisation de la page principale de mon site est désormais instantanée. YES!

Yannick Le 24 août 2011 à 18h48

Bonjour,

J’ai mis en place la mise en cache sauf:
Header unset ETag
FileETag none
ces deux lignes font planter le serveur.

Par contre http://pagespeed.googlelabs.com/ me dit toujours que je devrais exploiter la mise en cache du navigateur et me donne les urls avec à droite (délai d’expiration non spécifié).

Je ne comprends pas. Si quelqu’un à une idée du problème…

Merci d’avance

Henri666 Le 01 septembre 2011 à 1h52

Salut, je voudrais appliquer ce fichier htaccess sur mon site : http://www.cursus-droit.fr, une fois que je remplace le fichier, la page d’accueil s’affiche parfaitement sauf… que TOUTES mes autres pages, articles… renvoient des erreurs 404. quelqu’un pourrait m’aider ?

PS:J’utilise wordpress et je suis chez easy-hebergement.

Daniel Roch Le 01 septembre 2011 à 7h26

L’un des blocs du htaccess doit être incompatible avec hébergeur. Il faut donc tester élément par élément pour savoir lequel pose problème.

Bruno Le 01 septembre 2011 à 10h25

Bonjour,
Je suis sur blogspot et je voudrais savoir comment installer le fichier htaccess sur mon blog mais je ne sais pas comment faire.
Pour le HTML pas de problèmes mais le PHP ne passe pas.
Je vous remercie.
Cordialement,
velane19

Henri666 Le 01 septembre 2011 à 20h09

Salut Daniel,

J’ai déjà testé, mais rien ne marche :(

voici mon htacces d’origine :

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Ou me conseilles-tu de mettre le code ?

Daniel Roch Le 01 septembre 2011 à 20h46

Normalement, ce code issu de WordPress doit être placé après ceux présents dans cet article.

Alain Le 07 septembre 2011 à 17h41

Bonjour et bravo pour vos conseils
Hier, j’ai mis en application toute la partie jusqu’à # KILL THEM ETAGS compris mais je pense qu’il y a un problème.
L’optimisation a été mise dans le htaccess se trouvant à la racine du site.
Dans un sous répertoire, j’ai un forum avec son propre htaccess non optimisé comme le précédent

Depuis ce matin Google crawle mon forum avec des url de ce type :
monsite.net/forums/forum-t463-p1

alors que les bonnes adresses sont sous la forme :
monsite.net/forums/forum-t463-p1,titre-du-message.html
J’ai retiré l’optimisation du htaccess principal et Google reprend mes pages avec les bonnes adresses.
Je pense donc qu’il y a un problème qui coupe les adresses avant la virgule.
Avez-vous une idée
Merci par avance

Daniel Roch Le 08 septembre 2011 à 8h05

Normalement, il n’y as pas de cause à effet entre mes optimisations du htaccess et ton problème d’URL. Il faudrait que tu regardes la documentation de ton forum pour savoir comment corriger le problème.

C-Jay Le 03 octobre 2011 à 12h51

Merci pour cet article fort intéressant !
Petite question :
Est-il possible d’appliquer la règle ExpiresByType image/jpg « access plus 2592000 seconds » à l’ensemble des sous-dossier présents dans le répertoire /image ?

Daniel Roch Le 03 octobre 2011 à 14h20

Oui, on peut faire cela. Si je ne dis pas de bêtises, il suffit de placer un fichier htaccess dans le répertoire que l’on cible, en l’occurrence le répertoire image.

C-Jay Le 03 octobre 2011 à 14h59

Exact ! Merci beaucoup.

Jean-Michel DAIX Le 11 octobre 2011 à 10h47

Il reste à gérer les fichiers externes tels que celui de Google Analytics sur lequel nous n’avons pas la main pour définir une date d’expiration. Il existe pour WordPress cette extension pour gérer le script GA.js en local mais il n’est pas compatible avec la version 3 : http://wordpress.org/extend/plugins/local-analytics/

D’autres idées pour améliorer le chargement de ces fichiers externes ?

blh Le 04 novembre 2011 à 0h21

Bonjour, (bonsoir selon)
je lis avec un réel plaisir toutes vos recommandations cependant, elles sont souvent assez techniques et ne répondent qu’à certains WP.
1)- faut-il ou non inclure deux systèmes de cache? Quant à celui du navigateur, quel doit-être sa valeur ?
2)- il est souvent question d’avoir un sous domaine réservé aux images et vidéos; soit, mais comment établir le lien?
3)- il existe un plugin wp pour le php.info qui ne donne pas partout les mêmes valeurs, par exemple les valeurs de la mémoire: quel est le procédé le moins mauvais ?
4)- beaucoup de questions’réponses des commentateurs font que l’on a tendance à s’y perdre: serait-il possible de donner un exemple de blog wp sérieusement référencé ou chacun adapterait ses particularités, et où interviendraient des google analytic et autres plugins de ce genre?

Je suis chez nuxit, en php5.2 sous serveur dédié et me promène avec une url de cette forme:
, avec blh-land comme nom de domaine. Est-il possible de simplifier cette adresse dans la mesure où j’ai un autre blog se terminant en Wa ?
Bravo évidemment pour cet article.

remerciements.

Daniel Roch Le 04 novembre 2011 à 9h31

1- oui : il faut que le site Internet mette en cache les pages (comme WP-Super Cache pour WordPress), en complément du htaccess qui va mettre en cache sur le navigateur les données
2- je ferais un tutoriel là dessus car c’est un peu plus complexe
3- le mieux, c’est de passer uniquement par le fichier wp-config, et de demander à son hébergeur comment augmenter cette valeur.
4- le mien ;)
5- oui, le blog pourrait être situé à la racine sans répertoire. Regarde sur Google, il y a pas mal de tutos pour déplacer un blog WordPress

Jean lou Le 04 novembre 2011 à 17h49

intéressant mais tout comme il y a un lien pour tester le gzip, existe-t-il un moyen de tester que les commandes etag fonctionnent? Sur ovh mutu par exemple, si j’ai la commande :

########## Begin – ETag Optimization
## Note: It may cause problems on your server and you may need to remove it
FileETag MTime Size
########## End – ETag Optimization

Comment vérifier que ça fonctionne normalement?

Daniel Roch Le 05 novembre 2011 à 8h57

Normalement, l’outil en ligne GTMetrix l’indique quand les etags sont mal configurés.

blh Le 06 novembre 2011 à 22h09

Merci pour la réponse.
J’ai un taux de compression de 23% et un temps d’accès au site de 0,6 à 0,7 sec: est-ce correct ?
Les autre blocs du htaccess ont l’air de bien fonctionner.
Seul problème maintenant est de comprendre et de régler tous les plugins que vous aviez donnez, SEO… Je navique avec une page en anglais et la même en traduction french ( merci Google), c’est loin d’être évident.

La question qui se rattache à tous ces réglages est alors: quels sont les bons réglages? Le pire est que même en français, il faille un dico pour comprendre ce qui est écrit.
Juste deux petites questions sur cet article:
1)comment faire pour remplacer le pas beau du tout 404 par un truc plus sympa qui réinvite à revenir sur le site ?
2)l’icône animée en début d’url du site n’apparaît plus, est-ce en raison du htaccess ?
Merci une nouvelle fois.

Daniel Roch Le 07 novembre 2011 à 7h13

Pour ta première question, il existe pas mal de tutoriel ou de plugins pour faire cela : fais une recherche sur Google.

Pour la seconde, normalement le htaccess ne devrait pas bloqué les icônes animés…

blheblh Le 07 novembre 2011 à 17h45

effectivement, pour la seconde, tout est en ordre.
je regarde aussi pour les 404
:)

Fab Le 24 novembre 2011 à 10h21

Daniel,

Quel code faut-il insérer dans ton .htaccess pour mettre en cache l’affichage des plugins comme wordpress popular post, wordpress polls ou encore g-lock ?

Merci.

Fabien

Daniel Roch Le 24 novembre 2011 à 12h21

@Fab : cela ne dépend pas du fichier htaccess, mais des plugins de cache.

Fab - Olabonga Le 24 novembre 2011 à 14h18

Justement pour les plugin de cache, j’ai repris ton étude et ait opté pour DB et super cache. Une idée ?

Daniel Roch Le 24 novembre 2011 à 15h11

Normalement, ils devraient être mis en cache : regarde sur les pages dédiées à ces plugins pour en savoir plus.

Phil Le 27 novembre 2011 à 17h58

Bonjour,

compte tenu des évolutions sur le html5 et wordpress 3.3 qui arrive, est ce qu’il n’y aurait des changements à venir dans le fichier Htaccess .
Je te pose la question suite à la lecture d’un article sur http://fr.html5boilerplate.com/

Peux tu nous en dire plus ?

au plaisir de te lire
Phil

Daniel Roch Le 28 novembre 2011 à 11h58

Le fichier HtAcces de Html5 BoilerPlate est effectivement très bien conçu, mais il n’apporte des optimisations qui ne s’appliqueront que sur un petit nombre de sites. Quand j’aurais le temps, j’essaierai de faire un article complémentaire sur les éventuels ajouts à mettre en place.

thomas Le 16 décembre 2011 à 16h02

Bonjour , excellent htaccess.

je viens de l’installer sur un serveur mutualisé ovh pour un site (wordpress). J’ai vérifié avec YSlow et celui ci m’indique toujours des pbs avec mes Expired Header :-/

une idée du pb ?

merci

Daniel Roch Le 16 décembre 2011 à 16h54

Est-ce que les expires headers concernent des fichiers présents ailleurs, comme le fichier des boutons Twitter, Google + ou des publicités Google Adsense) ?

thomas Le 18 décembre 2011 à 9h27

Sur 24 liens, 6 sont extérieurs (notamment : http://fonts.googleapis.com/css?family=Yanone+Kaffeesatz ) a mon site.

Les autes font références aux PNG du theme utilisé

une idée ?

Daniel Roch Le 18 décembre 2011 à 17h20

Pour les PNGs, c’est bizarre car le code donné ici devrait fonctionner. Pour les autres fichiers, c’est normal car ils ne sont pas sur le serveur, donc le htaccess ne peut agir dessus.

thomas Le 18 décembre 2011 à 18h37

oui j’avoue aussi ne pas comprendre. tout semble pourtant correct.

impossible a corrigé. Peut etre cette option n’est pas utilisable sur un serveur mutualisé OVH.

thomas Le 19 décembre 2011 à 10h14

j’ai finalement trouvé la solution de cache control via ce site : http://www.askapache.com/optimize/speed-site-caching-cache-control.html

Semble t il la syntax en seconde semblait ne pas fonctionner.

Au cas ou ça peut aider.

Benoist Rousseau Le 04 janvier 2012 à 0h04

Merci Daniel pour cette précieuse aide. Mon site a gagné 5 points au speed test instantanément.

Je vais suivre de près les mises à jour de ce post pour le html5 et les évolutions avec wordpress 3.x

Julien Le 18 février 2012 à 20h50

Merci, je recherchais pour les Expire headers

Nabil Le 15 avril 2012 à 3h23

Bonjour,

Tout d’abord, merci pour cet article, il est effectivement de très grande utilité.

Je l’ai utilisé pour mon site http://nadorpresse.com qui tourne sous Joomla v2.5.*

Cependant le problème qui se pose actuellement, puisqu’il s’agit d’un portail d’actualités, concerne la mise à jour du site lors de la mise en ligne de nouveau articles.

Je remarque suite à l’ajour d’un nouvel article qu’il n’est pas visible immédiatement, ce qui pose un énorme problème.

Sachant que le plugin système du cache est activé, en plus des lignes rajoutées au fichier .htaccess, j’avoue que je ne sais plus ce qui empêche la mise à jour immédiate des nouveaux articles, est-ce le système de cache ou les lignes ajoutées au .htaccess…

J’utilise toutes les lignes proposées dans cet article.

Merci pour votre assistance.

Daniel Roch Le 15 avril 2012 à 14h39

@Nabil : faites d’abord un essai sans les optimisations du fichier htaccess afin de voir si c’est cela qui pose problème.

Oscar Le 17 avril 2012 à 21h52

Bonjour Daniel,
Je suis entrain d’optimiser la vitesse de sites sous WP et suis tombé sur plusieurs de tes articles bien utiles.
Pour le htaccess ci-dessus que j’utilise sur un sous-domaine cdn pour les ressources statiques est-ce vraiment utile d’ajouter le CacheControl si tu as déjà précisé le Expires ?
Voir ce lien :
http://gtmetrix.com/leverage-browser-caching.html

« It is important to specify one of Expires or Cache-Control max-age, and one of Last-Modified or ETag, for all cacheable resources. It is redundant to specify both Expires and Cache-Control: max-age, or to specify both Last-Modified and ETag. »

Merci
@+, Oscar

Daniel Roch Le 18 avril 2012 à 9h09

@Oscar : effectivement, cela peut être redondant. A l’époque, je n’avais pas eu de remontée d’info comme quoi il est inutile de préciser des directives qui auraient la même finalité.

Lisa Le 22 avril 2012 à 2h57

Salut Daniel. Merci pour cet excellent article. J’ai bien mis en place le code Etags et expire header mais je ne vois aucune différence sous GtMetrix… J’ai toujours F en expire header et 78 (C) pour les Etags. Voici mon code :

Daniel Roch Le 23 avril 2012 à 11h14

@Lisa : aurais-tu l’adresse de ton site pour voir d’où peut provenir le problème ?

Frédérique Le 23 avril 2012 à 12h01

Bonjour,
Je suis contente de voir que cette discussion est toujours active car j’ai le même soucis que Lisa. Cela fait pas mal de temps que j’essaie d’optimiser mon site grâce au htaccess (www.sestrea.fr). J’ai réussi à régler pas mal de problème grâce à vos astuces mais j’ai tjrs des mauvaises notes sur les expiration dates des header et sur la compressions.
Mon site est hébergé par 1&1, j’ai donc utilisé la solution donnée plus haut pour la compression : créé php.ini à la racine de mon site afin de gérer la compression mais GIDnetwork ne voit tjrs pas le résultat.
Est-il possible que des header dans les sources php écrasent les règles du .htaccess ?
Merci d’avance de votre aide :)

PS : je n’ai pas produit le code source du site que je récupère pour optimisation et je ne suis pas wed-developper malheureusement :/

Sylvain Le 26 avril 2012 à 13h18

Hello à tous,

Voilà ce que je viens de trouver dans mon htaccess :

Merci SUPER CACHE ! :P
Aurais-tu une idée Daniel de la façon dont ce code s’est retrouvé là ?

Daniel Roch Le 26 avril 2012 à 19h11

C’est le plugin qui l’ajoute pour pouvoir fonctionner. Rien de grave donc à retrouver des codes Htaccess propres au plugin WP Super Cache.

Sylvain Le 27 avril 2012 à 9h58

Désolé pour le long bout de code ^^ Pour expliquer plus en profondeur, j’ai fait il y a quelques mois un audit de sécurité de mon site et j’ai appris qu’il y avait un trojan JS-redirector qui avait pour effet de rediriger les visiteurs sur un autre site. J’ai localisé le code malicieux qui se trouvait dans le fichier functions.php et l’ai supprimé, mais chaque fois il revenait au bout de 2 ou 3 jours. Il a fallu une update du thème pour que le problème ne revienne plus.

J’ai quand même changé les mots de passe ftp, BDD et admin par mesure de sécurité.

Jusqu’à la semaine dernière où je reçois ce message de Google Webmasters Tools qui m’annonce que quelques pages de mon site contiennent un code malicieux.

Or, je ne trouve aucun code malicieux dans les fichiers du thème. Je précise que mon WordPress est à jour.

D’où mon message précédent : j’ai mis le plugin wp-supercache en cause car cette alerte est survenue juste après que je l’aie réactivé (je l’avais désactivé quelques semaines auparavant le temps de régler le problème).

Effectivement j’ai analysé les lignes de code un peu rapidement. Je savais que le plugin ajoutait des lignes au fichier .htaccess, mais j’ai pensé à tort que les lignes avec les appareils mobiles ressemblaient aux lignes de code que je supprimais dans mon functions.php à l’époque où il était infecté. Ça doit être sans doute du aux fichiers de cache que je n’avais pas du effacer convenablement.
Cela me ramène donc au point de départ :/ Merci pour ton aide !

Nico Le 14 juin 2012 à 23h18

Bonjour Daniel, petite question, est il possible de cumuler les techniques ci dessus et le plugin wp cache ou cela n’est pas trop conseille voir meme inutile. Merci par avance

Daniel Roch Le 15 juin 2012 à 9h18

Oui, aucun soucis à ce niveau là. C’est même recommandé. ;)

NIco Le 15 juin 2012 à 10h30

Ok, super, merci daniel. Juste autre chose, j’ai trouvé ce plugin de compression, WP PHP Speedy est ce que tu crois que cela vaut le coup de l’utiliser ? Merci

EDIT @daniel, je viens de m apercevoir, en regardant les entetes, que le site wordpress sur lequel je travaille, est sur un serveur Windows, en asp. Est ce que tout ce qui est au-dessus fonctionne aussi pour ce genre de serveur ? Et autre chose, est ce que cela fonctionne aussi sur un site wordpress multisite ? Merci ;)

Philippe Le 15 juin 2012 à 13h34

Bonjour, depuis que j’ai mis en place ce code dans mon htaccess, j’ai remarqué (d’après google analytics) que les utilisateurs de FIREFOX ont des temps de chargement extrêmement longs (en moyenne 12s) alors que les autres tournent à moins de 2s. C’est surtout vrai avec la version 12.

Sinon dans la ligne données, il n’y aurait pas un \ de trop?

Daniel Roch Le 15 juin 2012 à 16h06

@Nico : cela peut valoir le coup. Je ne connais pas ce plugin donc il faudra tester. Et concernant le type de serveur, cela n’aura normalement pas d’incidence.

@Philippe : bizarre, car tu es le seul à avoir eu ce problème. As-tu essayé d’enlever le code pour voir si cela venait de là ?

Philippe Le 15 juin 2012 à 16h20

Il y a 3 jours je n’avais pas ce code et Google analytics m’indiquait environ 3s pour charger la page avec Firefox et depuis lorsque je regarde heure par heure je descends rarement sous les 6 secondes.

Daniel Roch Le 15 juin 2012 à 16h43

@Philippe : dans cas, essayez de désactiver le code entier pour voir si cela vient de là. Si oui, alors je vous invite à rajouter progressivement chaque bloc pour savoir lequel pourrait poser problème sur votre hébergement.

vilto Le 16 juillet 2012 à 9h56

Bonjour, merci pour cet article très intéressant. Je me suis empressé de modifier mon ht access en rajoutant ces lignes de codes en plus de celles préconisées par wp-supercache.

Il apparait que les lignes concernant les Etags et le mode deflate fassent cracher mon site. tandis que le mod-Gzip a l’air de fonctionner. J’ai protégé mon ht access, est-ce pour cela que wp super-cache ne trouve aucune page mise en cache?

Dernière statistiques de mise en cache générées il y a 2 minutes.
WP-Cache (0KB)
0 Pages Mises en Cache 0 Pages Expirées
WP-Super-Cache (0KB)
0 Pages Mises en Cache 0 Pages Expirées

EDIT :J’ai effectué les modifications au htaccess, et pourtant voici ce que me dit pagespeed :

There are 72 static components without a far-future expiration date. Pourtant je n’ai pas adsense. J’ai dut modifier manuellement mon htaccess même si celui-ci etait en 755. Peut être parce-que j’ai mis ces lignes de code avant l’installation des plugins :

order allow,deny
deny from all

Merci pour votre aide

Etienne Le 02 août 2012 à 11h22

Je sais que l’article est vieux et tout et tout, que je vais surement le déterrer, mais je voulais juste te remercier pour toutes les explications.

Des htaccess on va en trouver tout fait sur internet, mais on a aucune explication quant à leur fonctionnement. La partie qui m’interesse notamment c’est la partie ou l’on peut empecher l’utilisateur d’acceder à un dossier sans index (jusqu’à présent j’utilisais la technique de mettre un index.htm vide dans mes dossiers)

Etienne

JibsouX Le 11 février 2013 à 19h52

onjour un petit plus pour tout ceux qui ne peuvent pas mettre la compression gzip pas htaccess a cause de leur hébergeur :

il suffit de rajouter dans le header.php
Apres le premier »?php :

détail :

phil Le 06 mars 2013 à 15h51

Super cette optimisation !

à ceci je rajouterais une protection contre les attaque des mauvais robots qui polluent nos serveurs (et donc les ralentissent)

avec ceci :

SetEnvIfNoCase User-Agent « ^libwww-perl* » block_bad_bots
Deny from env=block_bad_bots

Jeremy Le 20 mars 2013 à 1h22

Bonjour,

Tout d’abord bravo pour cette article, pour moi le meilleur pour optimiser son site wordpress via le .htaccess

J’ai bien rentrer le code complet et j’ai bien gagner en % au niveau des tests GTmétrix.

J’ai juste une question :

Le code est sensé améliorer la note du « Add Expires headers »

Hors moi c’est vraiment le point où la modification du .htaccess ne change rien, ma note est F

Que dois je faire ? C’est vraiment le dernier point que je dois régler mais je n’ai rien trouvé à ce sujet.

Merci et bonne continuation

Daniel Roch Le 20 mars 2013 à 14h13

Malheureusement, l’ajout des règles dans le htaccess peut ne pas avoir d’impact pour les ressources externes. Par exemple, le simple fait d’utiliser adsense bloquera la note à F pour les Expires Headers.

Neaj Le 07 mai 2013 à 10h39

Il me semble que la meilleure option pour améliorer les performances de son serveur web/ site (en terme d’utilisation ressource) est de ne pas utiliser de .htaccess. Les .htaccess modifient localement la configuration Apache2 à chaque connexion (visites). Plus il y a de visites, plus le nombre de reconfigurations locales va prendre des ressources. Il est plus judicieux d’utiliser toutes ces règles (qui sont très utiles ! =) ) directement dans la configuration Apache2 pour économiser pas mal de ressources serveur. Je suis en train de constater moi aussi une utilisation excessive de mes ressources sur le serveur par Apache2 qui peut être du à un grand nombre de .htaccess sur mes sites web.

lulu Le 05 juin 2013 à 18h04

Bonjour,

En accédant à mon ftp, je suis un peu perdu. J’ai un htaccess à la racine et un autre dans le dossier www.

Lequel prendre ? Dois-je en supprimer un ?

Merci d’avance,

    Daniel Roch Le 08 juin 2013 à 14h21

    Celui dès la connexion ne vous servira pas : utilisez directement le htaccess situé dans le répertoire www.

Aymeric Le 10 juin 2013 à 13h42

Hello, je retombe sur ton post et je me permets une petite correction (c’est toi qui a dit qu’on pouvait ;-) ) car il me semble qu’il manque un élément très important surtout quand on parle de performances Web: « Le htaccess est un fichier de configuration de votre serveur ».

En fait, c’est une extension du fichier de configuration du serveur qui fournit une méthode pour modifier sa configuration au niveau des répertoires.

D’ailleurs Apache déconseille l’utilisation de .htaccess quand cela est possible: « En principe, vous ne devriez utiliser les fichiers .htaccess que lorsque vous n’avez pas accès au fichier de configuration du serveur principal. » view-source: https://httpd.apache.org/docs/current/fr/howto/htaccess.html#when

Pour chaque requête, l’ensemble des répertoires dans lequel se trouve le fichier appelé sur le serveur sont parcourus à la recherche d’un éventuel .htaccess pour en exécuter le contenu. Multiplié à l’ensemble des requêtes, cela peut s’avérer assez gourmand!

Leur utilisation est utile uniquement lorsque la configuration du serveur n’est pas accessible, cas du serveur mutualisé par exemple.

Mais si vous avez un serveur dédié, ne les utilisez surtout pas et passez la directive « AllowOverride » à None en plaçant vos règles dans la configuration (apache2.conf/httpd.conf ou vhosts) pour stopper la détection des .htaccess dans chaque répertoire pour l’ensemble des requêtes, vos performances n’en seront que meilleures!

Plus d’infos ici: http://www.yapasdequoi.com/apache/2649-les-fichiers-htaccess-a-utiliser-avec-moderation.html

Yvaninho Le 14 juin 2013 à 23h48

Bonjour,

mon blog wordpress n’est pas installé à la racine de mon serveur mais dans un dossier.

Dois je avoir un fichier htaccess à la racine et dans le dossier d’installation de wordpress ?

Force htaccess optimisé doit être installé à quel niveau ?

Merci pour vos précisions

    Daniel Roch Le 17 juin 2013 à 9h37

    Le htaccess s’applique pour le dossier et tous les sous-dossiers qu’il contient. Donc en le plaçant à la racine, il s’appliquera à la perfection sur le dossier d’installation de WordPress.

Yvaninho Le 17 juin 2013 à 18h45

Merci pour ta réponse. C’est ce que j’avais fait ;)

Frank Le 04 juillet 2013 à 9h49

Merci pour ton message du 17 juin 2013, je me posais la question étant donné que je n’utilise pas de CMS pour certains de mes sites mais je les codes moi même. Et je me retrouve des fois avec des dossiers et sous dossiers. Enfin, une horreur quoi…

J’ai trouvé sur un autre site une autre façon d’écrire :
ExpiresDefault « access plus 1 week »

Au final, est-ce que ce n’est pas plus pratique que de sortir sa calculette pour transcrire les secondes ?

Je précise que le HTACCESS et moi, ça fait 2.

Patrick Le 06 juillet 2013 à 12h54

Bonjour et merci pour cet article.

J’utiise un CMS Prestashop sur un serveur dédié, mais avec un page speed de 35/40.

Après la mise en pala ce de ton htaccess avec Expire, je suis passé à 61, net progrés.
Par contre le ETAG me plante mon serveur avec une erreur 500, pas cool.
Une dernière chose, si comme moi des personnes mettent EXPIRE dans le htaccès et que GG trouve qu’il n’y est pas, il faut rentrer en SSH sur son serveur et passer les commandes :
a2enmod headers

a2enmod expires

Bon WE
Patrick

Mathieu Le 17 août 2013 à 14h31

Salut Daniel,

Merci pour ces infos toujours intéressantes pour bien optimiser un WordPress, ce qui n’est pas toujours facile quand on n’est pas né dans un bain de code.

Grâce à cet article et aux améliorations des commentateurs ci-dessus, je suis arrivé à bien étoffer mon fichier .htaccess avec des lignes que je n’avais pas pensé à ajouter. Mais j’aurai juste 3 questions :

1 – Tout comme d’autres utilisateurs, le code Etags bloque mon blog avec une erreur 500. Y-a-t’il une solution ? Ne manque-t-il pas un code du type «  »? Ce serait dommage, car ce code a l’air de bien accélérer le chargement !

2 – Quel est le meilleur temps à insérer pour le délai d’expiration des ressources ? Je vois que tu places certaines ressources en 7200 sec (0,8 j) et d’autres en 2.592.000 sec (30 j). Ne faudrait-il, comme le conseillent nombre d’outils, le placer en 604.800 sec (7 j) ?

3 – A ce propos, je tiens juste à te signaler une toute petite erreur : la ligne applications/javascript, où tu utilises plutôt la forme « AXXXXX » pour le délai (p’tit code copié ? ;)) n’indique que 259.200 sec… je pense donc que tu as oublié un « 0 » dans la précipitation ;)

Sinon, merci encore pour toutes ces bonnes infos qui font de SeoMix un des blogs WordPress les plus intéressants ! :)

Florent Le 07 novembre 2013 à 14h45

Bonjour,

Je ne sais pas si la question a déjà été posée. Mais nous savons que côté « serveur/hébergeur » certaines optimisations peuvent être en place.

Imaginons que je les ajoute tout de même en plus dans mon htaccess, cela risque de faire doublon et d’ajouter des traitements, donc une perte en efficacité ?

Merci pour votre réponse.

    Daniel Roch Le 08 novembre 2013 à 9h13

    @Florent : oui, les directives seront parcourues malgré tout pour chacune des requêtes afin d’écraser la configuration du serveur/vhost (allow override). Cela perd donc un peu en efficacité. (merci Aymeric pour la précision)

Jack Le 03 février 2014 à 10h02

Bonjour Daniel,

1 – Votre code est toujours d’actualité aujourd’hui ? ( 2 février 2014 )

2 – Faudrait-il remplacer tout le contenu du fichier .htaccess contenu dans le dossier d’installation de wordpress par votre code ici présent ou faut-il juste le rajouter à la suite du code existant ?

3- Les différents suggestions et rectifications de certains commentateurs ont-ils été pris en compte au final dans votre code ? Si non , peut-on quand-même l’utiliser tel quel ?

4 – Au cas où ce code ne marcherait pas pour x ou y raison, peut-on remettre en place l’ancien code (sauvegardé au préalable ) sans soucis ?

Merci d’avance pour votre précision et un grand bravo pour cet excellent travail !

    Daniel Roch Le 06 février 2014 à 8h43

    @Jack : le code est toujours d’actualité, et les suggestions des commentaires sont prises en compte.
    Par contre, il ne faut remplacer le contenu du votre, car en fonction de ce qui s’y trouve, certains éléments peuvent être utiles/inutiles voir entrer en conflit les uns avec les autres. Il faut donc tester et faire une sauvegarde du fichier original au cas où.

djib's Le 03 février 2014 à 15h22

Salut,

Il y a un soucis avec la compression gzip si on utilise un plugin de cache qui fait cette compression.

Chrome sur Windows va garder en cache pendant cette durée la page principale du site et ne va jamais la mettre à jour, même si on publie un nouvel article.

il faudra supprimer manuellemnt le cache.

Sur les autres navigateurs il n’y pas de probleme.

Pascal Le 09 février 2014 à 15h17

Bonjour,

Merci pour cet article.
Pourquoi dans les filematch certaines expressions commence par un baclslash et d’autres par 2 ??

    Daniel Roch Le 11 février 2014 à 15h32

    Effectivement, le double backslash ne servait à rien. C’est corrigé.

Syvoun Le 27 mai 2014 à 23h30

Les effets sur le chargement de la page sont-ils immédiat? Je m’explique, si je rajoute votre code htacess et que je vais dans gtmetrix, vais-je voir tout de suite un effet sur le temps de chargement? Ou bien cela se fait dans le temps? Sinon j’utilise le plugin W3 Total Cache avec les paramètres par défault pour mon blog sous wordpress? Dois-je le désactiver pour éviter les conflits ou votre code vient en supplément? Merci de votre aide.

    Daniel Roch Le 28 mai 2014 à 7h28

    Les effets sont immédiats, et le code est théoriquement compatible et vient en complément de W3 Total Cache

Cedric Le 29 mai 2014 à 11h39

Bonjour,
Comment mettre des Expires pour des fichiers particuliers?

J’ai mis des ExpiresByType mais bizarrement, d’après yslow ils ne semblent pas s’appliquer à certains fichiers particuliers comme:

LeDiligentWebfonts.css (qui est dans le meme repertoire que htaccess) et

LeDiligent_favico.png qui est dans un sous-répertoire

Pourtant j ai bien des ExpiresByType pour css et png

sam Le 01 août 2014 à 0h29

Bonjour, sur mon site, j’ai l’impression au vu des résultats sur GTmetrix qu’htaccess et plugin supercache ne font pas bon ménage. Je crois que c’est parce que les temps d’expiration spécifiés sont différents. J’avoue avoir pompé bêtement le htaccess… Cette théorie est-elle plausible ? Le htaccess permet-il de se passer du plugin de cache ? Merci de vos réponses ;-D

    Daniel Roch Le 01 août 2014 à 12h06

    Il s’agit de deux choses différente, et théoriquement les deux vont très bien ensemble

Mitchk6 Le 13 juin 2017 à 10h56

Bonjour !

Un grand merci pour ces bout de codes. Je pataugeais avec un plugin wp de cache, un autre d’optimisation soit disant au top.

Avec le .htaccess modifié, le site se charge deux (ou plutôt trois) fois plus vite… et avec des plugins en moins, ce qui n’est vraiment pas à négliger !
;)

marc Le 21 septembre 2017 à 13h03

bonjour,
merci beaucoup pour ce beau résumé mais je me demandais si je devais supprimer tout le contenu actuel de mon htaccess avant d’y coller « le code htaccess complet » repris ci-dessus OU si je n’avais qu’à l’ajouter à ce qui existe déjà?

Un énorme merci

Marc

    Daniel Roch Le 22 septembre 2017 à 11h30

    Difficile à dire car cela dépend fortement du contenu actuel de votre htaccess et de votre hébergeur. Je vous conseille de tester chaque bout de code en le rajoutant au fur et à mesure à votre htaccess (et en faisant une sauvegarde préalable).

marc Le 22 septembre 2017 à 15h33

Merci Daniel :) je vais faire ça. Belle aprem :)

Pack Le 26 novembre 2017 à 14h53

Merci beaucoup, ce résumé m’a vraiment aidé. Pour moi j’ai rajouté votre code à mon fichier .htaccess tout en conservant le contenu existant et ça bien marché. J’ai passé de 58/100 à 67/100 sur PageSpeed Insights c’est deja pas mal.

Urbanvibes Le 11 janvier 2018 à 23h42

Encore un article instructif, je vais tester ça rapidement, ça tombe bien je cherchais des solution pour accélérer quelques lenteurs sur des pages un peu lente de mon site…

Marc Le 20 février 2018 à 11h29

Le même pour nginx ce serais super :)

    Daniel Roch Le 20 février 2018 à 11h34

    Il faudrait que je prenne le temps effectivement de donner une configuration nginx pour la performance. Je le note.

Olivier Tassel Le 20 février 2018 à 14h25
ben Le 23 février 2018 à 13h17

Info pour ceux qui hébergent leurs sites WordPress sur OVH en mutualisé.
Ce paramétrage .htaccess fonctionnait très bien mais ça c’était avant…. depuis la mise en place de .ovhconfig (tous les nouveaux comptes sont concernés), le .htaccess ne sert plus à rien à part pour la réécriture d’urls. Les autres paramétrages ne sont pas pris en compte. OVH utilise à présent PHP-FPM pour accélérer notamment les scripts php. Couplé avec Php 7 les sites en WordPress sont rapides (pour le prix, c’est toujours la même histoire…). Dans tous les cas, merci à SEOMIX pour toutes les informations partagées sur leur site qui me sont fort utiles au quotidien. Je ne commente pas beaucoup les posts mais je les lis ;-)

Zer00CooL Le 03 mars 2019 à 5h39

Noter que configurer les VirtualHost d’un serveur VPS ou dédié permet d’accélérer d’avantage le site, que d’utiliser le .htaccess depuis un mutualisé. Le .htaccess reste la dernière couche de configuration de Apache2, mais, si il est possible de la faire depuis la configuration du serveur, dans les VirtualHost, c’est beaucoup mieux.

Zer00CooL Le 05 mars 2019 à 15h04

Maintenant que nous sommes en Apache 2.4, notamment, pour un système Debian Stretch, est ce que les balises sont toujours d’actualité ?

Ne faut t’il pas utiliser (‘uniquement’) DEFLATE ?

# Activer la compression.

SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain

Pour la mise en cache du navigateur, je pense que tu peux mettre à jour sur ce modèle, car, plus lisible.

# Mise en cache du navigateur.

ExpiresActive On
# Mise en cache par défaut du navigateur.
ExpiresDefault « access plus 1 month »
# Images.
ExpiresByType image/gif « access plus 1 year »
ExpiresByType image/jpg « access plus 1 year »
ExpiresByType image/jpeg « access plus 1 year »
ExpiresByType image/png « access plus 1 year »
AddType image/svg+xml .svg
ExpiresByType image/svg+xml « access plus 1 year »
AddType image/x-icon .ico
ExpiresByType image/ico « access plus 1 year »
ExpiresByType image/icon « access plus 1 year »
ExpiresByType image/x-icon « access plus 1 year »
# Structure du site.
ExpiresByType application/xhtml+xml « access plus 1 week »
ExpiresByType text/html « access plus 1 week »
ExpiresByType text/css « access plus 1 week »
ExpiresByType application/javascript « access plus 1 week »
ExpiresByType text/x-javascript « access plus 1 week »
ExpiresByType application/javascript « access plus 1 week »
ExpiresByType application/x-javascript « access plus 1 week »
ExpiresByType application/x-shockwave-flash « access plus 30 days »
# Documents.
ExpiresByType application/pdf « access plus 1 year »
# Polices.
AddType application/vnd.ms-fontobject .eot
AddType application/x-font-ttf .ttf
AddType application/x-font-opentype .otf
AddType application/x-font-woff .woff
ExpiresByType application/vnd.ms-fontobject « access 1 year »
ExpiresByType application/x-font-ttf « access 1 year »
ExpiresByType application/x-font-opentype « access 1 year »
ExpiresByType application/x-font-woff « access 1 year »

Voir mes notes sur Apache2 : https://www.visionduweb.eu/wiki/index.php?title=Installer_Apache2_sur_Debian

Zer00CooL Le 05 mars 2019 à 15h08

La question était, est ce que IfModule mod_gzip.c ne doit pas être remplacé par IfModule mod_deflate.c ?

Les balises ont été nettoyées lors de la publication.
IfModule mod_deflate.c CODE /IfModule
IfModule mod_expires.c CODE /IfModule

Greg Le 04 février 2020 à 0h31

Presque 2 secondes de gagné juste en ayant mis le cache coté serveur !
trop content merci beaucoup pour l’article
bon par contre petit coup de chaud quand j’ai modifié le htaccess

petite question. J’ai déjà ces lignes dans mon fichier htaccess ; cela veut dire que les ETAG sont deja désactivés ainsi que la compression GZIP?

Header unset Etag
FileETag none
AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/x-javascript font/ttf application/x-font-ttf font/otf application/x-font-otf font/opentype image/svg+xml

    Daniel Roch Le 04 février 2020 à 8h33

    Pour les etags, ton htaccess me semble correct. Pour la compression, je pense que le code est incomplet.

blogbo Le 19 janvier 2021 à 16h03

Bonjour et merci pour cet article toujours bien référencé malgré sa datation..je suggère aussi cet article dans lequel l’auteur signale qu’il ne faut pas retirer le Etag, sinon on risque une pénalité..https://robinroelofsen.com/browser-caching-htaccess-apache

blogbo Le 19 janvier 2021 à 17h21

re, je confirme que le lien que j’ai fourni précédemment n’est pas le bon exemple. Ma page web était à 2.7s environ, avec son code, je suis passé presque à 4s, et avec le tien, plutôt 1.7…le code fourni ici est donc toujours valide ! merci encore

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *