tag:content
预加载看起来和后加载原则是个矛盾,但它其实是为了另外一个目的。预加载组件让你可以利用浏览器的空闲时间来加载之后需要的组件(比如图片,样式表和脚本)。这样当用户浏览下一个页面的时候,大部分组件都已经在缓存里了而页面会加载的更快。
有几种预加载的类型:
tag:content
复杂的页面意味着更多的字节需要被下载而且也意味着在JavaScript中遍历DOM更慢。比如你在页面中添加一个事件,让它在500或者5000个DOM元素中循环,它们的效率是不同的。
更多的DOM元素表明有些标签需要被改良而并不一定需要移除实际内容。你是否为了布局而使用繁琐的网一样的表格?你是否只是为了弥补一些布局的问题而使用了更多的div标签?也许还有更好和更符合语义的标签可以使用。
YUI CSS utilities可以很好的帮助进行布局:grid.css 可以帮助你进行所有的布局,front.css 和 reset.css 可以帮助你去除浏览器默认的格式。这是你开始重新审视你的标签的机会,比如只在语义符合时使用div标签,而不是用它来另起一行。
DOM元素的数量很好检测,只要在Firebug的控制台里输入:
document.getElementsByTagName('*').length
那么多少DOM元素算多呢?查看下类似的使用较好的标签的页面。比如Yahoo! Home Page是一个很丰富的页面但只有700以下的DOM元素(HTML标签)。
tag:内容
将部件分割能使你获得最大的并行下载效率。但你同时需要注意不使用多于2~4个域名,以避免DNS查询导致的问题。例如,你可以将HTML内容和动态的组建放于www.example.org域名下,将静态组件分别放于static1.example.org和static2.example.org之下。
查看Tenni Theurer和Patty Chi的"Maximizing Parallel Downloads in the Carpool Lane"获取更多关于并行下载的信息。
tag:内容
Iframes 能够使HTML文档被插入进父级文档中。首先需要明确iframe的工作方式,才能有效的利用这一形式。
<iframe>的优点:
<iframe>的缺点:
tag:内容
一个获得没用的404响应的HTTP请求对于宝贵的HTTP请求资源来说是完全不必要的,而且这样还会减慢用户的体验。
有的网站提供了有帮助的404错误信息,比如"你是否在寻找……?",这样虽然能提高用户体验,但同样浪费了服务端资源(比如数据库)。尤其不妙的是在请求一个外部的Javascript脚本文件失败时获得的一个404错误,因为这样不但会堵塞并行的下载,而且浏览器会尝试分析404响应的内容,来辨识它是否是有用的Javascript代码。
tag:cookie
有多种理由让我们应用HTTP cookie,比如身份验证,或者个性化设置。Cookie中的信息在服务端和浏览器间被放在HTTP头中交换。尽量减少cookie的体积对减少用户获得响应的时间十分重要。
查看Tenni Theurer和Patty Chi的"When the Cookie Crumbles"获取更多信息。
tag:cookie
当浏览其请求一个静态图片并一同发送cookie时,服务器并不需要这些cookie。这样只是毫无益处的创建了多余的网络流量。应当保证静态的部件在请求时没有携带cookie,所以需要把你的静态部件放在另一个子域名下。
如果你的域名是www.example.org,你可以将你的静态部件放在static.example.org中。如果你把cookie设置在顶级域名example.org上而不是www.example.org,那么所有发送至static.example.org的请求会包括那些cookie。在这种情况下,你可以买一个全新的没有cookie的域名来放置你的静态部件。Yahoo!使用了yimg.com,YouTube试用了ytimg.com,Amazon使用的是images-amazon.com。
将静态部件放于没有cookie的域名下的另一个好处是一些代理服务器会拒绝缓存有cookie的部件。于此相关的一点是,如果你怀疑你应该为你的首页使用example.org还是www.example.org,考虑cookie的赢下。省略www会让你不得不把cookie写到*.example.org下,所以考虑性能,最好使用www.子域名,然后把cookie写到这个子域名下。
tag:javascript
利用Javascript读取DOM元素很慢,所以为了获得响应更快的页面,你应该:
查看Julien Lecomte的"High Performance Ajax Applications"获得更多信息。
tag:javascript
如果有太多的事件处理逻辑部署在DOM树的不同元素上,它们的频繁执行会拖慢页面的响应速度。而使用事件委托是一个好的解决方法。如果在一个Div中有10个按钮,与其在每个按钮上都放一个事件处理程序,步入只在Div上放一个事件处理程序。事件会冒泡上溯,这样你就会捕获这一事件,并找出是哪个按钮发起的它。
同样,你并不需要等待onload事件来启动一些操作DOM树的程序。你只需要保证你需要操作的元素可用就可以了。你不需要等待所有的图片下载完毕,你应当使用DOMContentLoaded事件来替代onload事件,当然,目前并不是所有浏览器都支持这一事件,你可以使用YUI Event组件,其中包含了一个onAvailable
函数。
查看Julien Lecomte的"High Performance Ajax Applications"获取更多信息。
tag:css
前面提到把CSS应当放在最顶端来提供预显。在IE中,放在页面底部的@import和<link>效果是一样的,所以最好不要用它。
tag:css
IE专有的AlphaImageLoader
过滤器是为了解决半透明真色PNG图片在IE7之前的版本中显示的问题。这个过滤器会在图片下载时堵塞住展示。而且它会消耗内存并影响每个元素而不仅仅是每张图片,所以这个过滤器的问题很多。
所以最好在IE中完全不使用AlphaImageLoader过滤器,而使用渐淡的PNG8图片。如果你明确需要AlphaImageLoader,请使用hack _filter,从而不影响到你的IE7+的用户。
Optimize Images tag:images
当设计师制作好网站的图片后,还有些事情应该是你在把这些图片上传到服务器之前做的。
identify -verbose image.gif
如果你看到一个4色的图片却有一个256色的调色板,那么还有很大的空间来做性能优化。 convert image.gif image.png
“我们强调的是,给PNG一个机会!”
pngcrush image.png -rem alla -reduce -brute result.png
jpegtran -copy none -optimize -perfect src.jpg dest.jpg
tag:images
tag:images
不要使用大小超过需要的图片,即使你能够在HTML中设置它的属性。如果你需要
<img width="100" height="100" src="mycat.jpg" alt="My Cat" />
那么就使用恰好100*100px的图片,而不是使用缩放后的500*500的图片。
tag:images
favicon.icon是放在服务器根目录的一个图片,它是个麻烦却不得不处理,因为即使你不关心,浏览器依然会请求这张图片,所以最好不要提供一个404的错误。而且由于它是在同一服务器下的,Cookie也会随着每次请求一并发送。这张图片同样干扰下载队列,比如在IE中,当你在onload事件中请求额外的组件时,favicon会在这些额外组件之前下载。
所以为了减少favicon.ico的不利影响,我们应当:
Imagemagick 能够帮助你创建小图片。
tag:mobile
这一限制是因为iPone不会缓存大于25K的组件,注意这里指的是未压缩前的大小。这就是为什么缩小大小很重要,因为单单gzip并不足够。
查看Wayne Shea和Tenni Theurer的"Performance Research, Part 5: iPhone Cacheability - Making it Stick"获取更多信息。
tag:mobile
把组件打包进多部分文档类似一封包含有附件的邮件,它能让你通过一个HTTP请求获取多个组件(记住HTTP请求是很昂贵的)。当你使用这一技术,请先检查客户端是否支持它(iPone不支持)。