Les redirections 301 ralentissent-elles la navigation

[raknal]

Bonjour,

J'apprête à ajouter 250 lignes de redirections 301 dans mon .htaccess
Plus exactement 240 Redirect 301 et 10 RedirectMatch 301

Cela ne risque-t-il pas de ralentir le site web?
Car à chaque surf, Apache doit vérifier chaque URL qui transite en lui???

 

[Wiam]

Bonjour,

250 lignes ? C'est énorme, tu ne peux pas faire ça avec des regex ?

 

[UsagiYojimbo]

Ou gérer ça directement avec PHP ?

 

[longo600]

Il faut faire des essais. j'arrive jusqu'a 1000 lignes parfois d'url unique, normal sur un annuaire de 3 millions d'établissements qui recoit bcp de modifs. Je perçoit un léger ralentissement quand j'atteins cette limite, donc je vide le fichier pour ne laisser que les 200 dernières modifs.

 

[raknal]

Comme j'ai dit: 10 sont en regex
Mais les 240, on ne peut pas faire autrement!

Car il s'agit d'un ancien site statique qui a migré vers Wordpress, aucune logique n'existe pour l'url des 240 faut faire comme ça

 

[UsagiYojimbo]

Plutôt que de balancer tes 200 règles dans un .htaccess, tu fais une table de correspondance où tu stockes, pour chaque enregistrement, l'ancienne et la nouvelle url. Lors de l'appel d'une url, tu fais une requête sur cette table pour savoir si l'url en cours est une ancienne url. Si c'est le cas, tu rediriges en PHP en utilisant le deuxième champ de ta table. mieux vaut éviter de balancer trop de règles dans le htaccess.

 

[FortTrafic]

