BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Google提出Web性能优化新方法——Diffable

| 作者 崔康 关注 0 他的粉丝 发布于 2010年8月13日. 估计阅读时间: 2 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

Google Maps的开发人员Josh和James最近提出并实现了一种Web性能优化新方法——Diffable,即在浏览器加载Web页面时,促使其比较相关文件(Html、JavaScript等)在服务器端和客户端缓存区的版本并只下载差量(Deltas),降低网络下载造成的延迟。本文简要介绍了Diffable方法的背景、原理、优势和实现情况。

背景

众所周知,Google Maps是一款“重量级”的富互联网应用,主要JavaScript文件大小接近300K,而一个平常的补丁更新只有不到20K,这意味着如果用户的浏览器已经缓存了旧版本的JavaScript文件,那么在通常情况下,用户不得不下载多余的280K(内容没有变化),页面加载速度就会受此影响。为了解决类似问题,Google Maps的工程师提出了Diffable方法。

原理

Diffable方法需要在服务器端和客户端同时实施,如图1所示。

  • 服务器组件记录网页相关文件版本更新的差量,以便在客户端需要时向其发送补丁以更新过时的缓存文件。
  • 客户端组件(采用JavaScript编写)检测是否缓存了过时文件并在必要时请求新版本的差量补丁,与缓存的文件合并完成更新。

图1. Diffable方法原理图 (来源:Velocity 2010年会演讲资料

性能优势

对于Google Maps来说,Diffable方法节省了1200毫秒(减少页面加载时间的25%),请注意这种方法只对已经缓存旧版页面文件的Google Maps用户有效,此类用户约占全部用户的20%-25%,参见图2所示:

 

图2. Diffable方法在Google Maps应用的性能对比 (来源:Velocity 2010年会演讲资料

实现

Diffable方法是一种Web性能优化思想,目前Google的开发人员已经针对J2EE应用完成了相应的开源实现,采用Apache License 2.0授权,具体细节可以参考以下文档:

感兴趣的朋友可以登陆Diffable开源项目官方网站了解更多详情。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

javaweb框架 by framework simple

Re: javaweb框架 by 崔 康

楼上的朋友,你能不要长期采取这种方式来宣传自己的作品吗?前些日子已经给你gmail发信要求了解你的这个开源项目了,如果项目对开发社区发展有益的话,InfoQ会进行报道的。适可而止吧,谢谢!

关注下....... by geng gavin

RT

有个疑问 by 丁 凯剑

到官网看了流程图,发现需要客户端用JavaScript对资源做merge。
问题是必然不可能将老的资源进行修改,因为违反浏览器安全性,那么就只能将被缓存的不同部分每次都合并老的文件里。
如果我的想法没有错的话,浏览器每次都承担了额外的计算,相比起来是不是直接下载新的资源更加一劳永逸呢?
希望我没有弄错这个组件的思想,是以浏览器的计算来换网络的传输开销。个人以为这么做不值得。

Re: javaweb框架 by 龙 张

这位大哥我是彻底服了,天天发啊

Re: 有个疑问 by Zhao Ken

考虑到google map会有多少人使用,节省的流量很可观的。还是需要在复杂度及开销之间做一个平衡的决策。为20%-25%的用户节省了近90%的传输开销,google确实把产品做到极致了 :-)

Re: 有个疑问 by 崔 康

到官网看了流程图,发现需要客户端用JavaScript对资源做merge。
问题是必然不可能将老的资源进行修改,因为违反浏览器安全性,那么就只能将被缓存的不同部分每次都合并老的文件里。
如果我的想法没有错的话,浏览器每次都承担了额外的计算,相比起来是不是直接下载新的资源更加一劳永逸呢?
希望我没有弄错这个组件的思想,是以浏览器的计算来换网络的传输开销。个人以为这么做不值得。

凯剑应该没有理解错,对于浏览器的计算压力和下载时间的取舍,Google应该给出更多的数据佐证,网络流量的节省倒是很明显。

Re: 有个疑问 by 崔 康

考虑到google map会有多少人使用,节省的流量很可观的。还是需要在复杂度及开销之间做一个平衡的决策。为20%-25%的用户节省了近90%的传输开销,google确实把产品做到极致了 :-)

的确,从流量角度看,这项技术非常优秀。

Re: 有个疑问 by Wang Xuesong

单纯只是合并文件的话对浏览器计算占用的资源太有限了,再说如果服务器端能较好的分离每一次脚本更新的话,单纯两个 <script></script> 就解决问题了,这能有什么不值得的,关键节省了不少带宽资源。

服务器端文件和客户端的进行比较然后只传输差量部分 by 黄 之昊

这个对版本管理的要求很高,要记录每个不同版本间的差异,而且往往不只是增量,还有减量
这个环节的付出的成本是否过大?

自己画饼计算的吧? by du roy

为20%-25%的用户节省了近90%的传输开销,前提是每次都有1/4的回头客,并且js库频繁更新。以至于不更新这1/4的用户都节省不了。

很显然是理想状态下。比起这1/4 * 90%的理想值,巨大的代码工作量也是值得考虑的。

应该让浏览器支持版本更新的优化 by Derry Lemon

支持版本更新的相关协议也是浏览器优化的一部分

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

12 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT