À 9 h 40, le trafic augmente de 30 %. Le temps propre du contrôleur varie peu, mais le premier octet passe de 420 ms à 2,6 secondes. Le pool de connexions est plein, des requêtes attendent un worker et les timeouts arrivent par vagues. À 10 h 15, les pages répondent de nouveau : la moyenne quotidienne effacera presque l’incident.
Cette séquence décrit une saturation de l’origine. Une ressource limitée atteint sa capacité, une file se forme, puis chaque requête reste plus longtemps dans le système. Même le travail normalement rapide devient lent parce qu’il attend avant de commencer.
Le vrai enjeu est de relier ce mécanisme à trois expériences distinctes : l’attente visible dans le TTFB, les erreurs subies par les visiteurs et la diminution possible des explorations lorsque les crawlers rencontrent trop de réponses 5xx ou 429. Aucun de ces signaux ne suffit isolément.
La méthode suit la demande de l’edge aux dépendances, avec notre accompagnement en SEO technique. Contrairement à ce que suggère un CPU moyen encore modéré, une origine peut déjà être saturée si son pool de base, ses workers ou une API tierce constituent le goulet.
Reconnaître la signature d’une origine saturée
La saturation combine demande, capacité et temps de service. Quand les arrivées approchent durablement du débit maximal, la file devient sensible aux petites variations. Le percentile haut et le nombre de requêtes en vol se dégradent avant que la moyenne CPU ne paraisse totalement occupée.
Chercher des signaux concordants
Les signaux comprennent file de workers, attente du pool SQL, connexions actives, backlog du load balancer, durée des dépendances, timeouts, 502, 503, 504 et refus de connexion. Leur horodatage est rapproché du débit et des releases.
Une hausse de TTFB sans croissance de file peut venir d’un traitement plus lent. Une file sans hausse de trafic peut venir d’une dépendance qui immobilise les workers. La signature complète évite de commander des serveurs avant d’avoir identifié la contrainte.
Comparer état sain et état dégradé
Le même gabarit, la même cardinalité et le même état de cache sont comparés avant, pendant et après. La release, la région et le statut d’authentification accompagnent le segment.
La reprise est informative : si la file se vide lentement après la baisse du trafic, la capacité de récupération est faible. Un système qui reste dégradé après le pic peut conserver des requêtes bloquées, un circuit ouvert ou un cache froid.
Distinguer service lent et attente avant service
Le temps de réponse d’une requête comprend l’attente et le service. L’application peut mesurer 180 ms de code alors que le client attend deux secondes, parce que 1,5 seconde s’écoule avant l’attribution d’un worker ou d’une connexion.
Instrumenter les points d’admission
Le proxy date arrivée, admission et départ. Le runtime mesure attente de worker. Le pool SQL mesure acquisition et durée d’usage. Les appels externes distinguent file locale, connexion et réponse.
Les horloges et identifiants de trace permettent un rapprochement. Si une couche ne sait pas mesurer son attente, l’équipe utilise une estimation et l’étiquette ; elle ne l’attribue pas au temps applicatif.
Observer la loi de croissance
Le test augmente le débit par paliers. Avant saturation, le TTFB progresse modérément. Près du plafond, la file et les percentiles s’infléchissent. Après le plafond, erreurs et timeouts limitent artificiellement les requêtes achevées.
Le nombre de réponses par seconde ne doit donc pas être lu seul : il peut se stabiliser parce que le service rejette une partie de la demande. Le volume offert, accepté, achevé et refusé est conservé.
Décomposer le TTFB de l’edge à l’application
Le TTFB côté navigateur couvre résolution, connexion, demande et attente du premier octet. Un CDN peut répondre directement ou transmettre à l’origine. Le rapport sépare donc hit edge, hit shield et miss complet avant d’interpréter l’application.
Publier des durées contrôlées
Server-Timing peut exposer des mesures telles que edge, queue, app et db. La spécification W3C fournit une syntaxe et une interface pour communiquer ces métriques. Les noms restent courts et aucune information d’infrastructure sensible n’est révélée.
Navigation Timing fournit les jalons observés par le navigateur, dont début de requête et début de réponse. Le RUM rapproche cette expérience des durées serveur, avec une couverture et un échantillonnage documentés.
Garder le chemin froid visible
Le cache réduit volontairement la demande origine. Une sonde protégée mesure un petit corpus en bypass contrôlé, tandis que le trafic public conserve le bénéfice du cache. Le bypass n’est jamais une query string ouverte à tous.
Une baisse du TTFB edge peut masquer une hausse du TTFB origine. Les deux résultats sont utiles : l’expérience s’améliore, mais la dette backend doit encore être traitée avant la prochaine tempête de misses.
Mesurer le crawl sans inventer de causalité
Google indique que ses systèmes réduisent la cadence d’exploration lorsqu’ils rencontrent un nombre significatif d’URL en 500, 503 ou 429, afin de ne pas surcharger le serveur. Une réduction prolongée signifie moins de découvertes et des actualisations plus lentes ; elle ne doit pas être confondue avec une sanction.
Croiser logs et Search Console
Les logs montrent requêtes de crawlers, statuts, latence, octets et gabarits. Les identités de robots sont validées selon le mécanisme officiel plutôt que par le seul user agent. Les statistiques disponibles dans Search Console complètent la tendance agrégée.
Le rendu SSR et son JavaScript d’hydratation sont distingués dans la trace : le premier porte l’indexation et le HTML initial, tandis que le second ne doit pas masquer une erreur origine. La CI contrôle aussi l’invalidation puis la revalidation du cache sur le gabarit critique.
Une baisse de hits peut provenir de saisonnalité, d’un changement d’URL, de robots non vérifiés ou de la demande de crawl. Le rapport sépare fait — moins de requêtes observées — et interprétation — la saturation en est une cause probable.
Éviter le faux 200
Lorsqu’une page ne peut pas être produite, servir un document vide avec 200 cache une panne aux visiteurs et aux moteurs. Le statut doit représenter le résultat. Un 503 temporaire et, lorsque pertinent, un Retry-After cohérent valent mieux qu’un succès trompeur.
Les erreurs répétées sur plusieurs jours peuvent nuire à la présence des URLs selon la documentation Google. Le mode dégradé vise donc à conserver une réponse utile, pas à prolonger indéfiniment une indisponibilité.
Identifier les gabarits qui consomment la capacité
Une moyenne par serveur ne dit pas quelles pages provoquent la file. Les traces regroupent route normalisée, gabarit, cardinalité, cache et dépendances. Le coût unitaire est multiplié par le débit pendant les fenêtres critiques.
Relier consommation et valeur
Une fiche produit coûteuse mais très cacheable peut peser moins sur l’origine qu’un endpoint léger appelé à chaque interaction. Le classement combine temps CPU, durée SQL, connexions occupées, fréquence de misses et volume.
Le SEO ajoute nombre d’URL, impressions, entrées organiques et profondeur. Une page rare mais très lente peut révéler une dette ; une catégorie très demandée peut créer le pic. Les deux reçoivent des priorités différentes.
Trouver les amplificateurs
Requêtes N+1, fan-out d’API, transformations à la volée, pagination profonde et sessions verrouillées augmentent le temps de service. Une purge ou une clé fragmentée augmente simultanément la fréquence d’accès.
La file résulte souvent de cette combinaison : plus de demandes et moins de capacité par seconde. Le plan traite les deux côtés au lieu d’opposer cache et code.
Construire un modèle de capacité exploitable
Le modèle définit une unité de travail : une réponse de gabarit à cardinalité donnée et cache froid. Il mesure débit soutenable, temps de service, concurrence, ressource limitante et marge avant le seuil de dégradation.
Distinguer plafond et cible opérationnelle
Le maximum observé juste avant l’effondrement n’est pas une cible. L’exploitation garde une marge pour variabilité, failover, maintenance et pics. Le SLO fixe percentiles et erreurs acceptables à un débit donné.
Une réplication ou un autoscaling n’est utile que si la ressource limitante suit. Ajouter des workers devant une base déjà saturée peut augmenter la file SQL et aggraver les timeouts.
Prévoir les scénarios combinés
Le plan couvre trafic métier, crawl, publication, cache froid et perte d’une instance. Chacun consomme une part de capacité. Une release acceptable en régime normal peut échouer pendant une purge.
Les prévisions sont mises à jour avec les mesures réelles. La marge est un indicateur versionné, pas un nombre figé dans une présentation.
Choisir cache, optimisation, quotas ou délestage
Le cache réduit le débit qui atteint l’origine. L’optimisation réduit le temps de service. Les quotas limitent une classe de demande. Le délestage rejette ou dégrade proprement avant que toutes les requêtes n’échouent.
Prioriser le goulet prouvé
Si l’attente SQL domine, corriger les requêtes ou le pool vient avant d’ajouter du PHP. Si les misses simultanés dominent, shielding, coalescence et préchauffage peuvent rendre de la marge. Si une API tierce bloque les workers, timeout et circuit breaker sont prioritaires.
Le bon arbitrage associe chaque action à un signal attendu. « Ajouter du cache » n’est pas un plan sans liste d’objets, clé, TTL, fraîcheur et mesure de misses.
Dégrader sans mentir
Le mode dégradé peut retirer une recommandation, servir un fragment stale autorisé ou reporter un calcul non critique. Il conserve titre, offre, navigation et statut exact. Un élément contractuel ne devient pas approximatif pour sauver un score.
Le délestage donne la priorité aux parcours essentiels selon une règle publique et testée. Il n’identifie pas Googlebot pour lui servir un contenu artificiellement privilégié.
Instrumenter files, dépendances et statut HTTP
La télémétrie part de l’admission. Chaque couche publie file, concurrence, durée et résultat. Les traces suivent les dépendances ; les métriques agrègent le système ; les logs expliquent un événement précis.
Limiter la cardinalité
Les labels acceptés sont route normalisée, gabarit, release, région, état cache et classe de statut. URL complète, identifiant utilisateur et query string ne deviennent pas des labels de métriques.
La journalisation échantillonnée garde un identifiant de trace, des empreintes et des durées. Les paramètres sensibles sont masqués. Le taux d’échantillonnage augmente temporairement pendant un canari sans saturer l’observabilité.
Rendre l’alerte actionnable
Une alerte combine file, TTFB, erreurs et débit. Elle indique le gabarit dominant, la dépendance suspecte et le run de changement. Un seuil isolé sur le CPU ne suffit pas.
Le monitoring possède une mesure de couverture. Une panne de collecte ne doit pas produire un faux état vert ; elle déclenche une alerte distincte.
Tester charge, montée et récupération
Le test de capacité augmente le débit par paliers suffisamment longs pour stabiliser les files. Il utilise des gabarits et cardinalités représentatifs, avec un mélange contrôlé de hits et de misses.
Mesurer la courbe complète
Chaque palier relève demandes offertes, acceptées, achevées et rejetées, puis TTFB, files, ressources et erreurs. Le test s’arrête avant de menacer des systèmes partagés.
Après la montée, le débit diminue et la durée de récupération est mesurée. Une file qui ne se résorbe pas révèle un risque opérationnel absent d’un simple test de pointe.
Tester les défaillances
Une dépendance lente, un pool réduit, une instance perdue et une purge contrôlée sont injectés en environnement autorisé. Le système doit respecter timeouts, quotas, circuit breaker et mode dégradé.
Le test vérifie aussi l’arrêt : les générateurs de charge cessent, les files reviennent à zéro et le cache ne conserve pas d’erreur au-delà de la politique.
Répondre à l’incident sans servir un faux succès
L’incident commence par protéger le service : suspendre une publication, réduire une tâche non critique, activer un mode dégradé ou limiter une source abusive. La modification est petite, réversible et tracée.
Utiliser les statuts correctement
Une indisponibilité temporaire peut répondre 503 ; une limitation peut répondre 429 selon le cas. Retry-After indique quand une nouvelle tentative est souhaitée lorsque le serveur peut fournir une estimation. Le choix suit la sémantique HTTP, pas une astuce SEO.
Le site ne bloque pas sélectivement les crawlers pour conserver les visiteurs sans analyser l’effet. Google prévient qu’une réduction de crawl affecte le hostname et qu’un usage prolongé d’erreurs peut avoir des conséquences.
Conserver la chronologie
Début de file, première erreur, décision, effet et retour à la normale sont horodatés. Les changements de configuration et purges rejoignent la timeline.
Le post-incident identifie le facteur déclencheur, le goulet et l’absence de garde-fou. Il ne conclut pas « trop de trafic » lorsque la capacité réelle n’a pas été mesurée.
Décider depuis un cas entièrement simulé
Cas concret entièrement simulé : une origine fictive tient 180 requêtes par seconde avec un TTFB p75 de 480 ms. Une purge de catalogue fait monter la demande fictive à 260 requêtes par seconde ; le pool SQL atteint sa limite, la file dépasse 900 demandes et 6 % des réponses deviennent 503. Dans ce scénario, le seuil d’arrêt impose le délestage ; ces nombres ne décrivent aucun client.
Identifier les deux amplificateurs
Les traces simulées montrent des catégories N+1 à 44 requêtes SQL et des misses simultanés depuis huit régions. Un chargement groupé réduit le temps de service ; un shield mutualise les demandes identiques. Les deux leviers sont testés séparément puis ensemble.
Après correction fictive, l’origine soutient 280 requêtes par seconde à p75 540 ms et le pic réel n’en transmet plus que 110. La marge augmente sans prétendre rendre le backend infiniment rapide.
Définir les seuils
Le canari s’arrête si la file dépasse le seuil simulé de 200 pendant deux minutes, si le p75 franchit 750 ms après le volume minimal ou si les 5xx dépassent 0,5 %. Dans ce cas, le repli restaure le lecteur SQL et la topologie précédente.
Les logs simulés de crawl sont comparés avant et après sans conclure à un gain de classement. Ils vérifient seulement la réduction des erreurs et la reprise des requêtes observées.
Répartir les responsabilités opérationnelles
Le SRE possède capacité, alertes et incident. Les équipes applicatives réduisent temps de service et fan-out. L’équipe CDN maîtrise clés, purges et shield. Le SEO identifie les gabarits et interprète les signaux de crawl.
Rendre la reprise autonome
Le runbook indique comment reconnaître le goulet, activer le mode dégradé, vérifier le statut public et revenir en arrière. Une personne étrangère au correctif le rejoue avant la release.
La méthode convient aux sites dynamiques dont le trafic et le cache varient. Un site statique peut appliquer le volet CDN, mais n’aura pas les mêmes files applicatives.
Éviter les diagnostics qui masquent la file
La première erreur surveille seulement CPU et mémoire. Le pool de connexions ou les workers peuvent saturer avant eux. La seconde mesure uniquement les requêtes achevées et oublie celles qui ont été refusées ou ont expiré.
Ne pas tester avec un cache irréaliste
Un cache toujours chaud masque l’origine ; un cache toujours froid surestime un régime rare. Le scénario reproduit la distribution observée et contient un test froid séparé.
Une autre erreur augmente les timeouts. La file grossit alors et retarde davantage les demandes sans ajouter de capacité. Le timeout doit être cohérent avec le budget et le repli.
Ne pas déclarer une perte SEO sans preuve
Une baisse de crawl simultanée aux erreurs soutient une hypothèse, mais d’autres facteurs existent. Les faits, l’interprétation et la conséquence métier sont écrits séparément.
Enfin, servir 200 avec une coquille vide ne protège rien. Il détruit la qualité de la réponse et brouille la reprise.
Plan d’action : retrouver une marge en trois semaines
Le pilote retient deux gabarits exposés, une fenêtre de pic et un scénario de cache. Application, base, plateforme, CDN, SEO et QA partagent la même timeline.
Semaine 1 : instrumenter la file
L’équipe mesure admission, attente worker, pool SQL, dépendances, application et TTFB. Elle segmente routes, cardinalité, cache et statuts. Les logs de crawl sont validés et agrégés sans donnée personnelle.
Le test par paliers localise l’inflexion et le goulet. Le modèle de capacité fixe une cible sous le plafond, avec marge pour purge et perte d’instance.
Semaine 2 : réduire demande et temps de service
Une action de chaque côté est testée : clé ou shield pour la demande, requête ou dépendance pour le service. Le mode dégradé, les quotas et statuts sont vérifiés sous panne.
Les entrées sont débit, gabarit, cache et release ; les sorties sont file, TTFB, erreurs et capacité. Les responsabilités, dépendances, instrumentation, monitoring et journalisation accompagnent chaque seuil.
Semaine 3 : canari et exercice d’incident
Le canari ouvre un gabarit, atteint le volume minimal et vérifie marge, contenu, statut et récupération. Une purge contrôlée puis une dépendance lente testent le runbook.
Dans les faits, la généralisation exige une baisse de file au débit cible, un TTFB conforme et aucune hausse d’erreur. Le rollback restaure code et configuration ; l’observabilité confirme que la file se vide.
- Mesurer attente et service à chaque couche.
- Classer les gabarits par coût, débit et valeur SEO.
- Réduire à la fois demande origine et temps de traitement.
- Tester montée, panne, délestage et récupération.
- Généraliser avec marge, seuils et statuts exacts.
Guides complémentaires et sources primaires
Les références suivantes établissent la mesure, la sémantique des réponses et le comportement déclaré du crawler. Elles ne remplacent pas les logs et la capacité propres au système.
Vérifier performance et protocoles
Les spécifications W3C Navigation Timing Level 2 et Server Timing décrivent les jalons client et les métriques communiquées par le serveur. La RFC 9110 définit notamment 503 et Retry-After.
Google documente comment les erreurs 500, 503 et 429 influencent la cadence de ses crawlers. La ressource web.dev sur l’optimisation du TTFB replace hébergement, CDN et backend dans le même délai.
Traiter les causes voisines
Le diagnostic des requêtes N+1 et du TTFB réduit le temps de service applicatif. L’origin shielding CDN agit sur les demandes redondantes sans supprimer le besoin de mesurer l’origine.
- Mesurer le débit offert, pas seulement les réponses achevées.
- Distinguer attente de file et temps de service.
- Employer les statuts HTTP conformément au résultat réel.
Conclusion : piloter la marge avant la panne
La saturation ne commence pas au premier 503. Elle commence lorsque la marge diminue et que la file rend les percentiles sensibles au moindre pic.
Décomposer le TTFB révèle l’attente cachée. Classer les gabarits relie cette attente à la demande métier et aux parcours organiques sans inventer de causalité SEO.
Cache, optimisation, quotas et délestage répondent à des mécanismes différents. Les tests de montée et de récupération prouvent qu’ils rendent réellement de la capacité.
Pour cartographier vos files, dimensionner la marge et protéger visiteurs comme crawl pendant les pics, notre accompagnement en SEO technique transforme TTFB, traces et logs en décisions opérationnelles vérifiables.
