La recommandation d'inclure CSS avant JavaScript est-elle invalide?
dans d'innombrables endroits en ligne, j'ai vu la recommandation d'inclure CSS avant JavaScript. Le raisonnement est généralement, de cette forme :
quand il s'agit de commander votre CSS et JavaScript, vous voulez votre CSS venir en premier. La raison est que le fil de rendu a tout le l'information de style dont il a besoin pour rendre la page. Si le JavaScript inclut vient en premier, le moteur JavaScript doit analyser tout cela avant continuer sur la prochaine série de ressources. Cela signifie que le rendu le fil ne peut pas montrer complètement la page, puisqu'il n'a pas tous les styles dont il a besoin.
mes tests actuels révèlent quelque chose de très différent:
mon harnais d'essai
j'utilise le script Ruby suivant pour générer des délais spécifiques pour diverses ressources:
require 'rubygems'
require 'eventmachine'
require 'evma_httpserver'
require 'date'
class Handler < EventMachine::Connection
include EventMachine::HttpServer
def process_http_request
resp = EventMachine::DelegatedHttpResponse.new( self )
return unless @http_query_string
path = @http_path_info
array = @http_query_string.split("&").map{|s| s.split("=")}.flatten
parsed = Hash[*array]
delay = parsed["delay"].to_i / 1000.0
jsdelay = parsed["jsdelay"].to_i
delay = 5 if (delay > 5)
jsdelay = 5000 if (jsdelay > 5000)
delay = 0 if (delay < 0)
jsdelay = 0 if (jsdelay < 0)
# Block which fulfills the request
operation = proc do
sleep delay
if path.match(/.js$/)
resp.status = 200
resp.headers["Content-Type"] = "text/javascript"
resp.content = "(function(){
var start = new Date();
while(new Date() - start < #{jsdelay}){}
})();"
end
if path.match(/.css$/)
resp.status = 200
resp.headers["Content-Type"] = "text/css"
resp.content = "body {font-size: 50px;}"
end
end
# Callback block to execute once the request is fulfilled
callback = proc do |res|
resp.send_response
end
# Let the thread pool (20 Ruby threads) handle request
EM.defer(operation, callback)
end
end
EventMachine::run {
EventMachine::start_server("0.0.0.0", 8081, Handler)
puts "Listening..."
}
le mini-serveur CI-DESSUS me permet de régler retards arbitraires pour les fichiers JavaScript (serveur et client) et retards arbitraires CSS. Par exemple, http://10.0.0.50:8081/test.css?delay=500 me donne un délai de 500 ms transfert de la CSS.
j'utilise la page suivante pour tester.
<!DOCTYPE html>
<html>
<head>
<title>test</title>
<script type='text/javascript'>
var startTime = new Date();
</script>
<link href="http://10.0.0.50:8081/test.css?delay=500" type="text/css" rel="stylesheet">
<script type="text/javascript" src="http://10.0.0.50:8081/test2.js?delay=400&jsdelay=1000"></script>
</head>
<body>
<p>
Elapsed time is:
<script type='text/javascript'>
document.write(new Date() - startTime);
</script>
</p>
</body>
</html>
quand j'inclue le CSS en premier, la page prend 1,5 secondes pour rendre:
quand j'inclue le JavaScript en premier, la page prend 1,4 secondes pour rendre:
J'obtiens des résultats similaires dans Chrome, Firefox et Internet Explorer. Dans Opera, cependant, l'ordre n'a tout simplement pas d'importance.
ce qui semble se passer, c'est que L'interpréteur JavaScript refuse de démarrer jusqu'à ce que tous les CSS soient téléchargés. Il semble donc que le fait d'avoir JavaScript includes first est plus efficace puisque le thread JavaScript a plus de temps d'exécution.
est-ce que je manque quelque chose, est-ce que la recommandation de placer CSS includes avant JavaScript includes n'est pas correcte?
il est clair que nous pourrions ajouter async ou utiliser setTimeout pour libérer le fil de rendu ou mettre le code JavaScript dans le pied de page, ou utiliser un chargeur JavaScript. Il s'agit ici d'ordonner les bits essentiels JavaScript et CSS dans la tête.
13 réponses
C'est une question très intéressante. J'ai toujours mis mon CSS <link href="..."> s avant mon JS <script src="..."> s parce que "j'ai lu une fois que c'est mieux."Donc, vous avez raison, il est grand temps que nous fassions de la recherche!
j'ai mis en place mon propre harnais de test dans le noeud (code ci-dessous). Fondamentalement, Je:
- S'est assuré qu'il n'y avait pas de cache HTTP, de sorte que le navigateur devrait effectuer un téléchargement complet chaque fois qu'une page est chargée.
- Pour simuler la réalité, j'ai inclus jQuery et le H5BP (CSS, donc il y a une quantité décente de script/CSS à analyser)
- installe deux pages-une avec CSS avant script, l'autre avec CSS après script.
- a enregistré combien de temps il a fallu pour le script externe dans le
<head>pour exécuter - a enregistré combien de temps il a fallu pour le script en ligne dans le
<body>à exécuter, qui est analogue àDOMReady. - a retardé de 500m l'envoi de CSS et/ou de script au navigateur.
- a effectué le test 20 fois dans les 3 principaux navigateurs.
résultats
D'abord, avec le fichier CSS retardé de 500ms:
Browser: Chrome 18 | IE 9 | Firefox 9
CSS: first last | first last | first last
=======================================================
Header Exec | | |
Average | 583ms 36ms | 559ms 42ms | 565ms 49ms
St Dev | 15ms 12ms | 9ms 7ms | 13ms 6ms
------------|--------------|--------------|------------
Body Exec | | |
Average | 584ms 521ms | 559ms 513ms | 565ms 519ms
St Dev | 15ms 9ms | 9ms 5ms | 13ms 7ms
ensuite, j'ai mis jQuery à retarder de 500ms au lieu du CSS:
Browser: Chrome 18 | IE 9 | Firefox 9
CSS: first last | first last | first last
=======================================================
Header Exec | | |
Average | 597ms 556ms | 562ms 559ms | 564ms 564ms
St Dev | 14ms 12ms | 11ms 7ms | 8ms 8ms
------------|--------------|--------------|------------
Body Exec | | |
Average | 598ms 557ms | 563ms 560ms | 564ms 565ms
St Dev | 14ms 12ms | 10ms 7ms | 8ms 8ms
enfin, j'ai mis à la fois jQuery et le CSS à retarder de 500ms:
Browser: Chrome 18 | IE 9 | Firefox 9
CSS: first last | first last | first last
=======================================================
Header Exec | | |
Average | 620ms 560ms | 577ms 577ms | 571ms 567ms
St Dev | 16ms 11ms | 19ms 9ms | 9ms 10ms
------------|--------------|--------------|------------
Body Exec | | |
Average | 623ms 561ms | 578ms 580ms | 571ms 568ms
St Dev | 18ms 11ms | 19ms 9ms | 9ms 10ms
Conclusions
tout d'abord, il est important de noter que je m'appuie sur l'hypothèse que vous avez des scripts situés dans le <head> de votre document (par opposition à la fin du <body> ). Il y a plusieurs arguments pour expliquer pourquoi vous pouvez créer un lien vers vos scripts dans le <head> versus la fin du document, mais c'est hors du cadre de cette réponse. Il s'agit uniquement de savoir si <script> s doit précéder <link> s dans le <head> .
dans les navigateurs de bureau modernes, il ressemble à un lien vers CSS premier jamais fournit un gain de performance. Mettre CSS après script vous procure un gain trivial lorsque CSS et script sont retardés, mais vous donne des gains importants lorsque CSS est retardé. (Illustré par le last colonnes dans le premier ensemble de résultats.)
étant donné que le lien vers CSS last ne semble pas nuire à la performance mais peut fournir des gains dans certaines circonstances, vous devez lien vers les feuilles de style externes après vous Lien vers les scripts externes seulement sur les navigateurs de bureau "1519690920 si la performance des anciens navigateurs n'est pas un problème. Lire la suite mobile de la situation.
pourquoi?
historiquement, lorsqu'un navigateur rencontrait une étiquette <script> pointant vers une ressource externe, le navigateur arrêtait parsing le HTML, récupérer le script, l'Exécuter, puis continuer à analyser le HTML. En revanche, si le navigateur a rencontré un <link> pour une feuille de style externe, il serait continuer parsing le HTML tandis qu'il a récupéré le CSS fichier (en parallèle).
par conséquent, les conseils largement répétés de mettre feuilles de style d'abord-ils téléchargeraient d'abord, et le premier script à télécharger pourrait être chargé en parallèle.
cependant, les navigateurs modernes (y compris tous les navigateurs que j'ai testés ci-dessus) ont mis en œuvre analyse spéculative , où le navigateur "regarde en avant" dans le HTML et commence à télécharger des ressources avant scripts télécharger et exécuter.
dans les vieux navigateurs sans analyse spéculative, mettre les scripts en premier affectera les performances car ils ne se téléchargeront pas en parallèle.
Prise En Charge Du Navigateur
L'analyse spéculative a d'abord été mise en œuvre dans: (ainsi que le pourcentage d'utilisateurs de navigateur de bureau dans le monde entier utilisant cette version ou plus à partir de janvier 2012)
- Chrome 1 (WebKit 525) (100%)
- IE 8 (75%)
- Firefox 3.5 (96%)
- Safari 4 (99%)
- Opera 11.60 (85%)
au total, environ 85% des navigateurs de bureau utilisés aujourd'hui prennent en charge des chargements spéculatifs. Mettre des scripts avant CSS aura une pénalité de performance sur 15% des utilisateurs globalement ; YMMV basé sur le public spécifique de votre site. (Et rappelez-vous que le numéro de est à la baisse.)
sur les navigateurs mobiles, il est un peu plus difficile d'obtenir des nombres définitifs simplement en raison de la façon hétérogène le navigateur mobile et le paysage D'OS est. Depuis Rendu spéculatif a été mis en œuvre dans WebKit 525 (publié en mars 2008), et à peu près chaque navigateur mobile valable est basé sur WebKit, nous pouvons conclure que "la plupart" des navigateurs mobiles devrait prise en charge. Selon quirksmode , iOS 2.2 / Android 1.0 utilisez WebKit 525. Je ne sais pas à quoi ressemble Windows Phone.
cependant, j'ai effectué le test sur mon appareil Android 4, et tandis que j'ai vu des nombres similaires aux résultats de bureau, je l'ai accroché à la nouvelle fantastique débogueur à distance dans Chrome pour Android, et onglet Réseau a montré que le navigateur était en fait en attente de télécharger le CSS jusqu'à ce que le JavaScripts complètement chargé – en d'autres termes, même le plus récent la version de WebKit pour Android ne semble pas supporter l'analyse spéculative. je soupçonne qu'il pourrait être éteint en raison des contraintes de CPU, de mémoire, et/ou de réseau inhérentes aux appareils mobiles.
Code
pardonnez la négligence – c'était Q & D.
app.js
var express = require('express')
, app = express.createServer()
, fs = require('fs');
app.listen(90);
var file={};
fs.readdirSync('.').forEach(function(f) {
console.log(f)
file[f] = fs.readFileSync(f);
if (f != 'jquery.js' && f != 'style.css') app.get('/' + f, function(req,res) {
res.contentType(f);
res.send(file[f]);
});
});
app.get('/jquery.js', function(req,res) {
setTimeout(function() {
res.contentType('text/javascript');
res.send(file['jquery.js']);
}, 500);
});
app.get('/style.css', function(req,res) {
setTimeout(function() {
res.contentType('text/css');
res.send(file['style.css']);
}, 500);
});
var headresults={
css: [],
js: []
}, bodyresults={
css: [],
js: []
}
app.post('/result/:type/:time/:exec', function(req,res) {
headresults[req.params.type].push(parseInt(req.params.time, 10));
bodyresults[req.params.type].push(parseInt(req.params.exec, 10));
res.end();
});
app.get('/result/:type', function(req,res) {
var o = '';
headresults[req.params.type].forEach(function(i) {
o+='\n' + i;
});
o+='\n';
bodyresults[req.params.type].forEach(function(i) {
o+='\n' + i;
});
res.send(o);
});
css.html
<!DOCTYPE html>
<html>
<head>
<title>CSS first</title>
<script>var start = Date.now();</script>
<link rel="stylesheet" href="style.css">
<script src="jquery.js"></script>
<script src="test.js"></script>
</head>
<body>
<script>document.write(jsload - start);bodyexec=Date.now()</script>
</body>
</html>
js.html
<!DOCTYPE html>
<html>
<head>
<title>CSS first</title>
<script>var start = Date.now();</script>
<script src="jquery.js"></script>
<script src="test.js"></script>
<link rel="stylesheet" href="style.css">
</head>
<body>
<script>document.write(jsload - start);bodyexec=Date.now()</script>
</body>
</html>
test.js
var jsload = Date.now();
$(function() {
$.post('/result' + location.pathname.replace('.html','') + '/' + (jsload - start) + '/' + (bodyexec - start));
});
jquery.js était jquery-1.7.1.min.js
il y a deux raisons principales pour mettre CSS avant JavaScript.
-
vieux navigateurs (Internet Explorer 6-7, Firefox 2, etc.) bloquerait tous les téléchargements ultérieurs quand ils ont commencé à télécharger un script. Donc si vous avez
a.jssuivi deb.cssils sont téléchargés séquentiellement: d'abord a puis B. Si vous avezb.csssuivi dea.jsils sont téléchargés en parallèle de sorte que la page se charge plus rapidement. -
rien n'est rendu tant que toutes les feuilles de style ne sont pas téléchargées - c'est vrai dans tous les navigateurs. Les Scripts sont différents - ils bloquent le rendu de tous les éléments DOM qui sont au-dessous de la balise script dans la page. Si vous mettez vos scripts dans la tête alors cela signifie que la page entière est bloquée du rendu jusqu'à ce que toutes les feuilles de style et tous les scripts sont téléchargés. Alors qu'il est logique de bloquer tout le rendu pour les feuilles de style (de sorte que vous obtenez le correct styling la première fois et d'éviter le flash de FOUC contenu non découpé), il ne fait pas de sens de bloquer le rendu de la page entière pour les scripts. Souvent, les scripts n'affectent aucun élément DOM ou juste une portion d'éléments DOM. il est préférable de charger les scripts aussi bas que possible dans la page, ou encore mieux de les charger de manière asynchrone.
c'est amusant de créer des exemples avec Cuzillion . Exemple, cette page a un script dans la tête de sorte que la page entière est vide jusqu'à ce qu'il soit fait téléchargement. Cependant, si nous déplaçons le script à la fin du bloc de corps, l'en-tête de page est rendu puisque ces éléments DOM se trouvent au-dessus de la balise SCRIPT, comme vous pouvez le voir sur cette page .
Je ne voudrais pas insister trop sur les résultats que vous avez obtenus, je crois que c'est subjectif, mais j'ai une raison de vous expliquer qu'il est préférable de mettre dans CSS avant js.
lors du chargement de votre site web, il y a deux scénarios que vous pouvez voir:
CAS 1: écran blanc > non stylé site > style de site web > interaction > style de site web interactif
Cas 2: écran blanc > site web non structuré > interaction > site web structuré > site web structuré et interactif
Je ne peux pas imaginer que quelqu'un choisisse le cas 2. Cela signifierait que les visiteurs qui utilisent des connexions Internet lentes seront confrontés à un site web non identifié, qui leur permet d'interagir avec elle en utilisant Javascript (depuis qui est déjà chargé). En outre, la quantité de temps passé à regarder un non stylé site web serait agrandie de cette façon. Pourquoi quelqu'un voudrait-il?
Il fonctionne mieux que jQuery états
" lors de l'utilisation de scripts qui dépendent de la valeur des propriétés de style CSS, il est important de faire référence aux feuilles de style externes ou au style embed les éléments avant de référencer les scripts".
lorsque les fichiers sont chargés dans le mauvais ordre (d'abord JS, puis CSS), tout code Javascript se fier aux propriétés définies dans les fichiers CSS (par exemple la largeur ou la hauteur d'un div) ne sera pas chargé correctement. Il semble qu'avec un mauvais ordre de chargement, les propriétés correctes soient "parfois" connues de Javascript (peut-être est-ce dû à une condition de course?). Cet effet semble plus ou moins grand selon le navigateur utilisé.
vos tests ont-ils été effectués sur votre ordinateur personnel ou sur un serveur web? Il s'agit d'une page blanche ou d'un système complexe en ligne avec des images, des bases de données, etc.? Vos scripts exécutent-ils une simple action d'événement de vol stationnaire, ou sont-ils un élément central de la façon dont votre site Web rend et interagit avec l'utilisateur? Il y a plusieurs choses à considérer ici, et la pertinence de ces recommandations deviennent presque toujours des règles lorsque vous vous aventurez dans le développement de haut calibre web.
le but de la règle "put stylesheets at the top and scripts at the bottom" est que, en général, il est le meilleur moyen d'atteindre optimal rendu progressif , qui est critique pour l'expérience de l'utilisateur.
mis à part tout le reste: en supposant que votre test est valide, et que vous produisez vraiment des résultats contraires aux règles populaires, ce ne serait pas une surprise, vraiment. Chaque site web (et tout ce qu'il faut pour chose apparaissent sur l'écran d'un utilisateur) est différent et L'Internet est en constante évolution.
j'inclus les fichiers CSS avant Javascript pour une raison différente.
si mon Javascript a besoin de faire le dimensionnement dynamique d'un élément de page (pour les cas de coin où CSS est vraiment un main à l'arrière), alors charger le CSS après que le JS se rouille peut conduire à des conditions de course, où l'élément est redimensionné avant que les styles CSS soient appliqués et par conséquent semble étrange quand les styles enfin kick in. Si je charge le CSS à l'avance je peux garantir que les choses fonctionnent dans l'intention l'ordre et que la mise en page finale est ce que je veux être.
la recommandation d'inclure CSS avant JavaScript est-elle invalide?
pas si vous le considérez comme une simple recommandation. Mais si vous le traitez comme une règle dure et rapide? oui, il est invalide.
de https://developer.mozilla.org/en-US/docs/Web/Reference/Events/DOMContentLoaded
feuille de style charge l'exécution de script de bloc, donc si vous avez un
<script>après un<link rel="stylesheet" ...>la page ne va pas finir d'analyser - et DOMContentLoaded ne tirera pas tant que la feuille de style n'est pas chargée.
il semble que vous ayez besoin de savoir sur quoi chaque script se base et de vous assurer que l'exécution du script est retardée jusqu'après l'événement d'achèvement juste. Si le script s'appuie uniquement sur le DOM, il peut reprendre dans ondomready/domcontentcharged, s'il s'appuie sur des images à charger ou des feuilles de style à appliquer, alors si je lis correctement la référence ci-dessus, ce code doit être différée jusqu'à l'événement onload.
Je ne pense pas qu'une taille de chaussette convienne à tous, même si c'est la façon dont elles sont vendues et je sais qu'une taille de chaussure ne convient pas à tous. Je ne pense pas qu'il y ait une réponse définitive à laquelle charger en premier, styles ou script. Il s'agit plutôt d'une décision au cas par cas de ce qui doit être chargé dans quel ordre et de ce qui peut être différé plus tard comme n'étant pas sur le "chemin critique".
pour parler à l'observateur cela a commenté qu'il est préférable de retarder la capacité des utilisateurs d'interagir jusqu'à ce que la feuille est jolie. Il y en a beaucoup parmi vous et vous agacez vos homologues qui ressentent le contraire. Ils sont venus à un site pour accomplir un but et les retards à leur capacité d'interagir avec un site en attendant des choses qui n'ont pas d'importance pour terminer le chargement sont très frustrants. Je ne dis pas que vous vous trompez, seulement que vous devez savoir qu'il existe une autre faction qui ne partage pas votre priorité.
cette question s'applique particulièrement à toutes les annonces placées sur les sites web. J'aimerais que les auteurs de site rendent juste divs placeholder pour le contenu publicitaire et fait en sorte que leur site a été chargé et interactif avant d'injecter les annonces dans un événement onload. Même alors je voudrais voir les annonces chargées en série au lieu de tous à la fois parce qu'ils ont un impact sur ma capacité à faire défiler même le contenu du site pendant que les annonces gonflées chargent. Mais c'est juste l'une des personnes du point de vue.
- connaissez vos utilisateurs et ce qu'ils apprécient.
- connaître vos utilisateurs et l'environnement de navigation qu'ils utilisent.
- Savoir ce que chaque fichier, et ses pré-requis. Tout faire fonctionner aura priorité sur la vitesse et la beauté.
- utilisez des outils qui vous montrent la ligne de temps du réseau lors du développement.
- dans chacun des les environnements que vos utilisateurs utilisent. Il peut être nécessaire de modifier dynamiquement (côté serveur, lors de la création de la page) l'ordre de chargement en fonction de l'environnement de l'utilisateur.
- dans le doute, modifiez l'ordre et la mesure à nouveau.
- il est possible que les styles de mélange et les scripts dans l'ordre de chargement soient optimaux; pas tous l'un alors tous les autres.
- expérimente non seulement dans quel ordre charger les fichiers, mais où. De la tête? Dans Le Corps? Après Le Corps? DOM prêt / chargé? Chargé?
- prendre en compte les options async et defer lorsque cela est approprié pour réduire le délai net que l'utilisateur connaîtra avant d'être en mesure d'interagir avec la page. Test pour déterminer si elles aident ou blessé.
- il y aura toujours des compromis à considérer lors de l'évaluation de l'ordre de charge optimal. Jolie vs Réactif étant juste.
mise à jour 2017-12-16
Je n'étais pas sûr des tests en OP. J'ai décidé d'expérimenter un peu et j'ai fini par détruire certains mythes.
synchrone
<script src...>bloquera le téléchargement des ressources ci-dessous jusqu'à ce qu'il est téléchargé et exécuté
Ce n'est plus vrai . Jetez un oeil à la cascade générée par Chrome 63:
<head>
<script src="//alias-0.redacted.com/payload.php?type=js&delay=333&rand=1"></script>
<script src="//alias-1.redacted.com/payload.php?type=js&delay=333&rand=2"></script>
<script src="//alias-2.redacted.com/payload.php?type=js&delay=333&rand=3"></script>
</head>
<link rel=stylesheet>ne bloque pas le téléchargement et l'exécution de scripts en dessous de it
C'est inexact . La feuille de style ne bloque pas le téléchargement mais elle bloque l'exécution du script ( petite explication ici ). Jetez un oeil à la performance graphique généré par Chrome 63:
<link href="//alias-0.redacted.com/payload.php?type=css&delay=666" rel="stylesheet">
<script src="//alias-1.redacted.com/payload.php?type=js&delay=333&block=1000"></script>
compte tenu de ce qui précède, les résultats dans OP peuvent être expliqués comme suit:
CSS First:
CSS Download 500ms:<------------------------------------------------>
JS Download 400ms:<-------------------------------------->
JS Execution 1000ms: <-------------------------------------------------------------------------------------------------->
DOM Ready @1500ms: ◆
JS Première:
JS Download 400ms:<-------------------------------------->
CSS Download 500ms:<------------------------------------------------>
JS Execution 1000ms: <-------------------------------------------------------------------------------------------------->
DOM Ready @1400ms: ◆
Je ne sais pas exactement comment votre temps de test "render" comme votre utilisation du script java. Toutefois, considérez ce
une page sur votre site est de 50k ce qui n'est pas déraisonnable. L'utilisateur est sur la côte est, tandis que votre serveur est à l'ouest. MTU n'est certainement pas 10k donc il y aura quelques voyages aller-retour. Il peut prendre 1/2 une seconde pour recevoir votre page et feuilles de style. Typiquement (pour moi) javascript (via jQuery plugin et autres) est beaucoup plus que CSS. Il y a aussi ce que se produit lorsque votre connexion internet s'étouffe à mi-chemin sur la page, mais laisse ignorer que (il m'arrive de temps en temps et je crois que la css rend, mais je ne suis pas sûr à 100%).
puisque css est en tête il peut y avoir des connexions supplémentaires pour l'obtenir ce qui signifie qu'il peut potentiellement finir avant la page fait. Quoi qu'il en soit pendant le type le reste de la page prend et les fichiers javascript (qui est beaucoup plus d'octets) la page est non activée ce qui fait apparaître le site / connexion lent.
même si l'interpréteur js refuse de démarrer jusqu'à ce que la CSS soit terminée, le temps nécessaire pour télécharger le code javascript est particulièrement long lorsque le serveur est éloigné de la css, ce qui rend le site peu attrayant.
Sa petite optimisation, mais c'est la raison pour elle.
Voici une RÉSUMÉ de toutes les réponses ci-dessus (ou peut-être ci-dessous pour plus tard :)
pour les navigateurs modernes, mettez css où vous le souhaitez. Ils analyseront votre fichier html (qu'ils appellent parsing spéculatif ) et commenceront à télécharger css en parallèle avec html parsing.
pour les vieux navigateurs continuer à mettre css sur le dessus (si vous ne voulez pas montrer une page nue mais interactive d'abord).
pour tous les navigateurs, mettez javascript le plus loin possible sur la page, car il va arrêter l'analyse de votre html. De préférence, téléchargez-le de façon asynchrone (appel ajax)
il y a aussi, certains résultats expérimentaux pour un cas particulier qui prétend mettre javascript en premier (par opposition à la sagesse traditionnelle de mettre CSS en premier) donne de meilleures performances, mais il n'y a pas de raisonnement logique donné pour cela, et manque de validation concernant l'applicabilité étendue, de sorte que vous pouvez l'ignorer pour l'instant.
donc, pour répondre à la question: Oui. La recommandation d'inclure le CSS avant JS n'est pas valable pour les navigateurs modernes. Mettez CSS où vous voulez, et mettez JS vers la fin, comme possible.
Steve Souders a déjà donné une réponse définitive mais...
je me demande s'il y a un problème avec le test original de Sam et la répétition de Josh.
les deux tests semblent avoir été effectués sur des connexions à faible latence où la mise en place de la connexion TCP aura un coût minime.
comment cela affecte le résultat du test je ne suis pas sûr et je voudrais regarder les chutes d'eau pour les tests sur un "normal" connexion de latence mais...
Le premier fichier téléchargé devrait obtenir la connexion utilisée pour la page html, et le deuxième fichier téléchargé la nouvelle connexion. (Les rougeurs au début modifie cette dynamique, mais il n'est pas fait ici)
dans les navigateurs plus récents la deuxième connexion TCP est ouverte spéculativement de sorte que la connexion est réduite / disparaît, dans les navigateurs plus anciens ce n'est pas vrai et la deuxième connexion sera ont la surcharge d'être ouvert.
tout à fait comment/si cela affecte le résultat des tests, Je ne suis pas sûr.
je pense que cela ne sera pas vrai pour toutes les affaires. Parce que CSS va télécharger parallèle mais js cant. Dans le même cas,
au lieu d'avoir une seule css, prenez 2 ou 3 fichiers css et essayez-les de cette façon,
1) css..CSS..js 2) le css..js..CSS 3) js..CSS..css
je suis sûr css..CSS..js donnera de meilleurs résultats que tous les autres.
nous devons garder à l'esprit que les nouveaux navigateurs ont travaillé sur leurs moteurs Javascript, leurs analyseurs et ainsi de suite, en optimisant les problèmes de code commun et de balisage d'une manière que les problèmes rencontrés dans les navigateurs antiques tels que <=IE8 ne sont plus pertinents, non seulement en ce qui concerne le balisage, mais aussi à l'utilisation de variables JavaScript, sélecteurs d'éléments, etc. Je peux voir dans un avenir pas si lointain une situation où la technologie a atteint un point où la performance n'est plus vraiment un problème.
personnellement, Je ne mettrais pas trop l'accent sur une telle" sagesse populaire."Ce qui était peut-être vrai dans le passé pourrait bien ne pas l'être aujourd'hui. Je suppose que toutes les opérations relatives à l'interprétation et au rendu d'une page web sont totalement asynchrones ("fetching" quelque chose et "acting upon it" sont deux choses entièrement différentes qui pourraient être gérées par des fils différents, etc. ), et en tout cas entièrement au-delà de votre contrôle ou votre préoccupation.
j'ai mis des références CSS dans la partie" head " du document, ainsi que toute référence à des scripts externes. (Certains scripts peuvent exiger d'être placés dans le corps, et si oui, les obliger.)
au-delà ... si vous observez que "cela semble être plus rapide/plus lent que cela, sur ce/ce navigateur", traitez cette observation comme une intéressante mais non pertinente curiosity et ne la laissez pas influencer votre conception décision. Trop de choses changent trop vite. (Quelqu'un veut faire des paris sur combien de minutes ce sera avant que L'équipe de Firefox sort avec encore une autre interim-release de leur produit? Ouais, moi non plus.)