写点什么

图片流量节省大杀器:基于 CDN 的 sharpP 自适应图片技术实践

  • 2019-08-22
  • 本文字数:3154 字

    阅读完需:约 10 分钟

图片流量节省大杀器:基于CDN的sharpP自适应图片技术实践

目前移动端运营素材大部分依赖图片,基于对图片流量更少,渲染速度更快的诉求,我们推动 CDN,X5 内核,即通产品部共同推出了一套业务透明,无痛接入的 CDN 图片优化方案:基于 CDN 的 sharpP 自适应图片无痛接入方案。据统计效果可在原图基础上节省 60%-75%的流量,比之前 webP 无痛接入方案效果提升 40%-50%,减少流量的同时提高页面渲染速度,提升用户体验。

效果数据

目前手 Q 增值业务:VIP 中心、游戏中心、动漫、游戏公会、特别关心 以及增值渠道的 QQ 钱包,空间的个性化商城已经接入 sharpP 自适应,优化效果数据:



sharpP 自适应方案在原有 webP 自适应方案效果提升 40%-50%,提升效果主要来自 sharpP 高于 webP 的编码压缩率,同时能优化到 webP 无法覆盖的 png 图片(备注:之前 webP 无痛方案只实现了 jpg 的支持),sharpP 方案和原图对比可以节省 60%-75%的流量。


以我们的 VIP 中心为例,之前 webP 方案:



上 sharpP 方案后



在图片增加的情况下 图片流量减少了近 100K,页面速度也有提升,并且 sharpP 图片的效果也经过设计同学的验证,肉眼几乎无法区分,图片质量参数细节后面会介绍。

方案概述

利用自建 CDN 结点的缓存,以及带请求头的回源能力做到同一个 URL 根据终端分辨率,以及是否支持 sharpP 解码,按需返回不同的原图副本,做到图片资源的最合理利用:


手 Q X5 内核支持 sharpP 图片的解码,请求图片时会带上 accept: image/sharpp 标识,User-Agent 中会加上手机的分辨率 Pixel 参数,CDN 节点收到请求后,先检查如果有对应的 sharpP 自适应副本直接返回,如果没有则将请求回源到 CDN 源站,源站会根据请求的 User-Agent、Accept 参数返回对应分辨率的 sharpP 图片副本(原图上传后,或第一个用户请求触发 CDN 源站服务器图片转换,生成不同尺寸的 sharpP 图片), 如果请求头没有 sharpP 标识,则按原有逻辑返回原图,不影响业务。



整套优化方案接入对基于 X5 内核的 H5 业务完全透明,无需改动代码,即可让页面的图片获得可观的图片专项优化效果;app 业务接入,音视频有提供 sharpP 解码的 sdk 的接入。

方案详解

1、何为 sharpP

sharpP 是腾讯公司 SNG 即通产品部音视频技术中心推出的一种图片压缩组件,现已支持 iOS、Android、Windows、Linux 四个平台。编码压缩率、编码耗时、解码耗时相比 webP 有明显的优势。

2、CDN sharpP 方案

在原有 webP 自适应无痛方案基础上,我们联合终端、CDN 进一步升级优化,做了如下优化改造:


终端支持:增值业务大部分是基于手 Q webview 的 hybird 应用,安卓平台基于 X5 内核,X5 内核于 2.1.1 版本开始引入了 sharpP 组件,支持 sharpP 解码,并约定支持 sharpP 的版本发起的请求会在 http 请求的头部带上 Accept: image/sharpp 字段,同时 X5 内核 UA 中会带上终端分辨率 Pixel 字段,iOS 平台由于系统对 webview 内核的限制,暂时无法很好的嵌入 sharpP 组件,未能支持 sharpP 解码。未来可以在原生 app 引入 sharpP 组件,原生请求带上 Accept:image/sharpp,就可以使用到 CDN 的 sharpP 能力。


CDN 侧改造:CDN 源站转换工具集成了 sharpP 组件,CDN 的 OC 结点新增支持 sharpP 副本的缓存,整体流程大致如下:



