Stratégie de Performance - Chromecast V3

Ce mémo répertorie les contraintes techniques, les risques critiques et les recommandations d'optimisation pour l'exécution de l'application sur la plateforme Chromecast V3.

1. Contraintes Matérielles

Le Chromecast V3 est un appareil extrêmement limité en ressources :

• CPU : Processeur basse consommation (souvent saturé au démarrage).
• RAM : ~512 Mo au total. La mémoire disponible pour l'onglet de navigation est très restreinte.
• GPU : Supporte l'accélération matérielle 1080p, mais peine avec les effets CSS complexes.

2. Risques Critiques Identifiés

A. Surcharge Mémoire (OOM - Out of Memory)

L'application tourne dans une iframe pilotée par une application hôte. Ce pattern "Matriochka" consomme une double part de RAM (Runtime de l'hôte + Runtime SvelteKit).

• Risque : Crash silencieux de l'iframe ou redémarrage complet du Chromecast si la RAM dépasse le seuil critique.
• Vigilance : Éviter les fuites mémoire (unmount des stores/events) et limiter le nombre d'assets chargés simultanément.

B. Saturation CPU au Démarrage (cmsPipeline)

Le pipeline de données lance de nombreuses requêtes asynchrones en parallèle.

• Risque : Le parsing simultané de plusieurs gros fichiers JSON (Showcase, Facility, Ads) peut bloquer le thread principal (UI Freeze).
• Conséquence : Si l'application ne répond pas aux PING du Watchdog de l'hôte pendant cette phase de saturation, elle sera redémarrée de force.

C. Coût des ResizeObserver

L'utilisation de ResizeObserver (notamment dans DetachedPage.svelte) pour détecter le scroll et le focus a un coût en calcul constant.

• Risque : Saccades (jank) lors des animations si l'observer surveille trop de nœuds enfants.

D. Bridage Thermique (Thermal Throttling)

Le Chromecast V3 dissipe mal la chaleur. Une activité CPU constante (SSE, animations complexes, polling) fait monter la température.

• Conséquence : Le système réduit la fréquence du processeur pour refroidir, rendant l'application de plus en plus lente au fil du temps.

3. Checklist d'Optimisation

Assets & Images

• [ ] Résolution : Ne jamais dépasser 1080p. Utiliser les transformations Directus pour servir des images à la taille exacte.
• [ ] Format : Privilégier le WebP pour réduire le poids et le temps de décodage.
• [ ] Fonts : Limiter à 1 ou 2 graisses de polices maximum.

CSS & Animations

• [ ] GPU Only : N'animer que transform (scale, translate) et opacity.
• [ ] Éviter : box-shadow, backdrop-filter: blur, et les gradients radiaux complexes qui sont rendus logiciellement par le CPU.
• [ ] Structure : Garder un DOM le plus "plat" possible (moins de 1000 nœuds au total).

Réseau & Data

• [ ] Payloads Lean : Utiliser le paramètre fields dans les appels API pour ne récupérer que les données affichées.
• [ ] Séquençage : Si le démarrage est trop lent, envisager de séquencer les appels du cmsPipeline au lieu de tout paralléliser.

4. Monitoring

Pour diagnostiquer les performances sur un appareil réel :

1. Utiliser l'inspecteur Chrome à distance (chrome://inspect).
2. Filtrer la console avec le tag [BRIDGE] pour surveiller la réactivité aux messages de l'hôte.
3. Surveiller l'onglet Memory pour détecter toute croissance linéaire de la consommation de RAM.