场景一： 使用 async 异步加载脚本场景对 onload 的影响
示例代码：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test</title>
<!-- 请求时长为1秒的js资源 -->
<script src="http://localhost:3010/index.js?delay=1000" async></script>
</head>
<body>
</body>
</html>
浏览器表现如下：
通过上图可以看到，瀑布图中深蓝色竖线表示触发了DOMContentLoaded事件，而红色竖线表示触发了window.onload事件（下文中无特殊情况，不会再进行特殊标识），由图可以得知使用了 async 属性进行脚本的异步加载，仍会影响页面加载总体时长。
场景二：使用 defer 异步加载脚本场景对 onload 的影响
示例代码：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test</title>
<!-- 请求时长为1秒的js资源 -->
<script src="http://localhost:3010/index.js?delay=1000" defer></script>
</head>
<body>
</body>
</html>
浏览器表现如下：
由图可以得知使用了 defer 属性进行脚本的异步加载，除了正常的在DOMContentLoaded之后触发脚本执行，也影响页面加载总体时长。
场景三：异步脚本中再次加载脚本，也就是常见的动态加载脚本、样式资源的情况
html 代码保持不变，index.js内示例代码：
const script = document.createElement('script')
// 请求时长为0.6秒的js资源
script.src = 'http://localhost:3010/index2.js?delay=600'
script.onload = () => {
console.log('js 2 异步加载完毕')
}
document.body.appendChild(script)
结果如下：
从瀑布图可以看出，资源的连续加载，导致了 onload 事件整体延后了，这也是我们再页面中非常常见的一种操作，通常懒加载一些不重要或者首屏外的资源，其实这样也会导致页面整体指标的下降。
不过值得强调的一点是，这里有个有意思的地方，如果我们把上述代码进行改造，删除最后一行的document.body.appendChild(script)，发现 index2 的资源请求并没有发出，也就是说，脚本元素不向页面中插入，脚本的请求是不会发出的，但是也会有反例，这个我们下面再说。
在本示例中，后来我又把脚本请求换成了 css 请求，结果是一致的。
场景四：图片的懒加载/预加载
html 保持不变，index.js 用于加载图片，内容如下：
const img = document.createElement('img')
// 请求时长为0.5秒的图片资源
img.src = 'http://localhost:3010/index.png?delay=500'
document.body.appendChild(img)
结果示意：
表现是与场景三一样的，这个不再多说，但是有意思的来了，不一样的是，经过测试发现，哪怕删除最后一行代码：document.body.appendChild(img)，不向页面中插入元素，图片也会发出请求，也同样延长了页面加载时长，所以部分同学就要注意了，这是一把双刃剑：当你真的需要懒加载图片时，可以少写最后一行插入元素的代码了，但是如果大量的图片加载请求发出，哪怕不向页面插入图片，也真的会拖慢页面的时长。
趁着这个场景，再多说一句，一些埋点数据的上报，也正是借着图片有不需要插入 dom 即可发送请求的特性，实现成功上传的。
场景五：普通接口请求
html 保持不变，index.js 内容如下：
// 请求时长为500毫秒的请求接口
fetch('http://localhost:3010/api?delay=500')
结果如下图：
可以发现普通接口请求的发出，并不会影响页面加载，但是我们再把场景弄复杂一些，见场景六。
场景六：同时加载样式、脚本，脚本加载完成后，内部 http 接口请求，等请求结果返回后，再发出图片请求或修改 dom，这也是更贴近生产环境的真实场景
html 代码：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test</title>
<!-- 请求时长为1.2秒的css -->
<link rel="stylesheet" href="http://localhost:3010/index.css?delay=1200">
<!-- 请求时长为0.4秒的js -->
<script src="http://localhost:3010/index.js?delay=400" async></script>
</head>
<body>
</body>
</html>
index.js 代码：
async function getImage () {
// 请求时长为0.5秒的接口请求
await fetch('http://localhost:3010/api?delay=500')
const img = document.createElement('img')
// 请求时长为0.5秒的图片资源
img.src = 'http://localhost:3010/index.png?delay=500'
document.body.appendChild(img)
}
getImage()
结果图如下：
如图所示，结合场景五记的结果，虽然普通的 api 请求并不会影响页面加载时长，但是因为 api 请求过后，重新请求了图片资源（或大量操作 dom），依然会导致页面加载时间变长。这也是我们日常开发中最常见的场景，页面加载了 js，js 发出网络请求，用于获取页面渲染数据，页面渲染时加载图片或进行 dom 操作。
场景七：页面多媒体资源的加载
示例代码：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test</title>
</head>
<body>
<video src="http://localhost:3010/video.mp4?delay=500" controls></video>
</body>
</html>
结果如图：
对于视频这种多媒体资源的加载比较有意思，video 标签对于资源的加载是默认开启 preload 的，所以资源会默认进行网络请求（如需关闭，要把 preload 设置为 none ），可以看到红色竖线基本处于图中绿色条和蓝色条中间（实际上更偏右一些），图片绿色部分代表资源等待时长，蓝色部分代表资源真正的加载时长，且蓝色加载条在 onload 的竖线右侧，这说明多媒体的资源确实影响了 onload 时长，但是又没完全影响，因为设置了 500ms 的延迟返回资源，所以 onload 也被延迟了 500ms 左右，但一旦视频真正开始下载，这段时长已经不记录在 onload 的时长中了。
其实这种行为也算合理，毕竟多媒体资源通常很大，占用的带宽也多，如果一直延迟 onload，意味着很多依赖 onload 的事件都无法及时触发。
接下来我们把这种情况再复杂一些，贴近实际的生产场景，通常 video 元素是包含封面图 poster 属性的，我们设置一张延迟 1 秒的封面图，看看会发生什么，结果如下：
不出意外，果然封面图影响了整体的加载时长，魔鬼都在细节中，封面图也需要注意优化压缩。
场景八：异步脚本和样式资源一同请求
示例代码：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test</title>
<!-- 请求时长为1秒的css -->
<link rel="stylesheet" href="http://localhost:3010/index.css?delay=1000">
<!-- 请求时长为0.5秒的js -->
<script src="http://localhost:3010/index.js?delay=500" async></script>
</head>
<body>
</body>
</html>
浏览器表现如下：
可以看出 css 资源虽然没有阻塞脚本的加载，但是却延迟了整体页面加载时长，其中原因是 css 资源的加载会影响 render tree 的生成，导致页面迟迟不能完成渲染。
如果尝试把 async 换成 defer，或者干脆使用同步的方式加载脚本，结果也是一样，因结果相同，本处不再举例。
场景九：样式资源先请求，再执行内联脚本逻辑，最后加载异步脚本
我们把场景八的代码做一个改造，在样式标签和异步脚本标签之间，加上一个只包含空格的内联脚本，让我们看看会发生什么，代码如下：
<!DOCTYPE html>
<html lang="en">
<head>
<script>
console.log('页面js 开始执行')
</script>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test</title>
<!-- 请求时长为1秒的css -->
<link rel="stylesheet" href="http://localhost:3010/index.css?delay=2000">
<!-- 此标签仅有一个空格 -->
<script> </script>
<!-- 请求时长为0.5秒的js -->
<script src="http://localhost:3010/index.js?delay=500" async></script>
</head>
<body>
</body>
</html>
index.js 中的内容如下：
console.log("脚本 js 开始执行");
结果如下，这是一张 GIF，加载可能有点慢：
这个结果非常有意思，他到底发生了什么呢？