C'est dommage tu aurais pu faire autrement justement en faisant en sorte que les urls wordpress aient toutes une particularité (exemple un dossier /blog/ ou autre mot clé important du site). Et donc tu aurais pu faire un regex pour que tout ce qui n'a pas cette particularité est dirigé vers un fichier php (sauf la page d'accueil du site par exemple) avec la requete en parametre/argument. ET le .php pouvait se charger de la redirection.
Mais si tu ne contrôles pas non plus la nouvelle version du site, je ne vois pas d'autre moyen que les 250 lignes dans le .htaccess

 

[mojorisin311]

Les utilisateurs ayant parametré des centaines de redirection 301 n'ont pas constaté de lenteur particulière.
Je t'invite à consulter le post suivant : https://www.webrankinfo.com/forum/combien-redirects-possible-dans-fichier-htaccess-t150740.html

 

[Wiam]

Pour le PHP, il faut prendre une chose en compte : l'ordre d’exécution.

Si tu as un CMS ou autre usine à gaz, si tu exécute ton code PHP à la fin du script ou après le traitement d'un code cons"quant, ben tu vas consommé beaucoup de ressources pour rien.

Je te suggère de mettre tes lignes dans un tableau PHP, puis le mettre en place la redirection (le script) tout en haut ^^, ainsi, tu pourras même avoir des centaines de l'url, ça passera en quelques millisecondes seulement .

Si tu as des milliers de lignes, il faut opter pour une base de donnée, puis utiliser APC (mémoire) comme cache, afin d’éviter d'allumer la DB pour rien .

 

[raknal]

J'ai plus de 500 redirections 301 et cela roule bien

Ce que dis un internaute dans le forum que tu m'as dit mojorisin301

Mais j'aimerais avoir encore d'autres feedbacks car je crains vraiment que ça va ralentir.

Pour la solution PHP, oui utiliser un tableau PHP est mieux, largement mieux! Sauf que le site est sous WORDPRESS, je dois le bidouiller!!!! ??

 

[indigene]

Tu fais ça dans la page d'erreur 404 personnalisée, comme ça tu as une seule ligne à mettre dans le htaccess et pour les milliers d'urls qui sont à la nouvelle sauce tu n'auras pas à te poser de questions de redirection.
Et si un jour tu as une ancienne url qui débarque, elle va tomber en 404 et sera redirigée vers la page personnalisée où tu vas commencer par regarder si l'url fait partie de ta liste des urls à rediriger.
Si c'est le cas tu rediriges
Sinon tu laisse s'afficher la page d'erreur personnalisée

 

[UsagiYojimbo]

C'est pas génial de faire une 301 après une 404. Ca n'a aucun sens.

 

[FortTrafic]

Tu fais ça dans la page d'erreur 404 personnalisée, comme ça tu as une seule ligne à mettre dans le htaccess et pour les milliers d'urls qui sont à la nouvelle sauce tu n'auras pas à te poser de questions de redirection.

Ca c'est une bonne idée et c'est la solution je pense, si le serveur ne renvoit pas d'office le code 404 mais laisse faire le fichier PHP de la page 404 personnalisée. Je pense que c'est le cas, donc c'est pour moi la solution, je n'y avais pas pensé, mais je ferai ça après avoir vérifié pour la forme que le serveur ne renvoit pas le code 404 de lui même..

 

[indigene]

C'est pas génial de faire une 301 après une 404. Ca n'a aucun sens.

Ce n'est pas encore une 404 car tu te places avant d'avoir envoyé le header de la page 404 personnalisée.

Et c'est comme ça que tu peux faire de l'urlrewriting chez un hébergeur qui n'a pas activé l'url rewriting (avec des 302 au lieu de 301 par contre)

 

[raknal]

C'est pas génial de faire une 301 après une 404. Ca n'a aucun sens.

Oui ça n'a aucun sens!

J'ai décidé de mettre le site en construction et tout renommer pour suivre une logique afin d'utiliser du regex c'est à dire RedirectMatch 301 dans htaccess!

 

[FortTrafic]

Ce nest pas parce que vous ne comprenezas encore que ca na aucun sens... un peu de modestie, non?
Au moins essayez de verifiez avant de denigrer surtout si au final vous avez tort, ce que je suspecte fortement

Sinon bien sur faire comme jai dit en rendant les urls de wordpress regexables (!!) Afin de cibler celles qui ne rentreront pas dans le cadre, cest le mieux... le coup du faux 404 cest une solution ingenieuse si on ne peut rien changer aux nouvelles urls.

 

[FortTrafic]

Le faux 404 fonctionnerait comme ça :
ErrorDocument 404 /moncode.php

Et dans moncode.php on regarde ce qui était demandé :
$quoi = $_SERVER['REDIRECT_URL'];

Ensuite c'est là que tu aurais eu ta liste de 250 pages, si c'était l'une d'elle alors tu peux renvoyer un 301 :
header("HTTP/1.1 301 Moved Permanently");
header ("Location: http://www.tonsite.com/TaBonneUrlDeRemplacement");

Sinon, tu renvois simplement un code 404 normal et affiche ce que tu veux (une page 404 améliorée avec liens internes du site, boite de recherche, inscription à la newsletter, etc..)
header('HTTP/1.1 404 Not Found');

Par contre si tu veux faire le sioux et ne pas dire à Google que c'est une 301, ni une 404, tu peux lui renvoyer un code 200 OK et puis ensuite afficher une vraie page qui sera différente selon l'url demandée..
header('HTTP/1.1 200 OK');
Et en utilisant la fonction php include() ou cURL même pour aller chercher le contenu ailleurs et l'afficher simplement avec un echo..

Bref avec cette façon, tu peux reporter toute la logique sur le fichier php et ainsi alléger ton htaccess.

 

[zeb]

Comme le dit a juste titre indigene si tu place une règle globale après les traitements classiques dans le htaccess, tu peut intercepter tout ce qui n'est pas "normal pour WP" vers un script qui lui renverra le header que tu veux vers là ou tu veux ...
Après savoir si tu met en base ou tableau, c'est question de perf ça se mesure.

le truc c'est qu'en fin de traitement de ton script il faut prévoir le cas ou rien n'a été fait (url non concordante) et là théoriquement faut envoyer un code 404 vers une page dédiée. bref tu n'as besoins que d'une ligen dans le htacces et contrairement a ce que j'ai pu lire sur le fil ; oui un grand nombre de règles a un impact significatif sur les perfs du serveurs car quand on opère a la racine, c'est le cas pour ce genre de traitement, c'est toutes les ressources qui sont prises en compte ... bref ça fait un sacré volume au final (je parle d'exp. j'ai testé et constaté la différence).

 

[zeb]

Le faux 404 fonctionnerait comme ça :
ErrorDocument 404 /moncode.php

Le souci de cette technique c'est que certains hébergements envoie un code 404 dans tous les cas ... Je l'ai constaté chez free a une époque ça a pu évoluer depuis.

 

[zeb]

le coup du faux 404 cest une solution ingenieuse

Oui ça en revanche c'est pas con dans le principe mais tu peux utiliser l'ordre des règles pour le réaliser sans te "casser la nenette".
Chaque traitement "normal" peut être suffixé avec un [L] pour indiquer qu'après c'est fini et du coup si tu place une règle global derrière elle se prend tout dans la tronche ...
Ce qui d'ailleurs est avantageux car au final une fois les 301 pris en compte cette règle ne sera atteinte que très rarement et les première elles ne sont pas du tout affectées. Donc le traitement "normal" du nouveau site est priorisé et on place au second plan les vieilles urls ...

 

[raknal]

J'ai pas bien analysé et vu que c'est une solution ingénieuse!

Mais comment le mettre en place sur un site sous wordpress comme mon cas! ErrorDocument 404 /blog/test.php ne marche pas, toujours le 404 de WP qui est appelé!

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>
# END WordPress

ErrorDocument 404 /blog/test.php

 

[FortTrafic]

Malheureusement je ne peux pas t'aider avec WordPress car je n'en ai aucun, juste installé un pour développer un plugin.
Mais peut être il faut utiliser son système de 404 personnalisées, donc mettre un fichier 404.php dans ton thème.. Mais ne pas appeler les fonctions header, etc.. de wordpress.. Je ne sais pas si ça fonctionne bien en fait. Là il faut un expert wordpress pour te répondre, ou alors ya google mais bon faut quand même s'y connaître pour arriver à filtrer les pages de réponses

Mais si tu met ton nouveau site dans /blog/ tu n'as plus besoin de faire ça.. Tu peux faire le regex inversé comme tu as dit.

 

[zeb]

Je connais mal Wp mais là ton htaccess renvoie toutes les requêtes sur "/blog/index.php" que tu as du installer dans le dossier "blog".
Vas dans ce dossier ouvre le fichier "index.php" et met ton test d'anciennes url en ligne 2. Tu interviendra donc en amont du traitement Wp via php (n'oublie pas de sortir de la condition avec un exit() une fois le taf réalisé)

 

