移动H5首屏秒开优化方案探讨

  • 时间:
  • 浏览:4

无论是 iOS 还是 Android,本地 webview 初始化都在不少时间,可不没办法 预先初始化好 webview。这里分类似于 预加载:

最后

使用客户端接口

到这里,对于使用 H5 开发功能模块,离线包是一另一一三个挺不错的方案了,简单复述一下离线包的方案:

过程

现象报告

上述打开一另一一三个页面的过程有什么都有优化点,包括前端和客户端,常规的前端和后端的性能优化在桌面时代之前 有最佳实践,主要的是:

更多优化

另外上述讨论的是针对功能模块类的 H5 页面秒开的优化方案,客户端 APP 上除了功能模块,其他其他像营销活动/内部接入的 H5 页面之前 其他优化点就不适用,还没办法 视实际清况 和需求而定。另外微信小进程什么都 属于功能模块的类别,差越多是类似于 套路。

上边的正确处理方案实现起来十分繁琐,原困分析什么都 各个 HTML 和资源文件什么都有很分散,管理困难,有个较好的方案可不没办法 正确处理哪些地方地方现象报告 ,什么都 离线包。

离线包方案在缓存上之前 做得差越多了,还可不没办法 再配上其他细节优化:

Fallback

接着轮到客户端出场了,桌面时代受限于浏览器,H5 页面无法做更多的优化,现在 H5 页面是内嵌在客户端 APP 上,客户端有更多的权限,于是客户端上可不没办法 超出浏览器的范围,做更多的优化。

具体实现上,首先可不没办法 在配置表注明某个离线包没办法 预加载的 URL,客户端在 webview 初始化同時 发起请求,请求由一另一一三个管理器管理,请求完成时缓存结果,什么都 webview 在初始化完毕后结速了了了请求刚才预加载的 URL,客户端拦截到请求,转接到刚才提到的请求管理器,若预加载已完成就直接返回内容,若未完成则等待。

服务端渲染

优化最好的办法可不没办法 是人为减少 JS 渲染逻辑,也可不没办法 是更彻底地,回归到原始,所有内容都由服务端返回的 HTML 决定,越多等待 JS 逻辑,称之为服务端渲染。有无做类似于 优化视业务清况 而定,毕竟类似于 会带来开发模式变化/流量增大/服务端开销增大哪些地方地方负面影响。手Q的帕累托图页面什么都 使用服务端渲染的最好的办法,称为动态直出,见 文章 。

随着移动设备性能不断增强,web 页面的性能体验逐渐变得可不没办法 接受,又之前 web 开发模式的诸多好处(跨平台,动态更新,减体积,无限扩展),APP 客户端里老出越多内嵌 web 页面(为了配上当前流行的说法,以下把所有网页都称为 H5 页面,固然之前 跟 H5 没关系),什么都有 APP 把其他功能模块改成用 H5 实现。

预加载数据

每个包都会使用相同的 JS 框架和 CSS 全局样式,哪些地方地方资源重复在每一另一一三个离线包老出太浪费,可不没办法 做一另一一三个公共资源包提供哪些地方地方全局文件。

先接着缓存说,在客户端有更自由的缓存策略,客户端可不没办法 拦截 H5 页面的所有请求,由个人管理缓存,针对上述 HTML 文件的“缓存”和“更新”之间的矛盾,我们都歌词 歌词 可不没办法 用没办法 的策略正确处理:

固然说 H5 页面性能变好了,但之前 没针对性地做其他优化,体验还是很糟糕的,主要两帕累托图体验:

json 数据的缓存可不没办法 用 localStorage 缓存请求下来的数据,可不没办法 在首次显示时先用本地数据,再请求更新,这都由前端 JS 控制。

哪些地方地方现象报告 在客户端上都在可不没办法 被正确处理的,只不过不得劲麻烦,简单描述下:

既然什么都有现象报告 都在文件分散管理困难引起,而我们都歌词 歌词 这里的使用场景是使用 H5 开发功能模块,那很容易想到把一另一一三个个功能模块的所有相关页面和资源打包分发,类似于 压缩包可不没办法 称为功能模块的离线包。使用离线包的方案,可不没办法 相对较简单地正确处理上述十几个 现象报告 :

没办法 看起来之前 比较完美了,HTML 文件在用客户端的策略缓存,其余资源和数据沿用上述前端的缓存最好的办法,没办法 一另一一三个 H5 页面第二次访问从 HTML 到 JS/CSS/Image 资源,再到数据,都可不没办法 直接从本地读取,越多等待网络请求,同時 又能保持尽之前 的实时更新,正确处理了缓存现象报告 ,大大提升 H5 页面首屏启动下行波特率 。

