单页式应用性能优化-首屏数据渐进式预加载

1顶
0踩

2017-04-26 10:10 by 副主编 jihong10102006 评论(1) 有12969人浏览

HTML 性能优化

前言
针对首页和部分页面打开速度慢的问题，我们开始对单页式应用性能进行优化。本文介绍其中一个方案：基于 HTTP Chunk 的首屏数据渐进式预加载方案，该方案总体减少了单页应用1.2s的首屏呈现时间。同时对比其与同构渲染方案的异同。

背景介绍
单页式应用是近几年来前端技术栈发展与落地的最典型场景，Angular、Vue、React等，这些相关的技术栈目的都是从架构层面为单页式应用提供研发解决方案，着重解决单页式应用的研发效率。基础框架的进化也催生着关联工具链路的发展，如 Yeoman，Grunt -> Gulp -> 各种 cli，Webpack1/2, Babel 等。

随着研发链路体系的稳定成熟，在功能上能够及时满足用户后，我们开始将精力集中关注产品的可用性层面。经过和产品，运营，用研等多个团队配合，我们走访了多位使用我们产品的用户，产出了一份流量端产品可用性得报告。除了部分交互和产品流程设计上的问题，另一个主要问题就是用户反馈整体的系统流畅性不错，但首页和部分页面打开极其慢，针对这块问题，我们开始了对单页式应用性能优化的探索和实践。

本文接下来将一步一步阐述对应用首屏呈现中各个节点的拆解，并根据拆解的节点推导出我的优化思路，最终为大家介绍我提出并尝试的第一个性能优化方案： 首屏数据渐进式预加载。

首屏呈现节点分析
在进行任何的性能优化之前，我们都应该先找出系统的性能瓶颈点，从而找出最有价值的优化方向。

绝大多数的单页式应用都符合 Application Shell 架构，根据这个架构我们可以看出一个应用首屏呈现节点可以分解为：请求入口页 -> 渲染应用外壳 -> 渲染首屏片段。我在此基础上进一步将三个节点细分如下：

即对渲染应用外壳和渲染片段这块细分为：应用资源加载，应用初始化，片段资源加载，片段初始化，片段数据加载，片段渲染这些节点。

有了这些细分节点，再将埋点记录的真实用户数据代入：

得出我们的首屏时间为：

T(s) = T1 + ... + T7 = 2800ms

注：我们一般都将首屏资源一起与应用资源打包在一起，因此这里耗时认为是0。

整个 timeline 如下：

首屏数据渐进式预加载方案
根据上面的节点数据，首屏数据渐进式预加载的优化思路也得到了体现：

优化首屏数据加载节点的速度。
预先加载首屏数据，使得多个串行节点并行化。

接下来详细介绍我们的优化步骤。第1点会在第一步优化中体现，但核心思路和主要优化收益更多体现在第2点：多个串行节点并行化。

Step1：资源文件下载与首屏数据请求节点并行

为了达到资源下载与数据请求并行的效果，我们充分利用了HTTP Chunk 传输与浏览器的渐进式渲染特性：
1、将入口页分为静态片段和数据片段：静态片段包含了各个资源标签（script,link），静态的导航栏，加载指示器等；数据片段则是包含首屏数据的内联脚本，大至如下：

<script>window.__APP_DATA__ = { /* 相关的首屏数据 */ };</script>

2、浏览器请求入口页时，入口页服务器(这里我们用了 NodeJS ) 并行做以下操作：

HTTP Chunk 方式输出静态片段
请求首屏数据并在所有数据请求完成后将数据片段和应用初始化代码返回给浏览器。

注：http chunk 方式输出在 NodeJS 中及其容易满足，简单的 res.write(chunk) 即可。

整体架构如下：

浏览器的渐进式渲染特性在收到静态片段并解析后立刻去下载资源，由此巧妙的将应用资源加载节点和首屏数据请求节点并行化；当应用初始化完毕后，首屏组件直接读取window.__APP_DATA__拿到数据渲染即可。

整个首屏呈现 timeline 变化如下：

