也许,DOM 不是答案

作者: 阮一峰

日期: 2015年2月22日

有一个词"手机网站"(mobile web),指供手机浏览的网站,但它是不存在的。

人们提到"移动互联网"的时候,其实专指另外一样东西:手机App。

一、Web App vs. Native App

比起手机App,网站有一些明显的优点。

  • 跨平台:所有系统都能运行
  • 免安装:打开浏览器,就能使用
  • 快速部署:升级只需在服务器更新代码
  • 超链接:可以与其他网站互连,可以被搜索引擎检索

但是,现实是怎样呢?

(1)体验差。手机App的操作流畅性,远超网站。

(2)业界不支持。所有公司的移动端开发重点,几乎都是原生app。

(3)用户不在乎。大多数用户都选择使用手机app,而不是网站。

如果将来有一天,Web app会成为主流,一定有一个前提,那就是它的性能可以赶上Native app。

二、为什么Web app有性能瓶颈?

Web app输给Native app的地方,不是界面(UI),而是操作性能。主要是互动(interaction)和动画(animation)这两方面,会出现卡顿(jank),用户会感觉到明显的时滞,有时简直慢得难以忍受。

Web app的性能瓶颈,主要有以下原因。

(1)Web基于DOM,而DOM很慢。浏览器打开网页时,需要解析文档,在内存中生成DOM结构,如果遇到复杂的文档,这个过程是很慢的。可以想象一下,如果网页上有上万个、甚至几十万个形状(不管是图片或CSS),生成DOM需要多久?更不要提与其中某一个形状互动了。

(2)DOM拖慢JavaScript。所有的DOM操作都是同步的,会堵塞浏览器。JavaScript操作DOM时,必须等前一个操作结束,才能执行后一个操作。只要一个操作有卡顿,整个网页就会短暂失去响应。浏览器重绘网页的频率是60FPS(即16毫秒/帧),JavaScript做不到在16毫秒内完成DOM操作,因此产生了跳帧。用户体验上的不流畅、不连贯就源于此。

(3)网页是单线程的。现在的浏览器对于每个网页,只用一个线程处理。所有工作都在这一个线程上完成,包括布局、渲染、JavaScript执行、图像解码等等,怎么可能不慢?

(4)网页没有硬件加速。网页都是由CPU处理的,没用GPU进行图形加速。

上面这些原因,对于PC还不至于造成严重的性能问题,但是手机的硬件资源相对有限,用户互动又相对频繁,结果跟Native app一比,就完全落在了下风。

三、FlipBoard的解决方案

FlipBoard原本是一个手机App,最近开始部署Web版本,结果就遇到了上面的问题:Web版的体验不佳。

上周,他们将解决方案公布在网站上,结果引起了业界轰动,因为这是一个史无前例的解决方案:

---- 他们没有使用DOM,而是将整个网站用canvas输出!

你可以用手机打开flipboard.com,体验一下,看看跟Native app有没有差别。如果你没有帐号,可以直接打开这里这里

这个方案的出发点是这样的:如果将网页变成了一个个canvas,用户就等于在跟图片互动,这样就绕开了DOM,降低了操作时滞。而且,canvas可以被硬件加速,这样就提高了性能。具体的技术细节,可以参考原文。canvas的转化基于React框架实现,FlipBoard 开发了一个专门的库React-canvas,已经开源。

这个方案引发了很多争议(这里这里),主要是canvas只是一个位图,本身没有语义,如果要在它上面实现UI,等于HTML语言已有的东西都要再发明一遍,比如如何实现超链接、如何实现CSS效果等等。一些最简单的东西都变得很麻烦,因为canvas不是自适应的(responsive),文字在哪里断行,都要自己计算,而且用户也无法选中文本。另外,怎么让搜索引擎检索网页,解决起来也不是很容易。

但是不管怎样,这是一个有意义的尝试。

四、未来的路

James Long对FlipBoard的尝试,写了一篇评论《Radical Statements about the Mobile Web》。本文就受到了那篇文章的启发。

