

前端性能保障体系
source link: https://tech.kujiale.com/qian-duan-xing-neng-bao-zhang-ti-xi/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

酷家乐是全球领先的3D云设计平台,作为一款主打室内装修设计软件,面向家居、公装、建筑、房产等领域,为企业和个人提供设计、营销、生产、管理等一站式解决方案,致力于“用设计让未来生活所见即所得”。那么要支撑云设计工具用户体验丝般顺滑,快速渲染出效果图、全景图和720°漫游图,离不开端到端的性能保障体系的支撑,这边重点介绍一下酷家乐前端性能保障体系:从2022年H2开始,明确提出前端性能领域体系化建设思路,全方位覆盖以云设计工具为主,包含酷家乐、美间、Coohom国际站、模袋云为产品代表的端到端用户体验的标准化性能保障体系。

二、性能标准&流程规约
目前酷家乐主要是2套性能标准、1套线下性能卡口流程规约:
- web页面标准一套:主要是酷家乐网站、美间网站、国际站主站使用。《 W3C标准 》、《 Google Lighthouse性能体验标准 》
- web应用标准一套:
线上:主要是酷家乐工具、美间工具、国际站工具、模袋云工具为代表。《 云设计工具性能标准 》
线下:《 线下宽口径性能标准及卡口流程规约 》;
那么我们接下来了解一下相关性能标准。
W3C性能标准
W3C-window.performance是W3C提供的用来测量网页和Web应用程序的性能api

按图所示,window.performance就记录从用户在浏览器输入url开始到前端页面onload达到页面加载完成达到完全可交互状态,酷家乐当前各业务站点的网页性能也是结合W3C业界通用标准梳理出相关核心性能指标。
- TTI:time to interactive,可交互时间,测量页面从开始加载到主要资源完成渲染
- FMP:first meanning print,首次绘制有意义内容,当整体页面的布局和文字内容全部渲染完成后时间
- TTFB:页面首字节响应的时间,衡量服务端响应以及网络情况。
- FP:白屏,衡量用户白屏等待的情况。页面开始展示的时间点(domLoading)-开始请求时间点(navigationStart)
Goole Lighthouse性能体验标准

Google在2020年5 月5日提出了新的基于用户体验量化方式 Web Vitals 来衡量网站的用户体验来综合评估移动友好性、浏览安全性,以及Core Web Vitals 中关于加载性能、交互性、视觉稳定性等,而且google本身提供系列指标项,将这些衡量结果用作其排名算法的一部分,所以我们一般会使用google lighthouse的指标做行业的竞争性能的排行。为了更好地理解这些内容,让我们来看看这些重要指标是什么
- 加载性能(FCP指标)— 首次内容绘制
- 加载性能(LCP) — 最大内容绘制
- 交互性(TTI) — 持续可交互时间
- 视觉稳定性(CLS) — 累积布局配置偏移
- 渲染阻塞(TBT) — 总阻塞时间
目前这套标准部分指标,比如LCP(Largest Contentful Paint)用于衡量加载体验,从真实用户的角度衡量网页的加载速度,作为Coohom国际站主站线上很重要的一个性能指标。同时,网站线下性能自动化,也广泛地应用了这FCP、LCP、TTI、CLS、TBT进行web页面的线下性能自动化评判标准。那么怎么样算是优秀的,google通过给出一套标准的性能体验评级推荐。
例如,LCP耗时在2.5秒之内被认为当前页面处于性能优秀,LCP指标耗时在2.5秒和4秒内,性能有待提升,而大于4秒则属于性能较差


再比如,当某些时候网页中的元素在加载时出现移动,这不是用户期待的优秀体验。在这样的场景中,CLS(Cumulative Layout Shift)测量在页面的整个生命周期中发生的每个意外的样式移动的所有单独布局更改得分的总和,可以方便地用来度量 web 页面的视觉表现。布局的移动可能发生在可见元素从一帧到下一帧改变位置的任何时候。为了提供良好的用户体验,网站应努力使 CLS 分数小于 0.1
设计工具性能标准
作为酷家乐的主营业务,不可不提云设计工具,这套是公司自定义的性能标准。《 云设计工具性能标准 》 、《 线下宽口径性能卡口标准 》当前定义了非常详细的标准,主要分为加载类和消耗类两大类性能指标项,具体见下图:


其中难点在于卡顿类的指标,平均帧率和最长帧耗时、最长帧耗时之间的关系是怎么样的,可以从下面这部分内容了解
屏幕成像原理及卡顿原因
屏幕显示原理 屏幕会把像素点上,由左往右,完成第一行的像素扫描,然后等待水平同步信号的到来,电子枪会来到第二行的初始位置,这样由左往右,从上往下,逐行扫描,来到显示器的右下方,等待垂直同步信号(vertical synchronization)的到来。这样就完成第一帧画面的绘制,电子枪复位,回到左上角。上面第二张图,主要描述,计算机系统中CPU、GPU、显示器相关模块的协同工作。CPU 计算好显示内容提交到 GPU,GPU 渲染完成后将渲染结果放入帧缓冲区,随后视频控制器会按照 VSync 信号逐行读取帧缓冲区的数据,经过可能的数模转换传递给显示器显示。
屏幕卡顿 在 VSync 信号到来后,系统图形服务会通过 CADisplayLink 等机制通知 App,App 主线程开始在 CPU 中计算显示内容。随后 CPU 会将计算好的内容提交到 GPU 去,由 GPU 进行变换、合成、渲染。随后 GPU 会把渲染结果提交到帧缓冲区去,等待下一次 VSync 信号到来时显示到屏幕上。由于垂直同步的机制,如果在一个 VSync 时间内,CPU 或者 GPU 没有完成内容提交,则那一帧就会被丢弃,等待下一次机会再显示,而这时显示屏会保留之前的内容不变,中间这个等待的过程就造成了掉帧,也就是会卡顿。如图所示,是一个显示过程,第 1 帧在 VSync 到来前,处理完成,正常显示,第 2 帧在 VSync 到来后,仍在处理中,此时屏幕不刷新,依旧显示第 1 帧,此时就出现了掉帧情况,渲染时就会出现明显的卡顿现象

- 平均帧率(avgFps):连续操作的帧率,如拖动家具等连续操作过程中的帧率,平均帧率的标准40帧,满帧一般情况60帧,即每一帧16.67毫秒
- 稳定帧率(stableFps):当前工具稳定帧,是去除了前面3帧,最后3帧,剩下54帧的平静帧率
- 最大帧耗时(maxFrameDuration):除之后一帧之外的行为最大帧耗时,单位毫秒,当前最大帧上限标准300ms 丢帧卡顿感主要参考指标
- 最后帧耗时(lastFrameDuration):最后一帧耗时,单位毫秒,当前最后帧耗时上线标准300ms,为啥最后帧耗时作为单独指标,是因为当前酷家乐工具在尾帧的时有model层的数据提交,一般会比较卡,所以单独列出来进行性能度量,而美间工具会以设置首帧耗时,是因为首帧有一些耗时操作需要单独衡量。丢帧卡顿感主要参考指标
最长帧/最大帧耗时对屏幕是否卡顿进行辅助性能分析,大家看上图-卡顿掉帧原因,Vsync垂直同步信号发生的间隔为16.67毫秒,也就是一帧的耗时。蓝色CPU计算和红色GPU渲染并行处理时间如果在2次Vsync间隔时间也就是16.67毫秒内完成不了,那么这一帧就丢了,这种行为就像赶公交车,连续赶不上10趟公交车,那么总卡顿时长=16.67*10约为167ms,可能发生在中间就可能成为最大帧耗时,发生在最后就是最尾帧耗时。
性能卡口流程规约
参照云图发布流程 ,要求云图发布双周大版本实施性能卡口,卡口范围包含方案加载耗时、核心场景平均帧率/最长帧/最后帧&内存增长、包体积卡点,线下性能基线新老版本对比性能退化超5%卡住不予以发布。

