前端 – 王春伟的技术博客

作者：张云龙
链接：http://www.zhihu.com/question/20790576/answer/32602154
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

接下来，我想从原理展开讲述，多图，较长，希望能有耐心看完。

—————————- 我是一条分割线 —————————-

让我们返璞归真，从原始的前端开发讲起。上图是一个“可爱”的index.html页面和它的样式文件a.css，用文本编辑器写代码，无需编译，本地预览，确认OK，丢到服务器，等待用户访问。前端就是这么简单，好好玩啊，门槛好低啊，分分钟学会有木有！

然后我们访问页面，看到效果，再查看一下网络请求，200！不错，太™完美了！那么，研发完成。。。。了么？

等等，这还没完呢！对于大公司来说，那些变态的访问量和性能指标，将会让前端一点也不“好玩”。

看看那个a.css的请求吧，如果每次用户访问页面都要加载，是不是很影响性能，很浪费带宽啊，我们希望最好这样：

利用304，让浏览器使用本地缓存。但，这样也就够了吗？不成！304叫协商缓存，这玩意还是要和服务器通信一次，我们的优化级别是变态级，所以必须彻底灭掉这个请求，变成这样：

强制浏览器使用本地缓存（cache-control/expires），不要和服务器通信。好了，请求方面的优化已经达到变态级别，那问题来了：你都不让浏览器发资源请求了，这缓存咋更新？

很好，相信有人想到了办法：通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源。好像这样：

下次上线，把链接地址改成新的版本，就更新资源了不是。OK，问题解决了么？！当然没有！大公司的变态又来了，思考这种情况：

页面引用了3个css，而某次上线只改了其中的a.css，如果所有链接都更新版本，就会导致b.css，c.css的缓存也失效，那岂不是又有浪费了？！

重新开启变态模式，我们不难发现，要解决这种问题，必须让url的修改与文件内容关联，也就是说，只有文件内容变化，才会导致相应url的变更，从而实现文件级别的精确缓存控制。

什么东西与文件内容相关呢？我们会很自然的联想到利用数据摘要要算法对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种可以精确到单个文件粒度的缓存控制依据了。好了，我们把url改成带摘要信息的：

这回再有文件修改，就只更新那个文件对应的url了，想到这里貌似很完美了。你觉得这就够了么？大公司告诉你：图样图森破！

唉~~~~，让我喘口气

现代互联网企业，为了进一步提升网站性能，会把静态资源和动态网页分集群部署，静态资源会被部署到CDN节点上，网页中引用的资源也会变成对应的部署路径：

好了，当我要更新静态资源的时候，同时也会更新html中的引用吧，就好像这样：

这次发布，同时改了页面结构和样式，也更新了静态资源对应的url地址，现在要发布代码上线，亲爱的前端研发同学，你来告诉我，咱们是先上线页面，还是先上线静态资源？

先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。
先部署资源，再部署页面：在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。

好的，上面一坨分析想说的就是：先部署谁都不成！都会导致部署过程中发生页面错乱的问题。所以，访问量不大的项目，可以让研发同学苦逼一把，等到半夜偷偷上线，先上静态资源，再部署页面，看起来问题少一些。

但是，大公司超变态，没有这样的“绝对低峰期”，只有“相对低峰期”。So，为了稳定的服务，还得继续追求极致啊！

这个奇葩问题，起源于资源的 覆盖式发布，用待发布资源覆盖已发布资源，就有这种问题。解决它也好办，就是实现 非覆盖式发布。

看上图，用文件的摘要信息来对资源文件进行重命名，把摘要信息放到资源文件发布路径中，这样，内容有修改的资源就变成了一个新的文件发布到线上，不会覆盖已有的资源文件。上线过程中，先全量部署静态资源，再灰度部署页面，整个问题就比较完美的解决了。

所以，大公司的静态资源优化方案，基本上要实现这么几个东西：

配置超长时间的本地缓存 —— 节省带宽，提高性能

采用内容摘要作为缓存更新依据 —— 精确的缓存控制

静态资源CDN部署 —— 优化网络请求

更资源发布路径实现非覆盖式发布 —— 平滑升级

全套做下来，就是相对比较完整的静态资源缓存控制方案了，而且，还要注意的是，静态资源的缓存控制要求在前端所有静态资源加载的位置都要做这样的处理。是的，所有！什么js、css自不必说，还要包括js、css文件中引用的资源路径，由于涉及到摘要信息，引用资源的摘要信息也会引起引用文件本身的内容改变，从而形成级联的摘要变化，大概示意图就是：

好了，目前我们快速的学习了一下前端工程中关于静态资源缓存要面临的优化和部署问题，新的问题又来了：这™让工程师怎么写码啊！！！

要解释优化与工程的结合处理思路，又会扯出一堆有关模块化开发、资源加载、请求合并、前端框架等等的工程问题，以上只是开了个头，解决方案才是精髓，但要说的太多太多，有空再慢慢展开吧。或者大家可以去我的blog看其中的一些拆解：fouber/blog · GitHub

总之，前端性能优化绝逼是一个工程问题！

以上不是我YY的，可以观察百度或者 facebook 的页面以及静态资源源代码，查看它们的资源引用路径处理，以及网络请中静态资源的缓存控制部分。再次赞叹facebook的前端工程建设水平，跪舔了。

建议前端工程师多多关注前端工程领域，也许有人会觉得自己的产品很小，不用这么变态，但很有可能说不定某天你就需要做出这样的改变了。而且，如果我们能把事情做得更极致，为什么不去做呢？

另外，也不要觉得这些是运维或者后端工程师要解决的问题。如果由其他角色来解决，大家总是把自己不关心的问题丢给别人，那么前端工程师的开发过程将受到极大的限制，这种情况甚至在某些大公司都不少见！

这一期，咱们一起聊一聊—-百度移动端首页前端速度的那些事儿

1 长什么样？

我们的业务就是 https://m.baidu.com
别以为只有一个搜索框，我们还有下面丰富的卡片内容，可以提供各式各样的服务。如图1.1

图1.1
其实整个页面的逻辑相对是比较复杂的(虽然，可能各位看官没用过)。
还有各式各样的卡片，轻轻下拉，即可看到,如图1.2

图1.2

2 面临的挑战

可能代码的量级没有很多webapp恐怖，可是“百度首页要秒开”却是一个共识，可以看到(如图2.1)，在利用上了缓存的情况下，我们的首页包大小gzip后只有11.1k左右。耗时也就是500多毫秒。大部分用户“秒开”不是事儿。

图2.1

但是，我们的业务在不断的增长的同时，要维持这样的包大小，就是一门艺术了。
要快，但是我们的服务也必须万无一失，（后续我会分享百度移动端首页的前端架构设计）那么这样的优化，是如何做到的呢，又如何兼顾稳定性，架构性，与速度呢？别急，让我们把这些优化一一道来。

3 我们的业务与我们的优化

3.1 静态文件在哪里？

为了求快，首页是没有js和css外链的，这样会再发起多次请求，相信对于各位前端小能手来说，也是老生常谈的前端优化了。所以，整个首页渲染出来，只需要一次请求(除了iconfont)。其他的首屏所需要的js与css，全部在上线前，编译时，编译内联至HTML中，如图3.1.1。

图3.1.1

3.2 缓存！缓存！

然而，首页并不满足于此，首页的很多样式和脚本，需要在同步的时候就初始化，但是，如果每次都传输一些不变的静态文件或者html，实在是太浪费了，如果html/css/js一直不变，那直接缓存到客户端不就好了。
于是首页的第二项优化，就展示了威力，localstorage，关于这个客户端存储，陌生的同学可以查一查。也可以直接阅读我接下来要写的聊一聊系列文章。
我们把不变的js/css/html全部存储到localstorage中去，下次加载首页的时候。在特定的位置，不必再从服务端把特定位置的js/css/html传过来。只需要传一句话—-“<script>readlocalstorage();</script>”就行。
至于存储的方法，例子如下：

<!DOCTYPE HTML>
<html>
    <head>
        <meta charset="utf-8"/>
    </head>
    <body>
        <div data-local="test1">
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
        </div>
        <script>
            function cacheOne(attrid) {
                var content = document.querySelector('[data-local="' + attrid + '"]').outerHTML;
                localStorage.setItem(attrid, content);
            }
            cacheOne('test1');
        </script>
    </body>
</html>

我们将html的内容存储到了localstorage中，如图3.2.1

图3.2.1
下次，再访问的时候，我们使用服务端把缓存起来的html不传送，而是只传送读取相关的js，如图3.2.2

<!DOCTYPE HTML>
<html>
    <head>
        <meta charset="utf-8"/>
    </head>
    <body>
        <script type="text/javascript" data-local="test1">
            function readOne(attrid) {
                var content = localStorage.getItem(attrid);
                document.querySelector('[data-local="' + attrid + '"]').outerHTML = content;
            }
            readOne('test1');
        </script>
    </body>
</html>

图3.2.2
我们看到，虽然展示内容相同，但是第二次传输的时候，页面的量明显减小。而且使用这种方式我们使用的地方越多，这种优势就越明显。

百度移动端首页的很多css/html/js就是这样缓存在客户端的。

有同学会说，那么如何知道什么时候该传读local，什么时候该传写local呢？
很简单，我们在写入local的时候，同时在cookie中种下当前所有要缓存的内容的版本(MD5戳)就行。
因为cookie是会在同步访问的时候，传送到服务端的，而local不会，所以，我们在服务端决定要传送内容，还是传送读取local代码。就靠我们种下的cookie了。我们在这里，使用php来做一个实验：

