移动Web加速技术月报第3期

为推进Web技术的发展,Brilliant Open Web 团队特推出每月一期的《移动Web加速技术月报》,该月报将整理较流行的移动Web加速技术,并跟进各项技术的进展和发展方向,以期帮助开发者了解或选用相关的技术,把握技术发展趋势。欢迎关注【OpenWeb开发者】公众号并回复“加群”,一起探讨相关技术。

作者 | Brilliant Open Web 团队breezet、chengang、shdong
编辑 | 尾尾

一、内容回顾

上一期的月报中,我们为大家介绍了Web页面中如何使用预取和预渲染来进行页面加速,同时也指出了目前浏览器提供的预取和预渲染方法所存在的问题以及改进优化的思路。

本期,我们将再次聚焦到一期讨论的浏览器缓存、页面云端缓存等技术上,详细展开讨论各种页面缓存技术能达到的效果以及所存在的一些问题。

二、相关技术介绍:云端页面缓存策略漫谈

近几年,无论是内容分发平台还是浏览器厂商都会通过云端的页面CDN Cache服务,为用户访问Web页面提供更快的页面访问。

通过更优质的CDN Cache,内容分发平台或浏览器厂商通过中间代理的方式,让用户享受了更优质的页面速度浏览体验。由于各公司提供的页面缓存服务在对缓存的处理策略上不尽相同,也导致站点在提供Web服务时,不清楚应该如何配置才能被正确缓存并且对自己业务无其他负面影响。

本章节会详细讲述其中存在的问题,综合百度在此方面的处理方案给出建议的通用标准实现。

1. 概述

内容分发平台或浏览器对Web页面进行服务端的缓存,主要的目的是因为很多的站点服务本身并没有提供较好的网络环境和服务快速响应,通过将此类站点的页面缓存在CDN Cache等网络中(页面代理缓存),可以使用户访问此类站点时享受到极快的页面加载。

但是,目前云端缓存的规范是不明确,具体表现为业界已经默认的规范不属于任何组织(如x-forward-for),部分规范是浏览器提供商(chrome,Firefox)等提出的,并未完全推进到标准中(如标识预加载的x-moz),从而导致页面开发者在自己的页面可能被缓存的情况下,无法正确的保障自己被缓存页面的用户体验以及功能。

本文将从以下几个方面在总结内容分发平台或浏览器在代理缓存服务策略上的问题和解决方案:

  1. Web site option for proxy cache server(web站点针对云端缓存的配置)
  2. Web site access info collection when page cached by proxy server(web站点针对云端缓存的统计方法)

2. Web site option for proxy cache server(Web站点针对云端缓存的配置)

本小节主要讲述页面站点在被浏览器或内容分发平台的代理服务缓存时所面临的问题,并给出对开发者更友好的缓存服务解决方案建议。

存在的问题

下图是一个用户访问站点时的请求所经过的缓存相关的路径。

浏览器部分云加速服务,对页面的修改以及缓存对开发者过于透明不可控,包括但是不限于:

  • 没有明确的配置协议,让控制哪些页面可以被缓存,哪些页面不能被缓存;
  • 页面缓存失效的时间配置,是否沿用HTTP Header中的Cache-Control头,没有明确规范,而各类代理缓存服务对此的处理也不一致;

解决方案建议

代理缓存服务本身会在页面访问时抓取对应的页面,因此可遵循以下缓存策略:

  • 使用robots.txt文件中新增字段描述站点url pattern粒度的是否允许被缓存;
  • robots.txt文件本身可缓存时间用Cache-Control来控制;
  • 缓存时间统一用Cache-Control头来控制缓存超时,用stale-while-revalidate头来控制平滑更新;
  • 对于站点主动配置的缓存系统来说,robots.txt里边的禁止相关的内容,效果等同于Cache-Control: no-cache
  • 代理缓存服务请求站点时,处理主要流程如下: 图片

用例说明

百度搜索结果页中的一个网站开发者,自己站点的/home/news/data 路径下的所有页面都是高时效性的页面,不希望被任何加速服务缓存。为了达到这个目的,站长应该在自己站点的robots.txt文件中加入如下内容:

