最近整理了一下WEB站点的性能优化项

总分划分成了几个类别，content、server、Cookie、CSS、JavaScript、Images、Mobile。

大致内容如下：

减少HTTP的请求数

合并Js、CSS文件，使用CSS sprites，使用Inline images（将base64的图片数据放在页面中会加大页面大小，可以放在可缓存的css中），使用iconfont。

合并文件是通过把所有的脚本放到一个文件中来减少 HTTP 请求的方法，如可以简单地把所有的 CSS 文件都放入一个样式表中。当脚本或者样式表在不同页面中使用时需要做不同的修改，这可能会相对麻烦点，但即便如此也要把这个方法作为改善页面性能的重要一步。

CSS Sprites 是减少图像请求的有效方法。把所有的背景图像都放到一个图片文件中，然后通过 CSS 的 background-image 和 background-position 属性来显示图片的不同部分；

CDN

用户80%~90%的时间是用来下载图片、样式、脚本、Flash等静态资源，将静态资源分发到离用户最近的服务器上，可加快下载速度。

减少 DNS 查找次数    

域名系统（DNS）提供了域名和 IP 的对应关系，就像电话本中人名和他们的电话号码的关系一样。当你在浏览器地址栏中输入 www.fufuok.com 时，DNS 解析服务器就会返回这个域名对应的 IP 地址。DNS 解析的过程同样也是需要时间的。一般情况下返回给定域名对应的 IP 地址会花费 20 到 120 毫秒的时间。而且在这个过程中浏览器什么都不会做直到 DNS 查找完毕。

缓存 DNS 查找可以改善页面性能。这种缓存需要一个特定的缓存服务器，这种服务器一般属于用户的 ISP 提供商或者本地局域网控制，但是它同样会在用户使用的计算机上产生缓存。DNS 信息会保留在操作系统的 DNS 缓存中（微软 Windows 系统中 DNS Client Service）。大多数浏览器有独立于操作系统以外的自己的缓存。由于浏览器有自己的缓存记录，因此在一次请求中它不会受到操作系统的影响。

Internet Explorer 默认情况下对 DNS 查找记录的缓存时间为 30 分钟，它在注册表中的键值为 DnsCacheTimeout 。Firefox 对 DNS 的查找记录缓存时间为 1 分钟，它在配置文件中的选项为 network.dnsCacheExpiration（Fasterfox 把这个选项改为了 1 小时）。

当客户端中的 DNS 缓存都为空时（浏览器和操作系统都为空），DNS 查找的次数和页面中主机名的数量相同。这其中包括页面中 URL 、图片、脚本文件、样式表、Flash 对象等包含的主机名。减少主机名的数量可以减少 DNS 查找次数。

减少主机名的数量还可以减少页面中并行下载的数量。减少 DNS 查找次数可以节省响应时间，但是减少并行下载却会增加响应时间。我的指导原则是把这些页面中的内容分割成至少两部分但不超过四部分。这种结果就是在减少 DNS 查找次数和保持较高程度并行下载两者之间的权衡了。

使用缓存

某站点设置静态资源缓存后，浏览网页时，一些公用的静态资源已经在浏览其它页面时下载缓存了，不用再发起请求。在缓存过期前，网页内容也没变动时，再次访问网页，所有静态资源都可以从缓存读取。

合理配置缓存策略，在公用的静态资源和请求数之间达到平衡，站点的不同页面间可以共用更多的公用的静态资源。站点更新不仅能即时反馈，而且做到网页只需加载有变动的文件。

http响应头信息Expires、Cache-Control是缓存字段。这里的缓存是指浏览器缓存，缓存过期前不用发起请求。

浏览器中刷新页面，会重新发起所有的请求；如果在地址栏按回车键，可以看到设置缓存的静态资源没有再次发起请求。

Gzip压缩

网络传输中的 HTTP 请求和应答时间可以通过前端机制得到显著改善。的确，终端用户的带宽、互联网提供者、与对等交换点的靠近程度等都不是网站开发者所能决定的。但是还有其他因素影响着响应时间。通过减小 HTTP 响应的大小可以节省 HTTP 响应时间。

从 HTTP/1.1 开始，Web 客户端都默认支持 HTTP 请求中有 Accept-Encoding 文件头的压缩格式：

Accept-Encoding: gzip, deflate

