对于加载精简来说，最大的好处莫过于对页面的加速。加速有两点：

　　第一是由于资源加载量减少，对于页面首屏加载速度的提升；

　　第二是某些加载精简的方法，会在一定程度上加快页面的渲染速度。

同时，由于加载量的减少，剩下了一些带宽，从而减少了带宽费用。

 

当然，事情都有两面的地方。加载精简会在一定程度上影响页面的SEO；部分方法也会造成一些额外的脚本开销。

寻找合适你的方法很重要，毕竟每个网站性质、用处、节点都可能不同。比如项目初期，可能宣传和扩散知名度方面重要些，这时候建议不要大量使用动态生成内容的方式，影响SEO。

 

第1章 存储资源

1.1 离线存储

1.1.1 为了移动

由于浏览器支持情况不同，离线存储在PC端没有大量的使用，反而在移动端的支持情况越来越好，如今Android、iOS都能使用离线存储，所以离线存储广泛的使用于离线APP应用。

对于离线存储，最重要的便是manifest文件。我们将需要缓存的文件列入cache段，将不需要缓存的内容列入network段即可。

图2-1 manifest文件示例

当浏览器加载页面时，发现manifest文件后，会检查它的内容是不是有修改，如果是，重新下载cache段的文件并缓存；如果不是，则跳过。

图2-2 更新离线缓存

需要注意的是，当我们使用离线存储时，浏览器会强行只读离线缓存的文件。我们需要将页面使用到的所有的资源都列入manifest文件中，不论是在cache段，还是network段。否则浏览器将报错，说找不到文件。

图2-3 未将所有文件列入的加载报错情况

1.1.2 更新

对离线存储的资源更新，需要修改manifest文件的内容。当然，我们一般不会随意修改文件名已达到修改manifest文件内容的目的。一般的做法是，在文件内新增一行注释，注释中写明目前的版本号，以后每次需要更新的时候，修改版本号就行了。

图2-4 第二行即为注释的版本信息

另外，我们可能需要功能更加强大的离线存储缓存更新的机制。试想一个新闻类的APP，我们需要在手机离线时读取本地存储的数据，当APP发现用户联网后，将读取在线的内容，更新本地的数据和页面信息。

对于图2-5，我们使用HTML5新提供的online时间在页面加载的时候判断手机是否在线。监听window的online和offline时间，可以判断手机是不是已经联网。一旦检测到手机联网，我们就可以调用applicationCache对象的update方法，去检测manifest文件是否有更新，如果有，下载新的版本。当updateready时，使用swapCache方法刷新缓存。

当然swapCache不能刷新页面的内容，只是把离线存储的文件更新成我们下载的新内容，我们还需要再使用JS替换页面的内容。

图2-5 离线存储进阶应用

1.1.3 残缺美

在使用离线存储的时候，总有些感到不是很爽的地方，列出来吐吐槽。

首先是两个更新的问题。我们知道，修改manifest文件后，浏览器会重新下载文件，而且是全部重新下载。这其实很蛋疼，有时候我们只需要更新其中一个文件，有点儿殃及池鱼的感觉。另外，在更新manifest文件后，我们需要刷新两次页面才能将最终的新内容呈现在页面上。

然后，如果我有很多文件要存储，需要把文件一个一个列入cache段里，就算使用程序生成，出来的manifest文件也有一定的体积。对于一个需要缓存300个文件的页面，使用相对路径，生成的manifest文件也有4K。在碰上更新的话，下载量有点儿大。

图2-6 APP有200多个小图标需要缓存

最后，对于同一个页面的带参URL路径，离线存储会当成不同的新文件进行缓存。如果您有100个不同的参数需要穿，而用户竟然访问过这100个文件，那就……

图2-7 如果您有100个不同的传参

1.2 本地存储

1.2.1 本地存储的方法

