有家大型的企业顺应时代发展的潮流开始投身于互联网行业了，它们为此专门设立了一个事业部，不过该企业把这个事业部里的人事成本，系统运维成本特别是硬件采购的成本都由总公司来承担，当然互联网业务上的市场营销成本这块还是由该事业部自己承担，可是网站一年运维下来，该公司发现该事业部里最大的成本居然不是市场营销的开销，而是短信业务和宽带使用上的开销，是不是有点让人感到意外呢?下面我们给大家介绍一下网站静态化处理吧!

短信这块是和通讯运营商有关，很难从根本上解决，当然该企业可以考虑使用像微信这样的工具来分摊下短信的成本，但是宽带流量消耗这个问题却很难有第二选择了，可能有人会感到诧异，一家做互联网的企业，用户都是使用自己掏钱的宽带来上网的，为啥企业会有宽带流量的成本呢?其实互联网公司的后台服务都是会放置在IDC即数据中心里的，除非你的企业是真正的高富帅，或者你本身的核心业务就是互联网业务，这样的企业才有可能会自建数据中心，绝大部分企业都会租用第三方的数据中心，而且有些企业为了容灾还会在不同地域建立不同的数据中心，不同数据中心之间是通过专线来通讯的，而专线的成本是很高的，我们想让自己开发的网站让更多人用，可以通过改造服务端并发处理能力来达到这个目的，但是这里还有一个制约因素，那就是服务端使用的带宽，一般而言，企业选择多大带宽是可以估算出来，最终采用一个合理的带宽，但是，如果这家公司是电商类型网站，就很有可能碰到像双十一啊，或者自身做大促销的情况，这个时候服务端的负载压力就会成倍增加，远远超出平时的网络流量，如是企业会提前扩充带宽，而扩充的带宽流量是昂贵的，这样就会无形增加网站运营成本。如果我们不去思考成本问题，当今社会讲求环保，例如淘宝就说它们网站没完成一次交易使用的电量可以煮熟两个鸡蛋，它们网站一天下来消耗的电量相当于中国一个三线城市一天消耗的电量，那么如果我们能节约每次请求消耗的宽带流量其实也就是在节约能源，所以不管是从成本角度还是从环保角度提高宽带的利用率都是有很大的现实意义的。

Web前端优化里有一个技巧就是压缩http请求的数据量，这个技巧很多人都是简单认为http请求的数据越小，那么http处理速度就更快些，不过我认为这结论其实是一个相对的结论，现在的网速是越来越快，很多人家里接入的宽带已经使用上了光纤，50兆，百兆的宽带已经飞进了寻常百姓家了，那么这时候其实网络传输100kb数据和传输300kb数据的效率差异基本可以忽略不计了，当然并非每个人网络访问速度都这么快，例如我们使用手机的2G网络上网，那么100kb和300kb的传输效率还是会有很大差异的，所以压缩http请求大小这个手段在客户端这块是一种解决短板的技巧，这个短板就是照顾那些上网速度太慢的人了，而非对人人平等的技术手段，但是这个问题换到服务端就不同了，减少http报文的数据大小可以提升企业对宽带的利用率，是一种节约网站运营成本的一个重要手段，因此压缩http传输数据的大小是一个很有价值的技术手段。

用来压缩http请求数据大小的手段很多，例如使用Gzip压缩http请求，压缩图片等等，不过我这里要特别说明一个手段那就是减少cookie存储数据的大小，这是一个常常被忽视的压缩http请求大小的技术手段。不过cookie技术对很多初学者常常会感到差异，cookie是客户端的数据，为什么服务端和客户端都能操作它，难道服务端也会存储一份cookie的备份吗?之所以初学者会对cookie使用有疑问，这主要是初学者不太清楚cookie信息除了保存在浏览器端，它还会包含在http报文头里的，每个http请求响应都会带着cookie信息进行传递，所以cookie既可以被客户端操作也能被服务端操作，如果我们忽视cookie这个特点，再加上我们滥用cookie，最后cookie被撑满了，这也就意味每次请求响应的数据量会增加，而这些信息可能大部分都不会被使用，纯粹多余。而网站在开发和维护时候很容易不自觉的让cookie变得越来越多，越来越大，如果我们一开始就明确cookie这个特点，提前设计cookie使用规范，那么就可以一定程度上规避cookie不合理使用导致的http数据量变大的问题。如果网站使用了单独的静态资源服务器，并且把静态资源放置在单独的域名下面，这个时候我们还要避免给静态资源域名下使用cookie技术，因为静态资源基本都不会有状态信息，使用cookie只会无谓的增加请求的数据大小。

网络是存储设备里效率最差的，如果页面加载时候还有些请求是一个坏请求，例如页面访问的某些静态资源突然丢了，浏览器这个时候会有一个容错的做法，这个做法具体是：浏览器不能确定有问题的请求到底是因为网速慢了还是找不到，所以浏览器会多次请求这个url，直到浏览器认为这个url的确是有问题无法访问了，浏览器才不去继续请求了，如果碰到的资源正好是外部javascript文件，那就很有可能阻塞整个页面的加载，所以剔除页面里的坏请求也是要经常留心的事情。