如果 Web 服务器在请求的文件头中检测到上面的代码，就会以客户端列出的方式压缩响应内容。Web 服务器把压缩方式通过响应文件头中的 Content-Encoding 来返回给浏览器。

Content-Encoding: gzip

Gzip 是目前最流行也是最有效的压缩方式。这是由 GNU 项目开发并通过 RFC 1952 来标准化的。另外仅有的一个压缩格式是 deflate ，但是它的使用范围有限效果也稍稍逊色。

Gzip 大概可以减少 70% 的响应规模。目前大约有 90% 通过浏览器传输的互联网交换支持 gzip 格式。如果你使用的是 Apache ，gzip 模块配置和你的版本有关：Apache 1.3 使用 mod_zip ，而 Apache 2.x 使用 moflate 。

浏览器和代理都会存在这样的问题：浏览器期望收到的和实际接收到的内容会存在不匹配的现象。幸好，这种特殊情况随着旧式浏览器使用量的减少在减少。Apache 模块会通过自动添加适当的 Vary 响应文件头来避免这种状况的出现。

服务器根据文件类型来选择需要进行 gzip 压缩的文件，但是这过于限制了可压缩的文件。大多数 Web 服务器会压缩 HTML 文档。对脚本和样式表进行压缩同样也是值得做的事情，但是很多 Web 服务器都没有这个功能。实际上，压缩任何一个文本类型的响应，包括 XML 和 JSON ，都值得的。图像和 PDF 文件由于已经压缩过了所以不能再进行 gzip 压缩。如果试图 gizp 压缩这些文件的话不但会浪费 CPU 资源还会增加文件的大小。

Gzip 压缩所有可能的文件类型是减少文件体积增加用户体验的简单方法。

服务端收到浏览器请求后，经gzip压缩后传输的大小可减小70%，浏览器接收后解压。pdf、图片本身已经压缩了不再需要gzip。一般文档类型默认启用了gzip，其它静态资源，比如样式、脚本要单独配置启用gzip。

将样式表放在页面上方

网页渲染是从上往下执行，边下载边解析页面元素，将样式放在页尾，下载完样式后执行会使页面样式闪烁。

貌似有些浏览器只有等css下载好了之后，才展示出页面。chrome访问过国外网站，出现过css没下载好，整个页面都是空白。

将脚本放在底部

浏览器中JavaScript与UI共用一个线程，现在的浏览器Js下载是并行的（IE8、Firefox3、Chrome2是串行），下载时会阻 止页面一些资源加载（google说下载、解释、执行都会阻止），如图片；执行是阻塞浏览器的页面的下载和渲染，所以引入的Js要放在页末。

css文件下载是并行的，不阻碍其它文件下载。而Js基本都用来操作Dom的，代码的执行要等Dom渲染完成，所以一般Js代码可以直接放在页尾，如果放在页首，处理Dom元素的Js代码要放在Dom下载完成的事件回调内。

除非你在DOM标签内部指定事件类型和回调函数名（不推荐），不然把Js放在页首没意义。

避免使用CSS中的Expressions

 这种写法只有IE支持，浏览器不仅在渲染页面或者改变页面大小时触发，甚至在滚动、移动鼠标时也触发，统计发现操作了一次浏览器产生10000个evaluations。

将JavaScript和CSS独立成外部文件

实现结构、样式、行为分离，独立成文件可以利用浏览器缓存。

压缩 JavaScript 和CSS

压缩JavaScript时，如果使用模块化开发时，比如seajs不能直接压缩，要先transport下，具体可参考spm的grunt-cmd-transport插件

避免重定向

Request URL:http://yun.ys7.com/gc.html
Request Method:GET
Status Code:301 Moved Permanently (from cache)

Response Headers
Content-Length:178
Content-Type:text/html
Date:Tue, 03 Feb 2015 15:34:42 GMT
Location:http://i.ys7.com/square/index.jsp
Server:nginx 

重定向的http请求返回301或者302，返回的报文的body部分是空的。

上面是访问http://yun.ys7.com/gc.html，服务器告诉浏览器重定向到//i.ys7.com/square/index.jsp，浏览器重新发起//i.ys7.com/square/index.jsp请求。

浏览器访问网页，通过重定向而发起两次请求，影响性能。

剔除重复的脚本

