看：
https://developers.google.com/speed/docs/insights/BlockingJS
谷歌在那里谈论“Render-Blocking JavaScript”，但在我看来，这个术语是不正确的、令人困惑的和误导的。这几乎看起来像“谷歌”也是不理解吗？
这一点是 Javascript 执行总是暂停/阻塞渲染并且也总是暂停/阻塞“HTML 解析器”（至少在 Chrome 和 Firefox 中）。如果是外部 js 文件，结合异步脚本标签，它甚至会阻止它！
因此，谈论通过例如使用异步来删除“阻止渲染的 Javascript”，意味着也存在非阻塞 Javascript，或者“异步 Javascript 执行”不会阻止渲染，但这不是真的！
正确的术语是：“渲染阻止下载”。使用 async 可以避免：下载 js 文件，不会暂停/阻止渲染。但是执行仍然会阻塞渲染。
另一个例子证实了谷歌似乎没有“理解”它。
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Test</title>
</head>
<body>
Some HTML line and this is above the fold
<script>
// Synchronous delay of 5 seconds
var timeWhile = new Date().getTime();
while( new Date().getTime() - timeWhile < 5000 );
</script>
</body>
</html>
我在 Firefox 和 Chrome 中对其进行了测试，它们在 5 秒后而不是在 5 秒内显示（渲染）：“一些 HTML 行，这是首屏”！！！！看起来 Google 认为在这种情况下，Javascript 不会阻塞渲染，但正如理论上所预期的那样，它会阻塞。在开始执行 js 之前，所有的 html 都已经在 DOM 中（除了 end body / html 标签），但是渲染还没有完成，将被暂停。因此，如果 Google 真的意识到了这一点，那么 Chrome 将首先完成渲染，然后再开始执行 javascript。
如果您采用上面的示例并且您正在使用：
<script src="delay.js" async></script>
或者
<script src="delay.js"></script>
而不是内部的javascript。然后它也可以给出与上面示例相同的结果。例如：
- 如果预加载器（扫描已经下载的文件）已经下载了“delay.js”，那么在“HTML 解析器”出现在 Javascript 部分之前。
- 通常来自 Google、Facebook 等的外部文件已经存储在缓存中，因此无需下载，它们只是从缓存中获取文件。
在这种情况下（以及异步），结果将与上面的示例相同（至少在很多情况下）。因为如果没有额外的下载时间，“Javascript 执行”将/可以在前面的 html 完成渲染之前开始。
因此，在这种情况下，您甚至可以考虑将“no-cache”/“no-store”放在 delay.js（甚至额外的延迟）上，以使您的页面渲染得更快。通过强制下载（或额外延迟），您将给浏览器一些额外的时间来完成前面的 html 的渲染，然后再执行渲染阻塞 Javascript。
所以我真的不明白为什么谷歌（和其他人）使用“Render-Blocking JavaScript”这个术语，而从理论和“现实生活”的例子来看，它看起来像是错误的术语和错误的想法。我看网上没有人讨论这个，所以我不明白。我知道我很聪明（j/k），但对我来说有点奇怪，成为唯一一个有上述想法的人。
