高性能网站建设的最佳实践（三）

最新推荐文章于 2024-09-25 18:15:20 发布

weixin_34177064

最新推荐文章于 2024-09-25 18:15:20 发布

阅读量92

点赞数

文章标签： javascript 运维数据库 ViewUI

原文链接：http://blog.51cto.com/moviejs/1305406

版权

原文译自雅虎开发者社区，转载译文请标明出处。

关注我的sina微博，共同进步！

为了让网页响应速度更快Exceptional Performance团队列出了一系列的最佳实践，包括35个最佳实践条目，分成7种类型类。

预先加载组件

标签：内容

预先加载看上去像是延迟加载的反面，但是它实际上有着不同的目的。通过预先加载组件，你可以利用浏览器的空闲时间并且可以请求将来需要的组件（比如图像、脚本以及样式）。这样当用户访问下一个页面的时候，你的大多数组件也就位于缓存之中了，你的页面加载对于用户来说就很快。

实际上有几种的预先加载类型

l无条件的预先加载——一旦onload时间触发了，你继续去加载其他的组件。看下Google.com是如何加载sprite图像的。在google首页并不需要的Sprite图像会被加载，因为在后续的搜索页中这些Sprite图像是确实需要的。

l条件预加载——基于用户的动作，你预算用户去往哪里并且相应的进行预加载。在search.yahoo.com中，你可以看到一些额外的组件在用户开始在输入框中输入东西的时候被加载。

l期望的预加载——在发起一个重新设计页面之前进行预加载。你经常听到在重新设计一个页面之后的反馈：“新站点很好，但是这比之前的要慢。”部分问题的原因是用户携带全量的缓存访问你的老页面，但是访问新的页面时缓存却为空的。你可以通过在最终发布重新设计的页面之前预先加载一些组件来缓解这个副作用。在你的老页面中利用浏览器空闲的时间来请求新页面中使用的图像和脚本。

减少DOM元素的数量

标签：内容

一个复杂的页面也就意味着需要更多的字节去加载，这也同样以为这在JavaScript中访问DOM元素变得更慢。例如，当你在一个具备500个DOM元素上注册事件和在一个5000个元素上注册事件是完全不同的。

大量的DOM元素意味着页面的标记应该被改进而不必移除内容。你使用包裹表格来完成布局的目的吗？你是否添加了跟多的DIV标签为了解决一个布局问题？或许存在更好的更加符合语义的方法来完成标记。

YUICSS Utilities会很好的帮助布局：grid.css可以帮助你整体布局，font.css和reset.css可以帮助你移除浏览器的默认样式。这有助于你重新更新和思考你的标记，例如，仅在具备语义意义的前提下使用<div>标记，而不是因为需要渲染一个空行。

DOM元素的数量很容易检测，使用Firebug的控制台，输入：

document.getElementsByTagName(“*”).length

问题是多少个DOM元素才算是多呢？检查下类似的具备优良标记的页面。比如Yahoo！Home Page是一个繁忙的页面并且是有不超过700个元素（HTML标签）。（译者注：实际上现在有2123个）

依据域名分割组件

标签：内容

分割组件可以使你最大化的利用并行加载。由于DNS查询的代价，确认你使用不超过2-4个域名。例如可以在www.example.org上管理HTML和动态的内容而将静态的组件分配到static1.example.org和static2.example.org上。

阅读Tnni Theurer和Patty Chi缩写的“Maximizing Parallel Downloads in the Carpool Lane”获取更多信息。

最小化iframes的数量

标签：内容

Iframe允许HTML文档插入到一个父文档中。理解iframe的工作机制有助于他们被有效的使用。

l有助于处理缓慢的第三方徽标和广告

l安全沙箱

l并行下载脚本文件

l如果为空的话会很浪费资源

l阻碍页面的onload

l非语义化的

不要有404响应

标签：内容

HTTP请求在发送一个请求并得到一个无用的响应方面的代价很高（也就是404 Not Found），并且会减慢用户的体验而不带有任何好处。

一些站点有帮助性质的404页面“你的意思是X？”，这提升了用户的体验但是也浪费了服务器资源（比如数据库）。特别的，当连接到一个外联的JavaScript文件并且结果是404的情况尤其的糟糕。首先，这个加载会阻碍其他的并行加载。其次，浏览器或尝试解析404响应报文体就如同它是JavaScript代码一样，并且尝试去发现一些没用的信息。

减少Cookie的大小

标签：cookie

HTTPcookies使用在广泛的场景中，比如授权和个性化。Cookies的信息通过HTTP头部的标签在浏览器和服务器端传输。保持Cookie尽可能的小是很重要的，这能够影响用户的响应时间。