测试owner在云图大版本迭代的前一周周三/周四/周五部署sit环境,当周周一/周二beta环境,进行性能自动化持续集成(定时任务不低于1小时/次,单日性能采样大于15次以上)。严重/大范围影响:方案加载耗时超20%;内存增长超10%(大范围表示核心场景超过50%及以上),不能走紧急报备,问题插件方排查修复后才能发布。局部/小范围影响:场景平均帧率/最大帧耗时/最大帧耗时超5%但小于10%局部场景、内存超5%局部场景,包体积:超5%短期不发修复,可走紧急发布邮件审批流程,限期整改修复上线。详见流程规约《 线下宽口径性能标准及卡口流程规约 》
性能卡口问题处理流程

三、性能体系优化方法&手段
性能监控度量分析体系
在整个性能保障体系中,性能度量及性能监控体系作为很重要的一环。通过监控发现问题,进行专项治理,结合性能标准等进行长效治理,做到性能长效保鲜防退化。同时结合线上/线下基线,结合业务关联特性,对监控体系的数据进行有效分析度量。
性能监控体系产品介绍
- tesseract数据小站:离线T+1数据,各个站点核心性能度量分析主要来自数据小站
- tetris:
- 监控告警数据:实时分钟级细分性能告警数据。
- 线下性能卡口性能基线看板,助力于线下性能卡口自动数据按照业务线维度展示。
- 用户行为分析(下钻):给到技术团队,以及技术支持团队,进行线上单点性能问题排查,用户性能行为回朔提供很好的数据分析支撑。
- 性能月报综合度量分析:形成闭环,通过性能月报定义反馈线上性能大盘水位线,持续跟进线上问题情况,同时核心业务增设线下性能准出,对比性能基线,长效保险防退化。






监控完善关键事件
国内酷家乐工具前端前端监控告警建设-2023H1经过2023上半年的工具前端告警监控事项的推进,目前已覆盖国内酷家乐工具前端整体性能及云图工具、户型、定制、硬装、渲染、BIM施工图、水电等主要插件方。
- 工具性能整体及各插件告警监控范围确认
- 数据小站(离线T+1)迁移tetris实时告警库、告警监控需求完善落地
- 性能告警实时大盘:灰度gray实时告警监控大盘、灰度+人群实时告警大盘建设
- 工具性能整体和各插件方制定性能故障等级定义,和告警监控项形成一一映射&咬合
国内酷家乐线下性能卡口性能看板建设-2023H1 为支撑国内酷家乐工具前端在2023年1月启动云图大版本性能卡口事项,各业务插件方逐步完善核心场景性能检查项,通过tetris看板持续关注大版本发布前的线下性能表现情况
用户行为回朔-2023H1
- 【监控产品功能完善】tetris用户行为回溯,增加过滤PC崩溃率,客户端崩溃率的日志,方便排查线上用户崩溃情况;
- 基于tetris用户行为回溯,完成排查工具分析,产出文档&宣导并提供技术支持日常使用
美间性能优化性能看板建设-2023H1 为支撑美间工具及美间平台,美间工具性能攻坚项目:美间工具性能瓶颈和低性能优化、美间工具操作性能优化、美间工具加载性能(图片性能优化)、渲染耗时长的页面数据和分析、慢渲染;平台侧性能优化项目:客户端内核升级、客户端监控SDK对接、全站webp支持(美间主站、插件、企业版)
国际站性能一期-2022H2 国际化性能专项一期,结合国际站前端性能基线,完善国际站前端线上性能分析度量体系、前端性能监控SDK、基线告警(分国家)、静态资源网络性能等基础建设

