High performance Web Sites

1.Make fewer HTTP requests
2.Use a CDN
3.Add an Expires header
4.Gzip components
5.Put CSS at the top
6.Move JS to the bottom
7.Avoid CSS expressions
8.Make JS and CSS external
9.Reduce DNS lookups
10.Minify JS
11.Avoid redirects
12.Remove duplicate scripts
13.Turn off ETags
14.Make AJAX cacheable and small

1. 尽可能的减少 HTTP 的请求数    [content]
2. 使用 CDN（Content Delivery Network）    [server]
3. 添加 Expires 头(或者 Cache-control )    [server]
4. Gzip 组件    [server]
5. 将 CSS 样式放在页面的上方    [css]
6. 将脚本移动到底部（包括内联的）    [javascript]
7. 避免使用 CSS 中的 Expressions    [css]
8. 将 JavaScript 和 CSS 独立成外部文件    [javascript] [css]
9. 减少 DNS 查询    [content]
10. 压缩 JavaScript 和 CSS (包括内联的)    [javascript] [css]
11. 避免重定向    [server]
12. 移除重复的脚本    [javascript]
13. 配置实体标签（ETags）    [css]
14. 使 AJAX 缓存


第一条、尽可能的减少 HTTP 的请求数 （Make Fewer HTTP Requests ）
http请求是要开销的，想办法减少请求数自然可以提高网页速度。常用的方法，合并css，js（将一个页面中的css和js文件分别合并）以及 Image maps和css sprites等。当然或许将css，js文件拆分多个是因为css结构，共用等方面的考虑。阿里巴巴中文站当时的做法是开发时依然分开开发，然后在后台 对js，css进行合并，这样对于浏览器来说依然是一个请求，但是开发时仍然能还原成多个，方便管理和重复引用。yahoo甚至建议将首页的css和js 直接写在页面文件里面，而不是外部引用。因为首页的访问量太大了，这么做也可以减少两个请求数。而事实上国内的很多门户都是这么做的。而css sprites是指只用将页面上的背景图合并成一张，然后通过css的background-position属性定义不过的值来取他的背景。
有几种常见的方法能切实减少 HTTP 请求：
1) 合并文件，比如把多个 CSS 文件合成一个；
2) CSS Sprites 利用 CSS background 相关元素进行背景图绝对定位；参见：CSS Sprites: Image Slicing's Kiss of Death
3) 图像地图
4) 内联图象 使用 data: URL scheme 在实际的页面嵌入图像数据.

第二条、使用CDN（内容分发网络）: Use a Content Delivery Network
简单地讲，通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的 cache服务器内，通过DNS负载均衡的技术，判断用户来源就近访问cache服务器取得所需的内容，杭州的用户访问近杭州服务器上的内容，北京的访问 近北京服务器上的内容。这样可以有效减少数据在网络上传输的时间，提高速度。更详细地内容大家可以参考百度百科上对于CDN的解释。Yahoo!把静态内容分布到CDN减少了用户影响时间20%或更多。
CDN技术示意图：


CDN组网示意图：


第三条、 添加Expire/Cache-Control 头：Add an Expires Header
这条守则包括两方面的内容：
对于静态内容：设置文件头过期时间Expires的值为“Never expire”（永不过期）
对于动态内容：使用恰当的Cache-Control文件头来帮助浏览器进行有条件的请求
现在越来越多的图片，脚本，css，flash被嵌入到页面中，当我们访问他们的时候势必会做许多次的http请求。其实我们可以通过设置Expires header 来缓存这些文件。Expire其实就是通过header报文来指定特定类型的文件在览器中的缓存时间。大多数的图片，flash在发布后都是不需要经常修改的，做了缓存以后这样浏览器以后就不需要再从服务器下载这些文件而是而直接从缓存中读取，这样再次访问页面的速度会大大加快。一个典型的HTTP 1.1协议返回的头信息：
HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: “3e86-410-3596fbbc”
Content-Length: 1040
Content-Type: text/html
其中通过服务器端脚本设置Cache-Control和Expires可以完成。
如，在php中设置30天后过期：
<?php
Header("Cache-Control: must-revalidate");
$offset = 60 * 60 * 24 * 30;
$ExpStr = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT";
Header($ExpStr);
?>
也可以通过配置服务器本身完成。想了解跟多的朋友可以参考http://www.web-caching.com/
据我了解，目前阿里巴巴中文站的Expires过期时间是30天。不过期间也有过问题，特别是对于脚本过期时间的设置还是应该仔细考虑下，不然相应的脚本功能更新后客户端可能要过很长一段时间才能“感知”到这样的变化。以前做[suggest项目] 的时候就遇到过这个问题。所以，哪些应该缓存，哪些不该缓存还是应该仔细斟酌一番。

