首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >双11主会场性能体验提升 - 秒开优化

双11主会场性能体验提升 - 秒开优化

作者头像
前端黑板报
发布于 2020-12-10 02:20:52
发布于 2020-12-10 02:20:52
2.4K0
举报
文章被收录于专栏:前端黑板报前端黑板报

NO.1

背景

会场作为承载天猫、淘宝等系列大促的重要载体。面对亿万的消费者,会场的性能体验直接影响消费者的购物体验。

会场性能优化专项小组联合了客户端基础团队、容器团队、前端团队、数据分析团队、测试团队等多个团队,跨栈协同共同努力,在性能优化方向上也做了不少的优化工作。梳理了全链路性能埋点、定义新的性能口径(从用户点击到可视),使用了预渲染、数据预请求、资源加速下载、离线资源等优化手段,既能全链路的维度来度量,也能拆分到各个子阶段细粒度的数据。

这些性能优化手段,经过了618、双11等大促场景的实践检验。用户打开会场的整体平均耗时缩短了200ms~700ms左右,秒开率提升10%~14%。优化对中低端机绝对收益更高,已实现在低端机上实现秒开会场。在中低端机和高端机上优化前后的对比效果。

Android y67 优化前 Android y67 优化后

iPhone 7P 优化前 iPhone 7P 优化后

iPhone12 优化前 iPhone 12 优化后

本文将从客户端和前端两个方向分别展开讲述优化过程中实践与思考。

NO.2

变化与挑战

统计口径

往年会场性能指标通常是指前端部分的耗时。客户端容器和前端是分开统计各自只负责自己的部分,没有整体串联起来,无法真实反映用户的体感。新的变化是从用户的体感出发,全链路的视角来看体验。使用全新的可视时间的口径,即从用户点击到看到页面内容的展示。新挑战要将各部分数据的口径统一和信息整合。

性能目标

相信很多人对一秒法则有所了解,指的是在WIFI或4G的网络下,一秒内能够完成首个页面的渲染。对于会场业务来说,新的性能目标,希望用户在一秒钟能够展示会场的首屏内容,提升这部分用户的比例让更多的人能在一秒钟内打开会场。以往多关注的前端阶段性能,新挑战要包含客户端、WebView、前端页面渲染多个阶段,要在一秒内展现,挑战更大。

NO.3

解决方案与分析实践

针对上面提到的两个变化与挑战。首先我们需要梳理在新的统计口径下,用户点击到页面展示,经历了哪些阶段。然后分析各阶段的时间与消耗,分析其合理性、找出可行性的优化、以及预估的优化收益。

以双11的预售会场为例,我们拆分了用户进入会场路径的各个阶段。大致可分为以下四个过程。从用户点击开始,经过路由模块,客户端PHA容器, WebView, 会场框架,最后上屏到用户看见会场页面。如下图所示:

阶段拆分

各阶段拆分如下图所示,同时与用户实际的体感(导航动画、容器白屏、WebView白屏、页面加载等)做了对应关系。

从用户体感这条线看,容器白屏时间、WebView白屏时间、页面加载渲染时间。是提升用户体感的关键时间。从阶段拆分这条线看,需先了解4个阶段的职能以及内部具体的实现,寻找可行的优化手段,做优化的成本与收益的权衡。

客户端部分会涉及:路由模块、PHA容器和WebView;前端部分涉及:WebView和会场框架。

客户端部分

  • 路由阶段

路由模块,核心作用是通过对跳转URL进行按规则拦截,并跳转分发到对应的模块,这部分本身时间消耗短,优化的收益不明显。

  • 容器阶段

会场业务中使用的是PHA容器。PHA(全称Progressive Hybrid App),它是提升Hybrid体验的一种应用框架,能提升页面加载速度和交互体验的渐进式Web应用。使用PHA开发的应用本质上没有脱离前端开发和W3C标准,但依然拥有原生应用的特性和体验。

PHA容器介于客户端Native和前端之间,是两者连接的纽带。以渐进式 Hybrid App 的方式,借助端能力不断改善端上 Web 页面的性能与体验,无限接近 Native 体验为目标。PHA容器功能上支持了Tabbar、横滑、多页面类型、样式定制等功能,性能方面也提供了预渲染、数据预请求、离线资源、NSR等特性。

关于会场性能中的用户体感涉及的两部分

  • 导航动画

导航动画部分是系统的导航提供的能力,该部分耗时在客户端表现稳定,且跟硬件和系统有直接关系,通常在15~30ms左右时间。其优化空间有限,收益也不明显。

  • 容器白屏

该阶段有容器的创建和页面配置这两部分。等这两部分都完之后才能进入Native容器的布局展示。

  • ‍‍容器创建

客户端ViewController或Activity的初始化和创建,此部分消耗由系统能力决定。

  • 页面配置‍‍

Web应用样式和页面的内容,是依赖JSON配置的下载和动态JS脚本的解析执行。由于会场业务的特殊性,除了JSON配置之外,还有一大部分动态JS的执行,内涵页面降级、页面展示、样式信息等信息。加速JSON配置的下载和提前解析执行,能减少或去除容器白屏时间。

  • WebView阶段

WebView作为基础容器,提供了很多扩展功能,JSBridge、资源加载加速、同层渲染组件等。关于性能,WebView的多进程架构,WebView的创建耗时高,尤其在低端机问题更加明显。

  • WebView白屏

上图中的WebView的白屏就是在页面加载过程中,实时创建WebView、loadURL、建立连接、页面所需的HTML/JS/CSS等资源。从数据上来看,这部分在整个链路中耗时占比较高,优化收益明显,是优化的重点部分。

前端部分

为了解决产品运营们随时调整页面结构、增删模块等灵活性的业务要求,同时在当前结构下能够利用客户端缓存做到资源离线最大化的技术诉求,目前的会场页面使用了多段式的终端渲染方案:先加载HTML和Entry JS,再发起数据请求,最后进行模块加载和渲染。

当前的终端渲染方案,虽然是在结构上的串行的加载渲染策略,但在运行时,首先我们将资源加载等部分利用客户端提供的ZCache、PHA资源缓存等能力实现了资源的离线推送和在线缓存,这大幅缩减了HTML、模块JS的资源加载耗时。

同时,当前的渲染方案也在运行时实现了部分并行,来优化整体耗时。例如,在当前的终端渲染方案中,我们结合了客户端的Data Prefetch预加载能力,将数据接口的请求前置到客户端跳转时,即用户从手淘首页点击进入会场时,就会同时触发客户端的运行代码、将下一跳页面的数据请求提前发送,前端只需要发送正常的请求,就可以获取到已经由客户端提前取回的数据。相比由前端代码执行的时机,节省了容器初始化和HTML的加载执行耗时,收益可观。

但有了以上这些,在性能的最优解上,还是不够。结合线上的大盘数据,可以分析出当前阶段仍然存在的问题有:

  • 数据请求耗时长

主会场作为大促业务的锋线,承载了流量分发、个性化推荐等作用,在这些业务逻辑背后所对应的繁杂的服务端接口,使得整个首屏接口的整体RT不容乐观。尤其是在页面的HTML文档、EntryJS等核心资源缓存、实现毫秒级返回后,数据接口的预加载提前量明显变少,如何解决用户的“白屏等待”,是主会场必须要解决的一个问题。

  • 模块加载串行

上面简单介绍过当前渲染方案的前端代码的执行时序,其中会场页面所包含的模块是未知的,必须要等待页面接口整体返回后才能开始加载。但前面的数据等待耗时能否先利用起来、是否可以有其他的优化手段来实现模块的提前加载,也是一个优化方向。

  • 模块渲染耗时长

主会场模块因为交互复杂、逻辑复杂等因素,4-5个首屏模块的资源总体积达到了300kb以上(gzip后)。如此大量的模块JS资源,在中低端的设备上的执行和渲染耗时都比较长,拖慢了整体耗时。在业务优先的前提下,暂时没有办法来通过简化代码、删减动效等方式来大规模降低首屏的渲染耗时。那么,这一渲染过程是否可以借用客户端的能力,不依赖前端时序而提前完成,这看起来也是一个可以尝试的解决方案。

NO.4

客户端的核心手段

Web应用对比Native存在一些差异,在于WebView容器的创建、资源加载速度、渲染速度等方面存在差距。这部分也是我们的突破口。再结合以上的各阶段分析,PHA容器和WebView需要做是

  • 去除白屏等待时间
  • 减少数据等待数据
  • 提升资源加载速度

对应的具体方案如下

  • WebView预渲染

