Quand le préchargement des feuilles de style est (ou n'est pas) pertinent
Exploration des considérations relatives au préchargement des feuilles de style pour l'optimisation des performances web.

Quand le préchargement des feuilles de style est (ou n'est pas) pertinent
Je rencontre régulièrement des feuilles de style préchargées et beaucoup de désinformation à leur sujet. Le préchargement d'une ressource modifie (généralement) sa priorité et le moment où son téléchargement est planifié. Cependant, comme beaucoup de stratégies d'optimisation que je croise quotidiennement, le préchargement des feuilles de style n'a pas beaucoup de sens la plupart du temps. Dans cet article, j'explorerai quand le préchargement des feuilles de style est pertinent et quand ce n'est peut-être pas le meilleur choix.
Table of Contents!
- Quand le préchargement des feuilles de style est (ou n'est pas) pertinent
- L'idée du préchargement des feuilles de style :
- Cas 1 : précharger la feuille de style juste avant de la déclarer.
- Cas 2 : précharger la feuille de style avec un en-tête Link.
- Cas 3 : 103 Early Hints pour les feuilles de style
- Cas 4 : précharger les feuilles de style pour obtenir un CSS asynchrone
- Cas 5 : pré-mettre en cache les feuilles de style
L'idée du préchargement des feuilles de style :
Avant de plonger dans les considérations, revisitons brièvement le concept de préchargement des feuilles de style. Les feuilles de style bloquent le rendu (render blocking). Cela signifie que pendant le téléchargement des feuilles de style, la page ne sera pas rendue par le navigateur et tout ce que le visiteur verra est un écran blanc.
Pour minimiser le temps de téléchargement d'une feuille de style, les développeurs ont parfois recours au préchargement. Le préchargement implique de récupérer les ressources critiques à l'avance, minimisant la latence associée à leur chargement lorsqu'elles sont réellement nécessaires. Cela est généralement réalisé en utilisant la balise <link> avec l'attribut rel="preload".
Cas 1 : précharger la feuille de style juste avant de la déclarer.
Parfois, les développeurs, dans leur enthousiasme, essaient de minimiser l'impact du CSS en le rechargeant dans le HTML juste avant la déclaration CSS réelle. Cela ressemblera à quelque chose comme :
<link rel="preload" as="style" href="style.css">
<link rel="stylesheet" href="style.css">
Or, cela n'a aucun sens et, au mieux, vous ne ralentirez pas la page ! Un navigateur lira le HTML et commencera à charger toutes les ressources critiques de la page, principalement dans l'ordre où il les trouve. Cela signifie que si vous supprimiez la ligne de préchargement, le navigateur aurait trouvé la feuille de style de toute façon et aurait commencé à la télécharger quoi qu'il arrive. Vous avez juste ajouté une ligne supplémentaire, c'est tout ! Mais il y a pire. Les feuilles de style préchargées ont une priorité inférieure aux feuilles de style normales. Donc, dans le pire des cas, vous ralentiriez réellement votre page !
3 feuilles de style préchargées

3 feuilles de style normales

Cas 2 : précharger la feuille de style avec un en-tête Link.
Cette idée est intéressante. Nous pouvons utiliser l'en-tête serveur Link pour précharger une feuille de style. Cela ressemblerait à ceci :
L'idée ici est d'amener le navigateur à mettre la feuille de style en file d'attente avant de commencer à analyser le HTML. C'est une assez bonne idée et j'aime la façon dont fonctionne l'esprit du développeur qui a pensé à cela ! Mais malheureusement, dans la vraie vie, vous en tirerez très peu de bénéfices. Nous parlons de quelques microsecondes. Ce sont des résultats assez décevants, mais ne vous inquiétez pas. Nous pouvons utiliser cette étape pour apporter de réelles améliorations !
Cas 3 : 103 Early Hints pour les feuilles de style
C'est la seule idée qui vous apportera réellement des résultats Core Web Vitals ! L'envoi de Early Hints pour les feuilles de style améliorera des métriques comme le First Contentful Paint (FCP) et le Largest Contentful Paint (LCP).
Les en-têtes 103 Early Hints sont envoyés avant la réponse HTML réelle. Cela signifie que pendant que vous téléchargez le HTML, le navigateur peut également commencer à télécharger les feuilles de style en parallèle. Le meilleur scénario est qu'au moment où le téléchargement du HTML est terminé, les feuilles de style pourraient l'être aussi. Cela signifie qu'il n'y a aucun temps de blocage du rendu dû à ces feuilles de style. Et cela peut arriver et arrive effectivement sur des réseaux plus lents ! Sur des réseaux plus rapides, l'effet est moins évident, mais l'utilisation de 103 Early Hints reste plus rapide dans presque tous les cas !
Une réponse 103 Early Hint ressemble beaucoup à un en-tête Link preload. Pour utiliser 103 Early Hints, vous devrez configurer votre serveur web ou votre CDN.
HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=styleCertains CDN comme Cloudflare vous permettront de déclencher un 103 Early Hint en définissant simplement un en-tête Link preload (comme décrit dans l'idée 2).
Cas 4 : précharger les feuilles de style pour obtenir un CSS asynchrone
Une astuce bien connue pour rendre le CSS non bloquant pour le rendu est de précharger la feuille de style et, une fois chargée, de l'ajouter à la page. L'idée est simple et ressemble à ceci :
<link
rel="preload"
href="style.css"
as="style"
Elle est basée sur le code de préchargement normal <link rel="preload" as="style" href="style.css"> et ajoute un écouteur d'événement onload onload="this.onload=null;this.rel='stylesheet'" qui change le lien vers sa forme finale <link rel="stylesheet" href="style.css">
C'est une autre idée qui a du sens. Si une feuille de style ne bloque pas le rendu, le navigateur peut continuer à analyser et à rendre la page sans avoir besoin de s'arrêter et d'attendre la feuille de style. Cependant, soyez prudent !
- Ne mettez pas le CSS en asynchrone dans la fenêtre d'affichage visible (viewport). Cela causera probablement un Cumulative Layout Shift (CLS) et cela conduira à une mauvaise User Experience (UX)
- Considérez le compromis. Le CSS asynchrone causera probablement un nouveau rendu de différentes parties de la page. Cela impactera des métriques comme l'Interaction to Next Paint (INP).
Cas 5 : pré-mettre en cache les feuilles de style
En de rares occasions, je vois des solutions astucieuses qui essaient de préchauffer les fichiers en cache pour les pages vues ultérieures. Et bien que j'applaudisse l'enthousiasme avec lequel ces solutions sont faites. S'il vous plaît, ne faites PAS cela !
L'idée est simple : sur la page d'accueil, vous pourriez, si vous le souhaitiez, déjà pré-mettre en cache les styles pour une autre page. Disons la page produit. À un moment donné après le chargement de la page, vous préchargeriez les feuilles de style pour les ajouter au cache du navigateur.
function preloadStylesheet(url) {
var link = document.createElement('link');
link.rel = 'preload';
link.href = url;
link.as = 'style';
document.head.appendChild(link);
}
window.addEventListener('load', function () {
preloadStylesheet('cart.css');
preloadStylesheet('shop.css');
});À première vue, cela ne semble pas si mal. Sur n'importe quelle page produit, cart.css et shop.css sont maintenant disponibles et ne bloqueront plus le rendu. Il y a quelques raisons de ne pas faire cela !
- Il y a de meilleurs moyens, par exemple le prérendu spéculatif ou l'utilisation d'un service worker.
- Vous allez probablement gaspiller des ressources et le compromis n'en vaudra pas la peine ! Soyons réalistes : si le préchargement des ressources était facile, les navigateurs y seraient meilleurs.
- Des solutions comme celle-ci sont difficiles à maintenir et causeront probablement des problèmes à un moment donné dans le futur
- Vous devrez précharger toutes les feuilles de style, pas seulement quelques-unes. Parce que toutes les feuilles de style bloquent le rendu et sont téléchargées en parallèle, une seule feuille de style peut avoir le même effet que plusieurs feuilles de style.
Urgent Fix Required?
Google Search Console failing? I offer rapid-response auditing to identify the failure point within 48 hours.
- 48hr Turnaround
- Rapid Response
- Failure Identification