客户端发起请求后,OC 结点根据请求 UA 检查 Accept 字段是否带有 image/sharpp,并获取 Pixel 分辨率信息,OC 结点判断是否有满足要求的原图副本缓存,没有缓存则将 URL+请求头回源,源站识别请求头中的信息,返回图片对应的 sharpP 副本,OC 结点缓存下来。源站图片如果未转换完成(图片上传后或第一次请求触发 CDN 源站异步转换),源站会先返回原图,max-age=10,让 OC 结点暂时不缓存,再次请求时,判断转换完成才返回 sharpP 图片并设置默认的缓存时间 max-age=25920000。


目前 CDN sharpP 已支持了我们 BGtop5 流量的域名:

imgcache . gtimg . cn、i . gtimg . cn、imgcache . qq . com、qzonestyle . gtimg . cn、qzs . qq . com


整体方案:结合之前我们做的自适应、webP 方案,与 sharpP 可以完全兼容,在 CDN 源站是 3 项单独的配置,可以按需配合或单独使用,整体方案如下图



优先判断是否有自适应,然后检查 sharpP,如果 sharpP 和 webP 都支持优先返回 sharpP。

3、项目中踩过的坑

1)运营商内容劫持,由于同一个 URL 可能返回不同的内容(不同分辨率的 sharpP/原图) 线上观察发现联通运营商会在请求到我们自建 CDN 结点之前加一层缓存,默认会按 URL 来缓存内容,其实就是内容劫持,导致不同请求头,返回错乱与我们期望的不一致,后面找到一种解决方法,基于 http 协议的 vary 字段,CDN 源站以及 CDN 结点返回内容的时候带上 Vary:User-Agent,Accept 字段,告诉运营商的缓存服务器根据请求的 Accept+User-Agent+Url 来缓存内容,经验证可以解决问题。


2)质量参数设置,尽可能保证图片压缩的更小,效果与原图差距不大


sharpP 采用有损压缩,转换工具会读取原图质量参数,适当降低:如果原图质量参数低于 75 则保持原质量参数直接转 sharpP,如果质量参数高于 75,则在原图基础上降低一些质量参数,根据业务要求自行设置,目前根据观察质量参数不低于 75 的 sharpP 图片基本肉眼无法区分。


3)新的业务开启 sharpP 自适应,源站图片转换导致磁盘 IO 压力过大


用脚本凌晨闲时对存量图片预转换生成各尺寸的副本;转换工具监听图片目录的新增文件,用户上传后就做转换;转换脚本做了优化,只有第一次请求触发转换。


4)sharpP 转换工具对某些图片转换失败,生成空文件


捕获转换失败错误码,空文件用原图替换,避免返回给结点空文件


5)有时候业务图片需要强制使用原图


支持 nosharpp 参数,url 带上参数后,CDN 强制返回原图。


6)图片缓存清理


由于一个图片 URL,对应了多份 CDN 结点缓存副本,如果图片更新的时候,可能有个别副本缓存刷新不及时,导致不同分辨率、sharpP、原图的用户看到的图片不一致,需要优化 CDN 缓存刷新工具,支持一次清理所有缓存副本。


以上皆为项目推进中遇到的问题,未考虑周全可能就会影响功能,线上实施前得在测试结点充分验证,结点部署要控制节奏,并且要有完善的线上监控机制,以及功能回退的能力。

4、图片检测监控

1、为了提高接入效率,减少人工验证步骤,我们开发了图片检测监控工具,定时监控业务页面图片在各 OC 结点返回是否正常。原理:工具根据业务 URL,抓取页面内所有 CDN 域名的图片,随机抽取一部分 OC 结点,构造 sharpP,webP,原图 3 种请求,根据返回的图片格式,大小对比验证图片是否正常。


2、现网图片加载数据上报:为了监控更多用户的图片加载真实数据,我们在业务中接入了图片加载上报组件,原理是利用 X5 内核收集的资源加载信息,过滤出图片信息,上报图片类型,返回码,加载耗时,网络类型等。

5、sharpP 开启验证

上传一张新图片,使用手 Q 安卓版本访问已支持 sharpP 域名的 CDN 图片,如果请求带了 Accept:image/sharpp,检查返回图片格式是否为 sharpP





如果旧的图片未按预期返回,返回了 webP 或原图可能是 OC 结点缓存,正常 3 天后过期回源则会返回 sharpP 图片。

未来规划

1、app 业务接入 sharpP 优化方案目前只有安卓平台基于 X5 内核的应用能得到这套 CDN sharpP 方案的优化效果,根据 CDN 日志的流量统计 BG 内最大的流量还是来自终端发起的请求,后续我们计划联合 CDN 大流量的终端业务接入 sharpP 解码组件,让这套方案能给更多业务带来收益,同时也为公司和用户节省流量成本。


2、sharpP 工具优化 sharpP 组件在不断优化,包括转码效率、成功率,gif 格式支持等,CDN 转换工具也将迭代支持。


作者介绍:


陈忱,腾讯工程师,13 年毕业加入腾讯,从事过研发流程平台工具开发,现负责手 Q VIP 中心,喜欢研究新技术,专注于前端性能优化。


本文转载自公众号小时光茶舍(ID:gh_7322a0f167b5)。


原文链接:


https://mp.weixin.qq.com/s/sj27FHBsjZkUPJxcDdY86Q


2019-08-22 16:175336

评论

发布
暂无评论
发现更多内容

还有比二分查找更快的算法,面向接口编程Protocol,John 易筋 ARTS 打卡 Week 05

John(易筋)

swift ARTS 打卡计划 二分查找 binary search protocol

架构师训练营第三周学习总结

CATTY

618 我们狂欢的是什么?

Neco.W

拼多多 电商 京东 热门活动

锦囊篇|一文摸懂RxJava

ClericYi

Prometheus 2.19.0 新特性

耳东@Erdong

Prometheus

week3.学习总结

个人练习生niki👍

springboot整合Quartz实现定时任务(api使用篇)

北漂码农有话说

架构师训练营 - 第三周命题作业

牛牛

极客大学架构师训练营 命题作业

锦囊篇|一文摸懂LeakCanary

ClericYi

锦囊篇|一文摸懂ButterKnife

ClericYi

极客时间架构师训练营 - week3 - 作业 2

jjn0703

极客大学架构师训练营

学习总结 - 第3周

饶军

关于多线程,你必须知道的那些玩意儿

ClericYi

锦囊篇|一文摸懂OkHttp

ClericYi

设计模式的十八般武艺

ClericYi

Redis系列(二): 连集合底层实现原理都不知道,你敢说Redis用的很溜?

z小赵

Java redis 高并发 高并发系统设计

游戏夜读 | 《FPS关卡设计》

game1night

第三周学习总结

iHai

极客大学架构师训练营

锦囊篇|一文摸懂EventBus

ClericYi

还不会十大排序,是准备家里蹲吗!?

ClericYi

我们是如何做go语言系统测试覆盖率收集的?

大卡尔

测试覆盖率 精准测试 Go 语言

第三周课后作业

iHai

极客大学架构师训练营

架构师训练营 -week3- 作业

晓-Michelle

极客大学架构师训练营

再谈云原生:我的看法

lidaobing

云原生 k8s 中间件

区块链系列教程之:比特币中的网络和区块链

程序那些事

比特币 区块链 网络 p2p

关于JVM,你必须知道的那些玩意儿

ClericYi

面试中的HashMap、ConcurrentHashMap和Hashtable,你知道多少?

ClericYi

ARTS-week-4

youngitachi

ARTS 打卡计划 arts

ARTS-03 -- ARTS-04

NIMO

ARTS 打卡计划 ARTS活动

重学 Java 设计模式:实战命令模式「模拟高档餐厅八大菜系,小二点单厨师烹饪场景」

小傅哥

设计模式 小傅哥 重构 代码优化 命令模式

锦囊篇|一文摸懂Handler

ClericYi

图片流量节省大杀器:基于CDN的sharpP自适应图片技术实践_大前端_陈忱_InfoQ精选文章