[Marie-Aude]

Il suffit de modifier le fichier 404.php du thème (ou de le créer) et d'y mettre le code de FortTraffic

 

[Marie-Aude]

Je connais mal Wp mais là ton htaccess renvoie toutes les requêtes sur "/blog/index.php" que tu as du installer dans le dossier "blog".
Vas dans ce dossier ouvre le fichier "index.php" et met ton test d'anciennes url en ligne 2. Tu interviendra donc en amont du traitement Wp via php (n'oublie pas de sortir de la condition avec un exit() une fois le taf réalisé)

Surtout pas. index.php est un fichier du core de wordpress, à ne jamais toucher (d'autant plus que la modif sera écrasée à chaque mise à jour)

 

[zeb]

je suis pas certains qu'avec les conditions la ligne errordocument soit atteinte une seule fois par siècle

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

Je suis même quasi sur du contraire vue que -f -d indique clairement que ce qui ne correspond pas a un fichier ou un dossier doit être traité par "/blog/index.php" et qu'après ça on exit [L]

 

[zeb]

d'autant plus que la modif sera écrasée à chaque mise à jour

Oui dans le principe je partage ton avis sur intervenir sur le core, mais bon si tu le sait et que ça se borne a rajouter un include c'est gérable et de toute façon vue le fichier en question (je l'ai sous les yeux là) je doute qu'une update y change quoi que ce soit.

<span class="syntaxdefault"></span><span class="syntaxkeyword"><?</span><span class="syntaxdefault">php<br /></span><span class="syntaxcomment">/**<br />&nbsp;*&nbsp;Front&nbsp;to&nbsp;the&nbsp;WordPress&nbsp;application.&nbsp;This&nbsp;file&nbsp;doesn't&nbsp;do&nbsp;anything,&nbsp;but&nbsp;loads<br />&nbsp;*&nbsp;wp-blog-header.php&nbsp;which&nbsp;does&nbsp;and&nbsp;tells&nbsp;WordPress&nbsp;to&nbsp;load&nbsp;the&nbsp;theme.<br />&nbsp;*<br />&nbsp;*&nbsp;@package&nbsp;WordPress<br />&nbsp;*/<br /><br />/**<br />&nbsp;*&nbsp;Tells&nbsp;WordPress&nbsp;to&nbsp;load&nbsp;the&nbsp;WordPress&nbsp;theme&nbsp;and&nbsp;output&nbsp;it.<br />&nbsp;*<br />&nbsp;*&nbsp;@var&nbsp;bool<br />&nbsp;*/<br /></span><span class="syntaxdefault">define</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'WP_USE_THEMES'</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">true</span><span class="syntaxkeyword">);<br /><br /></span><span class="syntaxcomment">/**&nbsp;Loads&nbsp;the&nbsp;WordPress&nbsp;Environment&nbsp;and&nbsp;Template&nbsp;*/<br /></span><span class="syntaxkeyword">require(</span><span class="syntaxstring">'./wp-blog-header.php'</span><span class="syntaxkeyword">);&nbsp;</span><span class="syntaxdefault"></span>