大场景专题
大场景性能benchmark思路
酷家乐发展至今,其实大场景性能前面已经做了3期( 2021年-工具大场景三期)了,架构为了适应业务快速增长不断垒叠本身已非常庞大负担不堪,本身所带来各种性能&用户体验问题,工具性能优化技术在当下已经进入性能深水区;那么随着我们的客户诉求提升,我们为了能支撑更大的面积,更复杂的模型,更流程的性能体验,于2022年底继续起航!
- 商业诉求聚焦商空办公行业:基于商空之前梳理的《 [2207]大场景需求描述 》逐个行业、案例分析讨论性能问题点,以及跟工具产品线的合作模式探讨。
- 工具性能各业务线大场景性能定义,阶段性找寻和商空办公行业商业诉求的match点,各业务线对齐大场景标准和定义后,针对商空办公行业,针对性提供几个典型方案,不同复杂度区间的方案,分别分析差距和缺口,时机合适立项优化。商空办公、全屋定制、云图工具平台启动P99大场景性能基线专项
- 震旦大场景性能优化项目:目前主要在支持震旦大场景的性能优化,具体见:《【震旦】性能&算量清单需求冲刺计划 》、《 施工图震旦项目仪表盘 》
- 性能极限探测:为了提升酷家乐设计工具的性能上限,目标支持一万平的设计方案,我们需要对云设计系统综合分析系统性问题对设计方案的性能极限探索所影响的点,并给出精细化的技术评估结论。《 云设计系统性能优化思路 》。第一轮:性能规模化问题分析:线上征集真实用户反馈的《 “崩溃/卡顿”问题跟进 》。第二轮:大场景(极限)复杂模型单一维度性能极限探测,不断地挑战技术能力上限。《 大场景性能极限探测 》
大场景性能自动化能力建设
大场景专题关键事项描述
线上P99大场景性能分析报告




大场景性能技术优化项

图片性能标准

图片优化技术
对于图片性能优化,目前最有效且高ROI的主要是图片的压缩策略,目前酷家乐主要的CDN厂商腾讯云提供了几种标准的图片压缩策略,接下来主要讲一下webp图片转化技术

图片压缩指在图片质量保持不变的情况,尽可能地减小图片大小,以达到节省图片存储空间、减少图片访问流量、提升图片访问速度的效果。对象存储(Cloud Object Storage,COS)基于 数据万象(Cloud Infinite,CI) 产品推出了 WebP 压缩功能,可将图片转换为 webp 压缩图片格式,其在压缩方面相比 jpg 格式更优越。在相同图片质量的情况下,webp 格式图片要比 jpg 格式图片减小25%以上,可以适配多终端使用场景。那么webp图片转化策略,是通过支持将 jpg、png、bmp、gif、tpg、heif、avif 等格式图片转换为 webp 格式,从美间及酷家乐实测《 图片webp格式转化实测记录 》,对于png图片转webp压缩比在75%以上,jps图片转webp压测在25%以上。
图片优化效果
美间《 工具教程图片webp优化项目 》图片优化效果非常好,不仅是美间工具这边的教程图片,还是gif教程动图等,结果来看体积优化和耗时优化可以说都到了极限(比如之前图片性能优化webp75%,还实际提升了不少)



图片专题相关事项介绍图片问题跟进

图片监控完善

美间图片优化项目
酷家乐线下性能基建能力建设
性能自动化能力基础
从2023H1酷家乐国内工具开始对云图发布双周大版本实施线下性能卡口,为了能具备性能高度自动化持续集成能力,且覆盖核心业务线场景诸多性能指标项,在大版本发布前3天做到性能问题发现,有效拦截,定位并修复上线,给云图各业务插件提出非常高的要求和挑战。
应对挑战关键事项
提升业务线核心场景覆盖密度 覆盖密度从最开始不足20-30% ——> 95%性能自动化脚本能力提升 性能指标原理解读↑ && 编写技巧提升↑ && 性能公共方法API丰富↑性能自动化环境问题解决 工具半年累计持续集成 3万+ 次 && 发现问题 33+ && 不断总结积累↑








