Event 页面性能排查记录

日期：2026-05-19<br>浏览器：Microsoft Edge headless<br>口径：Lighthouse mobile / DevTools throttling，另用 Edge 生成 390x844 mobile 和 1440x1000 desktop 首屏截图。<br>原始数据：lighthouse-edge/*.json<br>截图：screenshots/*.png

页面列表

编号URL对应路由
01https://www.lbank.com/event-new/pointmall/10001248-pointsevent/:locale/event/pointmall/[slug]
02https://www.lbank.com/event-new/10001416-luckydraw-tradingbonus-allusers/:locale/event/[slug]
03https://www.lbkpro.net/event-new/pointmall/10001248-pointsevent/:locale/event/pointmall/[slug]
04https://www.lbank.com/event/elitechampionship/116-pizzatrading/:locale/event/elitechampionship/[code]
05https://www.lbk.pub/event-new/pointmall/10001248-pointsevent/:locale/event/pointmall/[slug]

Edge Lighthouse 结果

页面ScoreFCPLCPSpeed IndexTBTTTI请求数传输体积第三方请求
01 pointmall lbank0.621.2s16.1s6.6s310ms23.5s1855.6MB66
02 lucky lbank0.634.0s5.6s6.8s150ms25.8s1981.9MB67
03 pointmall lbkpro0.611.3s16.2s6.7s320ms23.6s1845.6MB65
04 elite lbank0.623.8s11.0s5.4s150ms14.6s1762.0MB57
05 pointmall lbkpub0.621.1s16.0s6.8s310ms23.6s1845.6MB65

主要结论

HTML/SSR 不是这轮数据里的主瓶颈。Edge Lighthouse 中根文档耗时约 130-450ms；curl 直连时 5 个 URL 的 TTFB 约 0.46-0.67s。低两秒开率主要来自浏览器端首屏资源、第三方脚本和主线程执行。

01/03/05 Pointmall

这三个域名表现基本一致，LCP 约 16s，传输体积约 5.6MB。最大的阻塞资源来自 pointmall 默认 banner 动画：

资源体积Edge 耗时说明
0c94d950-...pag1.67MB9.7s移动端 PAG 动画源
libpag.wasm828-885KB5.4-5.7sPAG runtime
desktop poster c797...png839-840KB16.0-16.4s首屏背景图
mobile poster ace1...png641KB14.9s首屏背景图

对应代码：

截图观察：

建议优先级：

  1. 移动端首屏先展示静态 webp poster，PAG 延后到 idle、首屏稳定后或用户交互后加载。
  2. 对 pointmall poster 加 OSS resize + format,webp，并用 <picture> 或 CSS media 分端加载，避免 desktop/mobile 双图同时进入首屏竞争。
  3. 针对 10001248-pointsevent 在 POINT_MALL_BANNER_VIDEO_MAP 做单活动降级，先验证关闭 PAG 后的两秒开率改善。

02 Lucky Draw

LCP 5.6s，比 pointmall 好，但请求数最高：198 个。主要瓶颈是请求并发和全局脚本执行。

Top resources:

对应代码：

截图观察：

建议优先级：

  1. 抽奖组件首屏图片加尺寸裁剪和 preload/fetch priority。
  2. 极验初始化改为报名、抽奖或任务点击前触发，不在页面打开时立即初始化。
  3. 评估非首屏远程组件和第三方脚本延后策略。

04 Elite Championship

LCP 11.0s，请求/体积低于 pointmall，但首屏 banner 图耗时明显。

Top resources:

对应代码：

截图观察：

建议优先级：

  1. banner 图按移动端尺寸裁剪，不直接让 318KB 图成为移动端首屏关键资源。
  2. 如果后台 headVedioList 有视频，移动端优先静态图，视频延后。
  3. 检查 generateMetadata 和页面主数据是否可以共享或缓存，降低动态渲染波动。

共性问题

  1. 三类路由都声明了 revalidate = 45，同时又声明 dynamic = 'force-dynamic'。这会让 ISR 收益基本失效。当前 TTFB 不是主因，但高峰期会放大服务端压力。
  2. PageLayout 全局加载 Header/Footer、远程模块、monitor、data-trace、GA、LiveChat 等能力。活动页首屏并不一定需要这些全部立即参与关键路径。
  3. useGeetestInitEffect 当前在活动页打开后初始化 SDK，即使用户未交互也会引入极验脚本和主线程成本。
  4. 首屏大图和动画资源没有统一的移动端尺寸策略。Pointmall 尤其明显，PAG + WASM + 两张 poster 把 LCP 拉长到 16s 左右。

复核补充（2026-05-19）

使用 Edge 实际打开了三个代表页面：

另外两个 Pointmall 镜像域名（lbkpro.net、lbk.pub）未在 Edge UI 中逐个重复打开，但已通过 Lighthouse JSON 和资源明细对比确认与 lbank.com 表现基本一致。

本次代码复核把范围扩大到整个 growthx，重点检查了 VideoAnimation / TopBannerVideo / PagAnimation、useGeetestInitEffect、PageLayout、force-dynamic + revalidate 和 banner 图片预加载策略。新的补充判断：

秒开率核心影响因素

“秒开率”重点看用户进入页面后 2s 内能否看到稳定、可理解、可交互的首屏。结合 Edge 实测、Lighthouse 和代码路径，当前核心影响因素按优先级如下。

1. Pointmall 首屏主视觉资源过重

影响页面：01、03、05。

这是当前最直接拖低两秒开率的问题。Pointmall 首屏几乎完全由大 banner 占据，首屏能否快速稳定取决于 banner 静态图和动画资源。

关键数据：

关键代码：

判断：Pointmall 的两秒开率不是靠调 TTFB 能解决。必须先让 2s 内只加载一张正确尺寸的静态首屏图，把 PAG / WASM / 视频降为非关键路径。

2. 首屏同时发现 desktop/mobile 双图

影响页面：主要是 01、03、05。

Pointmall 视频模式下 desktop poster 和 mobile poster 是两个并列 <img>，通过 CSS 控制显示隐藏。即使最终只显示一张，浏览器仍可能提前发现两个图片资源并参与下载竞争。

关键数据：

判断：这会直接挤占移动端首屏网络带宽，降低 2s 内展示稳定 banner 的概率。应该改成 media-aware 的单资源发现策略。

3. PAG 固定 3s 延迟仍落在首屏关键窗口

影响页面：01、03、05，以及 growthx 里所有首屏使用 VideoAnimation / TopBannerVideo 的页面。

VideoAnimation 默认 delayLoad=true、delayLoadTime=3000。这能避免动画立即抢 FCP，但 3s 对“秒开率”仍太早：首屏图刚开始稳定时，又开始拉 libpag.min.js、libpag.wasm 和 .pag，继续抢网络和主线程。

关键数据：

判断：对两秒开率而言，PAG 应该是 idle/交互后的增强效果，不应固定 3s 自动启动。移动端优先静态图是更稳的策略。

4. 页面打开即初始化 Geetest

影响页面：01、02、03、05；代码同类问题也存在于 growthx/spotx。

useGeetestInitEffect 内部不管是否登录都会先 geetest.init({ autoReport: false })，这会插入 https://static.geetest.com/g5/gd.js 并触发后续 Geetest 资源。传入 { isLogin } 只能控制是否执行 reportGeeTokenToRisk，不能避免 SDK 初始化。

关键数据：

判断：风控 SDK 对报名、抽奖、任务点击有意义，但不应该在页面打开时进入秒开关键路径。应改为动作前懒初始化，并在未登录时跳过初始化。

5. 全局 Layout 脚本和远程组件参与首屏竞争

影响页面：所有 growthx 应用，包括 event、spotx、bonus、seo。

PageLayout 统一注入 Header/Footer、RemoteEsmUmdProvider、monitor、data-trace、GA、LiveChat、字体 preload 等基础能力。Footer 已经包了 PageLoadWrapper，LiveChat 也延后 2s，但 Header、远程模块、monitor、data-trace、GA 仍会参与首屏资源调度和主线程执行。

关键数据：

判断：全局能力不是唯一瓶颈，但会降低弱网/低端机下的秒开稳定性。不能在业务页私自删 Layout，应该给 PageLayout 增加可配置的延迟策略或活动页轻量模式。

6. Lucky Draw 的转盘图和动态 chunk

影响页面：02。

Lucky Draw 的 LCP 约 5.6s，已经明显好于 Pointmall，但 2s 内仍不稳。首屏视觉依赖转盘和背景，抽奖交互组件较重，Next chunks 也在 10s 左右继续下载。

关键数据：

判断：Lucky Draw 的优先级是首屏图尺寸/优先级、抽奖交互延后和 Geetest 延后，不是 SSR。

7. Elite banner 图加载慢

影响页面：04。

Elite 的传输体积低于 Pointmall，但首屏 banner 是关键 LCP 候选。Edge 打开时能看到黑底文案先出现，随后大图补齐。

关键数据：

判断：Elite 主要处理移动端首屏图裁剪、预加载和 fetch priority。它不是最大头，但优化确定性高。

TODO

记录口径：

P0：Pointmall 首屏资源减载

状态任务为什么要改预期提升
[ ]改 PointMallBanner 的静态回退路径：当 videoSource 没有 webmList/mp4List/pagList 时，BaseBanner 使用 videoSource.poster/h5Poster，而不是只回退到后台 bannerPic/bannerPicH5Black。当前如果只给 POINT_MALL_BANNER_VIDEO_MAP 配静态 poster，组件不会自然走到这两张图；必须先打通静态降级链路。为单活动关闭视频/PAG 提供低风险开关，支持先验证 Pointmall LCP 和两秒开率收益。
[ ]针对 10001248-pointsevent 在 POINT_MALL_BANNER_VIDEO_MAP 做活动级降级实验：先关闭 pagList / webmList，只保留静态 poster，复测 LCP 和两秒开率。该页面 LCP 约 16s，首屏资源约 5.5MB；PAG 1.67MB、WASM 约 0.8MB、poster 约 1.48MB 是当前最大瓶颈。让首屏从“图 + 动画运行时”变成“单张静态图”，预期明显降低 LCP、首屏资源体积和弱网白屏/黑屏时长。
[ ]将 Pointmall 视频模式的 desktop/mobile poster 从两个并列 <img> 改为单一资源发现策略，例如 <picture><source media=...> 或复用 PreloadImage 的 media 策略。当前 CSS 隐藏不等于网络不发现；mobile Lighthouse 下仍下载 desktop poster，双图合计约 1.48MB。移动端只下载移动端首屏图，减少带宽竞争，提高 2s 内首屏图稳定展示概率。
[ ]给 Pointmall poster URL 增加统一 OSS 尺寸裁剪和 format,webp。移动端按实际首屏展示尺寸裁剪，不直接使用 641KB 原图。当前 poster URL 没有尺寸裁剪；移动端加载超出展示所需的原始大图。降低 LCP 图片传输体积，提升弱网和低端机的首屏展示速度。
[ ]将 Pointmall PAG 加载从固定 delayLoadTime=3000 改为 idle、首屏稳定后或用户交互后加载；若业务允许，移动端默认静态图，PAG 作为增强效果。3s 延迟仍落在秒开关键窗口附近，会继续拉 libpag.min.js、libpag.wasm 和 .pag，并带来主线程执行成本。把动画资源移出首屏关键路径，减少首屏后 3-5s 的网络和 CPU 抖动，提升首屏稳定感。
[ ]为 VideoAnimation 增加可配置的移动端静态封面模式，例如 staticOnMobile / `loadStrategy="idleinteraction"`。VideoAnimation 被 event、spotx、bonus 和 shared 抽奖组件复用；如果只在 Pointmall 写特例，后续同类页面还会重复踩坑。形成 growthx 公共性能能力，统一控制移动端视频/PAG 是否进入首屏关键路径。

P1：Lucky Draw / 标准活动页

状态任务为什么要改预期提升
[ ]抽奖组件首屏转盘图和 banner 背景图补充尺寸裁剪、fetchPriority="high" 和明确宽高，优先处理 bg-raffle-wheel@x2.png。Lucky Draw 首屏核心视觉依赖转盘图；bg-raffle-wheel@x2.png 约 121KB，下载约 8.2s，是 LCP/首屏稳定候选资源。提前、按需加载首屏关键图，降低 LCP 和首屏视觉补齐时间。
[ ]将标准活动页 useGeetestInitEffect 从页面打开即初始化改为动作前初始化：报名、抽奖、任务点击等真实风控触发点前再 init/report。当前页面打开就拉 Geetest SDK、geeGuard 和风控请求，即使用户未点击报名/抽奖，也占用首屏网络和 CPU。减少首屏第三方脚本竞争，提升 FCP/LCP 周边稳定性，并降低未交互用户的无效资源消耗。
[ ]检查并调整 useGeetestInitEffect hook 语义：如果 isLogin=false，跳过 geetest.init。现有 hook 里 { isLogin } 只控制是否上报 token，不控制 SDK 初始化；未登录用户也会加载 Geetest。未登录访问活动页时减少第三方 SDK 请求和 bootup CPU，提升秒开率样本中的低成本访问体验。

P1：Elite Championship

状态任务为什么要改预期提升
[ ]Elite banner 背景图按移动端首屏尺寸裁剪，并确认 preload 的 URL 与实际 background-image URL 完全一致。Elite LCP 约 11s，banner 图约 318KB、下载约 7.2s；如果 preload URL 和实际 URL 不一致，预加载收益会被抵消。降低 banner 图下载时间，提升首屏从黑底文案到完整视觉的补齐速度。
[ ]若 headVedioList 存在视频资源，移动端优先静态 poster，视频/PAG 延后加载。Elite 当前无视频时主要是图片瓶颈；但代码支持视频资源，一旦后台配置视频，移动端可能复现 Pointmall 的视频/PAG 问题。防止后续活动配置视频后拖慢秒开率，保持移动端首屏稳定。

P2：GrowthX 共性治理

状态任务为什么要改预期提升
[ ]梳理所有 growthx 中 force-dynamic + revalidate 的路由，确认哪些确实依赖 request-time 数据，哪些可以恢复 ISR 或改为更细粒度动态数据请求。force-dynamic 会让 revalidate 基本失效；当前 TTFB 不是主瓶颈，但高峰期服务端压力会放大首包波动。降低服务端波动和高峰期首包风险，为秒开率提供更稳定的 HTML 基线。
[ ]和 PageLayout 维护方确认是否支持按业务页延后非首屏能力：Footer、LiveChat、GA、data-trace、远程模块等。PageLayout 当前统一注入 monitor、data-trace、GA、Header 远程模块等；这些能力会参与首屏网络和主线程竞争，但不能在业务页私自删除。在不破坏全站基础能力的前提下，为活动页提供轻量首屏模式，减少全局脚本对秒开率的影响。
[ ]将首屏图片规范沉淀到 growthx 公共组件：端侧 media preload、OSS resize/webp、避免 CSS 隐藏双资源、明确 LCP 候选图优先级。当前标准活动页、Pointmall、Elite 的首屏图处理策略不一致，容易出现双图下载、未裁剪、preload URL 不一致等问题。统一首屏图片性能能力，减少后续活动页重复问题，提升多页面秒开率一致性。
[ ]对 growthx/spotx Token Splash 的 VideoAnimation 和 useGeetestInitEffect 做同类性能审计。全局搜索发现 Token Splash 首页和详情页也有首屏视频动画与打开即初始化 Geetest 的代码路径。避免 event 优化完成后，同组其他活动页继续拖累 growthx 整体性能口径。

产物索引

Edge Lighthouse JSON:

Edge screenshots: