web-perf

Analyse les performances web à l'aide de Chrome DevTools MCP. Mesure les Core Web Vitals (LCP, INP, CLS) et les métriques complémentaires (FCP, TBT, Speed Index), identifie les ressources bloquant le rendu, les chaînes de dépendances réseau, les décalages de mise en page, les problèmes de cache et les lacunes d'accessibilité. À utiliser lorsqu'on vous demande d'auditer, de profiler, de déboguer ou d'optimiser les performances de chargement de page, les scores Lighthouse ou la vitesse d'un site. Privilégie la récupération depuis la documentation actuelle plutôt que les connaissances pré-entraînées.

npx skills add https://github.com/cloudflare/skills --skill web-perf

Audit de Performance Web

Vos connaissances sur les métriques de performance web, les seuils et les APIs d'outils peuvent être obsolètes. Privilégiez la récupération d'informations plutôt que les pré-entraînements lorsque vous citez des chiffres ou des recommandations spécifiques.

Sources de Récupération

Source Comment récupérer À utiliser pour
web.dev https://web.dev/articles/vitals Seuils Core Web Vitals, définitions
Documentation Chrome DevTools https://developer.chrome.com/docs/devtools/performance APIs d'outils, analyse de traces
Scoring Lighthouse https://developer.chrome.com/docs/lighthouse/performance/performance-scoring Poids des scores, seuils de métriques

D'ABORD : Vérifier les Outils MCP Disponibles

Exécutez ceci avant de commencer. Essayez d'appeler navigate_page ou performance_start_trace. Si indisponibles, ARRÊTEZ—le serveur MCP chrome-devtools n'est pas configuré.

Demandez à l'utilisateur d'ajouter ceci à sa configuration MCP :

"chrome-devtools": {
  "type": "local",
  "command": ["npx", "-y", "chrome-devtools-mcp@latest"]
}

Lignes Directrices Clés

  • Soyez affirmatif : Vérifiez les affirmations en examinant les requêtes réseau, le DOM ou la base de code—puis énoncez les résultats avec certitude.
  • Vérifiez avant de recommander : Confirmez qu'une ressource est inutilisée avant de suggérer sa suppression.
  • Quantifiez l'impact : Utilisez les économies estimées à partir des insights. Ne priorisez pas les changements avec 0ms d'impact.
  • Ignorez les non-problèmes : Si des ressources bloquantes de rendu ont 0ms d'impact estimé, notez-le mais ne recommandez pas d'action.
  • Soyez spécifique : Dites « compresser hero.png (450 KB) en WebP » plutôt que « optimiser les images ».
  • Priorisez sans pitié : Un site avec 200ms de LCP et 0 CLS est déjà excellent—dites-le.

Référence Rapide

Tâche Appel d'Outil
Charger la page navigate_page(url: "...")
Démarrer une trace performance_start_trace(autoStop: true, reload: true)
Analyser un insight performance_analyze_insight(insightSetId: "...", insightName: "...")
Lister les requêtes list_network_requests(resourceTypes: ["Script", "Stylesheet", ...])
Détails de requête get_network_request(reqid: <id>)
Snapshot accessibilité take_snapshot(verbose: true)

Flux de Travail

Copiez cette checklist pour suivre la progression :

Progression de l'Audit :
- [ ] Phase 1 : Trace de performance (navigation + enregistrement)
- [ ] Phase 2 : Analyse Core Web Vitals (inclut les culprits de CLS)
- [ ] Phase 3 : Analyse réseau
- [ ] Phase 4 : Snapshot accessibilité
- [ ] Phase 5 : Analyse de la base de code (ignorer si site tiers)

Phase 1 : Trace de Performance

  1. Naviguez vers l'URL cible :

    navigate_page(url: "<target-url>")

  2. Démarrez une trace de performance avec rechargement pour capturer les métriques à froid :

    performance_start_trace(autoStop: true, reload: true)

  3. Attendez la fin de la trace, puis récupérez les résultats.

Dépannage :

  • Si la trace est vide ou échoue, vérifiez que la page s'est chargée correctement avec navigate_page d'abord
  • Si les noms d'insights ne correspondent pas, inspectez la réponse de la trace pour lister les insights disponibles

Phase 2 : Analyse Core Web Vitals

Utilisez performance_analyze_insight pour extraire les métriques clés.

Note : Les noms d'insights peuvent varier selon les versions de Chrome DevTools. Si un nom d'insight ne fonctionne pas, vérifiez l'insightSetId de la réponse de trace pour découvrir les insights disponibles.

Noms d'insights courants :

Métrique Nom de l'Insight À Rechercher
LCP LCPBreakdown Temps jusqu'au plus grand élément de contenu peint ; décomposition de TTFB, chargement de ressources, délai de rendu
CLS CLSCulprits Éléments causant des changements de mise en page (images sans dimensions, contenu injecté, échanges de polices)
Blocage du Rendu RenderBlocking CSS/JS bloquant la première peinture
Latence Document DocumentLatency Problèmes de temps de réponse du serveur
Dépendances Réseau NetworkRequestsDepGraph Chaînes de requêtes retardant les ressources critiques

Exemple :

