技术文章 | 移动 H5 首屏秒开优化方案探讨
2017-08-18 13:49
323 查看
本文来源于阿里云-云栖社区,原文点击这里。
随着移动设备性能不断增强,web 页面的性能体验逐渐变得可以接受,又因为 web 开发模式的诸多好处(跨平台,动态更新,减体积,无限扩展),APP 客户端里出现越来越多内嵌 web页面(为了配上当前流行的说法,以下把所有网页都称为
H5 页面,虽然可能跟 H5 没关系),很多 APP 把一些功能模块改成用 H5 实现。
虽然说 H5 页面性能变好了,但如果没针对性地做一些优化,体验还是很糟糕的,主要两部分体验:
页面启动白屏时间:打开一个 H5 页面需要做一系列处理,会有一段白屏时间,体验糟糕。
响应流畅度:由于webkit的渲染机制,单线程,历史包袱等原因,页面刷新/交互的性能体验不如原生。
本文先不讨论第二点,只讨论第一点,怎样减少白屏时间。对 APP 里的一些使用 H5 实现的功能模块,怎样加快它们的启动速度,让它们启动的体验接近原生。
为什么打开一个 H5 页面会有一长段白屏时间?因为它做了很多事情,大概是:
初始化 webview -> 请求页面 -> 下载数据 -> 解析HTML -> 请求 js/css 资源 -> dom 渲染 -> 解析 JS 执行 -> JS 请求数据 -> 解析渲染 -> 下载渲染图片
一些简单的页面可能没有 JS 请求数据 这一步,但大部分功能模块应该是有的,根据当前用户信息,JS 向后台请求相关数据再渲染,是常规开发方式。
一般页面在 dom 渲染后能显示雏形,在这之前用户看到的都是白屏,等到下载渲染图片后整个页面才完整显示,首屏秒开优化就是要减少这个过程的耗时。
上述打开一个页面的过程有很多优化点,包括前端和客户端,常规的前端和后端的性能优化在 PC 时代已经有最佳实践,主要的是:
降低请求量:合并资源,减少
HTTP 请求数,minify / gzip 压缩,webP,lazyLoad。
加快请求速度:预解析DNS,减少域名数,并行加载,CDN
分发。
缓存:HTTP 协议缓存请求,离线缓存
manifest,离线数据缓存localStorage。
渲染:JS/CSS优化,加载顺序,服务端渲染,pipeline。
其中对首屏启动速度影响最大的就是网络请求,所以优化的重点就是缓存,这里着重说一下前端对请求的缓存策略。我们再细分一下,分成 HTML 的缓存,JS/CSS/image 资源的缓存,以及 json 数据的缓存。
HTML 和 JS/CSS/image 资源都属于静态文件,HTTP 本身提供了缓存协议,浏览器实现了这些协议,可以做到静态文件的缓存,具体可以参考这里,总的来说,就是两种缓存:
询问是否有更新:根据 If-Modified-Since / ETag 等协议向后端请求询问是否有更新,没有更新返回304,浏览器使用本地缓存。
直接使用本地缓存:根据协议里的 Cache-Control / Expires 字段去确定多长时间内可以不去发请求询问更新,直接使用本地缓存。
前端能做的最大限度的缓存策略是:HTML 文件每次都向服务器询问是否有更新,JS/CSS/Image资源文件则不请求更新,直接使用本地缓存。那 JS/CSS 资源文件如何更新?常见做法是在在构建过程中给每个资源文件一个版本号或hash值,若资源文件有更新,版本号和 hash 值变化,这个资源请求的 URL 就变化了,同时对应的 HTML 页面更新,变成请求新的资源URL,资源也就更新了。
json 数据的缓存可以用 localStorage 缓存请求下来的数据,可以在首次显示时先用本地数据,再请求更新,这都由前端 JS 控制。
>>>展开全文
随着移动设备性能不断增强,web 页面的性能体验逐渐变得可以接受,又因为 web 开发模式的诸多好处(跨平台,动态更新,减体积,无限扩展),APP 客户端里出现越来越多内嵌 web页面(为了配上当前流行的说法,以下把所有网页都称为
H5 页面,虽然可能跟 H5 没关系),很多 APP 把一些功能模块改成用 H5 实现。
虽然说 H5 页面性能变好了,但如果没针对性地做一些优化,体验还是很糟糕的,主要两部分体验:
页面启动白屏时间:打开一个 H5 页面需要做一系列处理,会有一段白屏时间,体验糟糕。
响应流畅度:由于webkit的渲染机制,单线程,历史包袱等原因,页面刷新/交互的性能体验不如原生。
本文先不讨论第二点,只讨论第一点,怎样减少白屏时间。对 APP 里的一些使用 H5 实现的功能模块,怎样加快它们的启动速度,让它们启动的体验接近原生。
过程
为什么打开一个 H5 页面会有一长段白屏时间?因为它做了很多事情,大概是:初始化 webview -> 请求页面 -> 下载数据 -> 解析HTML -> 请求 js/css 资源 -> dom 渲染 -> 解析 JS 执行 -> JS 请求数据 -> 解析渲染 -> 下载渲染图片
一些简单的页面可能没有 JS 请求数据 这一步,但大部分功能模块应该是有的,根据当前用户信息,JS 向后台请求相关数据再渲染,是常规开发方式。
一般页面在 dom 渲染后能显示雏形,在这之前用户看到的都是白屏,等到下载渲染图片后整个页面才完整显示,首屏秒开优化就是要减少这个过程的耗时。
前端优化
上述打开一个页面的过程有很多优化点,包括前端和客户端,常规的前端和后端的性能优化在 PC 时代已经有最佳实践,主要的是:降低请求量:合并资源,减少
HTTP 请求数,minify / gzip 压缩,webP,lazyLoad。
加快请求速度:预解析DNS,减少域名数,并行加载,CDN
分发。
缓存:HTTP 协议缓存请求,离线缓存
manifest,离线数据缓存localStorage。
渲染:JS/CSS优化,加载顺序,服务端渲染,pipeline。
其中对首屏启动速度影响最大的就是网络请求,所以优化的重点就是缓存,这里着重说一下前端对请求的缓存策略。我们再细分一下,分成 HTML 的缓存,JS/CSS/image 资源的缓存,以及 json 数据的缓存。
HTML 和 JS/CSS/image 资源都属于静态文件,HTTP 本身提供了缓存协议,浏览器实现了这些协议,可以做到静态文件的缓存,具体可以参考这里,总的来说,就是两种缓存:
询问是否有更新:根据 If-Modified-Since / ETag 等协议向后端请求询问是否有更新,没有更新返回304,浏览器使用本地缓存。
直接使用本地缓存:根据协议里的 Cache-Control / Expires 字段去确定多长时间内可以不去发请求询问更新,直接使用本地缓存。
前端能做的最大限度的缓存策略是:HTML 文件每次都向服务器询问是否有更新,JS/CSS/Image资源文件则不请求更新,直接使用本地缓存。那 JS/CSS 资源文件如何更新?常见做法是在在构建过程中给每个资源文件一个版本号或hash值,若资源文件有更新,版本号和 hash 值变化,这个资源请求的 URL 就变化了,同时对应的 HTML 页面更新,变成请求新的资源URL,资源也就更新了。
json 数据的缓存可以用 localStorage 缓存请求下来的数据,可以在首次显示时先用本地数据,再请求更新,这都由前端 JS 控制。
>>>展开全文
相关文章推荐
- [置顶] 移动 H5 首屏秒开优化方案探讨
- 移动 H5 首屏秒开优化方案探讨
- 移动 H5 首屏秒开优化方案探讨
- 移动 H5 首屏秒开优化方案探讨
- 移动 H5 首屏秒开优化方案探讨
- 移动直播技术优化-秒开及相关方案总结(干货)
- 锁-分布式锁2 Java非常用技术方案探讨之ZooKeeper
- 技术-技术方案优化策略--多线程与分布式
- H5移动前端性能优化
- 移动测试技术保护源代码!解码全球首款移动端白盒测试工具ThreadingTest (文章转自动点科技)
- 【技术原创】探讨一下京东商城价格图片解析算法的优化,附演示程序下载
- H5移动应用的发布优化(一)缓存优化
- 探讨高访问量网站优化方案(从图片角度)
- “信息防泄漏方案的选型与实施”技术探讨
- 基于ODS技术的政务信息系统方案探讨
- 秋色园QBlog技术原理解析:性能优化篇:数据库文章表分表及分库减压方案(十五)
- 探讨高访问量网站优化方案(从图片角度) 【转】
- 博客推广优化SEO排名方案大汇总!何必东奔西走这里的博客优化的文章应有尽有!!
- 本周ASP.NET英文技术文章推荐[很久以前 - 02/26]:Immutability、InterpolationMode、CompositingQuality、性能优化、单点登录、Spring.NET、Facebook、MySQL、Web Deployment Tool
- 移动直播技术秒开优化经验