<!DOCTYPE HTML>
<html>
    <head>
        <meta charset="utf-8"/>
    </head>
    <body>
        <?php $curversion='1'?>
        <?php if ($_COOKIE['localversion'] !== $curversion) {?> 
        <div data-local="test1">
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
            这部分内容非常多将会缓存起来
        </div>
        <script>
            function cacheOne(attrid) {
                var content = document.querySelector('[data-local="' + attrid +'"]').outerHTML
;
                localStorage.setItem(attrid, content);
            }
            cacheOne('test1');
            document.cookie="localversion=<?php echo $curversion?>;";
        </script>
        <?php } else {?>
            <script type="text/javascript" data-local="test1">
                function readOne(attrid) {
                    var content = localStorage.getItem(attrid);
                    document.querySelector('[data-local="' + attrid + '"]').outerHTML = content
;
                }
                readOne('test1');
            </script>
        <?php }?>
    </body>
</html>

我们在php中判断，如果cookie中有version，证明种过cookie，写过local，所以，不用传内容了，直接传script就好了，如果没有就要传输并且写入。我们可以看到效果，同样的页面，第一次访问的时候，内容大小是1.6K，如图3.2.3

图3.2.3
再次刷新的时候，内容量已经减小到了474b，如图3.2.4。

图3.2.4

如果用户的cookie和local不一致怎么办，如果用户不支持local怎么办？这些疑问其他读者自行思考一下(其实很简单)。

3.3 外链！外链！

毕竟业务庞大，光首屏的那些css/js/html已经无法满足我们了。我们需要更多的脚本，更多的css。你可能会很轻松的想到，外链引入呗。但是，经过调研，我们发现移动端的文件缓存率非常的低(大约30%左右)。也就是说移动端的缓存环境是非常残酷的。所以，我们又开始了极限优化。我们将所有的js/css等静态文件，通过一个接口全部返回。如图3.3.1

图3.3.1
这样可以达到合并外链请求的目的，我们又将这些静态文件，也一一缓存到localstorage中，如图3.3.2：

图3.3.2
每个文件以自己文件内容生成的版本号为戳，标识自己的唯一性。每次服务端返回页面时，会把当前在服务器上的所有静态文件版本号，返给前端，如图3.3.3

图3.3.3
前端首屏加载完成后，会用这些版本号与local中进行一一对比，发现不一致的js/css，会一起发送一个合并请求。如图3.3.1所示。这样可以保证每个文件的缓存与版本迭代。同时，也避免了过多的外链。

3.4 DOM也缓存

我们的模板和数据，也会被缓存至localstorage中，，有同学可能会问，那什么东西不缓存？答案就是，变化的东西，如果有部分html与数据在刷新的时候会经常性的变动的话，这种缓存方式就失去了它的意义，我们的宗旨是，不变的数据，缓存下来是可以带来信息量的不重复传输的。如图3.4.1

图3.4.1

3.5 使用iconfont

由于我们的很多业务是不需要多彩色图的，所以这个时候，iconfont就派上了用场，在满足UE高清的需求下，可以节省大量的资源。如图3.5.1，这些icon就可以使用iconfont。

图3.5.1

3.6 卡片的异步加载与缓存

随着我们的业务越来越多，我们的卡片也越来越多了，但是！！！依旧不能影响我们首页的速度。我们又开始了极限优化。首先，我们首屏也就需要2张卡片，按照市售手机的尺寸来看。我们两张卡片足够填充满首屏了。特殊情况，我们会有特殊处理（针对大屏幕手机），在用户下拉的时候，再去加载更多的卡片。这样可以节省用户流量，还能够提升首页速度。接下来，我们如法炮制，也将卡片内容(html/css/js)存储到了local中。异步拉取卡片的时候，如果卡片内容没有变。服务端就不要返回了。

3.7 不在首屏的就要异步化！

我们有很多用户功能，用户不一定每次都会用，如果上来就开始加载，必然会浪费速度与流量，于是，我们将一些“第二步操作”，只有在触发时才会进行加载。这样，保证了按需加载。
如，我们的管理页面功能，是个点击才能进入的浮层，对于这种功能设计，就可以采用按需加载，而不是伴随首页一起加载，如图3.7.1

图3.7.1

3.8 少量静态文件的域名

我们的logo与iconfont均是放在m.baidu.com域下的，这样节省了DNS的解析。虽然可能带来的问题是，发送图片请求的时候，会携带cookie。但是我们的cookie也是极少的。这点上性能还是有所提升的。如图3.8.1我们的logo就是在m.baidu.com域名下：

图3.8.1

3.9 极小的图片base64化

对于小于1k的图片，我们将其变为base64编码，并融入到css中，一起换存到localstorage中去，这样即节省了网络请求，同时使图片也可以缓存到local中去了。

图3.7.1

不要走开，请关注我。下一章，我们将继续聊聊web分辨率那些事儿。

测试了下写cache


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head> </head>
<body>
<h1>test</h1>
</body>
<script>
localStorage.setItem("hello", "world");
</script>
</html>

标签：前端

[转]大公司里怎样开发和部署前端代码？

[转]百度移动端前端性能优化