最终并行化这块耗时为：Max(下载资源文件，请求首屏数据输出片段) = 1000ms。
根据变化后的节点我们算出首屏呈现时间为：2350ms。

首屏呈现耗时的通用计算公式变为：

下载静态片段 + Max(下载资源文件，请求首屏数据) + 应用初始化 + 首屏初始化 + 首屏渲染

Step2：应用初始化，资源文件下载，首屏数据请求节点并行

在 Step1 的基础上继续分析，应用初始化节点耗时也很明显，同时该节点要进行必须等待资源文件下载完毕，但理论上可以不依赖我们的首屏数据，还是可以让其和首屏数据请求并行。

这里我们无法在 Step1 方案上直接将应用初始化和数据请求并行化，主要原因在于当首屏数据请求时间大于资源加载+应用初始化完成时间时，应用会在没有数据的情况下进入收入首屏渲染节点，从而导致异常。

解决方案是将数据片段的输出变成 promise 片段：
1、pending promise 片段，与静态片段一起输出，大概如下：

    <script>
    window.__APP_DATA__ = {
     RESOLVERS: {}
     userInfo: new Promise((resolve, reject) => {
       // 超时认为失败
       let timer = setTimeout(reject.bind(null, {message: 'timeout'}), 12000);
       window.__APP_DATA__.userInfo = (err, data) => {
         clearTimeout(timer);
         err ? reject(err) : resolve(data)
       }
     })
    };
    </script>

2、resolve promise 片段，该片段在数据请求成功返回后输出，大概如下：

<script>window.__APP_DATA__.RESOLVERS.userInfo(null, data); </script>

3、reject promise 片段，该片段在数据请求失败后输出，大概如下：

<script>window.__APP_DATA__.RESOLVERS.userInfo(error); </script>

即此时应用初始化完毕后可以无视首屏数据的完成度，直接进入首屏渲染节点，组件在数据 promise 被 resolve 后渲染即可：window.__APP_DATA__.userInfo.then(data => component.render());

通过对数据片段的promise化改造，使得应用初始化节点也加入了并行队列。

整个首屏呈现 timeline 变化如下：

根据变化后的节点我们得到首屏呈现时间为：1800ms

首屏呈现耗时的通用计算公式变为：

下载静态片段 + Max(下载资源文件 + 应用初始化，请求首屏数据) + 首屏初始化 + 首屏渲染

优化小结

经过上述2个步骤改进，我们应用首屏呈现时间从 2800ms -> 2350ms -> 1800ms，总体效果约为36%，可以看到是收益还是很可观的。

在实际项目中耗时是在1600ms左右，比1800ms还要小，主要原因如下：

用户在请求入口页中半个RTT时间，服务器就开始了数据请求。
数据请求在服务端进行减少了浏览器与服务端的请求创建开销，同时数据请求在内网进行，总体调用速度也会加快。

当首屏数据请求数超过浏览器并发请求数时，该方案收益会更明显，因为 NodeJS 端没有并发限制，甚至在NodeJS端与后端服务的交互中可以采用更高效的协议如HTTP2来提高调用速度。

与服务端同构渲染对比
看到这里，相信很多人会问，为啥不用服务端渲染直出HTML呢，或者和服务端渲染方案相比有何优势？

事实上，一开始我和大多数人想到的优化方案就是服务端渲染，但真正的障碍在于服务端渲染依赖视图层框架的支持，而我们的项目历史悠久，视图层框架并不支持这一点，为了优化而丧失产品的稳定性得不偿失。

当然，在另辟蹊径使用了数据渐进式预加载方案后，我总结该方案与与服务端同构渲染对比如下。

优势

对客户端代码来说数据渐进式预加载方案实现成本非常简单，基本可以做到透明化，我们在实际的开发过程中采用基于 uIoC（ecomfe/uioc ）提供的AOP拦截方案，通过配置化的方式让客户端的代码改造仅局限在配置文件，应用代码基本未改动。
对NodeJS端来说，分层合理的应用只需要将数据层简单适配下 NodeJS 端即可完成数据渐进式预加载，这对底层基础框架在视图层没有支持同构的应用来说，整个改造成本可以说大大减小，且收益明显。我们目前的应用基于自有的一套MVC框架，仅仅是将 Model 层简单适配 NodeJS 端执行输出数据。
服务端渲染方案如果未能提供较基于 BigPipe 的渲染，总体的页面呈现速度还是不如数据渐进式预加载的，且目前我也暂时还没有在三大框架中发现有一套基于BigPipe的服务端渲染方案。

