性能优化（part-1）

[Pomelo1213]

先不说性能优化怎么做，就先来说说为什么需要进行性能优化，做性能优化有什么好处？

抛开大前端的说话，从最开始的前端的工作来说，面对的主要是浏览器使用者，用户浏览的网页的精彩与否以及交互的舒适情况，本质是依赖于 JavaScript 脚本和 CSS 样式，再究其本质就是页面渲染。如果一个网页连加载出来都成为一个问题，相信用户就不太可能去浏览这个网页了。如果我们的网页体量足够小，那么也自然不存在优化的可能，但是前端技术飞速发展，网页的体量自然是日益膨胀，我们就不得不去进行相应的优化。那么优化到底有什么好处呢，我们可以对资源进行压缩或者合并，这样就可以节约我们大笔的流量开支，如果我们网页性能做的足够好，用户就更倾向于在我们的网页上获取信息，进而可以产生收益。

那么我们可以怎么做性能优化呢？我会一一道来。

对于前端来说性能优化的最有效的措施就是资源的压缩与合并，这是最简单，最直接，也是收益最大的一种方式，试想一下，如果我们的代码能够通过某种方式进行压缩体积，对于资源的节省是有相当大的帮助的。

资源的压缩

压缩资源我们可以先从 HTML 入手，CSS 和 JavaScript 也是类似如此的。

我们可以通过压缩 HTML 中的空白字符或者占位符来减少 HTML 文件的体积，如果一个 HTML 文件体积很大，那么进行优化的收益是挺大。

但是遗憾的是，进行 HTML 压缩来优化后可能文件大小也就仅仅减少了 1KB 左右的体积，看起来这个收益是非常小的，但是换成像：Facebook 的高流量的访问的场景来说，这种优化是非常有必要。1KB 体积的节省，可能为 Facebook 节省数亿美元的流量支出。

所以 HTML 压缩在日常优化中，显然没有压缩 CSS 和 JavaScript 来的收益更大！

我们可以通过 Webpack 的相应的插件可以进行压缩，基本上前端的代码，都会在发布到线上的时候去进行压缩，所以这一块好像没有特别需要说明，（Tips：JavaScript 最好还要进行混淆，不然，别有用户的用户可能会通过窥探你的代码来寻找网页的漏洞，进行攻击。）

资源的合并

我们知道网页的所有东西都是通过网络请求得到资源物料，然后通过浏览器的机制进行计算和渲染，那么网络请求就是我们另一个可以优化的地方。

我们无法决定用户的网络状况，但是我们决定用户的网络请求个数，我们知道浏览器针对一个 host 下的网络请求个数是会产生限制，这就意味着，如果我们的网页所需要请求的东西过多，超出了这个限制，那么剩下的请求就会处于等待状态，那么我们的需要的资源也会无法加载出来，这不是我们希望看到的。所以我们可以通过合并请求的方式来尽可能进行优化。

那是不是我们无脑将所有资源合并成一个就是正确的呢？对于网络请求来说，一个资源越大，那么花费在网络传输的时间就会越长，响应的就会越慢。这样也同样不利于我们页面的加载，所以对于资源的合并我们不能像压缩资源那么无脑，我们需要权衡利弊。如果我们有一些小的资源，但是它们都是单独占用一个请求，那么这种场景就是不合理的，因为资源过小，而网络请求数的开销却是比较昂贵。所以我们需要将多个小资源整合在一起，最经典莫过于雪碧图了，将多个小图标整合在一张图中，这样以来，请求数就缩小为一个，从而可以让出大量的请求数给必须的资源去使用，这才是合理的。

其实，资源的整合和压缩大致就是这样的一个思路，都需要自己去权衡收益比，已期达到最大化收益，这里并没有固定的限制。权衡收益比才是优化的核心思想，如果单纯为了用而使用，可能会适得其反。