我们如果再进一步分析下web前端优化的一些手段，就会发现很多优化手段其实都是基于静态资源来处理的，静态资源的特点就是在一定时间范围内不会发生变化的，而且当用户请求静态资源时候，服务端不需要任何计算操作即消耗CPU资源就能把结果返回给客户端，静态资源这种不参与计算的特点就可以让静态资源和业务应用服务器解耦，因此我们可以把静态资源单独抽取出来放置在CDN或者是请求效率处理更佳的静态资源服务器上。和静态资源相对的动态资源就很难做到这点，我们仔细回味下网站后台整个应用架构，就会发现所有网站都会使用存储系统即基本都会用数据库，而且应用服务器和数据库又是一种紧耦合的关系，因为我们想消除存储系统的状态问题基本是不可能完成的任务，这就让应用服务器没法做成CDN的形式，因此动态资源处理想使用CDN这种减少距离对网络通讯影响的手段基本是很麻烦的。我觉得网站静态化处理其实是根据web前端优化技术产生的技术，它让网站静态化资源和动态资源分离做的更好，所以我说网站静态化技术是充分发挥web前端优化手段的重要保证，这也就是我为什么会把web前端优化的内容也要放在网站静态化处理系列里的原因了。

静态资源因为在一定时间里不会发生变化，容易被缓存，而且浏览器本身也有缓存机制，那么如果我们把静态资源缓存在浏览器端，用户请求网站就不需要再去请求网络资源，这个效率不就更高了吗?现实情况的确是如此，但是我们想让浏览器端充分发挥这个缓存作用其实并非那么简单，因为我们会碰到如下的问题,具体如下：

问题一：网站对浏览器的控制是一种被动控制，用户才是控制浏览器的主动方，用户的很多行为都会导致网站对浏览器的缓存设计策略失效，如果缓存失效，那么用户再去访问网站时候就得重新请求资源，所以为了弥补浏览器缓存的不可靠性，CDN技术以及静态资源服务器的使用就派上用场了。

问题二：浏览器缓存网页部分资源可以让网页加载的更快，但是要做到这一点之前，我们首先要明确何时采用，同时采用何种方式让客户端缓存这些可以被缓存的资源?那么我们在知道某个用户要访问网站了，我们提前把需要缓存的资源发送个用户，让用户先缓存下这些资源，这个做法肯定是开国际玩笑了，一般我们都是在用户第一次访问网站时候将可以缓存的资源缓存起来，这个时候问题又来了，那就是用户第一次访问网站时候因为需要缓存的资源都没有被缓存，所以全部的资源都要通过网络请求下载，这个时候就会导致用户第一次访问网站页面的效率很差，有人可能认为网站又不是设计为访问一次的产品，只要资源被缓存了网页就会更快的，要是用户觉得第一次访问慢了，就先忍忍吧，以后会快的，这个想法又是再开国际玩笑了。就算用户忍受了第一次访问慢的情形，但是如果用户使用这个网站的时间间隔是很长的，例如某些专业性的网站，它的用户可能会很长一段时间后再访问该网站，而过了这段时间后，浏览器缓存的资源很有可能失效了，这个时候用户再去访问又等于是第一次访问了，那么我们这个缓存设计方案基本就是无效了。

问题二所反映的问题也就表明我们在如何合理使用浏览器缓存这块上是需要考虑用户的使用场景的，需要加入一些业务性的策略了，只有这样浏览器缓存方案才能充分发挥其优势。下面我就来谈论下浏览器端缓存策略设计的问题了。

首先我们来看一个场景，用户第一次访问网站，访问的是网站的首页，我们按照web前端优化原则设计了网站首页，特别是使用了一个优化原则就是把css合并成一个外部css文件，把javascript代码也合并成一个外部文件，首页都引入了这两个外部文件，这种情况首页访问至少会产生三个http请求，可是网站首页其实没有那么复杂，也就是说首页使用的css代码和javascript代码其实并不太多，如果我们把这些代码就放置到页面内部，那么首页加载就只有一个请求，虽然这会导致这个请求的数据量变大，不过按照我前面说到压缩http请求数据大小，其实在提升网络传输速度上这个角度是值得商榷的，但是多个http请求就会导致浏览器打开更多连接，而每个连接的建立和销毁却是十分消耗计算资源的，那么如果我们能把三个请求合并成一个请求完成就一定会让请求处理的更快，可是这个做法就会导致css和javascript文件没法被缓存，那么以后想复用它们就麻烦了。碰到这样的问题我们又该如何来抉择了?最理想的结果就是二者兼顾，但是要兼顾二者，那么页面就一定要处理这三个http请求了，我们到底能不能做到二者兼顾了?答案是肯定的，我们可以做到的。我们仔细的分析下这个场景，就会发现，快速加载页面和缓存静态资源在页面首次访问这个背景下其实是两个不同的业务操作，用户第一次访问首页用户只会关心页面是否快速被加载，至于加载静态资源的行为以及缓存静态资源的行为，用户是不用关心，因此我们就可以拆分这两个操作，首先是让页面快速被加载，等页面加载完毕后，我们在通过异步手段来加载外部的静态资源，这样就可以做到二