关注点
- HTML首屏渲染是效率低的(low performance),阻塞的(blocking),串行的(serial),即使在现代浏览器的优化下,表现依然差强人意,延迟页面load事件的触发时机
- 页面ready之后对于资源的操作和控制是高效的,非阻塞性的,并行的,可编程性的
为什么HTML首屏渲染性能如此之低?
一言以蔽之:
页面需要等待资源的加载
在回答这个问题之前,我们先来回过头看下上面的关注点:
HTML首屏渲染是效率低的(low performance),阻塞的(blocking),串行的(serial),即使在现代浏览器的优化下,表现依然差强人意,延迟页面load事件的触发时机
我们不禁要问:
浏览器就不能先把我的HTML展示出来,并行把所有的CSS/JS加载好,以最快的速度加载出来么?
理想是美好的,现实是骨感的。
CSS拥有决定页面元素样式和布局变化的权利。
浏览器内心OS:
我不确定你页面的layout和样式是什么鬼,你让我怎么提前渲染?
我只能等着CSS加载完毕,才能做出展示啊,所以我要等着CSS加载
其他的CSS排好队,等着前面一个CSS执行完了再依次过来
JS可能要获取当前的DOM结构,可能动态去创建和修改dom元素,修改cookie等全局状态(PS:
document.write()
了解一下?)浏览器内心OS:
鬼知道你的JS里做了什么骚操作,页面还没加载好,我可不敢先执行你,出了问题谁背锅?我只能等着在你之前的HTML解析渲染完毕再执行
其他的JS排好队,等着前面一个JS执行完了再依次过来。
正因为如此,HTML首屏加载,完全变成了等待 CSS资源加载,DOM渲染,JS解析执行的串行队列,不慢才怪。
下载与解析分离
我们都知道CSS&JS的解析是顺序相关的。而在浏览器的实现中,下载和解析动作通常是结合在一起的。那么这就导致了一个最坏的结果:
因为我们的解析是顺序相关的,需要串行,资源的下载也成了串行
通常情况下,我们一般认为下载是可以并行的,而执行要保证严格串行,这样才合理
这种诉求的解决办法:
通过编程手段(img标签/iframe等等)提前触发浏览器对于资源URL的请求。
浏览器后续请求同一URL时,根据缓存策略,可以命中max-age,304等策略,直接读取缓存的结果,从而节约后续下载时间
我想减少后端请求的耗时,如何优化
如果读者有这个想法,我觉得非常棒,毕竟最核心的耗时确实来自于服务端。但是本文并不想就此展开优化,因为这并不属于前端优化的技术范畴。欢迎你去找后端开发小伙伴探讨。
我不想在此讨论诸如如下问题
- 后端服务是否应该用redis/memcache?
- SQL应该如何优化?
- Node层中间件如何优化?(注意:以传统的BS架构来看,Node服务器仍然是后端)
- 等等
如果继续深入将偏离本文前端优化的初衷
再次重申:
本文所提及的优化,前提条件均为 假定后端服务的基本情况稳定不变
,大家做过实验课都知道,控制单一变量才能做出最终的结论。
Silver Bullet
HTML以最小的代价完成initial render,然后由一段极简的loader javascript来驱动后续资源的加载和渲染,最终呈现给用户
loader如何实现?这个问题我们可以继续拆解
有以下几个前提:
- 代码尽可能简洁,依赖少,普适性强。(如果一个loader的实现依赖了Promise/ES6新特性,甚至还依赖另外一个lib,那么这显然不合适)
- 一定要稳定,不能崩溃(就像计算机的)
尽最大限度去减少首屏的开销,第一时间把界面展示给用户。
至于部分人可能问的 后端数据如何正常展示?
自然是要用 前端loading提示/占位符 + Ajax 来做了。
我们已经拥有的黑科技
- AppCache
- ServiceWorker
- link preload/dns-prefetch/...
- ...
可喜可贺的是,现代浏览器的不断更新迭代,给我们提供了这么多新的黑科技
不论我们使用哪种优化,绕不开的一点,都是浏览器兼容性。
值得庆幸的是,上述优化黑科技都是一个optional的设计。
以ServiceWorker为例,最坏的情况,浏览器并不支持SW,但这不妨碍我们采用SW技术做优化,只要我们做好兼容和fallack,至少不会比优化前性能更差。
除去最坏的情况,仍有许多用户使用了比较新的浏览器内核,并且完美支持这些黑科技,那么这部分用户将会享受到 黑科技带来的体验提升。
而对于那些陈旧设备的使用者,便可以看做是提供了有损的服务体验
,但业务逻辑仍然可用。
渐进式优化
的概念由此而来,大家可以了解一下。
任何时候,都不要指望某一个方案全盘解决你遇到的问题。更多时候,你得到的是若干适用场景不一的解决方案。而我们要做的,是合理的去规划和组织这些子方案,扬长避短,最终形成一个相对完善的整体解决方案。后续只需不断迭代和完善这套解决方案即可。
优化的原则
- 不侵入业务代码
- 不影响应用的稳定性(不报错,fallback策略)
- 整体统一的解决方案,DRY