Décidez si le Critical CSS résout vraiment le problème
Commencez par des preuves, pas par une étiquette d’audit. Enregistrez un chargement à cache froid pour une page prioritaire sur des profils mobiles et desktop représentatifs. Inspectez la waterfall et le trace : est-ce qu’une feuille CSS retarde le premier contenu, et est-elle suffisamment importante pour compter ? DevTools Coverage montre le CSS utilisé pendant une session, pas pour chaque route ou état.
Essayez d’abord des travaux moins lourds en maintenance : retirer les règles inutilisées vérifiées, minifier et compresser la sortie, charger le CSS par route uniquement quand c’est nécessaire, et éviter les chaînes @import CSS simples. web.dev qualifie l’extraction et la différation de techniques avancées.
Un retard mesuré du premier rendu est lié au CSS, une visite à cache froid est importante, et la mise en page initiale peut être maintenue.
Si le goulot d’étranglement vient du serveur, des images, des polices, du JavaScript, ou d’une feuille déjà petite, l’insertion en ligne du CSS est peu susceptible d’aider.
Définissez la vue initiale comme une matrice de tests
La vue initiale, parfois appelée above the fold, est ce que le visiteur voit avant de faire défiler. Elle n’a pas de hauteur universelle : appareils, zoom, langue, cookies et variantes de contenu la modifient. Une capture d’écran desktop peut manquer un téléphone ou un titre traduit.
Utilisez des profils nommés. Incluez des mises en page étroites et larges, les breakpoints clés, les structures de connexion différentes, et toute bannière de consentement, promotion, message de maintenance ou erreur qui entre en haut de la page.
Consignez le template, le viewport, la locale, l’authentification, le consentement et les variantes en haut de page utilisés pour générer et tester l’ensemble.
Testez le défilement rapide, les menus et le focus de formulaire ; une règle différée est dangereuse si son contrôle peut apparaître avant que le CSS complet ne soit appliqué.
Extrayez un petit ensemble à partir d’une source de vérité
Générez le Critical CSS à partir du build de production. L’extraction peut identifier les règles utilisées dans un viewport, mais révisez les règles conditionnelles, dynamiques et de transition. Ne recopiez pas manuellement un second design system dans les templates ; il dérivera au fur et à mesure que les composants et le balisage évolueront.
Gardez la sortie générée et versionnée avec la release, tandis que le CSS source reste la source d’autorité. Inlinez uniquement les règles requises pour l’état initial utilisable. De gros blocs inline retardent le HTML et ne peuvent pas être réutilisés depuis le cache d’une feuille externe sur les pages suivantes. Comparez navigation à cache froid et chaud avant de déclarer l’amélioration.
Suivez les octets compressés inline, les octets restants de la feuille, et les règles dupliquées. Une requête de blocage en moins n’est pas nécessairement un gain net.
Signalez un build lorsque l’extraction est vide, dépasse le budget de taille inline, ou change de façon inattendue par rapport à une baseline revue.
Chargez le reste du CSS en toute sécurité et respectez les contraintes de politique
La feuille restante doit arriver avant que le contenu inférieur et les états ultérieurs n’aient l’air complets. Un pattern documenté précharge le CSS en tant que style puis le transforme en stylesheet après son chargement, avec un fallback sans JavaScript. Preload demande une ressource tôt ; il n’applique pas le CSS. Un ensemble incomplet peut provoquer un restyling visible.
Vérifiez la Content Security Policy avant d’utiliser un gestionnaire de chargement inline. web.dev note que la politique peut interdire le JavaScript inline onload, utilisez donc un loader compatible ou une autre conception. Testez avec JavaScript désactivé. Les fichiers qualifiés par media aident pour des styles conditionnels réels comme print ; une requête non-matching ne bloque pas le rendu, bien qu’elle puisse toujours être téléchargée.
Vérifiez qu’un visiteur sans JavaScript reçoit le CSS complet et peut terminer le parcours prioritaire.
Investigatez une police ou image première-viewport tardive séparément ; le Critical CSS ne change pas leur comportement de fetch.
Testez les régressions visuelles, fonctionnelles et de cache
Utilisez une comparaison visuelle sur chaque viewport nommé et état en haut de page. Vérifiez texte non stylé, chevauchement, navigation cachée, indicateurs de focus manquants, shift de mise en page et un saut quand le CSS différé s’applique. Exécutez la navigation au clavier, les chemins tactiles, les erreurs et le défilement rapide. Si une règle différée rend un contrôle inutilisable, elle appartient au chemin critique ou le design doit changer.
Testez les visites à cache froid et chaud. Les tests à froid montrent si la suppression de l’attente CSS améliore le rendu ; les tests à chaud montrent le coût répété des octets inline. Testez le HTML mis en cache antérieur et un retour après déploiement. Conservez des assets compatibles pendant que des HTML mis en cache peuvent en faire la demande, et n’écrasez pas une URL de feuille fichée (fingerprinted).
Comparez first content et le contenu visible principal, puis utilisez le trace pour expliquer un gain ou une régression.
Incluez focus, contraste, préférences de mouvement, zoom et ordre lisible. Un rendu plus rapide n’est pas une réussite si l’interface est inaccessible.
Opérez cela comme une fonctionnalité de livraison réversible
Donnez une ownership au pipeline et documentez ses entrées, artefact, templates, profils de test et limite de taille inline. Lancez des tests chaque fois que le CSS, le balisage, une librairie de composants, un feature flag ou un tiers above-the-fold change. Coverage guide la revue, mais un enregistrement ne peut pas prouver qu’une règle est sûre partout.
Publiez derrière une configuration réversible quand c’est possible. Enregistrez le chemin de feuille connu-good, la version de l’artefact, l’identifiant de build et la méthode de récupération. Si une régression apparaît, restaurez d’abord une livraison compatible, puis diagnostiquez l’état manqué. SIU utilise ce workflow pour stabiliser les chemins critiques avant que l’impact client ne se propage.
Une nouvelle bannière, un flux de consentement, une locale, un breakpoint, ou une mise en page de compte nécessite régénération et tests.
Revenez au template et à la configuration de livraison compatibles avec la génération ; n’éditez pas des URL d’assets immuables que d’anciens documents pourraient référencer.