Débogueur Chrome DevTools
Workflow général (ordre obligatoire)
Naviguer → Attendre chargement → Inspecter (snapshot) → Agir → Vérifier
- Naviguer vers la page cible (
navigate avec URL complète incluant le protocole).
- Attendre que la page soit stable (réseau idle,
DOMContentLoaded).
- Lister les pages disponibles si plusieurs onglets, sélectionner le bon
targetId.
- Snapshot de la structure (arbre d'accessibilité) — donne les identifiants uniques pour les interactions.
- Agir selon le besoin : clic, saisie, scroll, exécution JS.
- Vérifier le résultat : snapshot diff, console, capture si visuel requis.
Scénarios courants
1. Erreurs JavaScript
naviguer → snapshot → getConsoleMessages → evalScript
- Récupérer les messages console filtrés sur
level: error.
- Identifier le fichier et la ligne dans la stack trace.
- Exécuter du JS pour inspecter l'état en direct :
// Exemples copiables dans evalScript
document.querySelectorAll('[data-error]').length
window.__reactFiber !== undefined // détecter React
performance.getEntriesByType('resource').filter(r => r.duration > 1000)
- Si l'erreur est
Cannot read properties of undefined : vérifier le timing (race condition) avec document.readyState.
2. Problèmes réseau
naviguer → getNetworkRequests → filtrer → analyser
Filtres prioritaires :
| Symptôme |
Filtre à appliquer |
| Page blanche / données manquantes |
status >= 400 |
| Lenteur |
duration > 2000ms |
| Erreur CORS |
blocked: true, header Access-Control-Allow-Origin absent |
| CSP violation |
messages console de type Content Security Policy |
| Waterfall lent |
requêtes séquentielles au lieu de parallèles |
Snippet de diagnostic réseau via evalScript :
// Ressources lentes (> 1s)
performance.getEntriesByType('resource')
.filter(r => r.duration > 1000)
.map(r => ({ name: r.name, duration: Math.round(r.duration) }))
3. Analyse de performance
naviguer → startTrace → déclencher l'action → stopTrace → analyser
Points à identifier dans la trace :
- Long Tasks (> 50 ms) : bloquent le thread principal.
- Layout thrashing : alternance forcée lecture/écriture DOM en boucle.
- Repaints excessifs : vérifier
will-change, layers composites.
- Time to Interactive (TTI) : si > 3,8 s, chercher les scripts bloquants.
Snippet pour identifier le layout thrashing :
// Propriétés qui forcent un reflow
const reflow_props = ['offsetHeight','offsetWidth','clientHeight',
'scrollTop','getBoundingClientRect']
// Chercher dans le code source les lectures de ces props dans une boucle
4. Automatisation d'interactions
snapshot → récupérer nodeId → click/type/scroll → snapshot de vérification
Règles d'or pour les interactions fiables :
- Toujours utiliser le
nodeId issu du snapshot, jamais un sélecteur CSS deviné.
- Attendre un indicateur de stabilité après chaque action (snapshot qui ne change plus, network idle).
- Pour les formulaires :
type sur le champ → click sur le bouton submit → vérifier navigation ou message de confirmation.
Critères de décision : quel outil utiliser
| Besoin |
Outil |
Raison |
| Trouver un élément pour interagir |
snapshot |
Retourne les nodeId uniques, léger |
| Vérification visuelle (rendu, layout) |
screenshot |
Seul moyen de voir le rendu réel |
| Données hors arbre d'accessibilité |
evalScript |
Accès direct au DOM/window |
| Analyser erreurs runtime |
getConsoleMessages |
Messages filtrables par niveau |
| Diagnostiquer la lenteur réseau |
getNetworkRequests |
Timing, status, headers |
| Mesurer perf (LCP, TTI, FPS) |
startTrace / stopTrace |
Profil complet du thread principal |
Garde-fous et anti-patterns
Ne jamais faire
- Screenshot systématique — coûteux en tokens, inutile pour le débogage structurel. Réserver au besoin visuel explicite.
- Interagir sans snapshot préalable — les sélecteurs CSS peuvent pointer sur plusieurs éléments ; les
nodeId sont uniques.
- Ignorer l'ordre naviguer→attendre→inspecter — un snapshot trop tôt capture une page incomplète.
- Lancer une trace sur une page déjà chargée — démarrer la trace avant l'action à mesurer.
- evalScript avec
document.write — détruit le DOM existant.
Pièges fréquents
| Piège |
Symptôme |
Solution |
| SPA (React/Vue/Angular) |
snapshot vide ou partiel |
Attendre l'hydratation ; chercher [data-reactroot] ou #app |
| iframes |
éléments introuvables |
Changer de targetId sur l'iframe |
| Shadow DOM |
nodeId absent |
evalScript avec shadowRoot.querySelectorAll |
| Auth / cookies |
redirections inattendues |
Vérifier cookies via evalScript(document.cookie) avant navigation |
| HTTPS self-signed |
page blanche |
Passer --ignore-certificate-errors au démarrage de Chrome |
Bonnes pratiques 2026
- Headless Chrome : préférer
--headless=new (Chromium 112+) plutôt que l'ancien flag --headless.
- Core Web Vitals : cibler LCP < 2,5 s, INP < 200 ms, CLS < 0,1 — mesurables via
evalScript avec la Performance API ou PerformanceObserver.
- Données volumineuses : paginer ou filtrer côté DevTools avant d'exposer les résultats ; sauvegarder les traces dans un fichier JSON plutôt que de les inliner dans la conversation.
- Reproductibilité : documenter la séquence exacte d'actions (URL, snapshots, scripts) pour rejouer le débogage.
- Si DevTools MCP ne suffit pas : orienter vers Playwright MCP (
dev-playwright-browser-automation) pour les scénarios E2E complexes, ou vers l'interface Chrome DevTools native pour le profiling GPU/memory avancé.
Communication Rules — MANDATORY
- Ultra-concise. No filler, no preamble, no pleasantries.
- Never say "happy to help", "sure!", "great question", "let me", or similar.
- Tool first, talk second. Act before explaining.
- Result first. Lead with outcome, not process.
- Stop when done. No summary, no recap, no trailing commentary.
- No politeness wrappers. Direct and blunt.
- Minimum words. If one word works, do not use ten.
- No unsolicited explanations.
- No emoji unless asked.
1---2name: dev-chrome-devtools-debugger3description: Débogage et automatisation de navigateur via Chrome DevTools MCP. Inspecter des pages, analyser les performances, surveiller le réseau et automatiser des interactions. À utiliser quand l'utilisateur veut déboguer une page web, analyser les performances ou inspecter les requêtes réseau. Se déclenche aussi avec "devtools", "debug navigateur", "inspecter la page", "performances web", "requêtes réseau", "console chrome". Also triggers on "inspect a page", "debug in the browser", "check page performance".4---56# Débogueur Chrome DevTools78## Workflow général (ordre obligatoire)910```11Naviguer → Attendre chargement → Inspecter (snapshot) → Agir → Vérifier12```13141. **Naviguer** vers la page cible (`navigate` avec URL complète incluant le protocole).152. **Attendre** que la page soit stable (réseau idle, `DOMContentLoaded`).163. **Lister les pages** disponibles si plusieurs onglets, sélectionner le bon `targetId`.174. **Snapshot** de la structure (arbre d'accessibilité) — donne les identifiants uniques pour les interactions.185. **Agir** selon le besoin : clic, saisie, scroll, exécution JS.196. **Vérifier** le résultat : snapshot diff, console, capture si visuel requis.2021---2223## Scénarios courants2425### 1. Erreurs JavaScript2627```28naviguer → snapshot → getConsoleMessages → evalScript29```3031- Récupérer les messages console filtrés sur `level: error`.32- Identifier le fichier et la ligne dans la stack trace.33- Exécuter du JS pour inspecter l'état en direct :3435```js36// Exemples copiables dans evalScript37document.querySelectorAll('[data-error]').length38window.__reactFiber !== undefined // détecter React39performance.getEntriesByType('resource').filter(r => r.duration > 1000)40```4142- Si l'erreur est `Cannot read properties of undefined` : vérifier le timing (race condition) avec `document.readyState`.4344### 2. Problèmes réseau4546```47naviguer → getNetworkRequests → filtrer → analyser48```4950Filtres prioritaires :5152| Symptôme | Filtre à appliquer |53|---|---|54| Page blanche / données manquantes | `status >= 400` |55| Lenteur | `duration > 2000ms` |56| Erreur CORS | `blocked: true`, header `Access-Control-Allow-Origin` absent |57| CSP violation | messages console de type `Content Security Policy` |58| Waterfall lent | requêtes séquentielles au lieu de parallèles |5960Snippet de diagnostic réseau via `evalScript` :6162```js63// Ressources lentes (> 1s)64performance.getEntriesByType('resource')65 .filter(r => r.duration > 1000)66 .map(r => ({ name: r.name, duration: Math.round(r.duration) }))67```6869### 3. Analyse de performance7071```72naviguer → startTrace → déclencher l'action → stopTrace → analyser73```7475Points à identifier dans la trace :7677- **Long Tasks** (> 50 ms) : bloquent le thread principal.78- **Layout thrashing** : alternance forcée lecture/écriture DOM en boucle.79- **Repaints excessifs** : vérifier `will-change`, layers composites.80- **Time to Interactive (TTI)** : si > 3,8 s, chercher les scripts bloquants.8182Snippet pour identifier le layout thrashing :8384```js85// Propriétés qui forcent un reflow86const reflow_props = ['offsetHeight','offsetWidth','clientHeight',87 'scrollTop','getBoundingClientRect']88// Chercher dans le code source les lectures de ces props dans une boucle89```9091### 4. Automatisation d'interactions9293```94snapshot → récupérer nodeId → click/type/scroll → snapshot de vérification95```9697Règles d'or pour les interactions fiables :9899- Toujours utiliser le `nodeId` issu du snapshot, jamais un sélecteur CSS deviné.100- Attendre un indicateur de stabilité après chaque action (snapshot qui ne change plus, network idle).101- Pour les formulaires : `type` sur le champ → `click` sur le bouton submit → vérifier navigation ou message de confirmation.102103---104105## Critères de décision : quel outil utiliser106107| Besoin | Outil | Raison |108|---|---|---|109| Trouver un élément pour interagir | `snapshot` | Retourne les `nodeId` uniques, léger |110| Vérification visuelle (rendu, layout) | `screenshot` | Seul moyen de voir le rendu réel |111| Données hors arbre d'accessibilité | `evalScript` | Accès direct au DOM/window |112| Analyser erreurs runtime | `getConsoleMessages` | Messages filtrables par niveau |113| Diagnostiquer la lenteur réseau | `getNetworkRequests` | Timing, status, headers |114| Mesurer perf (LCP, TTI, FPS) | `startTrace` / `stopTrace` | Profil complet du thread principal |115116---117118## Garde-fous et anti-patterns119120### Ne jamais faire121122- **Screenshot systématique** — coûteux en tokens, inutile pour le débogage structurel. Réserver au besoin visuel explicite.123- **Interagir sans snapshot préalable** — les sélecteurs CSS peuvent pointer sur plusieurs éléments ; les `nodeId` sont uniques.124- **Ignorer l'ordre naviguer→attendre→inspecter** — un snapshot trop tôt capture une page incomplète.125- **Lancer une trace sur une page déjà chargée** — démarrer la trace avant l'action à mesurer.126- **evalScript avec `document.write`** — détruit le DOM existant.127128### Pièges fréquents129130| Piège | Symptôme | Solution |131|---|---|---|132| SPA (React/Vue/Angular) | snapshot vide ou partiel | Attendre l'hydratation ; chercher `[data-reactroot]` ou `#app` |133| iframes | éléments introuvables | Changer de `targetId` sur l'iframe |134| Shadow DOM | nodeId absent | `evalScript` avec `shadowRoot.querySelectorAll` |135| Auth / cookies | redirections inattendues | Vérifier cookies via `evalScript(document.cookie)` avant navigation |136| HTTPS self-signed | page blanche | Passer `--ignore-certificate-errors` au démarrage de Chrome |137138---139140## Bonnes pratiques 2026141142- **Headless Chrome** : préférer `--headless=new` (Chromium 112+) plutôt que l'ancien flag `--headless`.143- **Core Web Vitals** : cibler LCP < 2,5 s, INP < 200 ms, CLS < 0,1 — mesurables via `evalScript` avec la Performance API ou `PerformanceObserver`.144- **Données volumineuses** : paginer ou filtrer côté DevTools avant d'exposer les résultats ; sauvegarder les traces dans un fichier JSON plutôt que de les inliner dans la conversation.145- **Reproductibilité** : documenter la séquence exacte d'actions (URL, snapshots, scripts) pour rejouer le débogage.146- **Si DevTools MCP ne suffit pas** : orienter vers Playwright MCP (`dev-playwright-browser-automation`) pour les scénarios E2E complexes, ou vers l'interface Chrome DevTools native pour le profiling GPU/memory avancé.147148149## Communication Rules — MANDATORY150151- Ultra-concise. No filler, no preamble, no pleasantries.152- Never say "happy to help", "sure!", "great question", "let me", or similar.153- Tool first, talk second. Act before explaining.154- Result first. Lead with outcome, not process.155- Stop when done. No summary, no recap, no trailing commentary.156- No politeness wrappers. Direct and blunt.157- Minimum words. If one word works, do not use ten.158- No unsolicited explanations.159- No emoji unless asked.