第四条、启用Gzip压缩：Gzip Components
Gzip的思想就是把文件先在服务器端进行压缩，然后再传输。这样可以显著减少文件传输的大小。传输完毕后浏览器会 重新对压缩过的内容进行解压缩，并执行。目前的浏览器都能“良好”地支持 gzip。不仅浏览器可以识别，而且各大“爬虫”也同样可以识别，各位seoer可以放下心了。而且gzip的压缩比例非常大，一般压缩率为85%，就是 说服务器端100K的页面可以压缩到25K左右再发送到客户端。具体的Gzip压缩原理大家可以参考csdn上的《gzip压缩算法》 这篇文章。雅虎特别强调， 所有的文本内容都应该被gzip压缩: html (php), js, css, xml, txt… 这一点我们网站做得不错，是一个A。以前我们的首页也并不是A，因为首页上还有很多广告代码投放的js，这些广告代码拥有者的网站的js没有经过gzip压缩，也会拖累我们网站。
图像和PDF文件由于已经压缩过了所以不能再进行gzip压缩。如果试图gizp压缩这些文件的话不但会浪费CPU资源还会增加文件的大小。  
第五条、将css放在页面最上面 （ Put Stylesheets at the Top）
将css放在页面最上面，这是为什么？因为 ie，firefox等浏览器在css全部传输完全之前不会去渲染任何的东西。css，全称Cascading Style Sheets (层叠样式表单)。层叠即意味这后面的css可以覆盖前面的css，级别高的css可以覆盖级别低的css。在[css之！important] 这篇文章的最下面曾简单地提到过这层级关系，这里我们只需要知道css可以被覆盖的。既然前面的可以被覆盖，浏览器在他完全加载完毕之后再去渲染无疑也是合情合理的很多浏览器下，如IE，把样式表放在页面的底部的问题在于它禁止了网页内容的顺序显示。浏览器阻止显示以免重画页面元素，那用户只能看到空白页了。Firefox不会阻止显示，但这意味着当样式表下载后，有些页面元素可能需要重画，这导致闪烁问题。所以我们应该尽快让css加载完毕，顺着这层意思，如果我们再细究的话，其实还有可以优化的地方。比如本站上面包含的两个css文件，<link rel=“stylesheet” rev=“stylesheet” href=“http://www.space007.com/themes/google/style/google.css” type=“text/css” media=“screen” /> 和<link rel=“stylesheet” rev=“stylesheet” href=“http://www.space007.com/css/print.css” type=“text/css” media=“print” />。 从media就可以看出第一个css是针对浏览器的，第二个css文件是针对打印样式的。从用户的行为习惯上来将，要打印页面的动作一定是发生在页面页面 显示出来之后的。所以比较好的方法应该是在页面加载完毕之后再动态地为这张页面加上针对打印设备的css，这样又可以提高一点速度。
第六条、将script放在页面最下面 （Put Scripts at the Bottom ）
将脚本放在页面最下面的目的有那么两点： 1、 因为防止script脚本的执行阻塞页面的下载。在页面loading的过程中，当浏览器读到js执行语句的时候一定会把它全部解释完毕后在会接下来读下 面的内容。（setTimeout 和 setInterval的执行有点类似于多线程，在相应的响应时间之前也会继续下面的内容渲染。）浏览器这么做的逻辑是因为js随时可能执 行 location.href或是其他可能完全中断此页面过程的函数，即如此，当然得等他执行完毕之后再加载咯。所以放在页面最后，可以有效减少页面可 视元素的加载时间。        2、脚本引起的第二个问题是它阻塞并行下载数量。HTTP/1.1规范建议浏览器每个主机的并行下载数不超过2个（IE只能为2个，其他浏览器如ff等都是默认设置为2个，不过新出的ie8可以达6个）。因此如果您把图像文件分布到多台机器的话，您可以达到超过2个的并行下载。但是当脚本文件下载时，浏览器不会启动其他的并行下载。
当然对各个网站来说，把脚本都放到页面底部加载的可行性还是值得商榷的。就比如阿里巴巴中文站的页面。很多地方有内联的js，页面的显示严重依赖于此，我承认这和无侵入脚本的理念相差甚远，但是很多“历史遗留问题”却不是那么容易解决的。
第七条、避免在CSS中使用Expressions （Avoid CSS Expressions ）
不过这样就多了两层无意义的嵌套，肯定不好。还需要一个更好的办法。
第八条、把javascript和css都放到外部文件中 （Make JavaScript and CSS External ）
不仅从性能优化上会这么做，用代码易于维护的角度看也应该这么做。把css和js写在页面内容可以减少2次请求，但也增 大了页面的大小。如果已经对css和js做了缓存，那也就没有2次多余的http请求了。当然，我在前面中也说过，有些特殊的页面开发人员还是会选择内联 的css和js文件。
第九条、减少DNS查询 (Reduce DNS Lookups)
在 Internet上域名与IP地址之间是一一对应的，域名（kuqin.com）很好记，但计算机不认识，计算机之间的“相认”还要转成ip地址。在网络 上每台计算机都对应有一个独立的ip地址。在域名和ip地址之间的转换工作称为域名解析，也称DNS查询。一次DNS的解析过程会消耗20-120毫秒的 时间,在dns查询结束之前，浏览器不会下载该域名下的任何东西。所以减少dns查询的时间可以加快页面的加载速度。yahoo的建议一个页面所包含的域名数尽量控制在2-4个。这就需要对页面整体有一个很好的规划。目前我们这点做的不好，很多打点的广告投放系统拖累了我们。
第十条、压缩 JavaScript 和 CSS (Minify JavaScript )
精简是指从去除代码不必要的字符减少文件大小从而节省下载时间。消减代码时，所有的注释、不需要的空白字符（空格、换行、tab缩进）等都要去掉。在JavaScript中，由于需要下载的文件体积变小了从而节省了响应时间。压缩js和css的作用很显然，减少页面字节数。容量小页面加载速度自然也就快。而且压缩除了减少体积以外还可以起到一定的保护左右。这点我们做得不错。常用的压缩工具有JsMin、YUI compressor等。
当然，压缩带来的一个弊端就是代码的可读性没了。相信很多做前端的朋友都遇到过这个问题：看Google的效果很酷，可是去看他的源代码却是一大堆 挤在一起的字符，连函数名都是替换过的，汗死！自己的代码也这样岂不是对维护非常不方便。所有阿里巴巴中文站目前采用的做法是在js和css发布的时候在 服务器端进行压缩。这样在我们很方便地维护自己的代码。
第十一条、避免重定向 (Avoid Redirects )
不久前在ieblog上看到过《Internet Explorer and Connection Limits》这篇文章，比如 当你输入http://www.kuqin.com/ 的时候服务器会自动产生一个301服务器转向 http://www.kuqin.com/ ，你看浏览器的地址栏就能看出来。这种重定向自然也是需要消耗时间的。当然这只是一个例子，发生重定向的原因还有很多，但是不变的是每增加一次重定向就会增加一次web请求，所以因该尽量减少。
第十二条、移除重复的脚本 (Remove Duplicate Scripts )
这点我想不说也知道，不仅是从性能上考虑，代码规范上看也是这样。但是不得不承认，很多时候我们会因为图一时之快而加上一些或许是重复的代码。或许一个统一的css框架和js框架可以比较好的解决我们的问题。
第十三条、配置实体标签（ETags） (Configure ETags )
在inforQ上找到一篇解释得比较详细的说明《使用ETags减少Web应用带宽和负载》，有兴趣的同学可以去看看。
第十四条、使 AJAX 缓存 (Make Ajax Cacheable )
ajax还要去缓存？做ajax请求的时候往往还要增加一个时间戳去避免他缓存。It’s important to remember that “asynchronous” does not imply “instantaneous”.（记住“异步”不是“瞬间”这一点很重要）。记住，即使AJAX是动态产生的而且只对一个用户起作用，他们依然可以被缓 存。
14+1. 对 AJAX 请求使用 GET 方法 (Use GET for AJAX Requests)
XMLHttpRequest POST 要两步，而 GET 只需要一步。但要注意的是在 IE 上 GET 最大能处理的 URL 长度是 2K。
Yahoo!Mail团队发现，当使用XMLHttpRequest时，浏览器中的POST方法是一个“两步走”的过程：首先发送文件头，然后才发送数据。因此使用GET最为恰当，因为它只需发送一个TCP包（除非你有很多cookie）。IE中URL的最大长度为2K，因此如果你要发送一个超过2K的数据时就不能使用GET了。
一个有趣的不同就是POST并不像GET那样实际发送数据。根据HTTP规范，GET意味着“获取”数据，因此当你仅仅获取数据时使用GET更加有意义（从语意上讲也是如此），相反，发送并在服务端保存数据时使用POST。