离屏提前将WebView和前端资源加载等提前执行,去除WebView的白屏等待时间。用户交互时使用快照数据渲染上屏可见,再做数据刷新。

  • 数据预请求

提前并发请求数据,减少动态数据请求的等待时间

  • 资源加载提速
    • 资源加载加速, 提前下载配置和静态资源,减少PHA容器和WebView白屏时间
    • 离线资源,支持规则拦截,缓存部分动态的js/css等资源,提升二次访问速度。

优化后的阶段拆分和用户体感变化,增加了预渲染阶段。当用户从点击,经过系统导航动画,直接解析提前下载的配置,解析执行,命中了预渲染WebView的缓存规则,直接上屏显示。从用户点击到可视时间大大缩短了。

WebView预渲染

预渲染是在今年双11会场中使用的技术方案,也是核心的抓手。将原有WebView阶段的WebView创建和资源加载等耗时部分提前。在某个合适的时机,去创建WebView,执行“渲染”,并将渲染结果缓存与内存之中。以备需要时使用。

该方案需要解决几个关键关节问题

  • WebView预渲染调度

WebView的预渲染是要消耗网络内存资源。因此尽量避免在任务密集的时刻去调度,很可能会阻碍正常的任务执行,会适得其反。由基础架构团队提供调度系统负责预渲染的触发执行。有多种可选的机制,如空闲状态、用户操作等多种触发时机。结合会场的业务形态,选择在进入会场之前,空闲时间执行调度任务。

  • WebView预渲染执行渲染

这里的渲染与正常执行页面渲染有差别。它是离屏状态下的操作行为,提前创建WebView以及页面依赖的JS的下载与执行,并会使用打底的数据做渲染。然后将已经执行预渲染WebView,按照一定的规则建立缓存。更重要的一点,还需要针对数据更新请求、面渲染内容、数据埋点等真实用户行为做延迟处理。更详细的内容在前端部分有展开说明。

  • WebView预渲染内容消费

当用户真正点击进入会场,并且访问的内容规则匹配命中了缓存中预渲染的WebView,那么将消费这个WebView,直接上屏,达到页面快速展示的效果。

具体的流程如下图所示

数据预请求

由于会场的业务复杂度高,服务端的数据计算的规则复杂,数据请求接口的耗时高,原有流程中的串行数据请求,严重影响了页面内容展示。数据预请求能力,将数据预请求的时机由业务发起请求的时机,提前到用户点击时,并行发送数据请求,缩短数据等待时间。

资源加载提速

  • 资源加载加速 资源加载加速,依赖ZCache提供的能力,对于业务依赖的一些通用的、固定的、很少变动的静态资源文件(html/js/css等),在使用之前提前加载放到本地缓存,并做好版本管理和动态下发的能力。
  • 离线资源 资源离线方案,PHA容器提供了为了解决静态资源二次加载慢的问题, 支持离线资源的规则配置,并实现应用级别隔离,支持LRU的缓存淘汰策略。

NO.5

前端的核心手段

在客户端容器的帮助下,主会场的H5页面可以提前在客户端首页通过离屏的WebView进行加载和渲染、并在用户实际访问时“即开即用”。除了上面介绍的客户端的部分策略,前端也利用了端侧能力在资源提前加载、页面提前渲染上实现了一定的优化。

预渲染适配

在提前创建的离屏WebView中,为了做到真正的秒开,会场页面可以提前进行渲染。但相比原有的访问过程,有一些关键节点必须要提前考虑:

  • 数据请求

因为手淘首页的qps远远超出主会场接口的qps阈值,所以在首页预创建的WebView时,会场页面在用户访问前,不能发起任何的实际数据请求,否则很可能会压垮服务端接口。

  • 页面埋点

主会场页面虽然已经预创建,但在用户真实访问之前,是不能够将预创建页面的UV、PV、数据曝光等埋点等发送出去,否则会干扰正常的数据统计。

  • 模块渲染

与数据请求的问题类似,会场内部一些独立发送请求获取数据的模块(例如,红包余额、权益领券等),必须在预渲染的过程中进行适配,例如提供静态占位、不发送异步请求等等。

在最终的预渲染方案中,前端通过使用快照方案,在不发起接口请求的前提下,基于快照数据完成了预先的节点渲染。在页面埋点和模块渲染的策略上,前端提供了全局的props.isPrender等透传属性,实现了页面埋点延迟发送,同时支持动态配置占位元素、实现了新模块的自动适配。

数据快照

为了能够做到真正的“秒开”,让用户不再有白屏的等待体感,本次的主会场仿照手淘客户端首页的渲染策略,将用户的上次访问数据进行了本地缓存,在预创建的WebView内渲染时,优先使用上次的数据作为打底数据进行占位渲染。在用户真正进入会场后,直接通过hydrate的方式局部刷新节点,实现“无感”的软刷新。

这套快照方案的核心节点为:

  • 数据快照写入

前端主动将用户上次的访问数据通过客户端JSBridge、localStorage等缓存接口存储在设备本地,并会在每次用户访问会场时、主动刷新缓存。同时为了保证读写稳定性,仅将首屏相关的数据、模块等写入缓存。

  • 默认静态数据

快照数据依赖用户访问,初次访问的用户本地一定是没有快照的。为了优化初次访问的体验,会场前端将主会场的模块列表、资源版本等静态信息,直接托管到CDN。在没有快照时,优先拉取这份静态数据来提前加载模块,减少模块加载耗时。

  • 快照失效策略

结合实时性、个性化等业务特点,会场侧设计了一套多级的缓存失效策略。快照缓存会拆分为两部分:模块数据 和 模块资源,并支持动态的失效时间配置。

模块数据(商品列表、版头图片等)默认当天当前一小时有效,支持动态配置失效时间,例如,3小时、6小时。限时秒杀、倒计时等时效性很强的业务玩法,可配置主动失效。

模块资源,默认不失效。即当页面数据失效时,前端依然会获取上一次的模块资源列表,将页面所需要的JS模块资源等提前加载。

节点更新

在预创建的WebView渲染中,前端使用了快照数据将节点提前渲染出来,并在真实访问时二次刷新。二次刷新的体验尤为重要,需要尽量少的避免抖动、闪烁等,否则方案可能会适得其反、给用户造成干扰。这里,前端侧直接采用了与SSR相同的hydrate方案。

在预创建的WebView中,类似于SSR的服务端渲染过程,前端先通过一个影子节点将模块内容渲染出来,获取到对应的首屏内容的html,将这部分html提前塞到根容器节点内。

而在用户点击进入后,会结合真实数据在根容器节点上进行hydrate渲染。相比于直接的两次渲染过程,这种hydrate方式可以做到局部刷新(例如,商品模块仅更新了图片、标题等元素),整体体验较好。

NO.6

全链路性能数据

要将性能指标能真实的反应优化的效果,将原来的分散的性能数据做收敛和串联。打通性能数据基础能力,并将各个子阶段和子任务的影响应能指标的状态和关键的性能节点都能串联起来,性能埋点实现统一上报。

NO.7

总结和思考

主会场性能优化达到最优效果有多个影响因素,对性能大盘有改进。主会场是切入点作为,整个淘系电商Web应用众多,性能体验是一个需要持续关注和长线投入去做的事情,那么如何提升淘系业务的大盘整体性能是一场艰巨的持久战。

  • 普惠的预渲染

PHA当前的WebView预渲染方案,有效果有收益,但资源消耗也不小,另外预渲染的整体运作实现机制以及配置有部分实现针对会场的定制化的实现。后续会探索更轻量级的、方便易用的、能服务更多常态化业务的方案。

  • 性能指标标准

与BI团队一起梳理性能数据的各阶段与细分的性能埋点,其实很多阶段和数据是具有通用性的。对这部分性能指标做进一步的抽象去服务更多的业务场景,作为判别业务性能的一项重要指标,也能做出更完整的性能大盘。

  • 辅助开发工具

目前对于性能数据整体,但是如何能够快速方便的获取当前性能数据,以便快速定位问题。需要有辅助工具来支持,PHA容器作为客户端和前端的中间纽带,规划辅助开发工具。

喜欢就点这里

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-12-03,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 前端黑板报 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
手淘店铺全链路性能优化
店铺是导购中重要的一环,承接来自商品详情页、主分会场、主搜等数十亿的流量,店铺的性能体验就显得尤为重要。店铺作为流量大,架构复杂,形态多样,稳定性要求高的典型场景,如何针对这类复杂的场景下做性能上的优化是极具挑战的。店铺性能优化是联合客户端容器团队、服务端团队、前端团队等多个团队,诸多团队协同合作,共同努力的结果。过程中我们打通了从容器侧到前端全链路的性能埋点采集链路,站在全局的链路看整个阶段耗时,有针对性的对链路进行深度优化,并通过可视化、多维度直观呈现性能数据。
winty
2021/08/24
6590
手淘店铺全链路性能优化
移动端体验优化经验总结与实践
很多企业都会特别注重自己产品的体验,尤其是移动端,那移动端的体验为什么这么重要?首先体验本身就很重要,好的体验带给用户的感受是截然不同的,用户选择使用一个产品除了产品本身功能满足需求之外,还有一个更重要的原因就是产品用起来“爽”,产品整个使用流程必然是舒适自然,才能受到大众喜爱;此外,产品体验已成为市场竞争力之一,借用人人都是产品经理上面对体验的论述:
ConardLi
2019/11/12
1.7K0
淘宝承接页是如何实现秒开的
用户承接页,是承载上游的落地页,其核心职能是承接流量、转化用户。对用户增长业务来说,如何让用户更快看到页面,是影响用户决策、决定拉新成功的关键。用增承接页的目标用户是手淘低活用户,这部分人的手机设备中低端占比90%以上,网络条件也不稳定,这对于我们承接页的性能、体验提出了更高的要求。
winty
2021/07/01
2.5K0
淘宝承接页是如何实现秒开的
移动 H5 首屏秒开优化方案探讨
导语 随着移动设备性能不断增强,web 页面的性能体验逐渐变得可以接受,又因为 web 开发模式的诸多好处(跨平台,动态更新,减体积,无限扩展),APP 客户端里出现越来越多内嵌 web 页面(为了配上当前流行的说法,以下把所有网页都称为 H5 页面,虽然可能跟 H5 没关系),很多 APP 把一些功能模块改成用 H5 实现。 虽然说 H5 页面性能变好了,但如果没针对性地做一些优化,体验还是很糟糕的,主要两部分体验: 页面启动白屏时间:打开一个 H5 页面需要做一系列处理,会有一段白屏时间,体验糟糕。 响
腾讯Bugly
2018/03/23
3.6K0
盘点这些年搭建器在用户体验优化的实践|得物技术
得物App中嵌入了大量的前端Web页面用以承接各种灵活多变的业务场景和玩法,但因为众所周知的原因,Web应用的用户体验是很难与原生应用相比的。然而,随着搭建器功能的不断完善,支持的业务场景和组件也越来越多,越来越多的团队和部门优选使用搭建器搭建会场页面投放于得物App当中,这对搭建器的整体用户体验提出了更高的要求。
得物技术
2024/12/26
1690
盘点这些年搭建器在用户体验优化的实践|得物技术
前端性能优化--容器篇
前面我们讲了很多前端应用内部的性能优化,实际上除了前端自身,我们还可结合容纳 Web 页面本身的客户端一起做优化。
被删
2024/01/21
4820
前端性能优化--容器篇
腾讯祭出大招 VasSonic,让你的 H5 页面首屏秒开!
小时光
2017/08/30
2.6K0
腾讯祭出大招 VasSonic,让你的 H5 页面首屏秒开!
WebView性能、体验分析与优化
在App开发中,内嵌WebView始终占有着一席之地。它能以较低的成本实现Android、iOS和Web的复用,也可以冠冕堂皇的突破苹果对热更新的封锁。 然而便利性的同时,WebView的性能体验却备受质疑,导致很多客户端中需要动态更新等页面时不得不采用其他方案。 以发展的眼光来看,功能的动态加载以及三端的融合将会是大趋势。那么如何克服WebView固有的问题呢?我们将从性能、内存消耗、体验、安全几个维度,来系统的分析客户端默认WebView的问题,以及对应的优化方案。 性能 对于WebView的性能,给人
美团技术团队
2018/03/13
5.3K0
WebView性能、体验分析与优化
H5开屏从龟速到闪电,企微是如何做到的
导读|H5开屏龟速常是令开发者头疼的问题。腾讯企业微信团队对该现象进行分析优化,最终H5开屏耗时130ms,达到秒开效果!企微前端开发工程师陈智仁将分享可用可扩展的Hybird H5秒开方案。该团队使用离线包解决了资源请求耗时的问题,在这个基础上通过耗时分析找到瓶颈环节,进一步采用“预热”进行优化提速以解决了WebView初始化、数据预拉取、js执行(app初始化)耗时的问题。希望这些通用方法对你有帮助。 背景 服务端渲染(SSR)是Web主流的性能优化手段。SSR直出相比传统的SPA应用加载渲染规避了首
腾讯云开发者
2022/12/18
3.1K1
H5开屏从龟速到闪电,企微是如何做到的
如何秒开WebView?Android性能优化全攻略!
在Android应用开发中,WebView是一个常用的组件,用于在应用中展示网页内容。然而,WebView的启动速度和性能可能会影响用户体验,特别是在一些性能较低的设备上。本文将介绍一些优化WebView启动的技巧,以提高应用的响应速度和用户体验。
Rouse
2024/04/11
1.9K0
如何秒开WebView?Android性能优化全攻略!
前端性能优化--归纳篇
对于前端开发来说,性能优化老生常谈了。不管是日常工作中,还是涉及到晋级答辩,性能都是频繁被我们提及的一个话题。
被删
2024/01/16
6032
前端性能优化--归纳篇
《移动端本地 H5 秒开方案探索与实现》
对 APP 里的一些使用 H5 实现的功能模块,一般体验都比原生差,那么怎么提高h5加载速度?优化 h5 体验?
腾讯Bugly
2018/05/29
5.7K11
前端性能和加载体验优化实践
用户为何会觉得页面卡? : 1. 等待时间长(性能) 项目本身包/第三方脚本比较大。 JavaScript 执行阻塞页面加载。 图片体积大且多。 特别是对于首屏耗时中的白屏时间,用户等待的时间就越长,用户感知到页面的速度就越慢。麻省理工学院的 Richard Larson 在讲话中指出,“人类将被动等待高估了 36%”(https://mazey.cn/t/em)。这意味着用户感觉到的等待时间比开发工具记录的长得多。 2. 看起来卡(体验) 页面结构不断调整,不连贯。抖动的页面往往让用户感觉很卡。 首先
腾讯云可观测平台
2022/01/26
1.7K0
存量用户运营企业微信的“用户端小程序”优化方案
企业微信端产品“C端用户小程序”,是一款服务于vivo线下代理、门店和导购,帮助导购连接用户,快速与用户进行沟通的工具。基于“C端小程序”的PU/UV量较为庞大,为了更加极致的用户体验,所以提升小程序性能优化是必然。
2020labs小助手
2021/03/16
9290
浅谈面向客户端的性能优化
有朋友通过《智能音箱场景下的性能优化》一文找到了我,既然智能音箱的性能优化相当于一个超集,那么对其的一个子集——客户端系统如何进行性能优化呢?
半吊子全栈工匠
2020/02/17
2.1K0
浅谈面向客户端的性能优化
从 “卡顿” 到 “秒开”:外投首屏性能优化的 6 个实战锦囊|得物技术
在互联网时代,网站性能的好坏直接影响用户体验和转化率。对投放的广告页面而言,如何在保证视觉效果和功能的同时提升加载速度,成为了开发者必须面对的挑战。
得物技术
2025/07/15
1240
从 “卡顿” 到 “秒开”:外投首屏性能优化的 6 个实战锦囊|得物技术
干货 | 携程RN渲染性能优化实践
随着 React Native 在前端业界规模性的应用越来越多,各大厂也对其渲染性能越来越看重。
携程技术
2020/07/02
2.9K0
QQ音乐Android客户端Web页面通用性能优化实践
作为一款注重于内容运营的应用程序,QQ 音乐 Android 客户端的 Web 页面日均 PV 达到千万量级,评论页、MV 页等核心页面均有 Web 页面参与,或完全由 Web 实现。
腾讯云开发者
2020/07/16
3.5K1
秒开率破90%!交易后台渲染性能优化 | 得物技术
一直以来,体验都是得物技术部的关键词之一,对于前端开发而言,提高用户体验更是一项至关重要的工作。
得物技术
2024/04/16
3420
秒开率破90%!交易后台渲染性能优化 | 得物技术
如何重新认知性能优化及其度量方法
我是来自 UC 内核团队的林洁伟,海愚是我的花名。今天我将分享的主题是如何重新认识性能优化及其度量方法。
winty
2021/07/01
1.2K0
如何重新认知性能优化及其度量方法
推荐阅读
相关推荐
手淘店铺全链路性能优化
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档