Back to catalog

profiling-performance

Analyzes and optimizes application performance (loading time, FPS, memory, bottlenecks). Use when experiencing slowdowns, before releases, or optimizing arcade games

  • Category: discovered
  • Tags: github, community
  • Version: 1.0.0
  • Author: walid
  • Downloads: 0
  • GitHub stars: 1
  • Updated: 2025-11-21

Download the latest version (v1.0.0) from this page.

SKILL.md

---
name: profiling-performance
description: Analyzes and optimizes application performance (loading time, FPS, memory, bottlenecks). Use when experiencing slowdowns, before releases, or optimizing arcade games
allowed-tools: Read, Grep, Glob, Bash, WebSearch
---

# Profileur de Performance

Analyse et optimise performances pour expérience utilisateur fluide (chargement, FPS, mémoire).

## Table des matières

- [Quand utiliser](#quand-utiliser)
- [Métriques cibles](#métriques-cibles)
- [Outils d'analyse](#outils-danalyse)
- [Zones de profiling](#zones-de-profiling)
- [Patterns essentiels](#patterns-essentiels)
- [Workflow](#workflow)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)

## Quand utiliser

- Ralentissements dans les jeux
- Avant chaque release majeure
- Ajout de features lourdes
- Optimisation FPS arcade
- Investigation memory leaks
- Mobile performance

## Métriques cibles

**Chargement :** FCP < 1.5s, TTI < 3s, TBT < 200ms
**Runtime :** FPS ≥ 60 (arcade), Memory < 50 MB (stable)
**Bundle :** Initial < 200 KB (gzipped), Total < 2 MB

## Outils d'analyse

**Chrome DevTools Performance :**

- Profile JS (Scripting), Rendering, Painting
- Identifie Long Tasks (> 50ms = problème)
- Mesure FPS en temps réel

**Lighthouse :**

- Performance > 90, Accessibility > 95, PWA > 90
- Identifie bottlenecks chargement

**Performance API :**

- `performance.mark()` / `performance.measure()`
- `performance.getEntriesByName()` pour résultats

## Zones de profiling

### 1. Chargement initial

- Lighthouse audit → FCP, TTI
- Lazy loading modules lourds (trouvé dans lazy-loader.js)
- Imports dynamiques existants

### 2. FPS arcade (< 60 FPS = problème)

- Trop de calculs dans game loop → cacher résultats
- Re-render inutiles → cherche dirty rectangles/layers
- DOM excessif → batch avec requestAnimationFrame

### 3. Memory leaks

- DevTools Memory → Heap snapshots
- Event listeners non nettoyés dans cleanup()
- Timers non clearés (setInterval/clearInterval)

### 4. Bundle size

- Scripts npm : analyze:dependencies, dead-code
- Lazy-loader configuration
- Code splitting opportunities

## Patterns essentiels

- **Debounce/Throttle :** Événements fréquents
- **Memoization :** Cache résultats coûteux
- **requestAnimationFrame :** Batch DOM updates
- **Lazy loading :** Modules > 50 KB
- **Cleanup :** Listeners/Timers en destroy

## Workflow

1. **Identifier :** Profile DevTools ou Lighthouse
2. **Mesurer :** Taille, FPS, TTI avant optimisation
3. **Optimiser :** Une stratégie à la fois
4. **Valider :** Re-mesure, seuils atteints, mobile OK

## Checklist

- [ ] Lighthouse Performance > 90
- [ ] FPS ≥ 60 (arcade)
- [ ] Lazy loading implémenté
- [ ] Cleanup() nettoyage complet
- [ ] Memory leak-free (heap snapshot stable)
- [ ] Bundle < 200 KB initial
- [ ] Debounce/throttle sur événements
- [ ] Assets optimisés

## En cas de doute

**Workflow minimal :**

```bash
# Profile avec DevTools ou Lighthouse
# Identifier bottleneck (chargement, FPS, mémoire)
# Appliquer pattern (lazy loading > debounce > cache)
# Mesurer avant/après
# Valider sur mobile (bas de gamme)
```

**Règles absolues :**

1. Profile d'abord, optimiser après
2. Mesure avant/après
3. Une optimisation à la fois
4. Tests passent