在文中,James Long对未来的Web app提出了几点预测,我认为很值得分享。

(1)多线程浏览器。每个网页应该由多个线程进行处理,主线程只负责布局和渲染,而且应该在16毫秒内完成,JavaScript由worker线程执行,这样就不会发生堵塞了。Mozilla正在开发的Servo就是这样一个项目。

(2)DOM的异步操作。JavaScript对DOM的操作不再是同步的,而是触发后,交给Event Loop机制进行监听。

(3)非DOM方案。浏览器不再将网页处理成DOM结构,而是变为其他结构。React的Virtual DOM方案就是这一类的尝试,还有更激进的方案,比如用数据库取代DOM。

(完)

留言(75条)

你们不卡吗?提供案例网站我的手机chrome,卡哭了

再往前一步看,为什么web要长得像app

引用woween的发言:

你们不卡吗?提供案例网站我的手机chrome,卡哭了

用手机的Firefox 顺畅无压力~

这要怪也只能怪 Javascript 引擎太慢吧,DOM 本身没有问题。

引用Sumhat的发言:

这要怪也只能怪 Javascript 引擎太慢吧,DOM 本身没有问题。

不是js慢,canvas也是用js绘制出来的。
反正有好有坏就是了,用canvas的话,不利于seo。但是只要浏览器能兼容好canvas的话,其他都不是问题(例如某些ie-_-)。


我比较care的是web app如果Canvas UI化的话,就意味着它本身就是在向着native app靠拢。。。native app的语义化本身也更弱一些吧=_=。(抛开这些,DOM的16ms确实是硬伤,想到这还是蛮喜欢canvasUI的。。。)


网站太卡应该是这两个原因:
1.设计太复杂。形式大于内容,贪婪的使用特效,盲目的拟app化。
2.代码写错了。正确的代码是不用优化的,也没有优化的空间。

不过懂设计的人太少,多的是以为自己懂设计的人;代码写对很难,也很浪费时间。

如果 canvas 是银弹的话,那 flash 早就是了,java applet 也不会死。

引用hzf的发言:

不是js慢,canvas也是用js绘制出来的。
反正有好有坏就是了,用canvas的话,不利于seo。但是只要浏览器能兼容好canvas的话,其他都不是问题(例如某些ie-_-)。

手机用IE,Windows Phone? 况且从IE11开始Canvas就没问题了,从IE12开始WebGL也支持的很好了

如果使用transform就可以使用GPU来提高性能了
HTML5Rocks上面有说过 http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/
QQ空间的手机游戏也有用到 http://isux.tencent.com/html5-game-development-cheats.html

不认同这样的说法,现在的手机浏览器也很快,在低帧率下跟原生app有得比,甚至比app还快。

用文中提到的例子吧:
如果网页上有上万个、甚至几十万个形状(不管是图片或CSS),生成DOM需要多久?
换成:
如果APP界面上有上万个、甚至几十万个形状,生成界面需要多久?
我可以保证,卡得一样糊涂。

dom拖慢js?我不知道能写出这样代码的程序猿是怎么通过面试的。如果是大量计算,那就应该分解分步骤,或者服务器直接给出结果来。

filpboard为何要用canvas?很简单,因为他们追求的特效,要求不能卡,而那种特效,用dom来渲染,可能会卡。这又得赞(tu)扬(cao)那帮追求完美的产品经理了。为了看起来漂亮而已,与dom慢不慢无关,跟js跟没关系了,毕竟canvas控制也得靠js,甚至整个网页都靠js在维持。
也许这样的网页,对cpu的消耗比dom组成的网页还高,耗电会更快,可能很快就会得出,看网页耗电比看app耗电更大的结论。这点只是个人猜测,纯属娱乐。

