[聊一聊系列]聊一聊百度移动端首页前端速度那些事儿

时间 2019-11-05

标签系列百度移动首页前端速度那些事儿栏目无线繁體版

原文原文链接

欢迎你们收看聊一聊系列，这一套系列文章，能够帮助前端工程师们了解前端的方方面面（不只仅是代码）：https://segmentfault.com/blog/frontenddriverjavascript

这一期，我们一块儿聊一聊----百度移动端首页前端速度的那些事儿php

1 长什么样？

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

图1.1
其实整个页面的逻辑相对是比较复杂的。
还有各式各样的卡片，轻轻下拉，便可看到,如图1.2

图1.2css

2 面临的挑战

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

图2.1html

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

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

3.1 静态文件在哪里？

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

图3.1.1web

3.2 缓存！缓存！

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

<!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分辨率那些事儿。

http://www.javashuo.com/article/p-ghwggguw-ez.html原创文章，版权全部，转载请注明出处