C'est juste un contrôleur basique sans rien de vital qui soit impacté par une maj.

 

[Wiam]

Bonjour,

Tout le trafic passe par l'index ... C'est qu'on appelle un peu du MVC, moi je vois deux solution :

1 - Mettre une règle dans le htaccess avant celle de WP, pour rediriger les urls qui commencent par "/xxxxx/xxxx.html" vers un autre fichier PHP. La meilleur solution, ainsi tu ne toucheras pas aux fichier du CMS.
2 - Mettre le code personnalisé en haut de ton fichier index de WP, ou via un petit include... Le probleme sera résolu vite fait bien fait.

 

[Marie-Aude]

je suis pas certains qu'avec les conditions la ligne errordocument soit atteinte une seule fois par siècle

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

Je suis même quasi sur du contraire vue que -f -d indique clairement que ce qui ne correspond pas a un fichier ou un dossier doit être traité par "/blog/index.php" et qu'après ça on exit [L]

Certes, mais WP renvoie le code 404 pour tout ce qu'il n'a pas en base. Donc le fichier 404.php du thème l'endroit où mettre le code (et en plus c'est propre ^^)

 

[zeb]

Donc le fichier 404.php du thème l'endroit où mettre le code (et en plus c'est propre ^^)

+1 c'est pas faut et ça évite le traitement obligatoire en amont de WP qui reste ainsi en traitement frontal.
Sinon pour les updates c'est pareil mais vis a vis du thème (si on met de côté les thèmes enfants que tu m'a habilement conseillé sur un autre sujet)

Sinon il y a aussi la solution de dériver WP et de le re-pluguer par derrière.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /old-site.php [L]

old-site.php :
if(....){ gestions de 301 }else{include('./blog/index.php');}

 

[Marie-Aude]

Dans ces cas là c'est à mettre avant ou après le bloc #begin wordpress #end wordpress

 

[zeb]

qui sera donc jamais atteint ... (logiquement :?: )

 

[Marie-Aude]

Tu as raison

Donc à éviter, car WordPress peut modifier ce blog, lors de réglages sur les permaliens...

 

[raknal]

En gros, il n'y a pas de solution sûre pour Wordpress

Pour la page 404.php de WP, quand on y arrive, le code 404 a déjà été envoyé en requête HTTP donc ce n'est pas la solution.

Pour l'édition du fichier htaccess, oui il faut mettre le traitement avant #BEGIN Wordpress
Oui ça marche pour "Redirect 301"

Mais par curiosité, si c'est juste du "Url Rewriting" que je cherche à faire ça ne marche pas, puisque c'est la section après #BEGIN Wordpress qui sera prioritaire!

 

[UsagiYojimbo]

Pour Wordpress il y a le plugin Redirections.

 

[raknal]

Oui je connais ce plugin

Mais tant qu'on peut se passer d'un plugin, on va coder, c'est léger pour le site.

 

[zeb]

De toute façon plu j'y pense plu je trouve que le htaccess de Wp est mal fichu. Comme beaucoup le font il prend pour règle que toutes les urls qui n'existent pas sont a traiter par le frontal de WP hors il y a 1000 raisons y compris avec WP pour que tu ai envie de traiter autre chose autrement. par exemple si tu mixe 2 CMS "comme" ici WP + PhpBB ...

Bref a mon humble avis je pense que la solution de détourner le frontal de WP depuis le htaccess est la solution la plus propre (entendu que tu ne veux pas lister toutes tes urls dans le hatccess) car c'est juste une ligne pour t'ouvrir la porte a un traitement php et ensuite si tu n'est pas concerné (url légitime WP) bah tu lui rend la main ...

l'impact sur le htaccess est tellement minime que pour un site en production qu'on est pas en train de bidouiller toutes les 5mn ça peut se justifier.