canvas绘画还是很出色的,也佩服那帮程序猿居然费这么大劲弄一个canvas版本的页面,不过目前还有些手机在canvas方面有缺陷(红米2就遇到过),不知道他们是否需要对兼容性进行测试。就算用了canvas,在某些手机上也一样卡得死死的,甚至在长时间运行后还失去响应。也许他们做出来之后只给那些左手iPhone6,右手iPhone6Plus的老板们乐乐而已。

在游戏方面,确实原生APP有很大的优势,但在纯粹的网站浏览方面,不一定比原生的差。

如果说canvas来模拟整个交互会更快的话,那是否应该考虑下页面的加载变慢了?
canvas的绘制依赖js执行,而浏览器中加载js又必须是串行下载,这样有一个问题:
得等react这个比较大的js下载好,再下载flipboard的js,然后页面中才出现内容。
总的来说,canvas对于动态的交互会有更好的体验,但是一些纯静态的内容应该没有多大优势。

既然是web app了,考虑SEO有意义吗,有人会考虑native app的SEO么?只是如果开发成本太大的话就失去了做web app的优势了,快速迭代

加载卡哭了,WIFI网络加载一分多钟还是白屏~~

作为移动开发者,我想说如果都用webapp代替native app,移动开发是不是快要失业了?
或者只是针对某些应用可行,比如说杂志新闻类?

Javascript引擎慢,DOM元素多,加载时间长

我试了一下,页面虽然没有flipboard原生应用流畅,但比较顺滑,我用的chrome beta

加载慢的是因为GFW吧 lol

这种解决方案还是很大胆很有创意的~

鱼和熊掌焉能兼得?

我只是在担心耗电问题,不知道有没有相关的测试报告

好前沿的东西,看得我一楞楞的。不过我赶脚:在硬件上,划时代的CPU就快临盆了。。

"用户就等于在跟图片互动,这样就绕开了DOM"
说的好像图片就不是dom一样。。

在新版的 IOS 系统中使用 cordova 开发网页应用,其操作的流畅性还是很不错的。但是在 Android 虽非绝不能用,但使用动画时依然还是会有明显的卡顿。

几年前刚看到canvas时,就在想,如果网页的布局什么的都用这个,那很多兼容性的问题是不是就都解决了。

如果将来有一天,Web app会成为主流,一定有一个前提,那就是它的性能可以赶上Native app。
---------
这句话不敢苟同,其实在今天,BS应用在某些方面的性能和用户体验仍不能媲美CS应用,但为何如今BS应用却得到广泛应用,所以个人认为市场的需求也是需要技术革命的推动。

(2)DOM拖慢JavaScript
----------
关于这一点,对于一些耗性能的操作,服务端往往是用多线程去处理,而如今客户端H5的技术可以用JS的worker来处理这种耗性能的业务场景。

(4)网页没有硬件加速。网页都是由CPU处理的,没用GPU进行图形加速。
-------------
支持H5的部分浏览器是有支持GPU硬件加速,比如IE9对CSS3动画就有硬件加速,这是浏览器厂商的问题,在一场新的技术革命面前,浏览器厂商不可能不革新自己的产品。

所以移动web技术前景还是蛮乐观的

为啥没有人实时 famo.us js 的方式呢. 挺快的

用Chrome的开发工具模拟iPhone6试了一下,确实非常流畅,但是再流畅也无法朝语native app,web app永远只能作为补充角色吧

引用henry_wu001的发言:

作为移动开发者,我想说如果都用webapp代替native app,移动开发是不是快要失业了?
或者只是针对某些应用可行,比如说杂志新闻类?

对mobile web抱有最大期待的是pc web程序员。
而不是希望给普通用户带来优秀体验的老板。
因此我想你不会失业的。

引用hzf的发言:

不是js慢,canvas也是用js绘制出来的。
反正有好有坏就是了,用canvas的话,不利于seo。但是只要浏览器能兼容好canvas的话,其他都不是问题(例如某些ie-_-)。

canvas 坑很多,第一个就是中文无法折行 react-canvas中就是替代dom的一个产品,但是在中国的路还很远

引用xo的发言:

再往前一步看,为什么web要长得像app