阅读 Tenni Theurer和Patty Chi的“When the Cookie Crumbles”获取更多消息。结论如下：

l减少不必要的cookies

l让cookies的大小尽可能的小，从而最小化对用户的响应时间的影响。

l注意在一个适当的域名级别设定Cookie使得子域名不熟影响

l适当设置过期时间。一个较早的过期时间会尽快的移除cookie从而提升响应时间

为组件使用免cookie的域名

标签：cookie

当浏览器发请求静态的图像会把cookies一起发送出去，而服务器端却不需要这些cookies。所以他们在网络上传输也是不必要的。你应该确保静态的组件在求请求时不要携带cookies信息。创建子域名并且将所有的静态资源部署到那。

如果你的域名是www.example.org，你可以在static.example.org中管理静态资源。然而如果你已经在顶级域名example.org上设置了cookies，而不是www.example.org，那么所有的请求到static.example.org将会包含cookies。这种情况下，可以通过购买一个新的域名，在那里管理你的静态资源，并且使得这个域名不含有cookies。雅虎使用yimg.com，Youtube使用ytimg.com，Amazon使用p_w_picpaths.amazon.com以及其他。

另一个在无cookie的域名中管理静态的资源的好处是，一些代理或许会拒绝缓存具有cookies信息的组件。注意下，如果你在想是否需要使用example.org或者www.example.org设置你的首页地址，考虑下cookie的影响。忽略www让你只有将cookies写到*.example.org上，所以为了性能的缘故最好使用www的次级域名，并且将cookies写到相应的次级域名下。

最少化DOM访问

标签：JavaScript

通过JavaScript来访问DOM元素很慢，所以为了更快的响应页面，你应该：

l缓存对已访问的DOM元素的引用

l离线更新节点然后将它们添加到树中

l避免使用JavaScript修复样式问题

阅读 YUI theatre的文章“High Performance Ajax Applications”了解更多。

开发敏捷的时间侦听器

标签：JavaScript

有时候，页面因为将太多的时间侦听器注册到DOM树中的不同的元素上而变得迟钝。这也是为什么使用事件代理是个好的途径。如果你有10个按钮位于一个DIV中，仅将一个事件侦听器注册到包裹对象DIV中，而不是为每个按钮注册事件。事件冒泡让你可以捕获事件并且知道它是哪个按钮元素发送的。

你也不必等待为了开始对DOM树做一些操作而等待onload事件。通常你所需要访问的仅仅是已经在树中的严肃。你不用等待图像的加载。DOMContentLoaded是你需要考虑的问题不是onload事件。你可以使用YUIEvent工具，有个onAvailable方法可以实现这些。

阅读Julien Lecomte的“High Performance Ajax Applications”了解跟多。

使用<link>而不是@import

标签：CSS

之前的最佳实践之一就是CSS应该被置于最顶端，从而实现渐进渲染。

在IE中@import和将<link>置于页面最低端的效果类似，所以最好不用这个功能。

避免滤镜

标签：CSS

在IE7一下的版本中，IE所特有的AlphaImageLoader滤镜致力于修正PNG图像半透明的问题。这个滤镜的问题是，当图像加载过程中它阻塞了渲染并且固化了浏览器。它也增加了内存的消耗，针对每个元素执行，而不每张图像，所以问题多多。

最好是避免使用AlphaImageLoader而是使用更优雅的PNG8，可以在IE中工作。如果一定要是用AlphaImageLoader，使用下划线的hack方法_filter使得不影响IE7以上的用户。

优化图像

标签：图像

当设计师为你的页面创建完图像后，在你将图像FTP到服务器上之前，你仍然可是试试一些方法来优化。

l你可以价差GIF图像，看看他们使用的画板颜色数是否和图像中的颜色树一致。使用p_w_picpathmagick可以很容易检出

Identify –verbose p_w_picpath.gif

当你使用4个颜色，而画板中有256色，这样也就有了提升的空间。

l尝试将GIF图像转化为PNG图像，查看是否有减小图像体积。时常的开发者因为浏览器支持优先而犹豫是否使用PNG图像，但是这只是过去的事了。真正的也是唯一问题是PNG图像的alpha透明度，而GIF并非是真色因而不支持透明图。所以任何GIF可以完成的，PNG（PNG8*）也可以完成（除了动画）。下面这个简单的p_w_picpathmigick命令产生可安全使用的PNG图像

Convert p_w_picpath.gif p_w_picpath.ong

