Pourquoi et comment j’ai migré les redirections de WordPress vers Cloudflare

Récemment, j’ai écrit sur la façon dont mon site avait été attaqué et comment j’ai finalement migré vers Cloudflare pour mettre fin au barrage de trafic de robots. Le trafic des robots détruisait également les performances de mon site car il frappait ce qui semblait être un nombre infini de sites inexistants. URL chemins, montée requêtes de redirections génériques cela n’allait jamais fonctionner.

Comment les redirections WordPress impactent les performances

Lors du dépannage de la mémoire et Processeur utilisation et résolution des problèmes, j’étais toujours surpris par les ressources consommées par les redirections statiques. Ensuite, j’ai commencé à analyser le processus nécessaire pour qu’une URL qui n’existe pas soit traitée par mon serveur :

1. Entrant HTTP demande: Le serveur Web reçoit une demande d’URL et effectue ses vérifications les plus élémentaires, notamment SSL négociation, correspondance d’hôte virtuel et existence de fichiers statiques. Si le fichier demandé existe physiquement sur le disque, comme une image, CSS fichier, ou statique HTML fichier, il est servi immédiatement sans invoquer WordPress.
2. Règles de réécriture au niveau du serveur Web : Si aucun fichier statique n’existe, le serveur évalue les règles de réécriture et de redirection définies au niveau de la couche serveur, telles que les directives de réécriture Nginx ou les règles Apache mod_rewrite dans .htaccess. Les redirections traitées ici sont terminées avant PHP ou WordPress est chargé, ce qui en fait l’option la moins gourmande en ressources.
3. Bootstrap PHP et chargement WordPress : Si aucune règle au niveau du serveur ne résout la demande, le serveur achemine la demande vers index.phpdéclenchant l’exécution de PHP et le processus d’amorçage de WordPress. À ce stade, les fichiers WordPress principaux sont chargés, les plugins sont initialisés et l’utilisation de la mémoire et du processeur augmente de manière significative.
4. Requête analysée et résolution des requêtes : WordPress analyse l’URL demandée pour déterminer si elle correspond à une publication, une page, un type de publication personnalisé, une taxonomie ou un autre point de terminaison de réécriture enregistré. Ce processus implique plusieurs requêtes de base de données sur les tables de publications, de termes et d’options.
5. Recherche de redirection via des plugins ou des hooks principaux : Si l’URL demandée ne correspond pas à un contenu valide, WordPress vérifie la logique de redirection enregistrée. Cela peut inclure des redirections canoniques de base, un code de redirection personnalisé ou des plugins de redirection qui interrogent leurs propres tables de base de données ou règles mises en cache pour trouver une URL source correspondante.
6. Évaluation du cache de redirection : Les systèmes de redirection bien implémentés vérifient d’abord les caches en mémoire ou les caches d’objets, puis reviennent aux recherches dans la base de données uniquement si nécessaire. Les plugins de redirection mal optimisés peuvent exécuter plusieurs requêtes de base de données à chaque échec, aggravant ainsi la charge du serveur sur les sites à fort trafic.
7. Réponse de redirection émise : Si une redirection correspondante est trouvée, WordPress envoie le code d’état HTTP approprié, tel que 301 ou 302et arrête la suite du traitement. La requête se termine ici, mais seulement une fois que les ressources WordPress et PHP ont déjà été consommées.
8. Détermination 404 : Si aucune règle de redirection ne correspond, WordPress marque la requête comme 404 et prépare la réponse d’erreur. Cela nécessite toujours une exécution complète de WordPress, y compris le chargement du thème et la résolution du modèle.
9. Rendu du modèle 404 : Le modèle 404.php du thème actif est chargé, ainsi que tous les actifs, hooks, widgets ou scripts de suivi associés. Même si la page affiche pas trouvé contenu, il s’agit souvent de l’un des résultats les plus gourmands en ressources en raison du rendu en pleine page.
10. Livraison de la réponse : La réponse HTML finale est renvoyée au navigateur, complétant ainsi le cycle de vie de la requête. Du point de vue du serveur, ce chemin représente le scénario de coût maximum pour une seule URL non résolue.

Pour tout site qui a été migré, dont les permaliens ont été restructurés ou qui est simplement un ancien site… les redirections sont essentielles pour l’expérience utilisateur et pour maintenir l’autorité des backlinks vers les pages pertinentes pour Référencement. Lorsque les redirections sont gérées dans WordPress, le serveur est obligé de faire beaucoup plus de travail que la plupart des propriétaires de sites ne le pensent. Chaque URL non résolue nécessite le démarrage de PHP, le chargement du noyau WordPress, l’initialisation des plugins et l’exécution de plusieurs requêtes de base de données avant même qu’une décision de redirection ne soit prise.

Sur un site très fréquenté, cela signifie que les cycles du processeur, la mémoire et les connexions à la base de données sont consommés pour indiquer au navigateur d’aller ailleurs. Multipliez ce coût par des milliers d’URL héritées, de liens mal saisis, de trafic de robots et de backlinks externes, et les redirections deviennent discrètement un handicap mesurable en termes de performances et de stabilité.

Pour mettre les choses en perspective, Martech Zone approche ses 20 ans avec de multiples changements de domaines, de migrations et de structures de liens permanents, ainsi que des milliers de liens d’affiliation pour lesquels j’utilise des redirections. j’ai amassé plus de 6 100 redirections ! En conséquence, le majorité des ressources de mon serveur ont été dépensées en redirections plutôt qu’en présentation du contenu réel.

Pourquoi migrer les redirections hors WordPress et vers votre serveur

Le déplacement des redirections vers la couche serveur élimine presque toute cette surcharge. Lorsque Nginx ou Apache traitent une redirection, la décision se produit avant que PHP ne soit invoqué et avant le chargement de WordPress. Il n’y a pas de requêtes de base de données, pas d’exécution de plugin et pas de rendu de thème. Le serveur évalue une règle simple, renvoie une réponse 301 ou 302 et ferme la requête.

Cela réduit le temps d’accès au premier octet (TTFB), réduit la charge de PHP et de la base de données et préserve les ressources WordPress pour les requêtes qui nécessitent réellement du contenu dynamique. En termes pratiques, les redirections au niveau du serveur évoluent mieux, répondent plus rapidement et réduisent le rayon d’action des pics de trafic, des robots d’exploration, des robots et des liens rompus. Pour tout site soucieux de performances, de fiabilité ou de rentabilité, les redirections appartiennent aussi près que possible du serveur Web, et non enfouies dans la couche application.

Avec VolerGrâce à l’intégration Cloudflare de Cloudflare, Cloudflare agit comme une passerelle pour tout le trafic, et pas seulement pour les ressources statiques, comme dans une configuration CDN typique. Du coup, Cloudflare était la solution parfaite pour migrer mes redirections. Désormais, le plugin de redirection n’utilise aucune ressource pour interroger et mettre en cache les redirections dans WordPress… Cloudflare gère tout.

Comment migrer les redirections vers Cloudflare

Parce que j’avais migré mon CDN à Flare nuageuse pour remédier à l’attaque du robot, j’ai fait des recherches et découvert qu’ils disposaient d’un moteur de redirection robuste qui permettait le téléchargement groupé de redirections. Le processus de migration des backlinks n’était pas simple, je souhaite donc le documenter ici au cas où vous souhaiteriez le faire également :

1. J’ai exporté mes redirections statiques (pas de caractère générique ou d’expression régulière) depuis Classement mathématique dans un CSV déposer.
2. Importé le CSV dans Règles > Règles de redirection > Accédez aux redirections groupées.

Source link