团队规模越大、代码越多，越有可能出现；如果出现，会导致没必要的请求和Js运算

配置ETags

etag判断一个静态资源有没有更新。请求一个静态资源，返回的头信息有etag字段，再次请求时，通过头信息中If-None-Match字段将 etag值带过去，与服务端的文件etag值比对，如果一致就直接返回状态码 304，浏览器使用缓存中的静态资源；不一致，服务器将最新文件传输过来。 etag值很重要，能反应出资源有无更新。一般的etag值inode-size-timestamp，虽然不同的服务器上inode值不一样。 这样如果静态资源部署在多台服务器上的，用etag就有问题。关闭etag，将判断一个静态资源有没有更新就交给Last-Modified。

使用AJAX缓存

使用get类型的ajax请求，后台处理接口时，加上http头信息Expires，以后浏览器再次发起请求时，在缓存的时间内，直接从浏览器缓存中读取。

比如有个网页联系人列表不经常变动，ajax请求联系人列表接口的url带上资源标志id（id是页面初始化时由后台带回来，后台根据联系列表生 成，如果列表变化了，id也变化），第一次访问时，ajax调用接口缓存了；第二次调用时，如果联系人列表没有变动过，id还是不变，url也不会变，直 接从缓存读取。

尽早刷新输出缓冲

后台生成一个完整的页面，要经历数据库查询，一系列业务流程，假设耗时为A，再由服务器容器转化成html页面返回给浏览器。浏览器边下载边解析 DOM，下载页面相关的静态资源，假设耗时为B，整个耗时就是（A+B）。 如果A和B并行呢？ 服务器容器先将静态资源的相关内容返回给浏览器，服务器一边进行查询等耗时操作（A），浏览器同时一边解析DOM中到引用静态资源，就开始下载（B）。 目前php支持。

Example:

...

...

使用GET来完成AJAX请求

使用post请求，浏览器要进行两个过程，先发头信息，再发送数据。而使用get，请求数据都在url上，只需发一次，IE下最大长度为2k，从语义化角度，来说，get是获取数据的意思。get请求会被缓存，post不会，post传输比较安全。

推迟加载内容

将所有静态资源都下载好了之后，再执行Js渲染等操作，会影响首屏内容最快显示。在模块化开发时，当用到插件效果时去下载，或者等浏览器加载的标签转圈圈好了之后，触发load之后再执行其它下载，使用require.async延迟加载。

你可以仔细看一下你的网页，问问自己“哪些内容是页面呈现时所必需首先加载的？哪些内容和结构可以稍后再加载？

把整个过程按照 onload 事件分隔成两部分，JavaScript 是一个理想的选择。例如，如果你有用于实现拖放和动画的 JavaScript ，那么它就以等待稍后加载，因为页面上的拖放元素是在初始化呈现之后才发生的。其它的例如隐藏部分的内容（用户操作之后才显现的内容）和处于折叠部分的图 像也可以推迟加载。

工具可以节省你的工作量：YUI Image Loader 可以帮你推迟加载折叠部分的图片，YUI Get utility 是包含 JS 和 CSS 的便捷方法。比如你可以打开 Firebug 的 Net 选项卡看一下 Yahoo 的首页。

当性能目标和其它网站开发实践一致时就会相得益彰。这种情况下，通过程序提高网站性能的方法告诉我们，在支持 JavaScript 的情况下，可以先去除用户体验，不过这要保证你的网站在没有 JavaScript 也可以正常运行。在确定页面运行正常后，再加载脚本来实现如拖放和动画等更加花哨的效果。

预加载

预加载和后加载看起来似乎恰恰相反，但实际上预加载是为了实现另外一种目标。预加载是在浏览器空闲时请求将来可能会用到的页面内容（如图像、样式表和脚本）。使用这种方法，当用户要访问下一个页面时，页面中的内容大部分已经加载到缓存中了，因此可以大大改善访问速度。

下面提供了几种预加载方法：

无条件加载：触发 onload 事件时，直接加载额外的页面内容。以 Google.com 为例，你可以看一下它的 spirit image 图像是怎样在 onload 中加载的。这个 spirit image 图像在 google.com 主页中是不需要的，但是却可以在搜索结果页面中用到它。

有条件加载：根据用户的操作来有根据地判断用户下面可能去往的页面并相应的预加载页面内容。在 search.yahoo.com 中你可以看到如何在你输入内容时加载额外的页面内容。

有预期的加载：载入重新设计过的页面时使用预加载。这种情况经常出现在页面经过重新设计后用户抱怨“新的页面看起来很酷，但是却比以前慢”。问题可 能出在用户对于你的旧站点建立了完整的缓存，而对于新站点却没有任何缓存内容。因此你可以在访问新站之前就加载一部内容来避免这种结果的出现。在你的旧站 中利用浏览器的空余时间加载新站中用到的图像的和脚本来提高访问速度。

减少DOM元素数量

一个复杂的页面意味着需要下载更多数据，同时也意味着 JavaScript 遍历 DOM 的效率越慢。比如当你增加一个事件句柄时在 500 和 5000 个 DOM 元素中循环效果肯定是不一样的。

大量的 DOM 元素的存在意味着页面中有可以不用移除内容只需要替换元素标签就可以精简的部分。你在页面布局中使用表格了吗？你有没有仅仅为了布局而引入更多的

元素呢？也许会存在一个适合或者在语意是更贴切的标签可以供你使用。

YUI CSS utilities 可以给你的布局带来巨大帮助：grids.css 可以帮你实现整体布局，font.css 和 reset.css 可以帮助你移除浏览器默认格式。它提供了一个重新审视你页面中标签的机会，比如只有在语意上有意义时才使用

，而不是因为它具有换行效果才使用它。

DOM 元素数量很容易计算出来，只需要在 Firebug 的控制台内输入：
document.getElementsByTagName(’*').length

那么多少个 DOM 元素算是多呢？这可以对照有很好标记使用的类似页面。比如 Yahoo! 主页是一个内容非常多的页面，但是它只使用了 700 个元素（HTML 标签）。

将静态资源划分到不同的静态服务上

根据域名划分页面内容

把页面内容划分成若干部分可以使你最大限度地实现平行下载。由于 DNS 查找带来的影响你首先要确保你使用的域名数量在 2 个到 4 个之间。例如，你可以把用到的 HTML 内容和动态内容放在 www.example.org 上，而把页面各种组件（图片、脚本、CSS)分别存放在 statics1.example.org 和 statics.example.org 上。

使iframe的数量最小

耗性能，即使是blank；阻塞父页面的onload。

ifrmae 元素可以在父文档中插入一个新的 HTML 文档。了解 iframe 的工作理然后才能更加有效地使用它，这一点很重要。

解决加载缓慢的第三方内容如图标和广告等的加载问题 Security sandbox 并行加载脚本。

即时内容为空，加载也需要时间，会阻止页面加载，没有语意。

不要出现404错误

HTTP 请求时间消耗是很大的，因此使用 HTTP 请求来获得一个没有用处的响应（例如 404 没有找到页面）是完全没有必要的，它只会降低用户体验而不会有一点好处。

有些站点把404错误响应页面改为“你是不是要找***”，这虽然改进了用户体验但是同样也会浪费服务器资源（如数据库等）。最糟糕的情况是指向外 部 JavaScript 的链接出现问题并返回 404 代码。首先，这种加载会破坏并行加载；其次浏览器会把试图在返回的 404 响应内容中找到可能有用的部分当作 JavaScript 代码来执行。

在本系列的第一节中，讲了提高网站性能中网站“内容”有关的10条原则。除了在网站在内容上的改进外，在网站服务器端上也有需要注意和改进的地方，它们包括：

使用内容分发网络
为文件头指定 Expires 或 Cache-Control
Gzip 压缩文件内容
配置 ETag
尽早刷新输出缓冲
使用 GET 来完成 AJAX 请求

减小Cookie大小

cookie在每次http请求会带到服务端，cookie越大，传输的数据量越大。

减少DOM访问

Dom操作时，js要通过js-dom桥访问dom，速度比js内部操作慢，所以要减少DOM操作。写代码时，

1）缓存指向dom的引用

2）离线操作节点，最后才更新到DOM中

3）避免Js操作一些属性导致浏览器的页面重绘

不要使用@import 用link

前面的最佳实现中提到 CSS 应该放置在顶端以利于有序加载呈现。

在 IE 中，页面底部 @import 和使用 作用是一样的，因此最好不要使用它。

避免使用滤镜