performance_analyze_insight(insightSetId: "<id-from-trace>", insightName: "LCPBreakdown")

Seuils clés (bon/besoins-amélioration/mauvais) :

  • TTFB : < 800 ms / < 1,8 s / > 1,8 s
  • FCP : < 1,8 s / < 3 s / > 3 s
  • LCP : < 2,5 s / < 4 s / > 4 s
  • INP : < 200 ms / < 500 ms / > 500 ms
  • TBT : < 200 ms / < 600 ms / > 600 ms
  • CLS : < 0,1 / < 0,25 / > 0,25
  • Speed Index : < 3,4 s / < 5,8 s / > 5,8 s

Phase 3 : Analyse Réseau

Listez toutes les requêtes réseau pour identifier les opportunités d'optimisation :

list_network_requests(resourceTypes: ["Script", "Stylesheet", "Document", "Font", "Image"])

À rechercher :

  1. Ressources bloquantes du rendu : JS/CSS dans <head> sans attributs async/defer/media
  2. Chaînes réseau : Ressources découvertes tard parce qu'elles dépendent du chargement d'autres ressources d'abord (par exemple, imports CSS, polices chargées par JS)
  3. Préchargements manquants : Ressources critiques (polices, images héros, scripts clés) non préchargées
  4. Problèmes de mise en cache : Headers Cache-Control, ETag ou Last-Modified manquants ou faibles
  5. Charges utiles volumineuses : Bundles JS/CSS non compressés ou surdimensionnés
  6. Préconnexions inutilisées : Si signalées, vérifiez si DES requêtes sont allées à cette origine. Si zéro requête, c'est définitivement inutilisé—recommandez la suppression. Si des requêtes existent mais chargées tard, la préconnexion peut toujours être utile.

Pour des informations détaillées sur les requêtes :

get_network_request(reqid: <id>)

Phase 4 : Snapshot Accessibilité

Prenez un snapshot de l'arbre d'accessibilité :

take_snapshot(verbose: true)

Signalez les écarts de haut niveau :

  • IDs ARIA manquants ou en doublon
  • Éléments avec mauvais contrastes (vérifiez par rapport à WCAG AA : 4,5:1 pour texte normal, 3:1 pour texte large)
  • Pièges au clavier ou indicateurs de focus manquants
  • Éléments interactifs sans noms accessibles

Phase 5 : Analyse de la Base de Code

Ignorer lors de l'audit d'un site tiers sans accès à la base de code.

Analysez la base de code pour comprendre où les améliorations peuvent être apportées.

Détecter le Framework et le Bundler

Recherchez les fichiers de configuration pour identifier la pile :

Outil Fichiers de Configuration
Webpack webpack.config.js, webpack.*.js
Vite vite.config.js, vite.config.ts
Rollup rollup.config.js, rollup.config.mjs
esbuild esbuild.config.js, scripts de build avec esbuild
Parcel .parcelrc, package.json (champ parcel)
Next.js next.config.js, next.config.mjs
Nuxt nuxt.config.js, nuxt.config.ts
SvelteKit svelte.config.js
Astro astro.config.mjs

Vérifiez aussi package.json pour les dépendances de framework et les scripts de build.

Tree-Shaking et Code Mort

  • Webpack : Vérifiez mode: 'production', sideEffects dans package.json, optimisation usedExports
  • Vite/Rollup : Tree-shaking activé par défaut ; vérifiez les options treeshake
  • À rechercher : Fichiers barrel (index.js ré-exporte), grandes bibliothèques utilitaires importées en bloc (lodash, moment)

JS/CSS Inutilisés

  • Vérifiez CSS-in-JS vs extraction de CSS statique
  • Cherchez la configuration PurgeCSS/UnCSS (config content de Tailwind)
  • Identifiez les imports dynamiques vs chargement enthousiaste

Polyfills

  • Vérifiez les targets @babel/preset-env et le paramètre useBuiltIns
  • Cherchez les imports core-js (souvent surdimensionnés)
  • Vérifiez la config browserslist pour un ciblage trop large

Compression et Minification

  • Vérifiez la minification terser, esbuild ou swc
  • Cherchez la compression gzip/brotli dans la sortie de build ou la config serveur
  • Vérifiez les source maps dans les builds de production (doivent être externes ou désactivés)

Format de Sortie

Présentez les résultats comme suit :

  1. Résumé Core Web Vitals - Tableau avec métrique, valeur et classement (bon/besoins-amélioration/mauvais)
  2. Problèmes Principaux - Liste priorisée des problèmes avec impact estimé (haut/moyen/bas)
  3. Recommandations - Corrections spécifiques et exploitables avec extraits de code ou modifications de configuration
  4. Résultats de la Base de Code - Framework/bundler détecté, opportunités d'optimisation (omettez si pas d'accès à la base de code)

Skills similaires

qdrant-memory-usage-optimization
github / awesome-copilot

31 949
copilot-usage-metrics
github / awesome-copilot

31 949
qdrant-monitoring-setup
github / awesome-copilot

31 949
web-perf
cloudflare / skills

1 381
cloudflare
cloudflare / skills

Naviguer les produits Cloudflare et construire des solutions adaptées à chaque besoin.

1 381