对了，再嘱咐你们一点，匿名函数我只能用统一的命名显示出来，所以你们调试的时候，估计不会很愉快。要根据情况决定是否真的有必要使用匿名函数啊~
我回来了~
所以说，我们首先可以合理加载执行script来减少html解析的阻塞，其实还有css的元素，因为css会阻塞css的执行，毕竟js有可能要操作css嘛。
还有什么回流、重绘什么的，这里就不再重复了。
有兴趣的朋友可以用某些网站查看一些performance，看看自己的掌握程度，有问题欢迎讨论。
猜测，类似词法解析和语法解析，词法解析先获取到要下载的内容，或者绑定在document上的事件，所以之后出发DOMContentLoad的时候会触发之前绑定的事件，而且没有在主线程中显示
总结本文简单的说了两个点，一是network的timing栏，二是performance panel，只要掌握了这两个功能的使用方法，就可以快速定位网站性能问题，进而进行优化，早点下班美滋滋~
常见优化方案
开启压缩
图片使用webp
cdn
提取关键帧资源，优先加载
代码分片，延迟加载
预加载，preload prefetch等
script defer async
域名分片，减少请求数
服务端渲染
如果已经升级为https，可以考虑使用http2.0。两个点：一个头信息压缩，二是解决了队头阻塞问题，三是增加了服务端push。
资源预取，混合应用可以加离线宝
在mvvm类框架进行前端渲染，我们可以使用defer加在我们的内容，在配上骨架图，保证用户看到的不是空白的页面。
当然少不了我们的业务代码，好的代码会让网站更稳定的运行下去
分析network的timing，然后通过本文最开始提及的各字段分析问题
如果你看过一些语言和框架，你会发现大同小异
不过，这些个优化只是在我们看来，还是不够完善的，我们需要知道真实的用户环境下是怎么样的，需要RUM(Real User Monitoring: 真实用户数据监测)，写个脚本来收集用户的访问情况，并可视化，作为我们的性能指标再好不过了。
这里推荐采用三组数据：
平均值: 平均速度
中位值: 中间速度
第95百分位值: 弱势网络、浏览器等数据，更全面
可以使用performance和Resource Timing API来进行数据收集
想做更多的优化，还是应该了解一下chromium源码，锦上添花。
如果不想看源码，那就让浏览器来告诉我们，它做了什么吧~
最后，在网站优化方面，前端能做的不是很多，真正的大头是在op和服务端，所以说，转行吧~