其他端到端性能优化技术介绍
前端性能优化总体策略:空间换时间,异步化,并行

如上图所示,从最开始容器初始化之后,把load JS、JS Parse&Run、请求发送之前都是串行的独立任务统一并行提前到初始化后,缩短整体端到端耗时,同时对页面dom节点数进行优化减小,同时对JS包体积进行瘦身也很关键,以及对JS包的提前预加载来缩减其downLoad耗时,这样提前自动更新,推送到用户本地侧,对页面性能加载优化提升起到了明显的效果。
SW缓存机制(Service worker)
Service Worker是运行在浏览器背后的一个脚本,可以使网页具备离线访问、推送通知和缓存数据等能力。其中,Service Worker的缓存机制是其重要功能之一。Service Worker缓存机制允许开发人员将资源(如HTML文件、CSS样式表、JavaScript脚本和图像等)存储在客户端,而无需每次请求都从服务器获取。这提供了更快的加载速度和离线访问功能。它有两重意义:1、JS资源在页面打开前就预先下载好,降低js下载时间;2、让JS到machine code的compile结果可以被缓存,从而降低js编译时间。
预加载(Prefatch)
在页面加载生命周期,把相关资源提前发起,同时利用浏览器的空闲时间进行异步任务,当前要保证几点:
- 不能阻塞主线程:即使开始prefetch的时刻浏览器是idle的,prefetch过程中涉及到的parse等计算,可能会占用比较长的CPU时间,在此过程中如果用户进行了交互,会感受到卡顿
- 不能占用太多内存:prefetch的数据和代码默认留在了内存中,如果占用内存过大,会增加程序整体OOM的崩溃风险
- 不能占用太多带宽:避免挤占带宽,导致其他正在使用的功能loading时间过长
懒加载(lazyLoad)

JS包体积瘦身
JS包体积,目前主要指云图yunDesign工具、BIM工具应用层代码包体积。其JS包代码体积大小和空方案/非方案加载有正相关性。在2022H2《 云图加载性能优化及包体积瘦身项目 》对于云图应用的代码体积包大小进行优化完成30%的瘦身。到2023年5月,云图和bim工具包体积持续下降创新低,云图包体积70多m接近80m左右,那会儿云图空方案12秒,最近云图总体积接近60m(瘦包26-28%左右),空方案耗时8.5秒(28%)