14+2. 缩小 Cookie (Reduce Cookie Size)
Cookie 是个很有趣的话题。根据 RFC 2109 的描述，每个客户端最多保持 300 个 Cookie，针对每个域名最多 20 个 Cookie (实际上多数浏览器现在都比这个多，比如 Firefox 是 50 个) ，每个 Cookie 最多 4K，注意这里的 4K 根据不同的浏览器可能不是严格的 4096 。别扯远了，对于 Cookie 最重要的就是，尽量控制 Cookie 的大小，不要塞入一些无用的信息。
HTTP coockie可以用于权限验证和个性化身份等多种用途。coockie内的有关信息是通过HTTP文件头来在web服务器和浏览器之间进行交流的。因此保持coockie尽可能的小以减少用户的响应时间十分重要。 主要包括：
·     去除不必要的coockie
·     使coockie体积尽量小以减少对用户响应的影响
·     注意在适应级别的域名上设置coockie以便使子域名不受影响
·     设置合理的过期时间。较早地Expire时间和不要过早去清除coockie，都会改善用户的响应时间。
14+3. 避免 CSS 表达式 (Avoid CSS Expressions)
CSS表达式是动态设置CSS属性的强大（但危险）方法。Internet Explorer从第5个版本开始支持CSS表达式。下面的例子中，使用CSS表达式可以实现隔一个小时切换一次背景颜色：
background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );
如上所示，expression中使用了JavaScript表达式。CSS属性根据JavaScript表达式的计算结果来设置。expression方法在其它浏览器中不起作用，因此在跨浏览器的设计中单独针对Internet Explorer设置时会比较有用。
      表达式的问题就在于它的计算频率要比我们想象的多。不仅仅是在页面显示和缩放时，就是在页面滚动、乃至移动鼠标时都会要重新计算一次。给CSS表达式增加一个计数器可以跟踪表达式的计算频率。在页面中随便移动鼠标都可以轻松达到10000次以上的计算量。
      一个减少CSS表达式计算次数的方法就是使用一次性的表达式，它在第一次运行时将结果赋给指定的样式属性，并用这个属性来代替CSS表达式。如果样式属性必须在页面周期内动态地改变，使用事件句柄来代替CSS表达式是一个可行办法。如果必须使用CSS表达式，一定要记住它们要计算成千上万次并且可能会对你页面的性能产生影响。
14+4. 使用 <link> 而不是@import （Choose <link> over @import）
在 IE 中 @import 指令等同于把 link 标记写在 HTML 的底部。而这与第一条相违背。
14+5.避免使用CSS Filter
尽量使用png格式的图片来代替滤镜效果，因为开启滤镜会加大浏览器的开销。 在每一个元素（不仅仅是图片）它都会运算一次，增加了内存开支，因此它的问题是多方面的。

14+6、使iframe的数量最小
ifrmae元素可以在父文档中插入一个新的HTML文档。了解iframe的工作理然后才能更加有效地使用它，这一点很重要。
<iframe>优点：
·     解决加载缓慢的第三方内容如图标和广告等的加载问题
·     Security sandbox
·     并行加载脚本
<iframe>的缺点：
·     即时内容为空，加载也需要时间
·     会阻止页面加载
·     没有语意
14+7、不要出现404错误
HTTP请求时间消耗是很大的，因此使用HTTP请求来获得一个没有用处的响应（例如404没有找到页面）是完全没有必要的，它只会降低用户体验而不会有一点好处。
      有些站点把404错误响应页面改为“你是不是要找***”，这虽然改进了用户体验但是同样也会浪费服务器资源（如数据库等）。最糟糕的情况是指向外部JavaScript的链接出现问题并返回404代码。首先，这种加载会破坏并行加载；其次浏览器会把试图在返回的404响应内容中找到可能有用的部分当作JavaScript代码来执