不足
整体呈现速度可能不如结合了BigPipe的服务端渲染方案，但这点没有经过论证，毕竟数据渐进式预加载与服务端同构渲染的区别仅仅在于渲染环节放在客户端还是服务端：渲染看的是CPU，服务端的CPU资源是有限的，要服务诸多请求，而客户端渲染则基本无此压力，渲染能力未必弱于服务端。

总结
我们在单页应用的性能优化上基于很朴素的并行化理念实施了首屏数据渐进式预加载方案，在实际项目中也得到了较为明显的效果，减少了1.2s的加载时间，整体的节点变化如下：

优化前：

优化后：

最终数据渐进式预加载方案的首屏呈现时间计算公式为：

下载静态片段 + Max(应用资源加载 + 应用初始化，请求首屏数据) + 首屏初始化 + 首屏渲染

这里忽略了影响很小的片段传输时间，有打算尝试的朋友可以将自己应用的相关节点数据代入计算即可。

数据渐进式预加载，服务端同构渲染，客户端渲染三种方案各有优缺和场景，个人未来计划是将三种方案结合实时流量数据动态切换：在服务器压力不大时用同构渲染；服务器压力较大时用数据预加载；服务器压力很大时用客户端渲染。

查看图片附件

来自: zhihu

分享到：

1
顶

0
踩

评论共 1 条请登录后发表评论

1 楼 imtpcf 2017-07-03 11:25

文章写得很好，有帮助。

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

百度SSP单页式应用性能优化实践

本文将介绍其中一个性能优化方案：基于HTTPChunk的首屏数据渐进式预加载方案，该方案减少了1.2s的加载时间。同时对比其与同构渲染方案的异同。单页式应用是近几年来前端技术栈发展与落地的最典型场景，Angular、Vue...

angular 首屏加载优化_单页式应用性能优化-首屏数据渐进式预加载

本文介绍其中一个方案：基于 HTTP Chunk 的首屏数据渐进式预加载方案，该方案总体减少了单页应用1.2s的首屏呈现时间。同时对比其与同构渲染方案的异同。注：原文为百度SSP单页式应用性能优化实践，专栏这里以稍微...

【 Vue3 性能优化】页面加载性能与更新性能

Vue 在大多数常见场景下性能都是很优秀的，通常不需要手动优化。然而，总会有一些具有挑战性的场景需要进行针对性的微调。

使用 React.js 的渐进式 Web 应用程序：第 2 部分 - 页面加载性能

系列第二篇，来看看基于 React 路由分块的页面加载优化。原文地址：Progressive Web Apps with React.js: Part 2 — Page Load Performance 原文作者：Addy Osmani ...使用 React.js 的渐进式 Web 应用程序...

谈谈前端性能优化-面试版

当我们去面试的时候，很大概率会被面试官问这么一个问题：你有尝试过对项目做性能优化吗？或者你了解哪些性能优化的方法？听到这个问题的你可能是这样的：似曾相识但又说不清楚，往往只能零散地说出那么几点，难以...

Vue -渐进式JavaScript框架

介绍vue 中文网vue githubVue.js 是一套构建用户界面(UI)的渐进式JavaScript框架库和框架的区别我们所说的前端框架与库的区别？Library库，本质上是一些函数的集合。每次调用函数，实现一个特定的功能，接着把控制权...

首屏渐进式渲染设想

这篇文章是关于 HTML 渲染的首屏优化的,主要是针对 web app 这种相对交互较多的应用场景,首屏优化主要为了改善用户对于页面的感知,而服务端渲染(SSR)是 web app 优化首屏依赖的重要手段. 昨晚录了视频, 解释了一遍, ...

前端性能优化总结

前端框架/架构，性能优化，负载均衡，首屏渲染