IE下使用AlphaImageLoader filter来解决IE<7不支持透明，在下载图像过程中，使用这个属性会阻塞浏览器，并且会加大内存消耗。避免使用而用png8代替，如果实在要使用AlphaImageLoader，用_filter。

优化图像

优化图像大小

不要在HTML中缩放图像

favicon.ico要小而且可缓存

保持单个内容小于25K(针对手机)

iPhone手机最大能缓存25k，ios3有这个限制，但是有人在ios7上用css测试3Mb的文件，缓存了没发起请求。

打包组件成复合文本（针对手机）

手机端请求是很昂贵的，打包成一个复合文本，减少请求数。但先要检测终端是否支持。

避免img标签的src为空

两种情况下会发生

浏览器可能发起请求当前页面所在目录，或者当前页面，引起没必要的麻烦，比如影响日志统计，服务端重新生成页面，浏览器重新接收引起的数据丢失。

其它优化点

DNS域名解析加速

咨询了运维，目前万网已经支持域名解析加速，可以向com推送变更，1分钟内生效，各省的域名解析服务器目前应该有双向能力。

图片要声明width和height

尽快渲染出，避免重排与重绘。

document.write

不要在外链中使用document.write加载资源

无阻塞的脚本

将脚本放在页面底部是Yahoo!性能优化的优化点，其实，是解决脚本下载与执行是阻塞问题。如果使用无阻塞的脚本呢？ Js引擎和UI线程公用一个线程，无阻塞引入脚本，可解决在引入js时，阻塞UI渲染。

1) 在script标签加入defer属性

当页面解析到script标签时，开始下载Js文件，页面并不等待继续解析，不会阻碍其它页面资源的下载，由于只有 Explorer 4+ 和 Firefox 3.5+支持，这里就不详细讨论。

2) 动态脚本注入（dynamic script tag insert）

在body结束标签处，通过Js的Dom操作，新建script元素，设置好src之后，添加到head中（最好是head,body中可能），就 开始下载，不会影响浏览器UI线程，下载完触发script标签的onload事件（不同浏览器有差异），如果创建多个script后并行下载，有可能后 增的Js先下载完成，有的浏览器会等待，比如FireFox、Opera，有的先下载完先执行。对于有依赖关系的Js文件，可以在前一个Js下载完成后， 再加载新的Js。目前豆瓣的do.js、in.js都根据这个原理实现的封装。

3) XMLHttpRequest注入

在项目里，我们俗称ajax，请求的路径改为一个js的url,在返回成功的回调里面，进行Dom操作，创建一个script，将请求得到的响应报 文，设置为scritpt的dom对象的text属性。 评析：不能请求跨域的js，设置text属性后，立马就执行Js，所以通过控制设置text属性的时机，来控制Js的执行。不过这种方法还是被很少用，可 能是将js内容直接填充到html页面的script元素中，总人本能觉得不整洁吧。

优化数据传输

传输数据的几种方式

xhr jsonp 获取信息，json-padding，基于动态脚本注入，支持跨域 Beacons 图片信标，简单效率高，一般用来发送页面统计信息

数据的传输格式

xml、Json、拼接的字符串、json-p

数据的本地存储

使用ajax缓存、localstorage

实践性能优化

有些性能优化点，需要前端工程师在编码过程中遵守；有些需要配置服务器，设置缓存、etag、gzip；ajax缓存需要后台提供接口时设置；一些关键的优化点，需要前端工程支持。

前端工程化支持

在模块化开发时，细分了许多小文件，如何合并压缩脚本、样式，并在多页面中利用好缓存，如何使css spirites、inline images用起来很easy。如何保证将样式表放在页面上方、将脚本放在底部、剔除重复的脚本。

nginx缓存设置

expires 浏览器本地缓存设置

语法：expires [time|epoch|max|off]
默认值：expires off
使用字段：http, server, location

off 将禁止修改头部中的 Expires和Cache-Control字段。
Time控制“Cache-Control”的值，负数表示no-cache
epoch 将Expires头设置为1 January, 1970 00:00:01 GMT。
max 将Expires头设置为31 December 2037 23:59:59 GMT，将Cache-Control最大化到10 年。
expires 30d;
expires 1h;

nginx的gzip设置

nginx 在http{….}两个大括号之间，配置gzip段如下：