Des erreurs 404 sur des fichiers statiques ralentissent la navigation

Lorsque vous accédez à une adresse qui n'existe pas dans WordPress, celui-ci renvoie une erreur 404 « page introuvable » avec le design de votre propre thème, ce qui est logique puisque le visiteur garde ainsi une navigation familière.

Le problème peut survenir lorsqu'une page appelle une image, un CSS ou un JavaScript inexistant et que la configuration du serveur envoie aussi cette requête à WordPress. Cela n'arrive pas sur tous les serveurs : vérifiez d'abord quel processus génère la réponse 404.

Il est utile de comprendre la différence de coût. Dans une configuration qui sert directement les ressources statiques, un fichier existant n'a pas besoin de démarrer PHP ; le temps réel dépend du serveur et du réseau. Un fichier qui n'existe pas tombe dans le routage de WordPress, qui démarre toute l'application, charge les plugins, interroge la base de données et compose la page 404 de votre thème. Dans un cas réel mesuré sur nos serveurs, chacune de ces 404 renvoyait 28 Ko de page générée, alors que la même erreur servie par le serveur web pesait 796 octets.

Si le modèle 404 lui-même redemande la ressource absente, chaque erreur peut générer des requêtes supplémentaires. Pour les relier à une surcharge, vérifiez qu'elles coïncident en heure et en chemin avec la hausse du nombre de processus ou du temps de réponse.

Comment le détecter

Une consommation CPU élevée et plusieurs processus PHP sur index.php sont des indices, pas la cause confirmée. Pour vérifier le lien, consultez le journal d'accès dans cPanel depuis Métriques → Accès bruts (Raw Access).

Cherchez-y la même URL répétée de nombreuses fois. Exemple tiré du cas, avec une adresse et un domaine de documentation :

192.0.2.10 - - [09/Aug/2026:22:36:03 +0200] "GET /wp-content/plugins/popup-maker/dist/packages/block-library-style.css?ver=7424eb959f91acb8bbb2 HTTP/1.1" 404 28113 "-" "WordPress/6.8.7; https://www.mondomaine.com"

Deux détails trahissent le problème :

• L'IP correspond à celle du serveur et l'agent se présente comme WordPress. Dans ce cas précis, il s'agissait d'une requête interne ; dans un autre journal, il faut recouper ces deux données avant de l'affirmer.
• Le code est 404 et la taille était de plusieurs dizaines de kilo-octets. Cette mesure correspondait à la page générée par le thème, mais vous devez vérifier votre propre réponse.

Dans ce cas précis, le site demandait le même CSS inexistant environ six fois par minute, sans interruption pendant des semaines, et finissait par épuiser la limite CPU du compte.

La solution : ne pas laisser WordPress gérer ces 404

La solution principale est de supprimer la référence au contenu inexistant. Si vous avez confirmé que ces requêtes arrivent dans WordPress, la règle suivante sert de filet de sécurité et fait répondre le serveur plus tôt pour les extensions indiquées.

Avant de le modifier, téléchargez une copie du .htaccess actuel pour pouvoir le restaurer si le site renvoie une erreur 500. Pour désactiver la gestion des erreurs 404 sur les fichiers statiques, ajoutez ensuite le bloc suivant :

# BEGIN 404 FICHIERS STATIQUES
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} \.(gif|jpe?g|png|webp|avif|svg|ico|css|js|map|woff2?|ttf|eot)$ [NC]
RewriteRule ^ - [R=404,L]
</IfModule>
# END 404 FICHIERS STATIQUES

Les deux premières conditions laissent passer tout fichier ou répertoire qui existe, de sorte que la règle n'agit que sur ce qui manque. La troisième limite la règle aux extensions de contenu statique et laisse normalement de côté les adresses du site sans extension. Il vaut la peine d'inclure les polices (woff, woff2, ttf, eot) et les source maps (map), qui font partie des sources de 404 silencieuses les plus fréquentes dans un thème.

Où placer le bloc

Cherchez dans le fichier la ligne # BEGIN WordPress et collez le bloc juste au-dessus. Laissez-le en dehors de tout bloc géré automatiquement par un plugin.

Il doit se trouver au-dessus de # BEGIN WordPress parce que c'est précisément ce bloc qui envoie à index.php tout ce qui n'existe pas sur le disque. Si vous le placez après, WordPress aura déjà pris en charge la requête.

Ne le placez pas avant les règles de LiteSpeed Cache : vous pourriez intercepter une URL que le plugin doit réécrire. Comme les blocs varient selon l'installation, testez une image optimisée existante et une URL inventée avant de conserver la modification.

Vérifiez aussi que ErrorDocument 404 ne pointe pas vers PHP. Si vous utilisez ErrorDocument 404 /404.shtml, vérifiez que ce fichier existe, qu'il est statique et qu'il ne repasse pas par WordPress.

Vérifier que cela fonctionne

Après avoir enregistré le fichier, ouvrez ces trois adresses dans votre navigateur en remplaçant mondomaine.com par votre domaine.

1. Votre site, pour écarter une faute de frappe

https://mondomaine.com/

Il doit se charger normalement. Si une erreur 500 ou une page blanche apparaît juste après la modification, restaurez la copie et consultez le journal. Il peut s'agir d'une faute de frappe, d'une directive non autorisée ou d'une interaction avec d'autres règles ; le code à lui seul ne permet pas de distinguer la cause.

2. Un fichier statique qui n'existe pas, avec un nom inventé

https://mondomaine.com/esto-no-existe.css

Il doit répondre avec un code 404 et une page légère servie sans charger le design de WordPress. Son apparence exacte dépend de la configuration du serveur et de ErrorDocument.

Si vous voyez au contraire la page « introuvable » avec le design de votre thème, son menu et son pied de page, vérifiez l'ordre de la règle et ErrorDocument : c'est peut-être ce dernier qui renvoie l'erreur vers PHP.

3. Une page de votre site qui n'existe pas

https://mondomaine.com/esta-pagina-no-existe/

Ici, vous devez continuer à voir la 404 de votre thème, avec son design habituel. La règle n'intercepte que les adresses inexistantes qui se terminent par l'une des extensions indiquées. Si votre application utilise des routes virtuelles avec ces extensions, ajoutez une exclusion spécifique et testez-les avant de conserver la règle.

C'est un filet de sécurité, pas la correction

Le bloc rend l'erreur moins coûteuse, mais l'appel au fichier manquant continue de se produire. Cherchez l'origine avec l'onglet Réseau des outils de développement du navigateur, qui vous indiquera quelle ressource est demandée et d'où.

La colonne Initiateur et le journal permettent de savoir quelle page ou quel composant a demandé la ressource. Ne réinstallez un plugin que si vous avez confirmé que le fichier doit appartenir à ce paquet ; si la référence provient d'un cache, purgez ce cache après l'avoir corrigée.

Pour aller plus loin sur les performances de votre installation, consultez le guide d'optimisation de WordPress et celui de LiteSpeed Cache.

Pour tester une URL inexistante, utilisez aussi des paramètres de requête et des majuscules dans l'extension. Vérifiez tout endpoint virtuel se terminant par .js, .css ou une extension incluse avant de déployer : la règle ne sait pas le distinguer d'un fichier absent. Comparez le code HTTP et la charge avant et après, en gardant la correction de la référence comme tâche principale.