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 :
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 %5EMozilla/4 gzip-only-text/html
BrowserMatch %5EMozilla/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-varyCompression 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 %25{HTTP:accept-encoding} gzip
RewriteCond %25{HTTP_USER_AGENT} !Safari
#make sure there's no trailing .gz on the url
ReWriteCond %25{REQUEST_FILENAME} !%5E.+\.gz$
#check to see if a .gz version of the file exists.
RewriteCond %25{REQUEST_FILENAME}.gz -f
#All conditions met so add .gz to URL filename (invisibly)
RewriteRule %5E(.+) $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 %5Eapplication/javascript$
mod_gzip_item_include mime %5Eapplication/x-javascript$
mod_gzip_item_include mime %5Etext/.*
mod_gzip_item_include mime %5Ehttpd/unix-directory$
mod_gzip_item_include handler %5Ecgi-script$
mod_gzip_item_include handler %5Eserver-status$
mod_gzip_item_include handler %5Eserver-info$
mod_gzip_item_include handler %5Eapplication/x-httpd-php
mod_gzip_item_exclude mime %5Eimage/.*
</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 :
- GIDZip Test (outil indisponible depuis la rédaction de l'article)
- What's my IP Compression test
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 headersInutile 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 HeadersLes 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 noneEt 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 -IndexesLe 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 %5EMozilla/4 gzip-only-text/html
BrowserMatch %5EMozilla/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 -IndexesEn 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.
154 Commentaires
Excellent article ! Va falloir que je teste tout ça. Merci beaucoup ! :)
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
Article très intéressant surtout la partie dédié aux Etags que je ne connaissaient pas du tout.
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.
De même ^ J'ai appris des choses. Merci :)
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.
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..
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.
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.
@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...
Bin tu regardes le fichier apache2.conf, et tu verifies si les fichiers ht* sont inaccessibles pour l'utilisateur
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.
Voilà un article très complet sur le .htaccess
Je l'ajoute dans ma revue de Web ;)
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 ?
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...).
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
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. ;)
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!!
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 !
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 !
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)
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...
@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.
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
@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. ;)
Très bon article. merci pour toutes ces infos :-)
j'ai pas mal galérer pour trouver l'info sur l'expiration des images !
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.
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
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 !)
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.
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.
Il faut chercher une application "minify" pour css (Google is your friend).
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).
Excellent. Merci beaucoup pour ton code Djib's !
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
@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)
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 !!
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.
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
@Billboc : normalement, aucun impact. Mais pour t'en assurer, il suffit de remettre le fichier htaccess initial.
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! :)
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.
@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 ^^ )
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.
@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
Merci,
je posterai si j'arrive à mes fins...
Merci pour cet excellent article !
Excellent article pour optimiser la vitesse de son site. Merci beaucoup.
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...
@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.
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
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 !
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?
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. ;)
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
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 !!
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).
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)
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!
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
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.
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.
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
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 ?
Normalement, ce code issu de WordPress doit être placé après ceux présents dans cet article.
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
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.
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 ?
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.
Exact ! Merci beaucoup.
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 ?
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.
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
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?
Normalement, l'outil en ligne GTMetrix l'indique quand les etags sont mal configurés.
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.
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...
effectivement, pour la seconde, tout est en ordre.
je regarde aussi pour les 404
:)
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
@Fab : cela ne dépend pas du fichier htaccess, mais des plugins de cache.
Justement pour les plugin de cache, j'ai repris ton étude et ait opté pour DB et super cache. Une idée ?
Normalement, ils devraient être mis en cache : regarde sur les pages dédiées à ces plugins pour en savoir plus.
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
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.
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
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) ?
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 ?
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.
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.
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.
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
Merci, je recherchais pour les Expire headers
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.
@Nabil : faites d'abord un essai sans les optimisations du fichier htaccess afin de voir si c'est cela qui pose problème.
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
@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é.
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 :
@Lisa : aurais-tu l'adresse de ton site pour voir d'où peut provenir le problème ?
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 :/
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à ?
C'est le plugin qui l'ajoute pour pouvoir fonctionner. Rien de grave donc à retrouver des codes Htaccess propres au plugin WP Super Cache.
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 !
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
Oui, aucun soucis à ce niveau là. C'est même recommandé. ;)
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 ;)
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?
@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à ?
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.
@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.
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
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
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 :
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
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
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.
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.
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,
Celui dès la connexion ne vous servira pas : utilisez directement le htaccess situé dans le répertoire www.
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
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
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.
Merci pour ta réponse. C'est ce que j'avais fait ;)
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.
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
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 ! :)
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.
@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)
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 !
@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ù.
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.
Bonjour,
Merci pour cet article.
Pourquoi dans les filematch certaines expressions commence par un baclslash et d'autres par 2 ??
Effectivement, le double backslash ne servait à rien. C'est corrigé.
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.
Les effets sont immédiats, et le code est théoriquement compatible et vient en complément de W3 Total Cache
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
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
Il s'agit de deux choses différente, et théoriquement les deux vont très bien ensemble
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 !
;)
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
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).
Merci Daniel :) je vais faire ça. Belle aprem :)
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.
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...
Le même pour nginx ce serais super :)
Il faudrait que je prenne le temps effectivement de donner une configuration nginx pour la performance. Je le note.
@Marc
https://github.com/h5bp/server-configs-nginx
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 ;-)
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.
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
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
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
Pour les etags, ton htaccess me semble correct. Pour la compression, je pense que le code est incomplet.
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
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