前端数据结构与算法- https://zhuanlan.zhihu.com/p/27659059&gt; 前端重构方案前端重构方案了解一下- https://blog.csdn.net/vM199zkg3Y7150u5/article/details/80681697 webApp重构之路——性能和用户体验...

前端项目性能优化（全面解析）

基于HAR存储于重建性能信息重要测量指标速度指数（Speed Index）4秒 TTFB 衡量请求到响应一共多少时间页面加载时间，页面加载完一共要用多久首次渲染不能一直是白屏，然后在后来的某一刻突然都出来，要给用户一...

Vue -渐进式 JavaScript 框架

Vue -渐进式 JavaScript 框架介绍官网 github Vue.js 是一套构建用户界面(UI)的渐进式 JavaScript 框架库和框架的区别库: ?&gt; 库，本质上是一些函数的集合。每次调用函数，实现一个特定的功能，...

vue 判断页面加载完成_使用Vue做 SPA应用的思考及总结

SPA应用也是我的知识复盘计划的组成部分。笔者亲身经历客户端和服务端技术变革，在以前没有所谓的前端开发概念，有些系统页面由网页设计师做好静态页面交给后端工程师的一并完成的，服务端渲染是主要的数据传递方式...

聊一聊前端性能优化

性能优化，每个工程师跑不掉的一个话题。这里是本人结合Mr.Max的一门课，总结的一些优化手法，希望对大家有所帮助，后续也会继续更新，想要看视频的可以直接去某课网搜。附演示源码和PPT...

单页面应用首屏时间慢问题解决方法

路由的懒加载加一个首屏loading图或骨架屏，提高用户的体验尽可能使用CSS Sprites和字体图标库图片的懒加载将公用的JS库通过script标签... 首屏数据渐进式预加载 https://zhuanlan.zhihu.com/p/26543645 ...

东营市乡镇边界，矢量边界，shp格式

矢量边界，行政区域边界，精确到乡镇街道，可直接导入arcgis使用

Java SSM 商户管理系统客户管理库存管理销售报表项目源码本商品卖的是源码，合适的地方.zip

毕业设计

075.JSP+SQL宿舍管理系统.zip

毕业设计

经验贝叶斯EB的简单例子

69页-智慧园区综合管理平台解决方案.pdf

智慧园区，作为现代城市发展的新形态，旨在通过高度集成的信息化系统，实现园区的智能化管理与服务。该方案提出，利用智能手环、定制APP、园区管理系统及物联网技术，将园区的各类设施与设备紧密相连，形成一个高效、便捷、安全的智能网络。从智慧社区到智慧酒店，从智慧景区到智慧康养，再到智慧生态，五大应用板块覆盖了园区的每一个角落，为居民、游客及工作人员提供了全方位、个性化的服务体验。例如，智能手环不仅能实现定位、支付、求助等功能，还能监测用户健康状况，让科技真正服务于生活。而智慧景区的建设，更是通过大数据分析、智能票务、电子围栏等先进技术，提升了游客的游玩体验，确保了景区的安全有序。尤为值得一提的是，方案中的智慧康养服务，展现了科技对人文关怀的深刻体现。通过智慧手环与传感器，自动感知老人身体状态，及时通知家属或医疗机构，有效解决了“空巢老人”的照护难题。同时，智慧生态管理系统的应用，实现了对大气、水、植被等环境要素的实时监测与智能调控，为园区的绿色发展提供了有力保障。此外，方案还提出了建立全域旅游营销平台，整合区域旅游资源，推动旅游业与其他产业的深度融合，为区域经济的转型升级注入了新的活力。总而言之，这份智慧园区建设方案以其前瞻性的理念、创新性的技术和人性化的服务设计，为我们展示了一个充满智慧与活力的未来园区图景。它不仅提升了园区的运营效率和服务质量，更让科技真正融入了人们的生活，带来了前所未有的便捷与舒适。对于正在规划或实施智慧园区建设的决策者而言，这份方案无疑提供了一份宝贵的参考与启示，激发了他们对于未来智慧生活的无限遐想与憧憬。

数学建模相关主题资源2

1顶0踩