想想N年前web UI为什么要做成跟桌面一样?道理是一样的。用户更容易接受,浏览器在用户的映像里面是一个App/Application/Software 用户会认为他应该跟别的软件一样。

呵呵 又在变成web和native两方工作者利益相关的YY了

引用Sumhat的发言:

这要怪也只能怪 Javascript 引擎太慢吧,DOM 本身没有问题。

恰恰跟你的认识相反……

引用dm的发言:

"用户就等于在跟图片互动,这样就绕开了DOM"
说的好像图片就不是dom一样。。

一根筷子你容易折断,给你一大捆你还容易折断吗?

首先,运行web app你需要一个浏览器,然后它是native app……

有APP的话还是会选择APP;

网站太多的话不可能每个网站都有APP,还是用浏览器比较方便。

阮老师现在技术性的文章要远多于其他类别,不知道是出于什么样的原因。

http2.0

没做过数据上的研究,但DOM解析真能那么慢?
总觉得web速度的瓶颈在于服务器响应时间和内容下载速度,如果通讯延迟足够小,那么以现有的硬件水平DOM解析应该不是什么大问题吧

自我总结了一下" 特效 网速 手机配置 服务器响应"

写得好,非常棒

我是你大学时代的兄弟,有空给我写封邮件,重拾财大时光!

想法还是挺好的,但是做起来真是要命。

如果web app 盛行,那么像iphone 这样的手机是不是可以轻易饶过App Store来发布

其实web也不算真真扩平台,中国还有大量的用户用着IE6、7、8,噩梦

我能说我的P6直接卡死机了么

引用Sumhat的发言:

这要怪也只能怪 Javascript 引擎太慢吧,DOM 本身没有问题。

Web开发 最慢的就是DOM操作。

引用doubled的发言:

首先,运行web app你需要一个浏览器,然后它是native app……

然而 浏览器 就是 系统。

引用wakan的发言:

如果web app 盛行,那么像iphone 这样的手机是不是可以轻易饶过App Store来发布

对于这种以封闭模式盈利的厂商肯定会伤害它的利益,Web App确实是开放的。
而对于内容发布者,要重拾以前的模式——内容收费模式。

引用abcdefghijklmnopqrstuvwxyz的发言:


手机用IE,Windows Phone?
况且从IE11开始Canvas就没问题了,从IE12开始WebGL也支持的很好了

WP求不黑,我专门用WP上的IE浏览了一下FlipBoard,效果很流畅。

小米手机自带的浏览器打不开这网址,电脑上可以,浏览器的手机模拟器也可以。

引用Duzz的发言:

对mobile web抱有最大期待的是pc web程序员。
而不是希望给普通用户带来优秀体验的老板。
因此我想你不会失业的。

作为手机用户我也很期待mobile web,因为被app的各种要权限,后台自启进程,弹通知等搞的很烦

(4)网页没有硬件加速。网页都是由CPU处理的,没用GPU进行图形加速。

这句话有问题吧,不是有GPU加速。

canvas不慢么?以前还想过用svg

看看之后的发展

个人认为,跨平台的方案是在性能上是无法与专为某平台而生的方案相比的,如果WebApp性能上能够有巨大的提高,那么NativeApp更可以提高了。

老师您好,我想问下,
1 为何不把js各种库集成到浏览器里面,
比如,浏览器都遵循这样一协议:他们的js文件都放在同样的路径下.
这样是否能给解决webapp的速度瓶颈提供一个好的方案

服务端生成就一定会卡的,因为有数据交互的时间,所以要想提升交互效果就一定要把在前端做mvc结构,与服务器只交互数据,不交互生成的界面才行。

你只说生成dom,不提插入和检索操作呢,一个简单的CSS选择 div > a ,就会造成全dom的检索的,这种在前端里处处都是啊。

还有转场效果,即从一个View切换成另一个View,受限于渲染和js数据加载等因素,就是这个的慢。

