大型Web应用对速度的追求并没有止步于仅仅利用浏览器缓存，因为浏览器缓存始终只是为了提升二次访问的速度，对于首次访问的加速，我们需要从网络层面进行优化，最常见的手段就是CDN（Content Delivery Network，内容分发网络）加速。通过将静态资源缓存到离用户很近的相同网络运营商的CDN节点上，不但能提升用户的访问速度，还能节省服务器的带宽消耗，降低负载。

　　不同地区的用户会访问到离自己最近的相同网络线路上的CDN节点，当请求达到CDN节点后，节点会判断自己的内容缓存是否有效，如果有效，则立即响应缓存内容给用户，从而加快响应速度。如果CDN节点的缓存失效，它会根据服务配置去我们的内容源服务器获取最新的资源响应给用户，并将内容缓存下来以便响应给后续访问的用户。因此，一个地区内只要有一个用户先加载资源，在CDN中建立了缓存，该地区的其他后续用户都能因此而受益。

　　如上图所示，之所以不同地区的用户访问同一个域名却能得到不同CDN节点的IP地址，这要依赖于CDN服务商提供的智能域名解析服务，浏览器发起域名查询时，这种智能DNS服务会根据用户IP计算并返回离它最近的同网络CDN节点IP，引导浏览器与此节点建立连接以获取资源。

　　结合上述两点，为了使用CDN网络缓存，我们至少要对静态资源的部署做两项改变：

　　　　1、将静态资源部署到不同网络线路的服务器中，以加速对应网络中CDN节点无缓存时溯源的速度。

　　　　2、加载静态资源时使用与页面不同的域名，一方面是便于接入为CDN而设置的智能DNS解析服务，另一方面因为静态资源和主页面不同域，这样加载资源的HTTP请求就不会带上主页面中的Cookie等数据，较少了数据传输量，又进一步加快网络访问。

　　CDN服务基本上已经成为现代大型Web应用的标配，这项技术“几乎”是一种对开发透明的网络性能优化手段，使用它的理由很充分，但是这里既然强调了“几乎透明”而不是“完全透明”，是因为使用CDN服务所需要的两项改变对前端工程产生了一定的影响，而这些影响我在之前的文章中已经介绍了，就是前端工程必须引入非覆盖式发布的根本原因。

　　
　　前端工程多米诺骨牌

　　上图向大家展示了整个前端静态资源缓存技术所带来的连锁性工程问题。很多人不理解为什么要选择FIS，而不是grunt，从本质上来说，工具并么有什么差异，只是fis的设计出发点是以上这些工程问题，设计中优先考虑了现代互联网应用是如何进行工程化部署与开发的，面临的问题是哪些，基于这些问题，要怎么解决。

　　比如我们在上图中可以看到，整个静态资源缓存技术的最终影响的节点是前端静态资源定位问题，而且前端资源定位又会进一步影响到开发，包括代码中的模块化加载、各种资源加载等。所以fis的设计核心之一就是资源定位。比如fis的核心配置roadmap，其目的就是为了解决在前端代码中的所有资源定位问题，连接开发和部署规范：

　　

　　此外，fis的静态资源表生成功能也是为了给模块化框架提供加载部署到其他域名下的路径中md5戳的资源部署路径，并建立资源之间的依赖关系。

至于文件压缩之类的功能，那只是工具问题，而非工程问题。

 

原文地址：https://div.io/topic/930