项目优化成果保鲜持续防范挑战大,这是一个长期过程,还好从2023年开始云图发布大版本实施包体积大小性能卡口,从根本抑制了对云图&BIM工具整体及各插件微应用细分包大小随着不断的需求发布导致JS体积增长,效果非常明显
酷品秀端到端性能优化
- SDK包下载耗时任务优化,->预加载
- 连接耗时优化(DNS查询+TCP+SSL)
- 页面渐进式加载体验优化:loading蒙层->页面骨架图秒开
- 参数化模型接口优化
- 架构设想→业务侧增加一层服务编排层
四、未来展望酷家乐是以分布式并行计算和多媒体数据挖掘为技术核心,推出的家居云设计平台,致力于云渲染、云设计、BIM、VR、AR、AI等技术的研发,实现“所见即所得”体验,5分钟生成装修方案,10秒生成效果图,一键生成VR方案,极大提升行业整体效率。作为“设计入口”,酷家乐致力于打造一个连接全球设计师、家居品牌商、装修公司以及业主的强生态平台,实现全人类的“所见即所得”体验。
正如酷家乐员工手册中映入眼帘的第一句话,我们在这条道路上始终坚信,并持之以恒......
重云端 利用云的CPU/GPU,将云端海量的运算及渲染能力发挥到极致,充分利用云端的资源,未来我们所有的产品设计理念及技术改造思路一定秉持这个理念继续前行。除了之前大量的篇幅介绍了前端性能之外,未来我们也会重点持续对应用集群的综合性能更清晰的去衡量和要求,作为稳定性&性能非常重要组成部分,整体的内存(频繁导致GC、OOM、内存异步化消峰)、方案大对象、长生命周期对象、是否支持分布式处理,计算维护:CPU飙高、请求维度:大量的请求出现流量尖峰(读写放大、负载不均衡、无线轮询、不合理不必要的请求)、任务积压、实例负载飙高等,配合长期的稳定性&性能专项保障及预案专项治理。
更大更复杂 未来,我们要实现1万平,甚至去探索10万平,支持更大更复杂的方案,更好的服务商业空间,商超,办公行业,室外建筑等大型生态行业客户。整体的架构为支持这个目标需要不断的迭代和革新,性能在此启动关键作用,作为评判用户交互体验的准绳。
国际化 驰骋在全球化的海洋中,做深做广,拥抱全人类。目标是宏远的,要做到此,未来还有很多事情需要去做,酷家乐当前的架构绝大部分还是以国内机房为主,升级改造衍生为国际化架构,解决跨国机房所有服务海外对等部署,全方位打造并逐步升级为跨国多机房标准模式,和海外云服务商共同合作,完善全球化网络拓扑节点,和国家POP边缘节点加速策略,以提升并有效适配海外不同国家和地区,努力打造访问酷家乐就如同访问本国本地机房的丝般顺滑的性能体感。
更智能 随着AI、AR等技术的飞度发展,酷家乐也会拥抱和全面迎接AI时代的到来。
~~未来所见即所得~~
</div
Recommend
-
15
Nodejs 线上服务稳定性保障体系小芋头君前端职业咨询加微信 yutou-963PS...
-
6
有赞搜索中台的前身是ES中间件,并没有一个中台的概念,相应的就会有一个问题,业务接入搜索场景的时候还需要为此投入开发资源同步搜索设计,一个需求上线往往耗时很久,重复性工作较多,所以就有了后来的搜索中台的成立,将搜索完整链路的复杂性折叠成一个简单...
-
6
摘要:本文整理自快手实时计算数据团队技术专家李天朔在 Flink Forward Asia 2021 实时数仓专场的演讲。主要内容包括:业务特点及实时数仓保障痛点快手实时数仓保障体系架构春节活动实时保障实践未来规划
-
11
正值秋招季,找工作的热度居高不下。公司鱼龙混杂,不仅求职者需要擦亮双眼,小心谨慎才不会踏进招聘陷阱,更需要招聘平台做好求职保障。本文作者复盘了赶集求职守护计划,讨论如何建立一个完整的保障设计体系,希望对你有帮助。
-
4
保障设计体系APP建立过程 10月 1, 2022 发表于: 用户体验. 评论...
-
5
从定标准到搭流程,看UWA性能保障体系搭建的实例分享 本次分享选自UWA DAY 2022 “UWA性能保障体系进一步拓展”议题,来自侑虎科技CTO张强...
-
9
浅谈大数据背景下数据库安全保障体系 2022-12-16 09:39:43 在大数据背景下,数据库的安全保障管理更加复杂,为了能够更好地适应数据库管理要求,相关人员要充分发挥大数据技术优势。
-
4
导读 本文将分享有数 BI 性能保障体系的建设与实践。 主要分为以下 4 个部分: 有数 BI 产品的介绍 企业高并发报表访问性能挑战 有数 BI 性能体系建设与实践...
-
6
WiFi万能钥匙建立“生态型网络安全”体系保障用网安全-品玩
-
9
本次分享将从酷家乐面临的稳定性问题和挑战,在稳定性保障上的工作思路,建设实践,保障体系,价值经验等几个方面,与大家一起分享交流。稳定性工作是一个非常复杂的工作,希望通过这次分享交流,我们可以一起持续探索这个领域的最佳实践。
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK