Pourquoi ne pas incorporer des styles / scripts en HTML au lieu de créer des liens?

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 de compilation côté serveur pour faire tout cela à notre place, pourquoi ne pas aller plus loin et incorporer ces styles et scripts concaténés dans le code HTML?

<style>.all{width:100%;}.my{display:none;}.css{color:white;}</style>
<!-- later... -->
<script>var all, my, js;</script>

Cela fait deux demandes HTTP de moins, mais je n'ai pas encore vu cette technique en pratique. Pourquoi pas?

Parce que la sauvegarde des requêtes HTTP n’est pas très utile lorsque vous y parvenez en cassant 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 nombreuses requêtes sur des pages extrêmement différentes. S'ils sont regroupés dans la même page HTML, ils doivent être retransmis à chaque fois. Unique. Demande.

Le code HTML de cette page, par exemple, est de 13 Ko actuellement. Les 180 Ko de CSS sont passés au cache, de même que les 360 Ko de JS. Les deux hits de cache ont pris des quantités minimales de temps et ne consommaient pratiquement pas de bande passante. Sortez le profileur réseau de votre navigateur et essayez-le sur d'autres sites.

Tout simplement parce que la performance Web compte vraiment! 99% de fois, les temps de réponse de l'utilisateur final seront plus rapides.

Voici quelques exemples de Velocity Conf.

• Bing - Une page ralentie de 2 secondes a entraîné une baisse de 4,3% du revenu / utilisateur.
• Google - Un retard de 400 millisecondes a entraîné une baisse de 0,59% du nombre de recherches / utilisateur.
• Yahoo ! - Un ralentissement de 400 millisecondes a entraîné une baisse de 5 à 9% du trafic de pages complètes.
• Shopzilla - En accélérant leur site de 5 secondes, le taux de conversion a augmenté de 7 à 12%, le nombre de sessions de marketing sur les moteurs de recherche a été doublé et le nombre de serveurs requis a été réduit de moitié.
• Mozilla - En économisant 2,2 secondes sur leurs pages de destination, le nombre de conversions de téléchargements a augmenté de 15,4%, ce qui, selon eux, entraînera 60 millions de téléchargements de plus par an pour Firefox.
• Netflix - L'adoption d'une seule optimisation, la compression gzip, a permis une accélération de 13 à 25% et une réduction de 50% du trafic réseau sortant.

Steve Souders, pionnier de l'optimisation de la performance Web,

80 à 90% du temps de réponse de l'utilisateur final est passé sur le front-end - 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 en-têtes de cache). Les scripts JavaScript et CSS inséré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éférencer 300 Ko de scripts et de ne pas croire que tout le monde a une bande passante de 100 Mbits / s avec une faible latence, exécutant une seule application (le navigateur) ouverte sur votre site Web. 99% de fois, les temps de réponse de l'utilisateur final seront plus rapides.

La fréquence à laquelle les composants JavaScript et CSS externes sont mis en cache par rapport au nombre de documents HTML demandés est également importante. Si les utilisateurs de votre site disposent de plusieurs pages vues par session et qu'un grand nombre de vos pages réutilisent les mêmes scripts et feuilles de style (ensembles), les fichiers externes mis en cache offrent un avantage potentiel plus important.

Toutefois, l’inclusion est parfois préférable pour une application à une page ou pour des sites Web avec une seule page vue par session. Il n’existe pas de règle d’or et l’oublie généralement car il s’agit principalement de sites Web très spécifiques, réellement concernés par les performances de l’utilisateur final.

Vous pouvez lire ici pourquoi la performance est importante (Avertissement: je suis l'auteur)

La dernière version de HTTP a été créée en 1999. En 1999, tout le monde était connecté à Internet par accès commuté. 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 inclure «car elles gênent la mise en cache» sont un peu trompeuses, en particulier à l’ère de l’Internet ultrarapide. Lorsque vous effectuez les calculs, il existe souvent une différence négligeable entre les temps de chargement avec les utilisateurs avec cache-warm et avec cache-cold si vous avez en ligne. Le fait qu’il y ait une petite différence n’est pas inhérent à la fois en ligne, mais à la conception inflexible de HTTP / 1.1.

Le protocole SPDY implémente quelque chose appelé push serveur . Cela prend essentiellement en compte le document HTML lui-même et le protocole. Un serveur intelligent saura quelles ressources le client possède déjà. Un serveur muet enverra simplement tout, peu importe, ce qui constituera un avantage en termes de performances, mais qui peut coûter cher 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 principe, le navigateur peut envoyer un signal pour annuler le transfert du serveur.

HTTP / 2.0 est basé sur SPDY et implémentera probablement le serveur push, mais vous pouvez théoriquement commencer à utiliser SPDY aujourd'hui. La véritable raison pour laquelle nous ne sommes pas en ligne est donc héritée: les protocoles existants sont anciens et ne sont pas suffisamment flexibles pour permettre une «intégration au niveau du protocole».

Outre les problèmes de mise en cache et de récupération soulevés par les autres réponses, j'aimerais mettre en évidence un autre problème, plus obscur: l' analyse .

Le 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 déclenchés en HTML. Ce problème disparaît lorsque vous fournissez CSS et JavaScript en tant que ressources externes, car ils ne doivent plus prendre en compte le contexte d'analyse "parent".

Si vous diffusez votre contenu au format XML, vous utilisez une partie des sections CDATA. CDATA, cependant, vient 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>

Inliners Méfiez-vous.

La séparation du contenu du style de sa présentation est généralement un avantage plus grand que moins de requêtes http.

La séparation de 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.

Pour vous, question spécifique cependant ... Si le serveur est conçu pour effectuer la minification lui-même, les actifs sont plus difficiles à gérer et à résoudre 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 framework ruby ​​on rails réduit désormais ses actifs de production. 5 à 10 requêtes http supplémentaires ne constituent généralement pas le goulot d'étranglement, mais plus s'il y a plus de 100 requêtes http (que vous obtenez souvent avec des images).

L'étape supplémentaire consistant à inclure le code dans les pages aurait l'inconvénient de disposer de pages plus volumineuses, ce qui vous obligerait à gérer la séquence de téléchargement avec soin et à ce que la page ne puisse pas afficher le contenu souvent sans le reste de la (maintenant grande) page. en cours de téléchargement.

1. Réduire au minimum le codage en double. pour gagner du temps (vous pouvez réutiliser le style et la fonction JS codés pour une page).
2. Minimiser les efforts de changement. (Si votre client vous demande de changer la couleur du bouton du site Web, vous devez parcourir une page sur une).
3. Réduisez le temps de chargement (si votre CSS et votre JS dupliquent, cela signifie une taille de page individuelle et un temps de téléchargement important, mais le CSS JS classique n’a pas besoin de télécharger encore et encore).
4. Utilisation à distance. (vous pouvez placer votre CSS commun JS JS dans un endroit distant. Ce n'est pas le même serveur hébergé)
5. Réduire le temps de correction des bugs. S'il existe un bogue dans une fonction, vous devez vous y rendre page par page pour corriger les bogues dans JS et CSS intégrés.
6. Pour augmenter le référencement (séparez simplement le contenu avec des métadonnées)
7. Plus propre et plus compréhensible du code (si vous incorporez tout dans un fichier, le débogage et la clarté du code disparaîtront. Chaque page sera une très longue page).
8. De plus, cela vous aidera à réduire la taille du produit.
9. Mais vous pouvez toujours envisager d’incorporer le plus unique dans la même page.

Nous ne devrions 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 une quantité minimale de CSS / JS possible.

à la place, nous utilisons des liens coz lorsque nous utilisons des liens pour lier css / scripts

La vitesse du site augmente pour les requêtes de plusieurs pages:

Quand une personne visite pour la première fois votre site Web, son navigateur télécharge le code HTML de la page actuelle, ainsi que le fichier CSS et JS lié. Lorsqu'ils accèdent à 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, en particulier si vous avez un grand fichier de style et de script.