Cache:*  
HttpsCacheDisallow:/home/news/data/  
HttpCacheDisallow:/home/news/data/  
# 对于所有的Cache来说,https和http的在/home/news/data/路径下的所有内容不允许被缓存
# 如果希望各层加速能平滑更新,那么可以在Cache-Control头里面写入如下内容:max-age=864000, stale-while-revalidate=1728000
# 表明:在86400s内本地缓存有效。在172800s内返回旧缓存的同时,异步发起更新。当时间超过172800s时,缓存失效,重新抓取。

所有遵循了缓存规范的服务解析站点的robots.txt文件后,不缓存/home/news/data路径下的所有内容。满足了开发者的需求。

当然,作为站长,不能滥用此规范,因为不缓存的页面往往意味着更慢的加载速度。

在这种场景下,处在HttpsCacheDisallow或者HttpCacheDisallow所配置的Path中的页面所返回的Cache-Control等header将会仅仅被用来控制浏览器端的缓存。

相应的,对于浏览器自带的云加速服务器来说,方便在浏览器上做热门站点的robots.txt文件,来判断那些页面可以直接不通过自己的云加速服务,而是直接访问源站。

3. Web site access info collection when page cached by proxy server

代理缓存服务进行页面缓存时,也会给站长带来数据统计上的困扰。本小节试图从数据统计的方面,提供缓存服务在统计上的一些解决方案。

存在的问题

  • 部分页面强依赖请求的Client IP来做一些策略
  • 部分站长需要实时知道自己站点的pv特征
  • 缓存后,这些信息尚无明确规范回传给站长
  • 目前,只有FireFox提出了基于x-forward-for的规范,但是这个规范不属于任何组织

解决方案建议

  • 代理缓存服务回传回源等数据的时候都加上x-forward-for头来指名真实的用户IP信息
  • HTML中新增用于日志回传的标签,用于告知浏览器需要将当前的x-forwad-for发送至对应地址,例如<meta x-forwad-for='true' sendTo='domain/path'>

三、主要技术进展

本月报将收录移动Web加速技术的主要进展,欢迎读者一起完善,投稿邮箱:openweb@baidu.com。

MIP本月进展

  1. mip-map地图组件上线,支持百度地图的定位、地图控件加载、坐标弹窗定制等功能;
  2. mip-stats-cnzz 功能升级,能够将页面的 cnzz 统计请求发送到自定义的 cnzz 服务器节点,修复固定节点的服务不稳定性问题;
  3. mip-showmore 功能升级,能够定制展开状态下的精美的按钮样式,让 showmore 的样式更加贴合开发者的自身需求;
  4. mip-sidebar 升级,弹出时增加平滑的动画效果,让弹出的效果更加优美;
  5. mip-bind:进行功能完善和升级,在官网上产出详细的使用说明文档和示例,帮助开发者更轻松使用此功能,同时协助部分电商站点完成 MIP 页面的该功能的添加;
  6. mip-form:去除 password,file等功能限制;
  7. 网盟广告加载速度优化实验,将投放脚本、广告位配置提前至 layout 之前加载;
  8. 官网文档开源,开放文档,做到开源共建。

AMP本月进展

  1. amp-story 默认静音,添加渐变效果,修复部分兼容性问题,提升组件使用体验;
  2. AdSense / Doubleclick 快速取回 unlayoutCallback 实验;
  3. AMP 元素增加API,实现元素的调度时间传递给元素本身;
  4. amp-analytics 增加新的分析服务商:Alexa Internet,增加参数this.isInabox_,支持基本批处理功能。

四、总结

百度在W3C 2017 TPAC会议上针对页面云端缓存策略的议题与全球各大互联网公司有过深入的交流和讨论,也收到了大家的积极响应和回复。

云端缓存策略是一项重大的技术创新,但技术野蛮生长的同时也对开发者造成了巨大的困扰,随着大家对此项技术的广泛深入应用,云端缓存策略必然需要统一的标准和规范,开发者通过统一的规范和标准,来配置自己的页面的云端缓存策略,来提供更可靠的体验和功能。

欢迎各位读者补充各项移动Web加速技术及其最新进展,可以发送邮件到 openweb@baidu.com,也可以关注【OpenWeb开发者】公众号并回复“加群”,一起来探讨相关技术,与我们携手推进Web技术的发展!