0%

Web

web20180409.jpg

WWW是环球信息网的缩写,(亦作“Web”、“WWW”、“’W3’”,英文全称为“World Wide Web”),中文名字为“万维网”,”环球网”等,常简称为Web。 分为Web客户端和Web服务器程序。 WWW可以让Web客户端(常用浏览器)访问浏览Web服务器上的页面。 是一个由许多互相链接的超文本组成的系统,通过互联网访问。在这个系统中,每个有用的事物,称为一样“资源”;并且由一个全局“统一资源标识符”(URI)标识;这些资源通过超文本传输协议(Hypertext Transfer Protocol)传送给用户,而后者通过点击链接来获得资源。

也许,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。

(完)

网站的肥胖症危机

作者: 阮一峰
日期: 2016年1月3日

最近,有一篇文章正在疯传。

它是上个月,Maciej Ceglowski在澳大利亚的一次演讲,名为《网站的肥胖症危机》(文本,视频),反思了互联网开发的现状。

该文非常值得一读,Hacker News排行榜高居榜首,得到了1000多人的推荐。

下面就是我的中文节译版。

===============================

网站的肥胖症危机(节译版)
作者:Maciej Ceglowski

译者:阮一峰

原文网址:The Website Obesity Crisis

1.

大多数网站的主要内容是文本,更准确地说,是简短的文本。

文本本身并不大,但是展示它们的网页,正变得越来越大。Twitter展示单条评论(140个字符)的页面,超过900KB。Medium的一篇文章大约400个词,页面大小是1.2MB。

如果这种趋势持续下去,2020年,网页的体积平均将超过5MB,比一本俄罗斯长篇小说还大。比如,陀思妥耶夫斯基的《罪与罚》,文本压缩后不到800KB。

TechTimes.com有一篇报道,介绍Google正在为大网页做标记。但是,这篇报道的网页,体积为18MB,外加一个3MB的视频。

2015年5月,Facebook引入了”Instant Articles”,帮助用户快速浏览新闻。但是,介绍这个功能的页面,体积为6.8MB,外加一个41MB的视频。你想了解这个功能的细节,唯一的方法就是去看这个视频。

2.

网页真的有必要这么大吗?明明200KB就足够,为什么要做成2MB?

因为我们要往里面塞很多不需要的东西:广告、高清图片、视频、用户追踪系统、社交媒体的代码……你不塞,公司就可能解雇你。

如今的时代,你跟雇主说,想做一张体积只有几百KB的网页,就好像跟SUV车主谈论省油的经济型轿车。

有人会说,这是免费内容的代价。但是,我想问,谁会从海量的互联网广告获利?广告主,还是消费者?真正获得暴利的是网络服务提供商和互联网广告公司,其他人都付出了巨大的成本。

3.

我们都忘了健康的网页,应该是什么样子。

值得阅读的文本,配上结构良好的标签。
适度的图片和视觉设计。
一层CSS
少量的JavaScript,只在必需时使用
但是,2015年真实的网页,却是下面这样。

一层HTML
一大堆垃圾
顶部还有一层监控代码
4.

宽带和光纤上网并不解决问题,实际上还鼓励了人们往网页上添加更多的东西。

为了平衡网页体积,工程师想出了很多方法:首屏快速渲染、压缩文件、异步加载、批量HTTP请求、管道发送等等……

网站开发越来越依赖代码精简、压缩、缓存、服务器配置这些中间步骤,这使得找出错误越来越困难,成本越来越高。

5.

复杂性让聪明人上瘾。

即使我们知道复杂不是好事,但难以抵抗。复杂的东西总是显得很酷,让人情不自禁想继续干下去。

大多数网站都过度复杂了。

我们做的每件事,都使得创造网站或编辑网页变得困难。把一篇文章放上网,正在变得需要一个专家团队才能完成。

新手越来越难通过源码学习。我们抽走了人们学习互联网的梯子。

6.

其实只需要两步,就可以大大缩小网页体积,提高性能。

第一步,确保最重要的内容,首先下载和渲染;

第二步,就此结束。

你不需要那些多余的垃圾,对最简主义保持信心就行。

7.

让我们保持互联网是一个超链接构成的媒体,不要把它变成另一种东西。

(完)

欢迎关注我的其它发布渠道