html怎么在标签栏加速形状,HTML加速

关注点

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