WebGL sans sacrifier la performance
On peut livrer un hero animé magnifique et atteindre quand même un score Lighthouse de 100. Voici le budget dans lequel je travaille.
Le mouvement vend, mais les saccades font fuir. L’objectif est un hero qui semble vivant sans voler les millisecondes qui décident si un visiteur reste.
L’amélioration progressive, toujours
Le contenu est d’abord rendu en HTML côté serveur. La couche WebGL s’hydrate par-dessus, si bien que la page est lisible et indexable bien avant la compilation du moindre shader.
Respecter l’appareil
Plafonner le pixel ratio, mettre en pause la boucle de rendu hors écran et respecter prefers-reduced-motion. Un téléphone sur batterie ne devrait jamais exécuter la même boucle qu’un GPU de bureau.
- Limiter devicePixelRatio à 2.
- Arrêter le rendu quand le canvas quitte le viewport.
- Prévoir un fallback statique pour les utilisateurs en reduced-motion.
La performance est une fonctionnalité. Un score de 100 avec le mouvement intact est une contrainte de conception, pas un compromis.
Articles similaires
Construire un CRM que les clients utilisent vraiment
La plupart des CRM échouent non pas par manque de fonctionnalités, mais parce qu’ils modélisent le workflow de quelqu’un d’autre. Voici comment je commence par modéliser le vrai.
Le predicate pushdown, expliqué simplement
Comment rapprocher les filtres du stockage a fait passer une requête de 90 secondes à 8 — sans acheter le moindre serveur supplémentaire.
Des modules ERP qui partagent un seul grand livre
La différence entre un ERP et quatre tableurs déguisés, c’est un grand livre unique et partagé. Voici pourquoi c’est essentiel.