“我们所能说的就是：给PiNG一个机会”

l运行在你所有的图像上运行pngcrush（或者其他任何PNG优化工具），例如：

Pngcrush p_w_picpath.png –rem alla –reduce –bruteresult.png

l在所有的JPEG图像上运行jpegtran。这个工具对JPEG图像进行无损处理比如旋转也可以用户优化并且移除注释以及其他的无用信息（比如EXIF信息）。

Jpegtran –copy none –optimize –perfect src.jpg dest.jpg

优化CSS Sprites

标签：图像

l将图像水平排列而不是竖直排列通常会导致更小的图像体积

l结合相似的图像到一个Sprite文件中会使得你的颜色数保存在一个较低的水平，理想情况下少于256色适用于PNG8图像

l“对移动设备优化”并且不要在Sprite的图像片段中遗留太多的空间。这对图像的尺寸的影响并不大但是会让用户代理消耗更少的内存来将图像解压到一个像素图像。100*100图像有10000像素，然而1000*1000的图像就有一百万像素。

不要在HTML文档中缩放图像

标签：图像

不要仅仅因为能够在HTML中设置Width和Height而使用比需要的图像更大的图像。如果你需要<imgwidth=”100” height=”100” src=”mycat.jpg” alt=”My Cat”/>，那么图像(mycat.png)应该为100*100像素而不是500*500像素。

让favicon.ico较小并且可以被缓存

标签：图像

Favicon.icon是位于你服务器目录根部的图像。这图像很棘手因为即使你不关心它，浏览器仍然会请求它，所以最好不要针对这个请求回复404 Not Found。同样，既然它位于同一个服务器上，每次发送请求cookies信息也被发送。这个图像同样也会干扰下载队列，例如在IE中，当你在加载时间中请求额外的组件时，favicon将会在其他额外组件加载之前加载。

为了减少favicon.ico的不利影响，确保：

l它很小，最好小于1K

l设置Expires头部为你认为的一个合适值（你不能通过重命名来改变它）。以或许可以设置Expires头部为未来几个月。你可以检查当前favicon.icon的最后修改时间以做出合适的决定。

Imagemagick可以帮助你创建小的favicons图像。

使得组件小于25K

标签：移动设备

这个限制和iPhone不能缓存超出25K组件有关。注意这是为压缩的大小。因为GZIP压缩本省可能并不足够，这也是前面所论述的减小尺寸的重要性所在。

阅读WayneShea 和 Tenni Theurer的“PerformanceResearch, Part 5: iPhone Cacheability - Making it Stick”获取更多信息。

将组件打包到多组件文档中

标签：移动设备

将组建打包到一个多组件的文档中就如同含有附件的邮件一样，这使得你可以用一个HTTP请求获取多个组件（记住HTTP请求的代价高昂）。当使用这个技术时，首先检查用户代理是否支持（iPhone不支持）。

避免p_w_picpath标签的src属性为空

标签：服务器端

空的src属性往往让人意外的出现。它以两种方式出现：

1、静态的HTML

2、JavaScript

var img = new Image();

img.src=””

两种形式引起同样的问题：浏览器向服务器发送一个额外请求

- IE将请求发送到页面所在的目录
- Safari和Chrome将请求发送到页面本身
- Firefox 3和更早的版本和Safari和Chrome的行为类似，但是3.5版本的解决了这个问题，并且不在发送请求
- Opera在遇见一个空的src属性时不做任何处理

为什么这种行为很糟糕

1、发送大量的非预期的请求消弱了服务器，特别的对于那些用户浏览量过百万的页面

2、浪费了服务器的计算资源生成了绝不会被访问的页面

3、或许让用户数据奔溃。如果你跟踪请求的状态，无论通过cookies还是其他方式，有可能毁掉用户的数据。即使图像请求并不返回任何图像，所有的头部被浏览器接受，包括所有的cookies。然而其他的响应被舍弃了，或许损害已经产生了。

这种行为的根源在于浏览器解析URI的方式。这种行为在RFC3986——统一资源定位符中被定义。当一个将一个空的字符串作为URI时，将被看作是一个相对地址并且会以及在5.2部分定义的算法解析。在5.4部分定义了空字符串的特性实例。Firefox、Safari和Chrome都正确的依据了规范解析空字符串，但是IE的解析方式是错误的，显然适合规范的一个较早的版本一致，RFC2396-统一资源定位符（这个规范被RFC3986淘汰了）。所以从技术上讲，浏览器做了他们应该做的工作以解析一个相对的URI地址。问题是在这种情况下，空的字符串显然不是故意设置的。