Tagged

缓存

A collection of 2 posts

web app

缓存为王

前面我写了一篇快速web app的关键是使用Ajax、优化Javascript和更好的缓存。 使用Ajax可以减少网络流量到只有少量的JSON请求。 优化Javascript(异步下载脚本、分组DOM修改、对UI进程作出让步等)允许请求可以并行然后快速渲染。 更好的缓存意味着web app的大部分资源是存储在本地,然后并不会再有任何http请求了。 理解每种技术在哪里发挥作用很重要。使用Ajax,例如,不会让页面初始化加载更快(而且常常会不小心让它更慢),但是后面的“页面”(用户操作)会更爽。另一方面,优化Javascript,会让初始页面和后面的页面都更快,更好的缓存则位于中间:第一次访问不快,但后面的访问会更快。同时,即便在用户关掉浏览器之后再一次返回你的网站时初始化页面也会更快——这样性能优势要胜过浏览器会话(sessions)。 这些网站性能优化并不是互斥的——你应该都使用!但我(或者你也)想知道哪一个才有最大的效果呢?所以我进行了一次测试来测量这些不同的因素。我想要看看它们在实际网站中的效果,所以我使用了WebPagetest,这里我可以很方便的在Alexa排名前1000的网站中做一些测试。由于并没有办法让一个网站直接“Ajax化”,所以我决定专注与网络使用的时间。最后,我做了下面4项测试: 基准——用IE9和一个模拟的DSL连接速度(1.5Mbps下载、384Kbps上传,

web app

快速web app之道

我最近提到,一个快速的Web App的关键是Ajax架构、Javascript和缓存。虽然这样说是基于我的经验——我并没有每一项的贡献的实际数据或者量化的可能节省的性能。但请听我细说~~ Ajax架构——Web 1.0的基于用户每次操作来重新加载页面显然不是正确的选择。让用户拉下页面(移动终端拉下页面来刷新的方法)然后重新请求没有任何改变的资源会是一种很2B的用户体验。使用Web 2.0的App来维持稳定的UI就会更优雅,而且Ajax允许我们通过轻量的数据API请求和客户端Javascript来实现内容更新,这会显得平滑而快速。 Javascript——Javascript是网站性能的中流砥柱,但是几年前它更糟糕。还记得吗?过去通常会加载一个脚本,然后阻塞HTML解析和页面中其它资源的下载。脚本一次只下载一个!在2009年,IE8成为第一个支持并行脚本加载的浏览器。Firefox 3.5、Chrome 2、Safari4也很快跟进了,然后最近Opera 12也才跟上队伍。(在我看来对网站性能来说,并行脚本加载是唯一的、最重要的改进)除了加载脚本以外,Javascript引擎自身的速度也有了显著的提高。所以我们比几年前强太多了。但是当我深入研究主流网站的性能的时候发现Javascript依然是导致网站比较慢的最常见的因素,特别是减慢渲染。这主要源于几个原因。比如,Javascript请求已经增加到了约200kb了。浏览器仍然屏蔽Javascript的一些行为,比如,在有些浏览器中一个后面跟有内联脚本的样式会阻塞后面资源的下载。