userData是IE提供的一个本地存储方法，他将需要存储的内容放置在本地的一个XML文件中，并在页面的一个元素中设置一个调用的锚点。具体使用方法为：使用getElementById获取页面内的一个元素，使用addBehavior(“#default#userData”)对其添加本地存储的行为；使用setAttribute将需要存储的内容对其进行赋值，并用save(“XXX”)方法将内容存储在名为XXX的XML文件中；使用load(“XXX”)方法加载本地的XXX.xml文件，并用getAttribute获取已经存储的内容。

图2-8 IE的本地存储数据

关于HTML5本地存储localStorage的详细方法，请参见我的翻译文章《网络应用程序本地存储的前世今生》。

图2-9 Chrome的本地存储数据

对于IE浏览器，使用IE提供的userData方法；对于支持HTML5的浏览器(Firefox、Chrome、Safari、Opera等)，使用localStorage提供的方法；对于其他浏览器使用常规方法加载内容。

图2-10 判断流程

1.2.2 资源处理

对于本地存储，我们可以使用来存储数据，或者能转为数据形式的文件。例如一些SEO要求不高的文字，链接等等。

图2-11 数据存储

对于图片、CSS、JS等文件，我们也可以转为文本来存储在本地。这种方式大量应用于移动端。例如《掌上英雄联盟》APP的图片大部分都转化为base64编码存储在本地（不用离线存储的原因前面提及了）。Google和Bing的移动版，也将CSS和JS拆分后本地存储了。

图2-12 脚本的本地存储

图2-13 图片转base64编码后的本地存储

另外，对于本地存储更新，我的做法是：先判断本地是否存在已存储的内容，如果没有数据或者版本已过期（所谓版本是我设置的一个变量，当修改这个变量时即为版本过期），加载相应的JS数据，通过一个函数将数据处理为需要的格式，然后存储在本地；如果有且版本没过期，直接从本地获取数据。接着将数据通过函数进行进一步的处理，插入相对应的结构中。

图2-14 本地数据版本判断

 

 

第2章 按需加载

2.1 滚动加载

2.1.1 滚动加载的方法

其实这是很多大型网站都使用了的方法，比如淘宝、拍拍等等。对于不同显示器分辨率不同，所以第一屏高度不一样，节省的加载量所浮动。

首先，记录所有需要滚动加载对象的纵坐标值到一个数组。然后使用JS的监听方法（IE是attachEvent，其他浏览器是addEventListener），监听页面的scroll事件。一旦页面滚动，就会执行一个编写的函数，来判断对象是否处于浏览器的当前一屏内，如果是，将加载对象，如果不是，继续监听。当页面内的所有对象都被加载后，取消监听。

图3-1 执行流程

对于图片，滚动页面后，我们可以看到如图3-2的效果。

图3-2 图片滚动加载过程

2.1.2 板块滚动加载

其实把每个板块按照上面说的那种方式，像图片一样，滚动加载就可以实现这种效果，类似于bigPipe+Lazyload。

我们将页面拆分为框架、板块、板块内容，甚至可以细分到板块样式、板块脚本。当页面滚动完成时，判断处于当前屏的板块，动态并行加载板块内容。这种方式可以大大减少页面的加载量，但会影响SEO。

图3-3 板块滚动加载方式

2.2 点击加载

2.2.1 形式

点击后动态加载有很多形式，这是我们平时使用最多的方式。诸如页卡、翻页、展开、下拉、切屏等等都会使用到。以往的我们可能直接在页面写入内容，或者使用include载入，并将看不到的内容隐藏掉。但如果用户并没有点击切换，那么直接加载这些内容就产生多余的加载量。

图3-4 触发加载页卡内容

图3-5 翻页触发动态加载

2.2.2 触发加载

一般来说，动态填充数据的前期判断有两种形式。

一种是使用条件语句，判断内容区域是否有内容，如果没有，填充内容。这种方式最容易想到，但每次触发的时候都会判断一次。

另外一种是监听的方式。我们监听触发的对象是否被点击，如果点击，就像目标对象填充内容，然后取消这个监听。

图3-6 判断的两种方式

很显然，第二种方式只需执行一次，测试结果也表明这种方式是最快的。

2.2.3 数据插入方式

我们的新闻系统在生成新闻列表的时候，会根据我们的模板同时生成html页面、xml文件（我们很少使用）、json文件，在选择将列表插入页面的时候，我们有两种方式。

一种是动态加载json文件，用JS生成内容，插入页面；另一种是使用XHR加载html文件，使用responseText获取内容，插入页面。

图3-7 html文件

图3-8 json文件

其实，使用第二种方法有明显的好处。第一是，html文件体积比json文件小，加载量减少；第二是直接使用html文件，减少了JS动态生成结构的开销。

2.3 延时加载

对于一组有加载时间间隔的资源，我们其实可以对其做加载延时，按照其前后出现的顺序，在时间间隔后即时加载下一个资源。例如轮播广告就很适合这么做。

图3-9 轮播广告

2.3.1 轮播广告

以往轮播广告的加载模式是一次性全部加载，虽然采用延迟加载，但用户可能不会浏览到所有的轮播广告。当用户在首页只停留5秒时（例如轮播广告设置的是5秒切换一次），第二张广告图片以后的图片加载就没有必要了。

图3-10 轮播广告加载的请求瀑布图

其实我们可以这样，第一次加载第一张广告图片，当5秒后，判断第二张图片是否加载过，如果没有，加载第二张图片，以此类推。判断的方式很简单，我们只要在初期生成轮播广告结构的时候，不设置img标签的src属性，然后加载时判断这张图片是否有src属性，如果没有，加载图片并设置这个属性。

图3-11 判断方式

这样，如果用户在首页停留时长只有14秒，那么就节省了第4、5张广告图片的下载量，大约有100K左右。

图3-12 优化后的请求瀑布图

 

第3章 其他方式

3.1 文件压缩

3.1.1 代码

老生常谈的方法。我们可以将代码里多余的空格，回车，无用标签删除，替换名字较长的变量名等等方式减少脚本文件大小。

图4-1 脚本压缩对比

3.1.2 多媒体

对于图片，不同格式，不同压缩率都会造成图片大小的千差万别。选择一个合适并且图片质量可以接受的压缩方式，可以节省很大一笔加载量。

图4-2 图片压缩对比

对于视频、音频、Flash来说，也都一样，码率、格式等等方面都会对大小造成影响。

图4-3 视频压缩对比

3.2 CSS 3

CSS 3是一个不算太新，但由于我朝浏览器限制而得不到大范围应用的技术。其实我们可以在一些效果表现不是很重要的页面使用CSS 3来针对浏览器做一些差异化效果，已达到减少加载量的目的。

3.2.1 替换图片

对于移动端，或者一些PC页面，我们可以用CSS 3来替换一些图片效果，比如渐变、阴影、圆角等等。

图4-4 绿色按钮

例如图4-4中的绿色按钮，使用CSS 3渐变和图片所造成的加载量差距很大，在能使用CSS 3的时候，尽量不要使用图片。

图4-5 CSS 3和图片的大小对比

3.2.2 替换JS动画

一些对象移动、宽高变换等效果，其实可以使用CSS 3动画来实现。例如使用CSS 3和JS，来实现一个对象左右切换的效果，需要的代码量如图4-6所示。我们可以看到，CSS 3的代码量极少，而且执行过程中没有JS那些复杂的运算。

图4-6 CSS 3和JS的代码量对比

3.3 服务器

3.3.1 GZIP

雅虎13条里的内容。其压缩比例很大，大部分网站都使用了。

图4-7 gzip效果

3.3.2 缓存

设置Expires、Cache-Control以减少页面加载量，使浏览器从本地读取缓存。

Expires和Cache-Control max-age均用于检测文件是否过期，如果没有，浏览器读取本地缓存。Expires是HTTP1.0的内容，需要返回一个304 Not Modified，并且过期时间是GMT时间，一旦客户端日期不准确，可能导致失效。Cache-Control是HTTP1.1的内容，使用文件自身的age值来做和请求时间对比，相对稳定。

图4-8 304 Not Modified

3.3.3 优图

优图是公司开发的，用于图片无损压缩的系统。目前互娱已经接入，在图片上传到服务器时，自动进行无损压缩，加载量减少的效果非常明显。

图4-9 优图

 

第4章 三个话题

4.1 对比

在以前一次分享文档中，有同学提问为啥要抛开浏览器与服务器的缓存机制，自己实现一套本地存储机制，有没有什么特别的优势。其实相对与传统缓存来说，本地存储的好处有4点。

一是，对于存储需要处理的数据来说，本地存储可以在第一次加载的时候就将处理的数据存在本地，而传统缓存策略需要每次加载的时候都处理一次数据。

二是，本地存储相对稳定，有独立的存储空间，一般不会向服务器发送请求，而传统缓存时常会丢失。

三是，相对于传统缓存策略，本地存储的读取速度要更快些。当然，也有例外，Chrome的本地存储读取速度要慢于缓存文件的加载。

四是，对于iOS设备，Safari在重启后（包含本身的重启，或者设备的重启），缓存会被清空，而本地存储和离线存储不会。

4.2 SEO

4.2.1 Landing Page

对于互娱这边的游戏，客户端会有一个Landing Page，上面包含了最新的新闻，活动等等信息，玩家每次启动客户端都会看到这个页面。

根据监控，Landing Page平均每天给官网带来250w左右的PV，而官网平均每日PV大约1000多万。这个量应该完全填补了SEO的损失。而且游戏官网的用处一般仅限于给玩家提供游戏的功能服务、新闻、活动信息等等，玩家查询游戏攻略、资料一般会去媒体站，而不是游戏官网。

图5-1 《英雄联盟》的Landing Page

4.2.2 内页链接

在某些内容需要动态加载的时候，我们可以写一个到内页的链接，让搜索引擎爬虫顺着这个链接到内页去记录信息。

图5-2 到内页的链接

例如页卡中的新闻列表需要动态填充，如果不做处理，爬虫可能无法获取这些列表中的新闻链接。我们可以像图5-2的那两种方式，写一个到列表页的链接，这样爬虫就可以顺着这个链接到列表页去抓取信息。

4.3 效果

4.3.1 健康度

健康度是我们以前接的加载时间检测系统，最近我们换用了OZ系统。使用了以上方法的网站，在3秒健康度上，有了很大的提升。

图5-3 3秒健康度

4.3.2 请求减少

采用以上方式减少加载量，虽然会造成整个网页的全部请求量有少许增加，但因为是按需加载，所以可以大大减少首屏请求量。

图5-4 首屏请求量

图5-5 整页请求量

4.3.3 带宽消耗

在我们接入优图后，图片服务器的带宽消耗大大减少。在图片压缩一半后，我们的带宽消耗减少了4G。

图5-6 图片压缩一半后服务器带宽消耗趋势图

由于公司系统只能针对服务器做带宽消耗监控，所以我们看不到做文件存储和按需加载后的带宽减少情况，但我们可以大概算算。如果一个游戏官网全部页面平均每天有PV1500w，用户平均每次加载页面节省10KB，假设第1天正常加载，后29天全部读缓存，每月可以节省带宽488MB。对于有几十款游戏产品的我们来说，这是一个很可观的量。

 

结束语

正如开篇所说的那样，介绍的这些方法，有部分会伤害SEO，增加脚本开销。所以大家在使用的时候需要进行一个合理的选择。

例如对于一个新产品，SEO相对更加重要些，这个时候可以适当选用一些减少加载量的方法；当产品成熟，有大量用户的时候，可以考虑进行更加深入的加载量优化。

希望此文档能帮助到今后做网站加载量优化的同学。