以iOS上的经典效果来说,短信的消息气泡的弹簧效果、返回手势使用时中间放弃后的操作阀值。这些用dom+js+css实现就是灾难啊!

我反而倾向于不要这么较真,常用的用app,不常用的用web,有通力在web上实现app的效果的公司真不多,现在web开发的氛围太活跃了,几天就出现一个所谓革命的技术,反而浪费了很多时间在学习上。

请看https://github.com/drawapp8/cantk

js是单线程的,但是浏览器不是单线程的,有渲染线程,ajax线程,事件线程~~

请问谁知道”数据库取代DOM“是什么方案?感觉很强大!

实测手机Chrome游览器的DOM渲染并不会阻塞js脚本。appendChild上去的时候css样式都没有渲染出来,已经进入下一步js语句了。

@蒋鑫:

你可以去看一下framework7,你说的这些效果都可以实现,而且很流畅

整个网站用canvas输出 ===> 这个方案我朋友3年前在深圳就用过了, 他后来还自己找了风头做整体解决方案,其实老外未必走在中国人前面。
http://www.tangide.com/

正在做这样的事,移植Android的一套UI到Web的Canvas,相信比ReactCanvas和React更优秀:
https://github.com/linfaxin/AndroidUI4Web

Javascript说:“网页慢,怪我咯?”

前面那些说时JS本身慢、DOM不慢的,我觉得应该再认真看看文章。现在讨论的内容是,DOM的渲染速度比JS引擎的执行速度慢了一个数量级,所以导致的效率问题,这是一个相对的原因。
好比是飞机汽车同时出发,飞机每隔一段时间要等汽车一下。
说JS慢的,建议换C++;说靠自己代码水平,消除DOM慢影响的,建议去面一下谷歌。
一开始看到那么多人留言说些风马牛不相及的,还以为是几年前的评论,毕竟最近两年,前端从业者对于“DOM太慢”以及“JS引擎的执行速度大大提高”这两件事应该是耳熟能详的。
无法理解硬要挑刺来展现一下自己半吊子水平的评论者。

2016.2.16晚
个人感觉的发展趋势:
1.目前阶段OS下,app+web混战
2.后面OS会整合部分功能(在安卓和IOS、WP上都可以看到一些身影,云计算大势所趋),app会慢慢和web没有很明显的界限,尤其是在网速不断提升的这个时代,web的劣势在减弱,
3.最后可能是一个软硬件结合的时代,不再单单是简单的软件了(理想很丰满)

目前我们项目已经全面使用h5做界面了。。最大的优点跨平台呀,java .net php ,cs 桌面程序,bs web程序,android手机程序 全部使用h5,一套界面全兼容。。当然除了游戏可能会慢点,其他方便的没有什么效率问题。

最近在用ionic做一个在线购物的手机APP,目前还挺流畅的,只是虽然说H5跨平台,但在一些表现样式上似乎还有差别

1,浏览器现在越来越多的把任务分到不同线程,尤其是IE/Edge; 渲染啦,图片解码啦,以及大量的用户输入处理(鼠标,键盘, touch).
2,浏览器现在大量使用硬件加速。

React Native vs React

作为初级前端开发者,已经被各项前言技术搞晕了,如何系统的深入的掌握前端技术,而不是蜻蜓点水似的都是略知一二,这对于我真真是一个问题。

先膜拜下这帮牛人,然后表达下观点:不看好。

目前最佳实践显然是: Native外壳+Web界面 (当然,游戏类APP除外)

现在很多公司目前都是这种模式了,
只可惜大家都是各自关起门来实现自己的,重复造轮严重,
现在缺的是一个标准,或一个简单的框架,
js框架千千万,为什么偏偏jq火的经久不衰,原因就两个字:简单


首先 浏览器就是一个app.....一个系统有很多app 一个app 有很多app....

引用英布的发言:

加载卡哭了,WIFI网络加载一分多钟还是白屏~~

要翻墙 老铁

估计那时候还没有 跨桌面应用

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接