On a mesuré un TTFB qui bondit de 180 ms à 1,4 s dans les cinq minutes qui suivent l’activation d’un Web Application Firewall trop agressif. Le site n’avait pas changé. Le déploiement non plus. Juste une règle de filtrage qui décidait d’inspecter chaque requête entrante avant de la laisser passer. On vous dira que sécurité et performance sont deux métiers distincts, qu’il suffit de les mettre autour d’une table. En pratique, quand l’infrastructure réseau étrangle le rendu d’une page, c’est d’abord le trafic organique qui encaisse. Et le diagnostic prend trois fois plus de temps parce que personne ne va regarder du côté des règles iptables quand le LCP est à 4,8 s.
Caméras IP, interphones connectés, portails gérés par API, serveurs internes exposés via reverse proxy : la sécurité d’un foyer ou d’une boutique passe par le réseau. Le piège classique : verrouiller ces flux sans regarder ce que chaque couche de filtrage impose aux pages que Google doit crawler. Un site e-commerce derrière un VPN site-à-site, c’est 150 à 400 ms de latence en plus sur chaque requête HTML.
Le WAF, premier amortisseur de TTFB
Un WAF s’intercale entre la requête HTTP et votre serveur d’origine. Si vous avez opté pour un moteur d’inspection qui reconstruit le corps de la réponse avant de la transmettre, chaque HTML met plus de temps à quitter l’infrastructure. Sur un site à fort trafic organique, la Search Console commence à afficher une dégradation du temps de réponse moyen sous « Statistiques d’exploration ». Le signal n’est pas dans Lighthouse, parce que Lighthouse ne teste que la page finale, pas le chemin complet depuis un bot situé à l’autre bout du monde.
Le pire cas qu’on ait documenté : une boutique en ligne avec inspection complète du corps des réponses JSON. Le panier était géré par un état client persisté en localStorage, mais chaque appel à l’API passait par une couche d’analyse comportementale. Résultat : un INP à 620 ms sur mobile, parce que les micro-tâches JavaScript attendaient des payloads retardés par le filtrage. Le framework n’y était pour rien.
Les WAF modernes proposent un mode « détection seule » ou un filtrage par route. Le filtrage profond a sa place sur les endpoints qui reçoivent des données utilisateur sensibles, pas sur les routes qui renvoient la structure HTML d’une page catégorie. Sur les autres, c’est une latence fixe payée à chaque chargement initial sans gain de sécurité réel.
Un certificat TLS mal chaîné casse le LCP mobile
On a vu un TTFB tomber de 820 ms à 190 ms en réinstallant un certificat intermédiaire manquant. Les clients mobiles passaient par un CDN sans la chaîne complète et déclenchaient une requête AIA bloquée par certains pare-feux opérateurs. Le délai atterrissait dans le « waiting for server response », invisible pour qui ne regarde que Lighthouse.
⚠️ Attention : une autorité de certification mal référencée dans les stores de confiance Android peut générer un temps d’établissement TLS de plus de 500 ms, uniquement pour les utilisateurs mobiles hors Wi-Fi.
Les pare-feux domestiques et la crawlabilité des SPA
L’IoT envahit les maisons, et chaque caméra, thermostat ou assistant augmente la surface réseau partagée avec votre box. Quand vous déployez un site en localhost ou sur un réseau local pour tester le rendu d’une application front, vous utilisez peut-être la même connexion que celle qui héberge ces objets. Certains routeurs grand public traitent le trafic entrant https:// local avec des couches DNAT qui tronquent les headers Accept ou User-Agent d’une manière qui n’arrive jamais en production. Ce biais fausse les mesures de LCP et surtout les tests de crawl mobile : Googlebot mobile s’annonce avec des en-têtes très compacts, et un pare-feu domestique qui les modifie empêche le bot de déclencher le rendu côté client.
Ce n’est pas un scénario de laboratoire. Sur trois side-projects testés depuis un réseau domestique avec un routeur surcouche FAI, le fetch des données JSON destiné au rendu hybride retournait un 401 parce que le pare-feu avait réécrit le Origin. Le SSR servait un fallback HTML vide, la Search Console ne montrait qu’une page blanche.
Le « security score » A+ qui sabote l’indexation mobile-first
Les scanners automatisés de sécurité attribuent des scores. Pour monter à A+, certains administrateurs activent les en-têtes Content-Security-Policy les plus restrictifs : pas de JavaScript inline, pas d’appel à un CDN non listé. Beaucoup de frameworks front modernes injectent pourtant un script inline pour amorcer l’hydratation. Une règle CSP trop agressive l’empêche, et le rendu côté bot meurt en silence : Googlebot ne voit qu’un squelette sans contenu indexable.
Cas réel : un site React en renderToPipeableStream, coquille HTML servie en 230 ms, contenu réel jamais hydraté parce que le CSP interdisait unsafe-inline. Le noscript de repli était vide. Google indexait un titre et une balise meta description. Le « security score » était parfait. Le trafic organique avait chuté de 70 % en quelques semaines, et personne dans l’équipe sécurité ne reliait les deux événements, parce que sur leur dashboard à eux tout allait mieux que jamais.
C’est typiquement le moment où le SEO technique et le RSSI doivent partager la même Search Console. Un CSP, ça se déploie en mode report-only d’abord, on regarde les violations remontées par le rapport, on les croise avec les domaines dont on a besoin pour le rendu, et seulement après on bascule en enforce. Sauter cette étape, c’est livrer un site invisible au bot mobile.
La sécurité réseau ne se limite pas aux ports ouverts, elle inclut la politique de chargement des ressources. Un score A+ qui n’a pas été testé avec le bot mobile via l’outil d’inspection d’URL de la Search Console, c’est un score qui ne reflète rien de la réalité du crawl.
Repenser l’infrastructure pour isoler le trafic critique
Placer les pages à indexer sur un sous-domaine dédié, protégé par un CDN qui ne partage pas les règles de filtrage de l’infrastructure interne, désamorce le problème. Le rendu côté serveur interroge les API métier via un bus interne, le bot ne traverse plus toute la chaîne de défense. Côté code, un state management qui garde la session en mémoire évite les jetons dans le localStorage et donc une couche de filtrage XSS de plus.
💡 Conseil : sur un site qui perd 30 % de crawl après un durcissement réseau, commencez par examiner les en-têtes
Varyet les codes 403 partiels dans les logs. Un seul blocage de polyfill CDN peut faire capoter le rendu du bot.
Questions fréquentes
Un VPN d’entreprise peut-il dégrader le LCP sans qu’on le voie dans les outils classiques ? Oui. Les sauts réseau supplémentaires augmentent le « time to first byte » sans apparaître dans les audits Lighthouse exécutés depuis un serveur proche de l’origine. La dégradation n’est visible qu’en simulant la géolocalisation du bot Google ou en lisant les données de la Search Console. Un test de performance depuis une région distante du datacenter confirmera le diagnostic.
Faut-il désactiver le WAF pour améliorer le INP ?
Pas systématiquement. Le passage en mode « detection only » sur les routes qui ne reçoivent que des GET publics suffit souvent à révéler le coût de l’inspection sur la variabilité de l’INP. L’exclusion d’un chemin du type /api/lire-article de l’inspection profonde réduit le blocage du thread principal sans rouvrir une surface d’attaque pertinente.
Comment savoir si mon routeur domestique filtre le trafic de test ?
Une méthode rapide : un curl avec le header User-Agent de Googlebot envoyé vers l’environnement local. Si le Content-Length ou les headers varient par rapport au même appel depuis un VPS, le matériel intermédiaire altère le trafic. Même les IDE modernes peuvent être paramétrés pour émuler ces conditions via un tunnel, mais la vérification réseau de base suffit généralement.
