Pourquoi ne pas intégrer des styles / scripts en HTML au lieu de les lier?
Nous concaténons les fichiers CSS et JavaScript pour réduire le nombre de requêtes HTTP, ce qui améliore les performances. Le résultat est HTML comme ceci:
<link rel="stylesheet" href="all-my-css-0fn392nf.min.css">
<!-- later... -->
<script src="all-my-js-0fn392nf.min.js"></script>
Si nous avons une logique côté serveur/build pour faire tout cela pour nous, pourquoi ne pas aller plus loin et intégrer ces styles et scripts concaténés dans le HTML?
<style>.all{width:100%;}.my{display:none;}.css{color:white;}</style>
<!-- later... -->
<script>var all, my, js;</script>
C'est deux demandes HTTP de moins, mais je n'ai pas vu cette technique en pratique. Pourquoi pas?
Parce que l'enregistrement des requêtes HTTP est peu utile lorsque vous y parvenez en interrompant la mise en cache. Si les feuilles de style et les scripts sont servis séparément, ils peuvent être très bien mis en cache et amortis sur de très nombreuses requêtes vers des pages extrêmement différentes. S'ils sont écrasés dans la même page HTML, ils doivent être retransmis avec chaque. Célibataire. Demande.
Le HTML de cette page, par exemple, est actuellement de 13 Ko. Les 180 Ko de CSS ont atteint le cache, tout comme les 360 Ko de JS. Les deux accès au cache ont pris moins de temps et n'ont consommé pratiquement aucune bande passante. Éliminez le profileur réseau de votre navigateur et essayez-le sur d'autres sites.
Tout simplement parce que Les performances Web comptent vraiment! 99% de fois, cela vous donnera des temps de réponse plus rapides pour l'utilisateur final.
Voici quelques exemples de Velocity Conf.
- Bing - Une page plus lente de 2 secondes a entraîné une baisse de 4,3% des revenus/utilisateur.
- Google - Un retard de 400 millisecondes a provoqué une baisse de 0,59% des recherches/utilisateur.
- Yahoo ! - Un ralentissement de 400 millisecondes a entraîné une baisse de 5 à 9% du trafic pleine page.
- Shopzilla - Accélérer leur site de 5 secondes a augmenté le taux de conversion de 7 à 12%, doublé le nombre de sessions du marketing des moteurs de recherche et réduit le nombre de serveurs requis en deux.
- Mozilla - Réduire les secondes de 2,2 de leurs pages de destination a augmenté les conversions de téléchargement de 15,4%, ce qui, selon eux, entraînera 60 millions de téléchargements Firefox supplémentaires par an.
- Netflix - L'adoption d'une seule optimisation, la compression gzip, a entraîné une accélération de 13-25% et a réduit leur trafic réseau sortant de 50%.
De Steve Souders, pionnier de l'optimisation des performances Web,
80 à 90% du temps de réponse de l'utilisateur final est passé sur le frontend - Commencez ici en premier.
L'utilisation de fichiers externes produit des pages plus rapides car les fichiers JavaScript et CSS sont mis en cache par le navigateur/réseaux/proxies (comme défini dans le protocole HTTP avec les en-têtes Cache). JavaScript et CSS intégrés dans les documents HTML sont téléchargés chaque fois que le document HTML est demandé. Cela réduit le nombre de requêtes HTTP nécessaires, mais augmente la taille du document HTML. Si vous utilisez des scripts de type Jquery, il est facile de réfrénérer 300 Ko de scripts et ne croyez pas que tout le monde dispose d'une bande passante de 100 Mo/s avec une faible latence, exécutant une seule application - le navigateur - ouverte sur votre site Web. 99% de fois, il vous donnera des temps de réponse plus rapides pour l'utilisateur final.
La fréquence à laquelle les composants externes JavaScript et CSS sont mis en cache par rapport au nombre de documents HTML demandés est également importante. Si les utilisateurs de votre site ont plusieurs pages vues par session et que plusieurs de vos pages réutilisent les mêmes scripts et feuilles de style (bundles), les fichiers externes mis en cache présentent un plus grand avantage potentiel.
Mais la mise en ligne est parfois préférable pour les applications à page unique ou les sites Web avec une seule page vue par session. Il n'y a pas de règle d'or, et on l'oublie généralement car il s'agit principalement de sites web très spécifiques réellement impliqués par les performances des utilisateurs finaux.
Vous pouvez lire ici pourquoi les performances sont importantes (Avertissement: je suis l'auteur)
La dernière version de HTTP a été créée en 1999. En 1999, tout le monde se connectait à Internet avec accès à distance. Internet était très lent. 16 ans plus tard, les choses ont beaucoup évolué, mais pas les protocoles que nous utilisons.
Les réponses que nous ne devrions pas intégrer "car cela interfère avec la mise en cache" sont un peu trompeuses, en particulier à l'ère de l'Internet ultra-rapide. Lorsque vous effectuez réellement les calculs, il y a souvent une différence négligeable entre les temps de chargement avec les utilisateurs cache-warm et cache-cold si vous avez intégré. Le fait qu'il y ait une petite différence n'est pas intrinsèquement parce que vous l'avez intégré, mais à cause de la conception rigide de HTTP/1.1.
Le protocole SPDY implémente quelque chose appelé serveur Push. Cela prend essentiellement l'incrustation du document HTML lui-même et dans le protocole. Un serveur intelligent saura quelles ressources le client possède déjà. Un serveur stupide enverra tout de toute façon - ce sera toujours un avantage en termes de performances, mais cela peut coûter en termes de bande passante. Si le navigateur a le contenu dans son cache, il peut simplement supprimer les copies entrantes. Le serveur attend que le code HTML soit chargé avant d'envoyer les ressources supplémentaires - en théorie, le navigateur peut envoyer un signal pour annuler le serveur Push.
HTTP/2.0 est basé sur SPDY et implémentera très probablement le serveur Push, mais vous pouvez en théorie commencer à utiliser SPDY aujourd'hui. Donc, la vraie raison pour laquelle nous ne nous alignons pas est héritée - les protocoles qui existent actuellement sont anciens et ne sont pas assez flexibles pour obtenir une "intégration au niveau du protocole".
En plus des problèmes de mise en cache et de récupération que soulèvent les autres réponses, je voudrais souligner un autre problème plus obscur: analyse.
JavaScript apparaissant en HTML peut rencontrer des problèmes d'analyse, comme dans cet exemple:
<html>
<head>
<script>
function myfunc() {
if ("</style> isn't a problem")
return "but </script> is"
}
</script>
<style>
body::after {
content: '</script> is okay, but not </style>'
}
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>
... ce qui signifie que vous devrez transformer votre script pour échapper à certains caractères qui se déclenchent en HTML. Ce problème disparaît lorsque vous fournissez CSS et JavaScript en tant que ressources externes, car ils n'ont plus à prendre en compte le contexte d'analyse "parent".
Si vous servez votre contenu en XML, vous avez un moyen de contourner cela en utilisant les sections CDATA. CDATA, cependant, est livré avec un problème similaire:
<?xml version="1.0" encoding="utf-8"?>
<html>
<head>
<script>
// <![CDATA[
function myfunc() {
if ("</script> is no longer a problem")
return "but ]]> is"
}
// ]]>
</script>
<style>
<![CDATA[
body::after {
content: 'same ]]> issue here'
}
]]>
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>
Attention aux inliners.
La séparation du contenu du style de sa présentation est généralement un plus grand avantage que moins de requêtes http.
Séparer tous les styles permet et encourage la réutilisation et les fichiers partagés.
Le contenu des fichiers sera également plus statique et disponible pour la mise en cache sur les serveurs et les clients pour cette page et les autres pages visitées.
Mais pour vous, une question spécifique ... Si le serveur est fait pour faire lui-même la minification, il est plus difficile de maintenir les actifs et de déboguer les problèmes. Cependant, de nombreux frameworks le font maintenant au niveau du fichier, par exemple tous les cs et tous les js. Par exemple, le Ruby on Rails framework minimise maintenant ses actifs pour la production. 5-10 requêtes http supplémentaires ne sont généralement pas le goulot d'étranglement, c'est plus s'il y en a 100) + requêtes http (que vous obtenez souvent avec des images).
L'étape supplémentaire consistant à inclure le code dans les pages elles-mêmes aurait l'inconvénient de pages plus grandes que vous auriez à gérer soigneusement la séquence de téléchargement et la page ne pouvant pas afficher le contenu souvent sans le reste de la page (maintenant grande) en cours de téléchargement.
- Minimisez le codage en double. pour gagner du temps (vous pouvez réutiliser le style et la fonction JS codés pour une page).
- Minimisez l'effort de changement. (Si votre client vous demande de changer la couleur des boutons du site Web, vous devez parcourir une page à la fois).
- Réduisez le temps de chargement (si votre CSS et votre JS font double emploi, cela signifie que la taille des pages individuelles augmente et prend beaucoup de temps à télécharger.
- Utilisation à distance. (vous pouvez placer votre CSS js JS commun dans un endroit distant. pas le même serveur hébergé)
- Réduisez le temps de correction des bogues. S'il y a un bogue dans une fonction, vous devez aller page par page pour corriger les bogues dans JS et CSS intégrés.
- Pour augmenter le référencement (séparez simplement le contenu des métadonnées)
- Plus propre et compréhensible du code (si vous intégrez tout dans un fichier, le débogage et la clarté du code disparaissent. Et chaque page sera une très longue page).
- De plus, cela vous aidera à réduire la taille du produit.
- Mais vous pouvez toujours envisager d'intégrer la chose la plus unique dans la même page.
Nous ne devons pas incorporer de styles/scripts en HTML car
Les styles/scripts intégrés doivent être téléchargés à chaque demande de page:
Ces styles ne peuvent pas être mis en cache par le navigateur et réutilisés pour une autre page. Pour cette raison, il est recommandé d'incorporer un minimum de CSS/JS possible.
à la place, nous utilisons la liaison coz lorsque nous utilisons la liaison pour lier css/scripts
La vitesse du site augmente pour les demandes de pages multiples:
Lorsqu'une personne visite votre site Web pour la première fois, son navigateur télécharge le code HTML de la page actuelle ainsi que le fichier CSS et JS lié. Lorsqu'ils naviguent vers une autre page, leur navigateur n'a qu'à télécharger le code HTML de la nouvelle page, le fichier CSS/JS est mis en cache et n'a donc pas besoin d'être téléchargé à nouveau. Cela peut faire une grande différence, surtout si vous avez un grand fichier de style et de script.