N'utilisez pas @import

Actualité par (Alsacréations, Strasbourg)
Créé le (52611 lectures)
Tags : css, link, performance

C'est par cette accroche étonnante que Steve Souders fait le point sur les performances de téléchargement des feuilles de style selon leur méthode d'appel en publiant un article intitulé Don't use @import. En effet il existe deux pratiques courantes pour lier une feuille de style CSS à une page HTML dans l'en-tête :

  • <link rel="stylesheet" href="styles.css">
  • <style type="text/css">@import url('styles.css');</style>

Cette dernière règle peut être appelée à l'intérieur d'une autre feuille de style, ce qui est relativement pratique dans certaines situations. Elle fait partie de la spécification CSS2 et est ignorée par les vieux navigateurs dont pouvait se servir Mathusalem (par exemple Netscape 4). La comparaison est détaillée dans l'astuce Comment appeler une feuille de styles.

Ces deux méthodes ne sont pas interprétées de la même façon par les navigateurs. Dans la plupart des cas, @import empêche le chargement de plusieurs feuilles de style en parallèle. Cela peut ralentir de façon significative le rendu de la page par le navigateur. Internet Explorer - toutes versions - se montre particulièrement déficient sur ce plan... sauf lorsque l'on emploie uniquement des instructions @import sans les mélanger avec des <link>.

Il en ressort les conclusions suivantes :

  1. Deux règles @import se téléchargent en parallèle.

    @import @import

  2. Deux appels mixtes @import et <link> se téléchargent successivement.

    link @import

  3. Un @import dans une feuille <link> se télécharge après celle-ci (ce qui peut paraître logique puisqu'il faut attendre le contenu du premier fichier).

    @import dans link

  4. Mélanger @import et <link> bloque le téléchargement des premiers imports.

    Multiple link + import

  5. Plusieurs @import ne se téléchargent pas forcément dans l'ordre spécifié. En y ajoutant un <script>, on ne peut être sûr que celui-ci sera chargé après les feuilles de style : cela peut entraîner des erreurs si celui-ci fait référence aux règles et classes contenues dans ces fichiers.

    import multiple

  6. C'est dans les vieux <head>'s que l'on fait les plus performantes soupes : deux <link> sont parallélisés.

    link only

Steve recommande donc de se limiter au classique <link rel="stylesheet" href="..." /> pour une efficacité maximale.

Steve Souders

Steve Souders travaille chez Google pour la performance des sites web et des projets open-source. Il est également le créateur de l'extension YSlow pour Firefox.

Source : http://www.stevesouders.com/blog/2009/04/09/dont-use-import/

Commentaires

krysttof a dit le

Etonnant et intéressant !
Voilà une synthèse bien pratique.

Florent V. a dit le

Hello,

Merci pour la news en français, je l'avais lue en anglais dans la journée mais c'est utile d'avoir un résumé dans la langue de Cindy Sander. :)

Selon moi il reste une utilité à la règle @import: son utilisation en phase de développement sur un gros projet avec de multiples feuilles de styles. Cela permet d'appeler une feuille de styles unique, puis de jouer sur les @import pour inclure ou pas certaines feuilles de styles. Sur les projets à plusieurs milliers de lignes de CSS, ça peut vite être très intéressant de scinder les feuilles de styles, de faire des essais séparés des modules CSS principaux afin de les intégrer plus tard (factorisation du code…), etc.

Bien sûr, en production il faudra basculer sur des mécanismes différents, des feuilles de styles débarassées de leurs commentaires et pourquoi pas minifiées et concaténées. On évitera alors @import.

Nykau a dit le

Merci pour cette info, enfin des comparaisons concrètes en terme de performance entre les deux méthodes.
Je vais de ce pas modifier quelques sites...

Raphael a dit le

Merci Dew pour cette info intéressante.
A ne pas oublier non plus : IE6 n'intègre pas une feuille appelée via @import si le media est indiqué (ex : @import url('styles.css') screen; n'aura aucun effet sur IE < 7)

Conclusion : what the FOUC !

digiboy a dit le

Intéressant article en effet. Je m'en servais pour me débarrasser justement de cette saloperie qu'est IE6, mais je vais revenir aux commentaires conditionnels ... et pis, c'est vrai quoi, what the fouc ! :D

yep a dit le

Ne pas utiliser @import pour des questions de performances, certes, mais "sémantiquement", il est plus juste d'utiliser <style> que <link> (lien).

Nico3333fr a dit le

Hihi, ça tombe bien, je n'utilise jamais cette façon de faire...

Benjamin D.C. a dit le

J'ai toujours un problème avec ce genre de titres racoleurs qui ne se base que sur l'analyse d'un seul et unique critère (la performance, en l'occurence)…

Comme le souligne Florent, il y a d'autres intérêts dans l'utilisation d'@import, notamment la possibilité de mélanger feuille de styles externe et styles directs (utile dans certains cas), le filtrage de certains navigateurs ou encore la concision d'écriture de feuilles de styles différentes selon le média:

<style type="text/css">
@import "screen.css" screen;
@import "handheld.css" handheld;
@import "print.css" print;
</style>

Mis à part cela, c'est selon moi typiquement le genre de préoccupations qui incombent aux constructeurs de navigateurs et non aux concepteurs de pages web.

Florent V. a dit le

@yep : laissons de côté la fausse sémantique, on ne s'en portera que mieux. (Si on veut parler de sémantique, alors <link rel="stylesheet" /> est très propre sur lui: c'est un appel à une ressource externe définie explicitement comme une feuille de styles.)

@Benjamin D.C. : en pratique, les insuffisances des navigateurs préoccupent aussi bien les constructeurs de navigateurs que les concepteurs de pages web.

Ganf a dit le

À mettre aussi en rapport avec une petite étude que j'avais faite sur le sujet il y a un an : http://performance.survol.fr/2008/04/css-et-i...

fredericB a dit le

Les bonnes pratiques Yahoo expliquent d'ailleurs qu'Internet Explorer, avec @import, va se comporter en fait comme si on utilisait <link /> mais placé en pied de page et non entre les balises HEAD, ce qui explique un certain ralentissement sous Internet Explorer.
http://developer.yahoo.com/performance/rules....