文件，js文件我们都会放置在一个resource包里，如果是企业开发，这个web应用上线时候也就直接打包在web工程里，一些互联网网站也只不过会将这些资源放置在单独的静态服务器上，我平时开发时常听到有人
说，项目里图片太多了，应该合并下，css文件和js文件也太多了也要合并下，这个多到底多多少了，几十
个文件，几百个文件，这个要和社交网站，电商网站这种用户可以产生图片的网站比起来那就是小巫见大
巫了，因为用户能产生内容的网站静态资源会随着时间推移文件规模变得异乎寻常的大，所以此类网站的
静态资源已经没法放置在项目下，它就要求我们需要有新的手段管理这些静态资源，并且有新的手段使用
这些静态资源，那么像TFS文件存储系统出现了，缓存技术出现了，最后我们在应用里使用ESI技术把它们
整合到我们网页里，通过这个分析我们就能明白ESI适用的业务场景了。
网站静态化处理我们首先要按规则拆分动静资源，拆分出来的静态资源该如何处理就是网站静态化处理的关键所在，把静态资源处理从服务端的web应用里剥离出来，不让服务端的web应用参入过多的静态资
源解析，这样就可以为服务端的web应用减少不必要的处理操作，从而达到提升服务端web应用的运行效
率，接着我们就把拆分出来的静态资源处理操作往前推移到静态web服务器，前两篇文章和今天的文章我着
重讲解了静态web服务器处理静态资源的手段，那么这里有个问题了，这些处理可以再往前推到浏览器来完成吗？答案当然是否定的，首先浏览器的缓存是非常不可靠的，如果用户把浏览器设置为不缓存任何数据
的模式，那么浏览器就没法缓存数据了，而用户的行为那是根本没法控制的，其次浏览器缓存的数据量是
有限的，如果我们要在浏览器进行缓存也是缓存最有价值缓存的数据，更重要的一点，为了做好网站静态
化处理我们对网页的动静资源做了拆分，但是拆分出的静态资源也并不是完全不需要进行任何逻辑处理就
能使用的，例如前面讲到的ESI适用的场景我们就发现，有些静态资源的获取还是要很多条件的参入，而这
些条件是由动态数据产生的，那么这样的静态数据浏览器是没法做缓存的，这点也说明了拆分出来的静态
化资源绝大部分还是要停留在服务端的，居然只能停留在服务端，那么最为高效的处理这些静态资源的地
方就是CDN和静态web容器了。所以在本系列的第一篇里我讲到网站生产部署时候最好是在服务端web应用之
前放置一个静态web容器，如果有了这样的静态web容器做反向代理，那么我们就可以让它来完成静态资源
的相关操作，而且静态web容器还能辅助完成一些逻辑上的处理，从而弥补了CDN的不足之处。当然这么做
的好处不仅仅只有这些，第二篇文章里我曾经讨论了反向代理的好处，可能大家印象还不是很深刻，我将
会在后面文章里对反向代理做更加深入的分析。
">
×
东莞市天英网络技术有限公司，一家专业营销型网站建设公司、响应式网站制作公司，提供企业响应式网站建设、自适应企业网站模板、营销型网站制作、响应式企业网站模板制作等服务。