Faut-il vraiment privilégier le FOUT au FOIT pour optimiser ses Core Web Vitals ?

Quelle est la différence entre FOUT et FOIT ?

Le FOIT (Flash of Invisible Text) désigne ce moment où votre navigateur cache complètement le texte en attendant que la police web custom se charge. Pendant ce laps de temps, l'utilisateur voit une page blanche ou des zones vides là où devrait apparaître le contenu textuel.

Le FOUT (Flash of Unstyled Text) affiche immédiatement le texte avec une police système de secours, puis effectue un swap vers la police personnalisée une fois celle-ci chargée. Le visiteur peut lire le contenu dès les premières millisecondes, même si le rendu visuel final n'est pas encore optimal.

Pourquoi Google pousse-t-il cette approche maintenant ?

La réponse tient en deux acronymes : LCP et CLS. Le FOIT retarde l'affichage du texte, ce qui dégrade directement votre Largest Contentful Paint si votre contenu principal est textuel. Beaucoup de sites e-commerce ou éditoriaux voient leur LCP exploser à cause de polices custom qui mettent 2-3 secondes à charger.

Le FOUT génère certes un léger flash visuel lors du swap de police, mais ce micro-changement est nettement moins pénalisant qu'un écran blanc prolongé. Google a clairement fait le calcul : un texte lisible immédiatement vaut mieux qu'un rendu parfait mais tardif.

Comment techniquement provoquer du FOUT plutôt que du FOIT ?

Les navigateurs modernes ont évolué dans leur gestion du FOIT. Certains comme Chrome imposent un timeout de 3 secondes maximum avant d'afficher le texte avec une police de fallback. D'autres comme Safari utilisent un timeout illimité, ce qui peut créer des situations catastrophiques.

Pour forcer un comportement FOUT uniforme, vous devez utiliser la propriété CSS font-display avec la valeur swap ou fallback. La valeur swap affiche immédiatement le texte système puis swap dès que la police custom arrive. La valeur fallback impose une fenêtre de swap très courte (100ms) puis bloque définitivement le swap si la police n'est pas arrivée.

• font-display: swap garantit que le texte est toujours visible, au prix d'un flash potentiel même tardif
• font-display: fallback limite le risque de CLS en bloquant les swaps tardifs après 3 secondes environ
• font-display: optional laisse le navigateur décider selon les conditions réseau, approche la plus performante mais moins prévisible
• L'ancienne pratique font-display: block provoque exactement le FOIT que Google déconseille désormais
• Toujours déclarer des polices de fallback cohérentes dans votre font-stack (taille, graisse, espacement similaires) pour minimiser le CLS lors du swap

Cette directive est-elle vraiment nouvelle ou juste un rappel ?

Soyons honnêtes : Google rabâche ce conseil depuis l'introduction de font-display en 2016. Ce qui change, c'est le contexte des Core Web Vitals qui transforme une recommandation UX en critère de ranking mesurable. Avant, optimiser le chargement des polices relevait du nice-to-have pour les sites exigeants.

Aujourd'hui, avec le poids croissant des CWV dans l'algorithme, ignorer le FOIT peut concrètement vous coûter des positions. J'observe sur le terrain que les sites qui passent de block à swap gagnent régulièrement 0,5 à 1 seconde sur leur LCP, ce qui les fait basculer du orange au vert dans PageSpeed Insights.

Quels sont les cas où cette règle devient problématique ?

La recommandation de Google suppose que le contenu textuel prime sur l'identité visuelle. Mais certains sites de luxe ou agences créatives ont des polices tellement distinctives que le FOUT crée une dissonance visuelle inacceptable pour leur marque.

Dans ces cas-là, vous avez deux options : soit vous préchargez agressivement vos polices critiques avec <link rel="preload"> pour réduire le délai à 200-300ms et rendre le FOIT quasi invisible, soit vous acceptez un score CWV moyen en utilisant font-display: block. [A verifier] : Google n'a jamais clarifié si un mauvais LCP causé par des choix de branding pouvait être compensé par d'autres signaux.

Le FOUT ne génère-t-il pas justement du CLS lors du swap ?

Absolument, et c'est le piège sournois de cette recommandation. Swapper d'Arial à une police custom qui a des métriques différentes provoque un reflow du texte qui peut faire bouger tout votre layout. J'ai vu des sites passer de 0,05 à 0,18 de CLS juste à cause d'un swap de police mal maîtrisé.

La solution passe par l'utilisation de size-adjust, ascent-override et descent-override dans vos @font-face pour faire matcher exactement les dimensions de votre police custom avec celles de la fallback système. Google Fonts fournit maintenant ces valeurs calculées automatiquement. Sans cet ajustement, vous échangez un problème LCP contre un problème CLS, ce qui n'arrange rien.

Comment auditer mes polices actuelles et détecter le FOIT ?

Ouvrez Chrome DevTools, onglet Network, filtrez sur Font et rechargez votre page en throttling Fast 3G. Observez si vos titres et paragraphes restent vides pendant le téléchargement des fichiers .woff2. Si oui, vous êtes en FOIT.

Autre méthode : inspectez vos déclarations @font-face dans le CSS. Si vous ne voyez aucune propriété font-display, les navigateurs appliquent leur comportement par défaut qui varie. Chrome fait du FOIT avec timeout 3s, Safari du FOIT illimité. Vous n'avez aucun contrôle, donc vous subissez.

Quelle valeur de font-display choisir selon mon contexte ?

font-display: swap convient à 80% des sites éditoriaux, e-commerce et services. Vous garantissez la lisibilité immédiate et acceptez un micro-flash visuel. C'est le choix le plus aligné avec la directive de Google.

font-display: fallback fonctionne mieux pour les sites où la cohérence visuelle compte beaucoup mais où vous ne pouvez pas précharger toutes les polices. Le swap se bloque après la fenêtre courte, évitant les changements visuels tardifs qui perturbent l'utilisateur déjà en train de lire.

Dois-je traiter différemment les icônes font vs les polices texte ?

Oui, et c'est un point souvent négligé. Les icon fonts (Font Awesome, Material Icons) provoquent un FOIT catastrophique : vos icônes de navigation, boutons CTA, étoiles de notation disparaissent complètement. Utilisez font-display: block uniquement pour ces polices et préchargez-les en priorité haute.

Mieux encore, migrez vers des SVG inline ou sprites pour les icônes critiques. Les icon fonts sont une dette technique qui pèse inutilement sur vos CWV. J'observe que remplacer Font Awesome par des SVG optimisés fait gagner 200-400ms de LCP sur les pages riches en icônes.

• Auditer toutes les déclarations @font-face et ajouter font-display: swap (ou fallback selon contexte)
• Calculer les métriques size-adjust pour chaque police custom afin de matcher la fallback système
• Précharger avec <link rel="preload"> uniquement les 1-2 polices critiques utilisées above-the-fold
• Tester en throttling réseau 3G le comportement réel du swap et mesurer l'impact CLS
• Envisager de limiter le nombre de graisses et variantes chargées (regular + bold suffit souvent)
• Migrer les icon fonts critiques vers SVG inline pour éliminer ce vecteur de FOIT