28、对于页面内容使用无coockie域名
      当浏览器在请求中同时请求一张静态的图片和发送coockie时，服务器对于这些coockie不会做任何地使用。因此他们只是因为某些负面因素而创建的网络传输。所有你应该确定对于静态内容的请求是无coockie的请求。创建一个子域名并用他来存放所有静态内容。
      如果你的域名是www.example.org，你可以在static.example.org上存在静态内容。但是，如果你不是在www.example.org上而是在顶级域名example.org设置了coockie，那么所有对于static.example.org的请求都包含coockie。在这种情况下，你可以再重新购买一个新的域名来存在静态内容，并且要保持这个域名是无coockie的。Yahoo!使用的是ymig.com，YouTube使用的是ytimg.com，Amazon使用的是images-anazon.com等等。
      使用无coockie域名存在静态内容的另外一个好处就是一些代理（服务器）可能会拒绝对coockie的内容请求进行缓存。一个相关的建议就是，如果你想确定应该使用example.org还是www.example.org作为你的一主页，你要考虑到coockie带来的影响。忽略掉www会使你除了把coockie设置到*.example.org（*是泛域名解析，代表了所有子域名译者dudo注）外没有其它选择，因此出于性能方面的考虑最好是使用带有www的子域名并且在它上面设置coockie。
29、优化图像
      设计人员完成对页面的设计之后，不要急于将它们上传到web服务器，这里还需要做几件事：
·     你可以检查一下你的GIF图片中图像颜色的数量是否和调色板规格一致。 使用imagemagick中下面的命令行很容易检查：
identify -verbose image.gif
如果你发现图片中只用到了4种颜色，而在调色板的中显示的256色的颜色槽，那么这张图片就还有压缩的空间。
·     尝试把GIF格式转换成PNG格式，看看是否节省空间。大多数情况下是可以压缩的。由于浏览器支持有限，设计者们往往不太乐意使用PNG格式的图片，不过这都是过去的事情了。现在只有一个问题就是在真彩PNG格式中的alpha通道半透明问题，不过同样的，GIF也不是真彩格式也不支持半透明。因此GIF能做到的，PNG（PNG8）同样也能做到（除了动画）。下面这条简单的命令可以安全地把GIF格式转换为PNG格式：
convert image.gif image.png
“我们要说的是：给PNG一个施展身手的机会吧！”
·     在所有的PNG图片上运行pngcrush（或者其它PNG优化工具）。例如：
pngcrush image.png -rem alla -reduce -brute result.png
·     在所有的JPEG图片上运行jpegtran。这个工具可以对图片中的出现的锯齿等做无损操作，同时它还可以用于优化和清除图片中的注释以及其它无用信息（如EXIF信息）：
jpegtran -copy none -optimize -perfect src.jpg dest.jpg
30、优化CSS Spirite
·     在Spirite中水平排列你的图片，垂直排列会稍稍增加文件大小；
·     Spirite中把颜色较近的组合在一起可以降低颜色数，理想状况是低于256色以便适用PNG8格式；
·     便于移动，不要在Spirite的图像中间留有较大空隙。这虽然不大会增加文件大小但对于用户代理来说它需要更少的内存来把图片解压为像素地图。100x100的图片为1万像素，而1000x1000就是100万像素。
31、不要在HTML中缩放图像
不要为了在HTML中设置长宽而使用比实际需要大的图片。如果你需要：<img width="100" height="100" src="mycat.jpg" alt="My Cat" />
那么你的图片（mycat.jpg）就应该是100x100像素而不是把一个500x500像素的图片缩小使用。
32、favicon.ico要小而且可缓存
      favicon.ico是位于服务器根目录下的一个图片文件。它是必定存在的，因为即使你不关心它是否有用，浏览器也会对它发出请求，因此最好不要返回一个404 Not Found的响应。由于是在同一台服务器上，它每被请求一次coockie就会被发送一次。这个图片文件还会影响下载顺序，例如在IE中当你在onload中请求额外的文件时，favicon会在这些额外内容被加载前下载。
      因此，为了减少favicon.ico带来的弊端，要做到：
