欢迎大家收看聊一聊系列,这一套系列文章,可以帮助前端工程师们了解前端的方方面面(不仅仅是代码):https://segmentfault.com/blog/frontenddriver

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

1 长什么样?

我们的业务就是 https://m.baidu.com
别以为只有一个搜索框,我们还有下面丰富的卡片内容,可以提供各式各样的服务。如图1.1
clipboard.png
图1.1
其实整个页面的逻辑相对是比较复杂的。
还有各式各样的卡片,轻轻下拉,即可看到,如图1.2
clipboard.png
图1.2

2 面临的挑战

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

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

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

3.1 静态文件在哪里?

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

clipboard.png
图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

clipboard.png
图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>

clipboard.png

图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
clipboard.png
图3.2.3
再次刷新的时候,内容量已经减小到了474b,如图3.2.4。

clipboard.png
图3.2.4

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

3.3 外链!外链!

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

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

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

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

3.4 DOM也缓存

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

clipboard.png
图3.4.1

3.5 使用iconfont

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

clipboard.png

图3.5.1

3.6 卡片的异步加载与缓存

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

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

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

clipboard.png
图3.7.1

3.8 少量静态文件的域名

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

clipboard.png
图3.8.1

3.9 极小的图片base64化

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

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

https://segmentfault.com/a/1190000005884985
原创文章,版权所有,转载请注明出处

22 条评论
wujohns · 2016年07月13日

图片-->base64字符串-->css-->local

+1 回复

monw3c · 2017年01月04日

其实就是多利用webstorage 有需要甚至还可以用上web database

+1 回复

智障少年 · 2016年07月06日

高人。谢谢分享。

回复

DH · 2016年07月07日

但是base64码的图片是不是在安卓端没有办法保持

回复

AnnatarHe · 2016年07月07日

好文,谢谢分享咯~

回复

limichange · 2016年07月07日

感觉纯svg要比iconfont好一些,毕竟都是支持的。记得github有篇对比的文章https://github.com/blog/2112-delivering-octicons-with-svg

回复

晓风残月 · 2016年07月07日

作为业余时间补充学习挺好的,开阔了视野,感谢分享!

回复

loudou · 2016年07月07日

什么意思0.0我现在都用的base64啊没问题额

回复

DH · 2016年07月07日

安卓上base64的图片不是不能保存吗?

回复

loudou · 2016年07月07日

可以的,base64是把二进制数据转换成普通字符保存在css中,我一直在用0.0要是有问题早炸了

回复

DH · 2016年07月07日

我是说保存在本地

回复

imingyu · 2016年07月08日

扩展了一些视野,好文!

回复

maser_yoda · 2016年07月09日

存在local裡面的文件是不會自動銷毀的,那要更新這些緩存時怎麼處理?(⊙_⊙?)

回复

丛九九Nighting · 2016年07月09日

文件名后面带有md5戳,每次请求资源的时候,会将md5戳比对,不一致的话服务器下发新的资源并更新md5,楼主有写啊上面

回复

苹果小萝卜 · 2016年07月09日

学习

回复

wujohns · 2016年07月13日

css可以存在local啊,感觉你没有认真看文章吧

回复

DH · 2016年07月13日

感觉你都没有好好看我之后的评论,看完再说话

回复

xgqfrms · 2016年09月03日

前端速度

回复

zygsf · 2017年03月08日

对于 3.2 缓存!缓存!的 localstorage 感觉没必要 用http的缓存就行了
还有 移动端的 localstorage 的性能 不见得比 网络消耗快

回复

0

http 缓存是不是需要服务器验证是否过期 etag 啥的啊 需要head头校验 需要网络请求

小开童鞋 · 2017年08月24日
0

强制缓存呀~

zygsf · 2017年08月25日
烟雨姑苏 · 2017年11月16日

请问。。不支持storage的浏览器怎么搞呢?

回复

载入中...
Planets
侯医生 侯医生

2.1k 声望

发布于专栏

前端小站

讲解前端知识的小站,讲解你不知道的前端

508 人关注

系列文章