HTML5页面渲染性能的”程序转换“思路

做浏览器内核引擎的，一般都会考虑怎么做性能优化，这个优化实际上包括下面的内容：

（1）内存占用的优化，特别是对于嵌入式设备尤其重要，chromium有个blimp thin client的模块，不知道有没有用处；

（2）渲染性能的提高，注意核心就是尽量利用硬件GPU来做渲染，避免CPU计算和内存Copy的开销

（3）网络IO性能的提高，改善页面加载、响应数据，乃至云加速压缩流量、广告过滤屏蔽无用流量，等等

好吧，性能优化也就是这么多内容。但我要讲的”程序转换“思路不是这么回事，这个想法是：

在保证页面最终渲染结构及用户UX可用性差别不大的情况下，做极端的处理在parser阶段转换HTML代码（包含CSS、JS）。

也就是说，这个思路的核心在于一个能够理解W3C规范的高级的类似于编译器前端转换引擎。

这个领域，目前似乎还没有进一步深入的工作。

对前端开发，Babel.js以其其他的一些JS工具能够将ES6语法的JS代码转换为老的JavaScript。不过，纯JS做这个源代码转换问题倒不是很大，可以在AST上面进行模板转换。

问题是对于一个包含了HTML+CSS+JS的复杂页面，做”程序转换“就不是那么简单了。

不过，假如Web的未来就是用JS实现一切（JS DOM、CSS Houdini用JS来定制Layout、Service Worker控制loader过程），那么也许这个问题最终还是可以转换为JS源代码转换。

假设现阶段只对HTML+CSS这么做的话（不考虑前端JS框架生成html代码的情况，因为这可以移到后端来完成），可以考虑的优化情形：

（1）针对设备的viewport进行layout相关的重新改写，比如，将某些auto width/height转换为固定的宽高，这可以大大提高浏览器内核进一步layout的速度；

（2）针对某些无用的嵌套很深的div、viewport外的或者隐藏不可见的div（可能需要JS来触发显示），可以在初始阶段直接忽略掉（但是需要实现一个按需的重新parser/load进DOM树的过程）

这只是设想的比较简单的情形。这个地方最关键的就是需要一个高性能的解释器引擎。

Asm.js创建了一套基于Type Hints的JS子集，此子集可供JavaScript引擎直接优化为类型特定的机器代码（而不是动态的对象访问）。

HTML5似乎也可以采用这种思路：定义一个HTML5的渲染性能优化子集。此子集可被layout引擎高效处理。甚至不需要创建复杂的render树（采用JS DOM描述）。但这个优化子集究竟应该是什么样子的，目前还没法给一个具体的描述。