如果包含这个返回头，那html文件是边返回边解析的，此时上面的计算方法是合理的。如果不包含这个头，则html文件是整一个返回来后才开始解析，此时上面的计算方法就少算了html的加载时间，也就不够精准。这个返回头是由后台控制的。
知道这个有何用？
- 如果我们想说明直出的优化程度，最好先瞧瞧你的html返回头。如果不包含chunk返回头，考虑拿HTML5 performance里面的 navigationStart 作为打点1（这个API也是Android4.4及以上才支持），要不就要评估文件大小变化做点修正了。
- 对于没有启用chunk的html，建议不要inline太多跟渲染首屏内容无关的js在里面，这样会影响渲染时间。
细节4：写在html里面的script节点的加载和解析会影响 domContentLoaded 事件的触发时间
我们有时会用 domContentLoaded 事件代替 onload 事件，在页面准备好的时候做一些处理。然而要知道，domContentLoaded里面的dom不止包含我们常说的普通dom节点，还包括script节点。
试验一下，我们将页面里面外联的一个js文件阻塞住一段时间再放开，我们看下chrome控制台：
很明显，js文件的加载时间会影响这个事件的触发事件。那js代码的解析时间会不会影响？我们在最后一个外联js文件后面打了一个点，它的时间是：
所以js文件加载执行会影响domContentLoaded事件的执行时机。
知道这个有何用？
- 如果我们打算在domContentLoaded、onLoad 事件里面做一些特殊处理且这些处理比较重要（如跟渲染有关），那我们最好就不要在html里面直接外联一些跟渲染无关的js文件，可以考虑改用动态加载。
总结
研究首屏时间和资源加载是一件挺有意思的事情，大家利用好chrome控制台（特别是里面的network标签）以及fiddler可以挖掘出很多有趣的小细节小结论。别以为这是在没事找事，理解好这些对大家做首屏性能优化、定位因为js文件执行顺序错乱导致报错等场景是非常有好处的。所以发现什么记得与我共享哈~