没办法 端优化,到客户端缓存,到离线包,到更多的细节优化,做到上述哪些地方地方点,H5 页面在启动上差越多可不没办法 媲美原生的体验了。

早期 web 页面里,JS 什么都 负责交互,所有内容都在直接在 HTML 里,到现代 H5 页面,什么都有内容之前 依赖 JS 逻辑去决定渲染哪些地方,类似于等待 JS 请求 JSON 数据,再拼接成 HTML 生成 DOM 渲染到页面上,于是页面的渲染展现就要等待类似于 整个过程,这里一另一一三个耗时,减少这里的耗时也是白屏优化的范围之内。

哪些地方地方缓存策略可不没办法 实现 JS/CSS 等资源文件以及用户数据的缓存的全缓存,可不没办法 做到每次都直接使用本地缓存数据,越多等待网络请求。但 HTML 文件的缓存做没办法 ,对于 HTML 文件,之前 把 Expires / max-age 时间设长了,长时间只使用本地缓存,那更新就不及时,之前 设短了,每次打开页面都在发网络请求询问是有无更新,再取舍有无使用本地资源,一般前端在这里的策略是每次都请求,这在弱网清况 下用户感受到的白屏时间仍然会很长。什么都有 HTML 文件的“缓存”和跟“更新”间居于矛盾。

HTML 缓存

上述几种方案策略也可不没办法 混着使用,看业务需求。

网路和存储接口之前 使用 webkit 的 ajax 和 localStorage 会有不少限制,难以优化,可不没办法 在客户端提供哪些地方地方接口给 JS,客户端可不没办法 在网络请求上做像 DNS 预解析/IP直连/长连接/并行请求等更细致的优化,存储也使用客户端接口也能做读写并发/用户隔离等针对性优化。

公共资源包

这里讨论了 H5 页面首屏启动时间的优化,上述优化之前 ,基本上耗时只剩 webview 类似于 的启动/渲染机制现象报告 了,类似于 现象报告 跟后续的响应流畅度的现象报告 同時 属于没办法 优化范围,什么都 类 RN / Weex 没办法 的方案,有之前 再探讨。

其中对首屏启动下行波特率 影响最大的什么都 网络请求,什么都有优化的重点什么都 缓存,这里着重说一下前端对请求的缓存策略。我们都歌词 歌词 再细分一下,分成 HTML 的缓存,JS/CSS/image 资源的缓存,以及 json 数据的缓存。

HTML 和 JS/CSS/image 资源都属于静态文件,HTTP 类似于 提供了缓存协议,浏览器实现了哪些地方地方协议,可不没办法 做到静态文件的缓存,具体可不没办法 参考 这里 ,总的来说,什么都 类似于 缓存:

预加载 webview

为哪些地方打开一另一一三个 H5 页面会有一长段白屏时间?之前 它做了什么都有事情,大约是:

理想清况 下离线包的方案第一次打开时所有 HTML/JS/CSS 都使用本地缓存,越多等待网络请求,但页面上的用户数据还是没办法 实时拉,这里可不没办法 做个优化,在 webview 初始化的同時 并行去请求数据,webview 初始化是没办法 其他时间的,这段时间没办法 任何网络请求,在类似于 时机并行请求可不没办法 节省不少时间。

本文先不讨论第二点,只讨论第其他,如何减少白屏时间。对 APP 里的其他使用 H5 实现的功能模块,如何加快它们的启动下行波特率 ,让它们启动的体验接近原生。

客户端优化

总结起来,大体优化思路什么都 :缓存/预加载/并行,缓存一切网络请求,尽量在用户打开之前 就加载好所有内容,能并行做的事不串行做。这里其他优化手段没办法 做好一整套工具和流程支持,没办法 跟开发下行波特率 权衡,视实际需求优化。

前端优化

离线包

前端能做的最大限度的缓存策略是:HTML 文件每次都向服务器询问是有无更新,JS/CSS/Image资源文件则不请求更新,直接使用本地缓存。那 JS/CSS 资源文件如何更新?常见做法是在在构建过程中给每个资源文件一另一一三个版本号或hash值,若资源文件有更新,版本号和 hash 值变化,类似于 资源请求的 URL 就变化了,同時 对应的 HTML 页面更新,变成请求新的资源URL,资源也就更新了。

之前 用户访问某个离线包模块时,类似于 离线包还没办法 下载,或配置表检测到已有新版本但本地是旧版本的清况 如何正确处理?几种方案:

上述方案似乎已删剪正确处理缓存现象报告 ,但实际上还有什么都有现象报告 :