Google PageSpeed suggère souvent de optimiser la livraison CSS . Il m'est venu à l'esprit que cela réduirait les allers-retours sur le réseau pour intégrer tous les CSS comme ceci:
<style type="text/css">
@{
var bootstrap = File.ReadAllText(Server.MapPath("bootstrap.min.css"));
var bootstrapTheme = File.ReadAllText(Server.MapPath("theme.min.css"));
var fontAwesome = File.ReadAllText(Server.MapPath("font-awesome.min.css"));
var bigfont = File.ReadAllText(Server.MapPath("bigfont.min.css"));
var bigfontPrint = File.ReadAllText(Server.MapPath("bigfont-print.min.css"));
}
@Html.Raw(bootstrap)
@Html.Raw(bootstrapTheme)
@Html.Raw(fontAwesome)
@Html.Raw(bigfont)
@Html.Raw(bigfontPrint)
</style>
Cela semble être une solution raisonnable au problème des chargements de page lents et a augmenté mon score de PageSpeed à 95 au lieu de 88.
Mis à part le style de code pour le moment, quelles raisons techniques, le cas échéant, existent pour NE PAS aligner tous les CSS de cette manière?
L'intégration de tout votre CSS signifie qu'il ne peut pas être mis en cache, donc chaque chargement de page contiendra tout le CSS requis, et lorsque vous utilisez de grandes bibliothèques, cela peut vraiment être beaucoup de bande passante gaspillée. Par exemple, Bootstrap est d'environ 120 000. Notez que le lien Google que vous avez partagé spécifie ce qui suit (c'est moi qui souligne):
Si les ressources CSS externes sont petites, vous pouvez les insérer directement dans le document HTML, qui est appelé inlining.
Ainsi, un chargement d'une seule page peut être plus rapide, mais dans l'ensemble, il sera probablement plus lent.
Personnellement, je m'en abstiendrais. Cependant, une chose que vous pouvez faire est de regrouper tous vos CSS en une seule demande (vous utilisez MVC, ce qui est relativement simple), vous n'avez donc qu'à effectuer un seul voyage supplémentaire vers le serveur pour votre CSS et toutes les pages futures demandées par le navigateur n'aura pas besoin de les demander à nouveau.
Personne n'a mentionné le cas d'utilisation prévu pour cette technique, qui n'est certainement pas de charger 100% de votre CSS. Cette technique est plutôt destinée à rendre les utilisateurs pensez la page s'est chargée plus rapidement.
Lorsque nous discutons de l'accélération du chargement des pages, le véritable objectif est généralement de rendre le chargement des pages plus rapide. Du point de vue de l'expérience utilisateur, cela est beaucoup plus important que de faire en sorte que la charge prenne moins de temps. Peu importe si la page entière prend 500 ms à charger, car un humain ne peut pas l'analyser aussi rapidement de toute façon. Ce qui compte, c'est la rapidité avec laquelle la page semble s'être chargée.
Donc, l'utilisation appropriée de cette technique est de charger, immédiatement, le CSS absolument essentiel pour rendre la page correctement. Autrement dit, il existe des règles CSS qui font que les images sont de la bonne taille, qui font que les choses flottent correctement, qui évitent cette horrible apparence de contenu de page qui saute autour de la page pendant que le SDK Facebook termine ses activités. Ce code doit être présent au même instant que le balisage est chargé. Solution: insérez ce CSS critique.
Mais certainement NE PAS incorporer tous les CSS. Il peut y avoir un autre 100 Ko qui se charge plus tard, si ce CSS ne style que le contenu qui se charge de manière asynchrone de toute façon. Mais s'il y a une structure de page qui doit être dans le bon format après 25 ms, ce CSS doit être en ligne.
Vous avez mal compris la suggestion de PageSpeed. La recommandation concerne les petits fichiers CSS:
Si les ressources CSS externes sont petites, vous pouvez les insérer directement dans le document HTML, qui est appelé inlining. [...] Gardez à l'esprit que si le fichier CSS est volumineux, l'inclusion complète du CSS peut amener PageSpeed Insights à avertir que la partie au-dessus de la ligne de flottaison de votre page est trop volumineuse via Prioriser le contenu visible.
En fait, l'article suggère plus tard une approche équilibrée pour les fichiers CSS volumineux: insérez le CSS critique et différez le fichier CSS restant.
Maintenant, même si PageSpeed vous donne un score décent après avoir inséré de gros fichiers CSS *, cela pourrait toujours être une mauvaise idée:
Les fichiers CSS en ligne signifient que vous dupliquez le <style>...</style>
tag sur plusieurs pages. Cela signifie que vous fournissez des données redondantes pour les pages vues suivantes ou répétées. Les données redondantes coûtent de la bande passante et augmentent le temps de téléchargement.
Un fichier CSS séparé ainsi que des en-têtes de mise en cache puissants vous permettent d'éliminer la redondance. Les en-têtes de mise en cache indiquent aux navigateurs de mettre en cache le fichier CSS lors de la première vue de page et de le réutiliser lors des vues de page suivantes ou répétées.
Les fichiers CSS en ligne réduisent la proportion de contenu "réel" sur la page. Les fichiers CSS en ligne vous obligent à insérer le CSS au-dessus du contenu tandis que la plupart d'entre nous s'efforcent de mettre le contenu réel près du HTML supérieur.
Le CSS en ligne obligera également le navigateur à télécharger des octets supplémentaires avant de lui permettre de télécharger d'autres ressources telles que JavaScript et des images.
Si votre page HTML est générée dynamiquement, alors, très probablement, elle sera servie non compressée. Certains serveurs (par exemple IIS) et logiciels (par exemple Wordpress) permettent la compression de contenu dynamique mais nécessitent plus de CPU + de mémoire par rapport à la compression de contenu statique (par exemple, des fichiers CSS). C'est encore une autre raison pour laquelle vous devriez conserver CSS dans un fichier séparé.
Pour les raisons ci-dessus, je conserverais mon CSS combiné, minifié, compressé et mis en cache, dans un fichier séparé, même pour les sites Web d'une page.
* À ne pas confondre avec styles en ligne
C'est trop long pour tenir dans un commentaire. Là où je travaille, nous utilisons Politique de sécurité du conten directives d'en-tête (en particulier style-src
) pour interdire explicitement l'utilisation de CSS en ligne. La raison de ne pas utiliser de CSS en ligne dans ce cas est de minimiser les risques d'injection CSS pour les pages créées dynamiquement. OWASP a des informations détaillées sur ce sujet, y compris des exemples d'exploitation: https://www.owasp.org/index.php/Testing_for_CSS_Injection_ (OTG-CLIENT-005) . Si seul du contenu statique est diffusé sur le navigateur, il ne devrait y avoir aucun risque.