·     文件尽量地小，最好小于1K
·     在适当的时候（也就是你不要打算再换favicon.ico的时候，因为更换新文件时不能对它进行重命名）为它设置Expires文件头。你可以很安全地把Expires文件头设置为未来的几个月。你可以通过核对当前favicon.ico的上次编辑时间来作出判断。
Imagemagick可以帮你创建小巧的favicon。
28、对于页面内容使用无coockie域名
      当浏览器在请求中同时请求一张静态的图片和发送coockie时，服务器对于这些coockie不会做任何地使用。因此他们只是因为某些负面因素而创建的网络传输。所有你应该确定对于静态内容的请求是无coockie的请求。创建一个子域名并用他来存放所有静态内容。
      如果你的域名是www.example.org，你可以在static.example.org上存在静态内容。但是，如果你不是在www.example.org上而是在顶级域名example.org设置了coockie，那么所有对于static.example.org的请求都包含coockie。在这种情况下，你可以再重新购买一个新的域名来存在静态内容，并且要保持这个域名是无coockie的。Yahoo!使用的是ymig.com，YouTube使用的是ytimg.com，Amazon使用的是images-anazon.com等等。
      使用无coockie域名存在静态内容的另外一个好处就是一些代理（服务器）可能会拒绝对coockie的内容请求进行缓存。一个相关的建议就是，如果你想确定应该使用example.org还是www.example.org作为你的一主页，你要考虑到coockie带来的影响。忽略掉www会使你除了把coockie设置到*.example.org（*是泛域名解析，代表了所有子域名译者dudo注）外没有其它选择，因此出于性能方面的考虑最好是使用带有www的子域名并且在它上面设置coockie。
29、优化图像
      设计人员完成对页面的设计之后，不要急于将它们上传到web服务器，这里还需要做几件事：
·     你可以检查一下你的GIF图片中图像颜色的数量是否和调色板规格一致。 使用imagemagick中下面的命令行很容易检查：
identify -verbose image.gif
如果你发现图片中只用到了4种颜色，而在调色板的中显示的256色的颜色槽，那么这张图片就还有压缩的空间。
·     尝试把GIF格式转换成PNG格式，看看是否节省空间。大多数情况下是可以压缩的。由于浏览器支持有限，设计者们往往不太乐意使用PNG格式的图片，不过这都是过去的事情了。现在只有一个问题就是在真彩PNG格式中的alpha通道半透明问题，不过同样的，GIF也不是真彩格式也不支持半透明。因此GIF能做到的，PNG（PNG8）同样也能做到（除了动画）。下面这条简单的命令可以安全地把GIF格式转换为PNG格式：
convert image.gif image.png
“我们要说的是：给PNG一个施展身手的机会吧！”
·     在所有的PNG图片上运行pngcrush（或者其它PNG优化工具）。例如：
pngcrush image.png -rem alla -reduce -brute result.png
·     在所有的JPEG图片上运行jpegtran。这个工具可以对图片中的出现的锯齿等做无损操作，同时它还可以用于优化和清除图片中的注释以及其它无用信息（如EXIF信息）：
jpegtran -copy none -optimize -perfect src.jpg dest.jpg
30、优化CSS Spirite
·     在Spirite中水平排列你的图片，垂直排列会稍稍增加文件大小；
·     Spirite中把颜色较近的组合在一起可以降低颜色数，理想状况是低于256色以便适用PNG8格式；
·     便于移动，不要在Spirite的图像中间留有较大空隙。这虽然不大会增加文件大小但对于用户代理来说它需要更少的内存来把图片解压为像素地图。100x100的图片为1万像素，而1000x1000就是100万像素。
33、保持单个内容小于25K
      这条限制主要是因为iPhone不能缓存大于25K的文件。注意这里指的是解压缩后的大小。由于单纯gizp压缩可能达不要求，因此精简文件就显得十分重要。
      查看更多信息，请参阅Wayne Shea和Tenni Theurer的文件“Performance Research, Part 5: iPhone Cacheability - Making it Stick”。
34、打包组件成复合文本
      把页面内容打包成复合文本就如同带有多附件的Email，它能够使你在一个HTTP请求中取得多个组件（切记：HTTP请求是很奢侈的）。当你使用这条规则时，首先要确定用户代理是否支持（iPhone就不支持）

以上参考《Yahoo!网站性能最佳体验的34条黄金守则》