在网上无数的地方，我都看到过在JavaScript之前使用CSS的建议。推理一般是这样的:
当涉及到CSS和JavaScript的排序时，你需要你的CSS
先来。原因是呈现线程拥有所有的
样式显示页面所需的信息。如果JavaScript
include首先出现，JavaScript引擎必须先解析所有内容
继续到下一组资源。这意味着渲染
线程不能完全显示页面，因为它没有所有的
它需要的样式。
我的实际测试揭示了一些完全不同的东西:
我的测试装备
我使用下面的Ruby脚本为各种资源生成特定的延迟:
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..."
}
上面的迷你服务器允许我为JavaScript文件(包括服务器和客户端)设置任意延迟和任意CSS延迟。例如，http://10.0.0.50:8081/test.css?delay=500给我一个500毫秒延迟传输CSS。
我使用下面的页面进行测试。
<!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>
当我首先包含CSS时，页面需要1.5秒来呈现:
当我首先包含JavaScript时，页面需要1.4秒来呈现:
我在Chrome、Firefox和ie浏览器上得到了类似的结果。然而，在Opera中，顺序并不重要。
似乎发生的情况是，JavaScript解释器在下载所有CSS之前拒绝启动。因此，首先使用JavaScript包含似乎更有效，因为JavaScript线程获得了更多的运行时间。
我遗漏了什么吗?把CSS include放在JavaScript include之前的建议是不正确的吗?
显然，我们可以添加async或使用setTimeout来释放呈现线程，或将JavaScript代码放在页脚中，或使用JavaScript加载器。这里的重点是关于基本JavaScript位和CSS位在头部的排序。
在JavaScript之前包含CSS的建议是无效的吗?
如果你只是把它当作一个建议就不会了。但如果你把它当做一个硬性规定呢?是的，是无效的。
从窗口:DOMContentLoaded事件:
样式表加载块脚本执行，因此如果您有一个<script>
在<link rel="stylesheet"…>页面将不会完成解析
和DOMContentLoaded将不会触发—直到样式表被加载。
似乎您需要知道每个脚本依赖于什么，并确保脚本的执行延迟到正确的完成事件之后。如果脚本只依赖于DOM，它可以在ondomready/domcontentloaded中恢复。如果它依赖于要加载的图像或要应用的样式表，那么如果我正确地阅读了上面的引用，那么该代码必须延迟到onload事件。
我不认为一个尺码的袜子适合所有人，尽管这是他们销售的方式，我知道一个尺码的鞋子不适合所有人。我不认为有一个明确的答案，首先加载样式或脚本。它更多的是一个个案决定，什么必须以什么顺序加载，什么可以推迟到以后，因为不是在“关键路径”上。
To speak to the observer that commented that it is better to delay the users ability to interact until the sheet is pretty. There are many of you out there and you annoy your counterparts that feel the opposite. They came to a site to accomplish a purpose and delays to their ability to interact with a site while waiting for things that don't matter to finish loading are very frustrating. I am not saying that you are wrong, only that you should be aware that there is another faction that exists that does not share your priority.
这个问题尤其适用于所有放在网站上的广告。如果网站作者只渲染广告内容的占位符div，并确保他们的网站在注入广告在onload事件之前是加载和交互式的，我将会很喜欢。即使这样，我也希望看到广告是连续加载的，而不是一次性加载，因为它们会影响我在加载臃肿的广告时甚至滚动网站内容的能力。但这只是一个人的观点。
Know your users and what they value.
Know your users and what browsing environment they use.
Know what each file does, and what its prerequisites are. Making everything work will take precedence over both speed and pretty.
Use tools that show you the network time line when developing.
Test in each of the environments that your users use. It may be needed to dynamically (server side, when creating the page) alter the order of loading based on the users environment.
When in doubt, alter the order and measure again.
It is possible that intermixing styles and scripts in the load order will be optimal; not all of one then all of the other.
Experiment not just what order to load the files but where. head? In body? After body? DOM Ready/Loaded? Loaded?
Consider async and defer options when appropriate to reduce the net delay the user will experience before being able to interact with the page. Test to determine if they help or hurt.
There will always be trade-offs to consider when evaluating the optimal load order. Pretty vs. responsive being just one.
更新2017-12-16
我不确定op的测试。我决定做一点实验，最终打破了一些神话。
同步<脚本src…>将阻止资源的下载
直到下载并执行为止
这已经不是事实了。看看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>
样式表>将不会阻止下载和执行
下面的脚本
这是不正确的。样式表不会阻止下载，但会阻止脚本的执行(这里有一点解释)。看看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>
综上所述，OP的结果可以解释如下:
CSS:
CSS Download 500 ms:<------------------------------------------------>
JS Download 400 ms:<-------------------------------------->
JS Execution 1000 ms: <-------------------------------------------------------------------------------------------------->
DOM Ready @1500 ms: ◆
JavaScript:
JS Download 400 ms:<-------------------------------------->
CSS Download 500 ms:<------------------------------------------------>
JS Execution 1000 ms: <-------------------------------------------------------------------------------------------------->
DOM Ready @1400 ms: ◆
