thekof
Tous les articles
Performance07/08/202612 min

Liquid Glass : performance, compatibilité et accessibilité

Le flou d’arrière-plan est un effet de composition coûteux et contextuel. Un audit Liquid Glass doit mesurer des appareils modestes, prévoir un rendu sans filtre et vérifier les usages clavier, contraste et mouvement.

Anneaux translucides verts autour d’un noyau lumineux sur fond sombre

Mesurer le vrai écran

Une carte isolée dans un catalogue de composants ne révèle pas le coût réel. Testez la page complète, avec défilement, images et plusieurs surfaces. Enregistrez une trace sur un appareil mobile moyen : temps de frame, rasterisation, paint et mémoire GPU sont plus utiles qu’une impression de fluidité sur une machine de développement.

Le coût augmente avec la surface filtrée, le rayon de blur et le nombre de couches. Réduire de quelques pixels un blur plein écran apporte souvent plus qu’optimiser un petit composant React. Évitez d’animer le rayon lui-même; animez plutôt opacité et transformation d’une couche déjà composée.

Définir un budget de matière

Fixez des limites : nombre maximal de surfaces filtrées visibles, rayon maximal sur mobile et absence de blur dans les listes longues. Les panneaux hors écran n’ont pas besoin d’un filtre actif. Une variante « low » peut réduire saturation et blur sans modifier la structure.

will-change n’est pas une solution permanente. Il réserve des ressources et peut aggraver la mémoire. Utilisez-le seulement autour d’une animation identifiée, puis retirez-le.

Matrice de compatibilité

Testez au minimum Safari iOS, Chrome Android, Safari et Chromium desktop, plus Firefox selon votre audience. Vérifiez le préfixe WebKit si vos cibles l’exigent, mais conservez toujours le fallback opaque. Les webviews intégrées et modes économie peuvent se comporter différemment du navigateur principal.

Le test le plus important reste simple : désactivez le filtre. La hiérarchie, la lecture et les actions doivent rester intactes. Si une bordure disparaît, restaurez-la dans la base plutôt que dans une exception navigateur.

Audit accessibilité

Mesurez contraste du texte et des contrôles sur la composition finale. Parcourez la page au clavier dans les deux sens. Zoomez à 200 %, augmentez la taille du texte et vérifiez que le contenu ne déborde pas d’une surface à hauteur fixe. Activez réduction des mouvements, couleurs forcées et contraste renforcé quand la plateforme les propose.

Les reflets purement décoratifs doivent être absents de l’arbre d’accessibilité. Les images éditoriales ont un alt localisé; une texture sans information utilise un alt vide. Les surfaces ne changent pas l’ordre de lecture et ne doivent pas masquer un focus derrière un overflow.

Dégradation pilotée par les capacités

Préférez la détection CSS avec @supports aux tests de navigateur. Pour les effets interactifs, combinez capacités de survol et pointeur fin. Un appareil tactile reçoit une surface stable. Une préférence de réduction reçoit moins de mouvement. Ce n’est pas une expérience diminuée : c’est une matière adaptée.

Critères de sortie

Définissez des seuils vérifiables : pas de long task liée au mouvement, focus visible partout, contenu utilisable sans filtre, contraste conforme et aucune régression aux tailles clés. Conservez captures et profils dans la revue de pull request.

Les recettes viennent des articles CSS accessible et interactions React. Une fois l’audit stable, industrialisez-les dans un design system Liquid Glass.

À lire ensuite