📊 Minara 性能专题首页 分析报告·优化方案·Lighthouse 原始报告

Minara Discover 性能分析报告

代码库快照 · release @ 3f254fd71 · 报告生成 2026-04-19 · 范围：Next.js 15.3 + React 19 全栈前端（src/ 2,278 TSX 文件，public/ 138 MB）

本报告基于对构建配置、依赖体积、渲染策略、数据链路、静态资源和运行时模式的静态审计（未跑 Lighthouse 实测； Lighthouse 复测列为优化方案第 0 阶段任务）。每项问题带有严重级别、证据文件路径和量化影响估计。

🎯 执行摘要

🚨 Lighthouse 移动端实测（Slow 4G Throttling · 8 个页面 · 2026-04-19）： Performance Score 分布 25 / 26 / 28 / 28 / 29 / 29 / 33 / 46（满分 100，Good ≥ 90），全数不及格。 最差页 /app/workflow：LCP 44.9 s、TTI 45.2 s、下载 9.8 MB、主线程 35.2 s、重定向链 7.8 s。 最大单资源：/quick-search/all-assets JSON 2.5 MB，icon0.svg 1.2–1.5 MB（favicon bug），cooking GIF 单张 1.5 MB。 所有页面被重定向到 /zh/，浪费 1.3–7.8 秒。

当前瓶颈并非业务代码，而是三条结构性失衡：

① 首屏「万物 client」：412/1,652 个 TSX 标记 'use client'（25%），首页、use-case、about 全部客户端渲染； generateStaticParams 用量为 0，<Suspense> 用量为 0，整个站点退化为纯 SSR on-demand； 营销页无法享受 SSG / 流式渲染。

② 138 MB 公共资源 + 10+ 无策略第三方脚本：单张 GIF 27 MB、hero 背景 PNG 13–14 MB、OG 图每张 3 MB； <head> 中同时加载 GA/GTM/Facebook Pixel ×3 ID/CoinGecko/TradingView 库/canvas-datagrid (unpkg)/7 套 Google Fonts， 其中 markdown-it-fix 以 beforeInteractive 阻塞水合。

③ 依赖与路由双重冗余：highlight.js + react-syntax-highlighter + prismjs 三套高亮库并存； echarts 与 TradingView charting_library（2.7 MB bundle）双图表栈； how-to-guides 目录 30 个 1,909 行模板复制粘贴共 ~57K 重复 LOC； ignoreBuildErrors + ignoreDuringBuilds 关闭了类型与 lint 的 CI 保护。

保守可回收：JS 初始包 ~2.5 MB · 静态资源 ~60 MB · 首屏第三方脚本 6 个。 预计修复后 LCP 改善 1.5–3 s，TBT 下降 40–70%，月度流量成本同比下降 ≥30%。

🔥 Chrome 实测补充（见下方「线上实测」节）： 未登录的营销页 /home 冷加载 37 个 fetch 请求，其中 cross-chain/activities 被调 8 次、 pnls/all 被调 6 次、arbitrum/batch 被调 6 次 —— Root Layout 里的 Auth/Wallet Provider 在无条件拉用户数据。 同一个 757 KB 大 chunk（1476-*.js）在所有路由都加载。/app/chat 冷启动 73 个 fetch · 4.5 MB。

规模与关键指标

2,278
TSX/TS 源文件
含 30 份 how-to-guides 重复模板
412
'use client' 文件
占比 25%，包含全部营销页
138 MB
public/ 静态资源
单文件最大 27 MB GIF
17
i18n 语言包
3.3 MB，服务端按 locale 加载
0
<Suspense> 边界
全站无流式 / 渐进水合
0
SSG 路由
generateStaticParams 零使用
2
next/dynamic 用量
Monaco + 电子表格，仅此两处
10+
head 内第三方脚本
GA/GTM/FB×3/CG/TV/CDG + 7 fonts

审计方法

未执行：next build --profile 生成真实 bundle 图、火焰图采集（Chrome DevTools Performance 面板）。 下节的 Lighthouse 实测已经覆盖了 CWV 基线。

🚨 Lighthouse 实测（5 个页面 CWV）

工具：npx lighthouse · 移动端模拟（Slow 4G, 4× CPU throttle）· headless Chrome · 采样时间 2026-04-19 07:28–07:35 UTC+8 · 原始报告：docs/perf-baseline/2026-04-19/lh-*.report.{json,html}

核心指标总表

页面 Score LCP FCP TBT TTI SI CLS TTFB Bytes Unused JS Main Thread
/home 28 20.8 s 4.2 s 2.3 s 33.6 s 22.1 s 0.000 194 ms 5.5 MB 1.6 MB 34.6 s
/about 29 21.0 s 6.3 s 1.5 s 42.6 s 21.3 s 0.000 180 ms 5.4 MB 0.8 MB 20.9 s
/use-cases 33 17.1 s 3.2 s 2.0 s 24.4 s 8.4 s 0.000 205 ms 3.8 MB 1.1 MB 15.9 s
/how-to-guides/[slug] 46 4.0 s 3.6 s 1.7 s 23.1 s 7.7 s 0.000 195 ms 3.7 MB 0.8 MB 11.5 s
/app/chat 28 20.6 s 3.4 s 2.3 s 31.3 s 15.3 s 0.099 189 ms 10.7 MB 1.5 MB 36.4 s
/app/trade/perps/BTC 26 28.3 s 4.8 s 2.1 s 34.5 s 14.7 s 0.102 188 ms 7.3 MB 1.5 MB 19.9 s
/app/strategy-studio 29 29.4 s 4.0 s 1.1 s 33.8 s 25.7 s 0.145 511 ms 11.0 MB 1.5 MB 45.8 s
/app/workflow 🏆 最差 25 44.9 s 9.7 s 2.4 s 45.2 s 26.1 s 0.077 199 ms 9.8 MB 1.5 MB 35.2 s
Good 阈值 ≥ 90 < 2.5 s < 1.8 s < 0.2 s < 3.8 s < 3.4 s < 0.1 < 0.8 s - - < 2 s

Score：Performance 类别 0–100 · LCP/FCP/TBT/TTI/SI：Lighthouse 合成指标 · CLS：累计布局偏移 · TTFB：服务器响应时间 · Bytes：页面总下载 · Main Thread：主线程总工作时长。LCP/TBT/TTI 均为 Bad 等级。

Critical · Lighthouse #1 LCP 17–45 秒：8 个页面全数失败 CWV
实测（按 LCP 排序）： /app/workflow 44.9 s · /app/strategy-studio 29.4 s · /app/trade/perps/BTC 28.3 s · /about 21.0 s · /home 20.8 s · /app/chat 20.6 s · /use-cases 17.1 s · /how-to-guides/[slug] 4.0 s（唯一接近 Poor 边界的）。 Good 阈值是 2.5 s，当前大部分值是阈值的 7–18 倍。
影响： CWV 直接影响 Google 搜索排名（Core Web Vitals 是 ranking signal）； 真实用户流失率按 Akamai 公开研究，LCP > 4 s 会导致 bounce 率翻倍、转化率下降 10–20%。 当前水平意味着 SEO 与增长漏斗同时受损。 /app/workflow 的 LCP 44.9s 与其 redirect savings 7.8s + 主线程 35.2s 组合相符。
Critical · Lighthouse #2 主线程工作 11–36 秒 · TTI 23–42 秒
页面Main ThreadTTITBT
/app/chat36.4 s31.3 s2.3 s
/home34.6 s33.6 s2.3 s
/about20.9 s42.6 s1.5 s
/use-cases15.9 s24.4 s2.0 s
/how-to-guides/[slug]11.5 s23.1 s1.7 s
影响： 用户打开后要等 23–42 秒才能真正交互；期间点击、滚动都会卡顿； TBT 1.5–2.3 秒对应 INP 通常 500 ms+（失败 Google INP ≤ 200 ms 标准）。 这是综合症：大 chunk（757 KB）+ 全路由 'use client' + 40+ 重型依赖 + 无 code splitting 的共同结果。
Critical · Lighthouse #3 1.6 MB "未使用 JavaScript"（Lighthouse 直接标注可救）
Unused JavaScript 按页： /home 1,625 KB · /use-cases 1,139 KB · /app/chat 1,533 KB · /about 801 KB · /how-to-guides 833 KB。 Lighthouse 估算：仅移除未使用 JS，/home 可省 2,800 ms，/app/chat 可省 6,740 ms。 典型代表是 /_next/static/chunks/1476-96a798bef671f884.js 757 KB 在所有路由加载。
影响： 这是 bundle 结构问题 —— 大 chunk 把所有路由的代码都打到一起， 实际这个页面只用其中 20–40%。对应优化方案 P1.4（重型依赖按 next/dynamic）+ P1.5（barrel / namespace import 重构）。
Critical · Lighthouse #4 全部页面被重定向到 /zh/，白白耗 1.3–4.3 秒
Lighthouse 诊断的 redirect savings： /about 4,265 ms、/how-to-guides 1,665 ms、/home 1,637 ms、/app/chat 1,344 ms、/use-cases 1,285 ms。 最终 URL 全部带 /zh/ 前缀（例：/about → /zh/why-minara/about 实际是 两跳 重定向）。 这源于 next-intl 无法根据 Lighthouse 的 Accept-Language 正确判定 locale 后重定向； 真实用户中非中文地区用户也会遇到同样路由链问题。
影响： 平均每次首次访问多 2–3 秒；SEO 上每条规范 URL 都是多跳，爬虫预算浪费； /about 的 4.3 秒 意味着单个重定向问题占其 FCP 6.3s 的 68%。
Critical · Lighthouse #5 App 路由每页 7–11 MB · 单 API 2.5 MB · 1.2–1.5 MB favicon · cooking GIF 横扫
Top 重资源（每个 app 页面都会出现的"重复重量"）：
资源/chat/perps/BTC/strategy-studio/workflow
api.minara.ai/quick-search/all-assets (JSON)2,563 KB1,699 KB2,564 KB2,563 KB
minara.ai/zh/icon0.svg (favicon!)1,210 KB–1,466 KB–
images/cooking/*.gif (2 个)~2,500 KB~1,024 KB~2,495 KB~2,501 KB
/charting-library/charting_library.js–15 KB*15 KB*14 KB*
_next/static/chunks/1476-*.js (大共享)757 KB757 KB757 KB757 KB
_next/static/chunks/5728-*.js290 KB290 KB290 KB290 KB
widgets.coingecko.com/...widget.js213 KB213 KB213 KB213 KB
页面总下载10.7 MB7.3 MB11.0 MB9.8 MB

* TradingView 主 charting_library.js 是入口（15 KB），真正重的是 6 个 bundle 文件（runtime、library、语言包等）， Lighthouse 报 0 KB transferSize 实为"测量窗口结束时仍在下载" —— 即 TradingView 2.7 MB bundle 直接吃掉一大段 LCP。 关键：TradingView 入口脚本在所有 app 路由都加载（perps 合理 · strategy-studio 边缘合理 · workflow 完全不需要）， 因 src/app/[locale]/layout.tsx L149 的全局 <Script defer>。

影响：
  • App shell 装载 10 MB+ 意味着移动 4G 用户需要 40–60 秒才能完成下载
  • /quick-search/all-assets 每次都返回 1.7–2.6 MB JSON — 应该分页或按字段缩减
  • icon0.svg 1.2–1.5 MB 是明显 bug（正常 SVG favicon < 5 KB）
  • cooking GIF 在所有 app 路由都显现 — 应为全局 loading state，属于 UX 而非数据；需确认是否可换成单张轻量占位或 CSS skeleton
  • TradingView 入口在 /app/workflow 加载毫无必要，应下沉到 /app/trade/** + /app/strategy-studio 两个分组
High · Lighthouse #5B 重型库按需加载实际上是生效的（Monaco / @xyflow/react / echarts）
证据： 在 /app/strategy-studio、/app/workflow 的 Lighthouse 首屏网络请求里没有 Monaco editor（vs/editor）、 echarts、@xyflow/react 相关 chunk —— 说明这几个库都是用户触发（点按钮、打开画布）才加载。
结论： 优化方案 P1.4 的部分工作（Monaco/xyflow/echarts 的 dynamic import）已经生效。 剩下需要的是把公共 757 KB 大 chunk 拆开（对应 P1.5 barrel 重构），这是 "Unused JS 1.5 MB" 的根源。
High · Lighthouse #6 第三方脚本清单：Facebook、CoinGecko、unpkg、Google 加一起 ~650 KB + 150–200 ms 阻塞
每个页面稳定加载的第三方（Lighthouse third-parties-insight）：
EntityTransferMain Thread备注
Facebook Pixel269–270 KB89–120 ms3 个 pixel ID + Privacy Sandbox register × 3
CoinGecko widget213 KB28–30 ms所有 5 个页面都加载，仅需在特定路由
Google OAuth SDK96 KB7–8 msRoot Layout 无条件挂载
unpkg canvas-datagrid62 KB5–6 ms未固定版本的 CDN，非必需
Google Fonts174–423 KB0 ms7 套字体，Noto Serif SC 对所有语言加载
YouTube embed451 KB（仅 /about）-新发现：about 页嵌入了 YouTube 播放器
影响： 单计 Facebook + CoinGecko 就是 ~480 KB + 120 ms 主线程工作， 完全可以砍 CoinGecko 到 /token/* 或 /app/* 路由内； YouTube embed 应换 lite-youtube-embed 方案（把 451 KB 延迟到 user click）。
Good TTFB 与 CLS 表现健康
TTFB 180–205 ms（全部 Good ≤ 800 ms），说明 CDN / origin 响应足够快； CLS 0 或 0.099（全部 Good ≤ 0.1），布局稳定。 瓶颈完全在 JS 执行、图片/资源 payload、重定向链上，不在服务器性能。

与原预估对比

指标原静态估算Lighthouse 实测（最差页）修正后认知
LCP4.0–6.5 s21.0 s严重低估，实际是阈值 8 倍
TBT0.6–1.4 s2.3 s低估约 60%
TTI5–9 s42.6 s严重低估，实际是估算 5–8 倍
首屏 Bytes3.3 MB10.7 MB（/app/chat）/app/chat 实际更重
Unused JS-1.6 MB新发现可救 1.6 MB 死代码
CLS0.15–0.250–0.099高估 · CLS 实际已 Good

结论： 原静态审计对 CWV 的量级判断偏乐观。LCP / TTI 实际是估算的 5–8 倍。 CLS 原以为是问题，实际已 pass（字体 display=swap 起作用）。 优化方案 P0.X "重定向链根治" 从未列入，现在必须补到 P0.0 作为紧急任务（收益 1.3–4.3 s，工作量 < 1 小时）。

⚡ Chrome MCP 补测（API 重复、SW）

采样时间 2026-04-19 · 工具：claude-in-chrome MCP 注入 PerformanceObserver + Resource Timing + Navigation Timing。 tab 处于后台（document.hidden = true），Chrome 不发 paint/LCP 事件，故本节 不含 LCP/FCP/CLS/INP 实测； 这些需在前台或 Lighthouse 中测。以下全部为实测数据，非估算。

各页面冷加载关键指标

页面 TTFB DCL Load 下载总量 脚本量 资源数 长任务 fetch 数
/app/chat 首次 - 4515 ms 6305 ms 3.3 MB 3.1 MB 193 7 / 1081 ms -
/home（营销） 184 ms 677 ms 3124 ms 2.4 MB 2.2 MB 119 4 / 701 ms -
/home?cb=cold1 (SW 卸) 551 ms 1208 ms 1373 ms 4.0 MB 3.2 MB 152 6 / 752 ms 37
/about → 跳 /why-minara/about 710 ms 1198 ms 6266 ms 3.3 MB 1.9 MB 113 4 / 773 ms 23
/use-cases 478 ms 738 ms 1355 ms 2.3 MB 1.9 MB 95 2 / 167 ms 23
/how-to-guides/btc-eth-... 244 ms 724 ms 2152 ms 2.7 MB 1.9 MB 112 2 / 405 ms 26
/app/chat?cb=cold1 209 ms 761 ms 1078 ms 4.5 MB 3.2 MB 178 4 / 580 ms 73

注：后几次浏览器有磁盘缓存残留，DCL/Load 偏乐观；TTFB 与 fetch 数不受缓存影响。/app/chat 首次测量是 SW 仍在、首次登录场景，Load 6.3 s 最接近真实新用户体验。

Critical · 实测发现 #1 同一 API 被重复请求 4–8 次 / 次加载
证据（来自 Resource Timing 去重计数）：
URL/home 冷/app/chat 冷/use-cases
api.minara.ai/v1/tx/cross-chain/activities884
api.minara.ai/users/pnls/all644
outpost.minara.ai/api/v1/prices/arbitrum/batch644
outpost.minara.ai/api/v1/prices/ethereum/batch-5-
token.minara.ai/api/v1/public/token/info/0x2260…（WBTC）-4-
api.minara.ai/v1/fully-managed/futures-grid/positions-4-
api.minara.ai/discover/events-4-
api.minara.ai/limit-order-bot3-2
static.minara.ai/demo/chat-demo.mp43--
api.hyperliquid.xyz/info-3-
fonts.googleapis.com/css2-7-
facebook.com/tr + privacy_sandbox/pixel/register-3 + 3-
影响： 未登录的营销页（/home、/use-cases）都在调用 pnls/all、cross-chain/activities 之类的用户态接口 —— 大概率是 Root Layout 的 CustodialWalletStoreProvider / UserAuthStoreProvider 在挂载时无条件触发； ahooks.useRequest 没配 cacheKey，多个组件并行请求同一资源时不会去重； chat-demo.mp4 被请求 3 次暗示视频组件多次挂载或有 bug； Facebook Pixel 3 ID 各自触发一次 tr + 一次 Privacy Sandbox 注册，6 个额外请求纯浪费； fonts.googleapis.com/css2 一次加载发 7 个请求，直接印证静态审计结论。
Critical · 实测发现 #2 同一 757 KB 大 chunk 在所有路由加载
证据： /_next/static/chunks/1476-96a798bef671f884.js = 757 KB，在 /home、/about、/use-cases、/how-to-guides/[slug]、/app/chat 每个页面都出现。 首次下载冷加载耗时 3.6 s；后续走缓存 0 ms。
影响： 单一超级 chunk 意味着任何路由都要承担所有路由的代码 —— 这正是 barrel import + 'use client' 根层级蔓延 + 重型依赖未 dynamic 的后果；该 chunk 本身应拆为 5–10 个路由级 chunk。 是"单页 JS 首屏 3 MB"的根本成因。
Critical · 实测发现 #3 未登录访问 /app/chat 冷加载 73 个 fetch · 4.5 MB
证据： /app/chat?cb=cold1：178 resources，73 个 fetch/XHR，4.5 MB 总下载，3.2 MB 脚本； cooking/2.gif 1,000 KB（实际测到）； api.minara.ai 单机打中 21 次（含 8 次同接口重复）。
影响： App Shell 首屏即"把整个应用预载"； 7 long tasks / 1081 ms 主线程阻塞（首次真实访问）； 登录流成本巨高。
High · 实测发现 #4 TTFB 波动 184–710 ms，印证无 SSG
证据： 同一次采样内 /home 184 ms、/use-cases 478 ms、/about 710 ms、/how-to-guides/[slug] 244 ms。
影响： 若开启 SSG + CDN 边缘缓存，TTFB 应稳定在 40–120 ms 且方差极小。 当前全部页面都是 Node.js 实时 SSR，每次请求要跑完 next-intl + Provider 初始化 + metadata 生成。
High · 实测发现 #5 Service Worker 生效 · 作用域 /sw/
证据： navigator.serviceWorker.getRegistrations() 返回 1 个 SW，scope https://minara.ai/sw/； cache storage 空（说明 SW 还未缓存业务资源或使用 runtime 策略）。 minara.ai/cdn-cgi/rum 出现在网络面板 → Cloudflare RUM 已部署，意味着线上已经有真实 CWV 数据，建议查看 Cloudflare 控制台 Web Analytics。
行动： 直接从 Cloudflare Web Analytics 拉真实用户的 LCP/INP/CLS P75 数据回来， 比任何手动 Lighthouse 结果都更能代表线上情况。
High · 实测发现 #6 第三方请求恒定 30 个（含 FB Pixel + unpkg 等）
每个页面稳定 29–34 个第三方请求、300–328 KB； connect.facebook.net/en_US/fbevents.js (96 KB)、unpkg.com/canvas-datagrid、ipapi.co、 fonts.googleapis.com × 7、mpc2-prod-25-...a.run.app（MPC 钱包服务）全页面加载。
与静态审计"6 个无 lazy 策略第三方脚本"高度吻合；实际更严重， 每次 FB Pixel 初始化会连带 Privacy Sandbox 注册 → 3 个 pixel ID 相当于 6 个额外请求。

实测 vs 静态审计对照

审计断言静态推断实测验证
营销页无 SSG代码侧 generateStaticParams = 0✅ 印证 · TTFB 波动 184–710 ms
未登录页也跑 Auth/Wallet ProviderRoot Layout 无条件挂载✅ 印证 · pnls/all 在 /home 被调 6 次
useRequest 缺 cacheKeydiscover/trade store 静态扫描✅ 印证 · 同一接口 4–8 次重复
7 套 Web 字体layout.tsx <link> 清点✅ 印证 · fonts.googleapis.com 被请求 7 次
FB Pixel 3 ID 冗余layout.tsx 静态字符串✅ 印证 · facebook.com/tr 3 次 + Privacy Sandbox 3 次
unpkg.com canvas-datagrid 全站加载layout.tsx 全局 <Script>✅ 印证 · 每个页面都出现
单个大 chunk 拖垮所有页面barrel + 'use client' 蔓延推测✅ 印证 · 757 KB 的 1476-*.js 在所有路由
3+ MB 图片在首屏public/ 目录扫描⚠️ 部分 · cooking/2.gif 1 MB 实测加载，大 hero PNG 尚未在测过页面触发，需在实机上滚动确认
长任务主线程阻塞React 重型库 + Provider 堆叠推测✅ 印证 · 首次访问 7 次长任务 / 1081 ms

本节尚未测到的关键实测项： LCP、FCP、CLS、INP（需前台 tab）、单个用户路径的 CPU 火焰图、实际渲染延迟。 建议配合 PageSpeed Insights 和 Cloudflare Web Analytics 的 P75 数据补齐。

① 构建与依赖

Critical 三套语法高亮库同时存在
证据： package.json 同时声明 highlight.js、react-syntax-highlighter、prismjs。 实际导入仅分布在 5 个文件（markdown render、code viewer、openclaw-skill entry、layout css）， 但三个库均被打入 bundle。
影响： 冗余 ≈ 1.0–1.3 MB min（≈ 350–450 KB min+gz）。
Critical how-to-guides 30 份模板复制粘贴
证据： src/router/how-to-guides/ 下 30+ 目录，每个 index.tsx 恰为 1,909 行； 对比 btc-eth-trading-strategy-complete-battle-plan 与 estimate-roi-virtual-genesis-launches-expected-returns， 骨架 100% 一致，仅内嵌 JSON 文案不同。
影响： ~57K 重复 LOC；构建时间膨胀；每条路由打出独立的 page bundle； 维护任一 UI 改动都要改 30 个文件。应重构为单一组件 + 内容 metadata（app/[locale]/how-to-guides/[slug]/page.tsx + 每 slug 的 content.json）。
Critical ignoreBuildErrors + ignoreDuringBuilds 关闭 CI 保护
证据： next.config.mjs L15–19：eslint.ignoreDuringBuilds: true、 typescript.ignoreBuildErrors: true。
影响： 类型破坏、dead import、无效 dep 可能随代码直接上线。 即使 CI 侧已 "run separately"，线上构建自身没有最终防线。
Critical Namespace import 与 barrel re-export 破坏 tree-shaking
证据： src/ 下 20+ 文件使用 import * as X； components/primitive/index.ts、features/chat-base/index.ts、utils/date/index.ts 等 barrel 用 export * 再导出；lodash 有 41 处以 from 'lodash' 整包引入（optimizePackageImports 只能救部分，顶层 namespace 仍打全包）。
影响： 即使业务只用一个按钮，barrel 会把整个 primitive 包拉进来； import * 彻底禁用 shaking。单次页面跳转额外拉 200–600 KB 不等。
High 双图表栈并存：echarts + TradingView
证据： echarts + echarts-for-react 已在 optimize 列表； public/charting-library/charting_library/bundles/library.8fdacc60e5256d6fcc84.js 单文件 2.7 MB； TradingView 在 layout.tsx L149 <Script defer> 全局加载，不止交易路由。
影响： 非交易页用户也被迫下载 TradingView。应仅在 trade / strategy 路由按需加载。
High 三重状态管理库：zustand + jotai + constate
证据： 三者均在依赖，70 个文件引用。CLAUDE.md 声明 "zustand + constate for state"， jotai / jotai-immer 用途未说明。
影响： 认知成本 + 冗余字节。需审计 jotai 实际用量， 若仅分散几处建议统一到 zustand。
Medium next/dynamic 仅 2 处，重型库全部同步打入
证据： 全仓 next/dynamic 仅见于 spreadsheet 的 canvas-grid 与 Monaco editor modal。 cropperjs、dom-to-image、@zumer/snapdom、@xyflow/react、 canvas-datagrid、katex、react-syntax-highlighter、@lexical/* 等均为静态 import。
影响： 所有路由共担。预计按需化后每路由初始 JS 可降 30–50%。
Low Turbopack 仅 dev，生产仍 webpack
Next 15.3 的 Turbopack 尚未稳定支持 next build，非缺陷，待 15.4+ 再评估。

② 渲染策略

Critical 首页与营销页全部 'use client'
证据：
  • src/router/homepage/index.tsx 及其 11 个同级文件（action/content/footer/trusted/voices/capability/layout/header/powered/download-app-modal）均 'use client'。
  • src/router/use-case/index.tsx、src/router/about/index.tsx 同样 client。
  • 全仓 412/1,652（25%）。
影响： 完全放弃 RSC；静态内容被拉到客户端再水合； Google 爬虫与社媒预览抓取 HTML 时拿到的是骨架；LCP 与 SEO 同时受损。
Critical generateStaticParams 零使用 · <Suspense> 零使用 · 无 loading.tsx
证据： 全仓搜索 generateStaticParams 结果为 0；Suspense 结果为 0；find src/app -name loading.tsx 无命中。仅一个 force-dynamic（api/proxy-favicon）。
影响： 30 份 how-to-guides、about、use-case 等完全静态内容也在运行时渲染； 用户每次访问都要走一次 Node.js 渲染链，CDN 完全无法缓存 HTML。
High Root Layout 8 层 Provider 对所有路由生效
证据： src/app/[locale]/layout.tsx L188–215，嵌套： NextIntlClientProvider → ThemeStoreProvider → FloatLayerProvider → LayoutStoreProvider → GoogleOAuthProvider → UserAuthStoreProvider → ShareChatImageStore → MaybeUserStoreProvider → CustodialWalletStoreProvider。 UserAuthStoreProvider 在挂载时读 credential、解析 device info， CustodialWalletStoreProvider 挂载时绑定 emitter。
影响： 未登录访问 /about 也要跑完整登录态初始化； 水合时间包含每层 Provider 的首次 effect。
High React 19 已装，但未启用 React Compiler 与 PPR
证据： react: ^19、next: 15.3.6； next.config.mjs experimental 仅 optimizePackageImports，无 ppr、无 reactCompiler； package.json 未见 babel-plugin-react-compiler。
影响： React 19 的自动记忆化、PPR 的混合静态/动态能力未兑现。

③ 数据与状态

High 激进轮询，频率密集
证据：
  • src/trade/shared/trade.service.ts L304/326/419/447：仓位、订单、账户概览 3 / 4 / 5–30 / 10 s 轮询。
  • src/store/discover/index.ts L147/181–191：恐慌/贪婪、BTC、全局市场指标 30 s 轮询，均无 cacheKey。
  • src/services/use-chat-list.ts L27：运行中 3 s 轮询聊天列表。
  • src/components/swap/use-simulate-swap.ts、token-window stock、spreadsheet 均 5–10 s 轮询。
  • 23 个文件含 setInterval/setTimeout；抽样 12 个未见 cleanup。
影响： 后台标签页持续消耗带宽/CPU；存在 unmount 后仍触发的内存泄漏风险； API Gateway 成本同比上升。
Medium useRequest 缺失 cacheKey · 无 Next.js fetch 缓存
证据： discover 4 个 useRequest 全无 cacheKey； src/request/service.ts 原生 fetch 不带 cache / next.revalidate 选项； src/features/chat-base/message-view/section/schema/token-link-base.tsx L65–66 设 cacheTime: -1, staleTime: -1（反模式）。
影响： 同一页面多组件重复请求相同接口；无法利用 Next Data Cache / fetch memo。
Medium Zustand / constate 大 Store + 宽选择器
证据： src/store/trade-store/index.ts 导出 41 个 selector； src/store/chat/index.tsx L286 constate(useChatService, s => s) 暴露整个 state； 抽样消费点多为整 store 读取而非细粒度 selector。
影响： 任何一个字段变更都触发订阅组件重渲染。
Good XHR SSE 流式做得不错
src/features/chat-base/core/xhr-stream-utils.ts L152–332：RAF 节流、连接复用、429 识别都到位。 流式 markdown（create-streaming-markdown.tsx）采用段落级哈希 memo，完成段落不再重算。

④ 静态资源与第三方

Critical 单张 27 MB 动图 + 多张 10+ MB 背景
文件大小建议动作
public/images/guide/minara.gif27 MB转 MP4/WebM，预计 1–2 MB
public/images/share/dark/background.png14 MB转 WebP + 降分辨率
public/images/copilot/hero-bg.png13 MB转 WebP + 降分辨率
public/images/share/light/background.png7.1 MB转 WebP + 降分辨率
korea-trading-competition/hero.png4.9 MB转 WebP
og/image-0.png · image-1.png · image-2.png3 × ~3 MBOG 规范 < 500 KB，WebP/JPEG 85q
cooking/1.gif – 4.gif~4 MB 合计转 WebM，< 200 KB/个
影响： 保守可回收 45–55 MB 静态流量； hero PNG 若出现在首屏将直接拉高 LCP。
Critical <head> 中 6 个第三方脚本无 lazy 策略
证据： src/app/[locale]/layout.tsx
  • L87–100 GA gtag.js + 内联 config（两条 <Script>）
  • L96 GTM 内联 init
  • L102–110 markdown-it-fix 显式 strategy="beforeInteractive"，阻塞水合
  • L113–126 Facebook Pixel 初始化 3 个 ID
  • L148 CoinGecko widget
  • L149 TradingView 2.7 MB 库（全局加载）
  • L150 unpkg.com/canvas-datagrid（无 SRI、无版本锁）
Next.js <Script> 默认 afterInteractive，但放 <head> 里仍会与 HTML 解析竞争主线程。
影响： 主线程长任务；Time to Interactive 受多个同步 HTTP 请求串联影响； unpkg 未固定版本存在供应链风险。
High 7 套 Web 字体，其中 Noto Serif SC 对所有语言加载
证据： next/font/google 加载 Roboto 3 档；layout.tsx L154–166 另加 6 个 <link>： DM Serif Text、Pixelify Sans、Jost、Righteous、Noto Serif、Noto Serif SC。
影响： 6 个额外 HTTP 请求 → 150–300 ms 首字节延迟； Noto Serif SC 只有中文语言使用却对所有 locale 加载。
High 24 处原生 <img> 绕过 next/image
全仓原生 <img> 24 处 vs next/image 35 处； 其中 WrappedImage（内部 <img>）被用于 27 MB GIF、13 MB hero PNG。
影响： 无响应式尺寸、无 AVIF/WebP、无懒加载。
Medium SVG 中存在 ≥ 500 KB 大文件与重复文件
minara-logo-with-text-light.svg、minara-logo-with-text-dark.svg 各 618 KB， 且同时存在于 public/svgs/ 与 public/images/；about/blockchain.svg 959 KB； chain/base.svg 793 KB。
整理/精简/去重可回收约 1.5 MB。
Medium next.config 允许任意远程图片来源
images.remotePatterns 通配 * 的 http/https。
安全面（SSRF 风险）+ CDN 账单面都应收紧到白名单。

⑤ 运行时与 React

High Discover news feed 无虚拟化
src/router/session/discover/news-page/index.tsx L60–68 直接对 eventsList 做 .map() 渲染 NewsCard； NewsCard 本身是 framer-motion 动画组件；feed 可能长达 100+ 条。
滚动卡顿；页面加载时 100+ 并行动画；移动端布局抖动。
Medium React.memo 覆盖率 3.9%
64 / 1,652 个 TSX 使用 React.memo； useMemo / useCallback 使用分散在 424 文件，但父组件未 memo 的情况下效果大减； create-markdown-render.tsx L198–227 存在 5 条串联预处理 useMemo 可合并。
Medium 回调/样式对象内联于循环内
app/[locale]/campaign/trading-competition/leaderboard.tsx L36/228/231 循环内 style={{ ... }}； chat message view 16 处 onClick={() => ...} 未抽出。
Medium 热路径残留 console.warn
features/chat-base/message-view/section/create-markdown-render.tsx L53/159/224； 生产构建已开 compiler.removeConsole，但仅对非 dev 环境。
Medium Share layout 三次 getTranslations
src/app/[locale]/share/chat/[id]/layout.tsx L15/46/53 同请求周期 3 次调用。

Top 问题优先级矩阵

#问题影响面估计收益工作量级别
1第三方脚本策略化 + 下沉 TradingView/CoinGecko 至对应路由TBT / LCP / TTI-400 ~ -1200 ms TBTSCritical
227 MB GIF 转 WebM + 13/14 MB hero PNG 转 WebP流量 / LCP-45 MB 流量, -1~2 s LCPSCritical
3how-to-guides 30 模板重构为单路由 + 内容 metadata构建 / 维护 / 包体-57K LOCMCritical
4首页 / about / use-case 切 RSC + 启用 SSGLCP / SEO / CDN 缓存-1.5~3 s LCPMCritical
5语法高亮三合一：保留 react-syntax-highlighter 或改 Shiki SSR包体-1.0 MBSCritical
6移除 ignoreBuildErrors + ignoreDuringBuilds可靠性防止回归SCritical
7namespace import + barrel re-export 重构包体 / tree-shake-200~600 KB/页MCritical
8字体瘦身：删除 Jost/Righteous/Pixelify；Noto Serif SC 仅 zh localeLCP / CLS-150~300 msSHigh
9重型库按 next/dynamic + ssr:false 切分包体 / 初始 JS-30~50%/页 初始 JSMHigh
10引入 Suspense + loading.tsx + 启用 PPR / React CompilerTTI / 体验感知更快MHigh
11discover 轮询加 cacheKey / 指数退避 / visibilitychange 暂停CPU / 带宽 / 成本后台 CPU -70%SHigh
12discover news feed 虚拟化滚动 FPS> 55 FPSSHigh
13echarts vs TradingView 选型统一，或严格路由级分包包体-600 KBMHigh
143 张 OG PNG 压缩 + SVG 去重 + 24 处 <img> 替换 next/image流量 / 体验-10 MBSMedium
15Root layout Provider 下沉：Auth/Wallet 挪到 session 分组水合时间 / SSG 可行性-100~200 ms TTIMMedium
16zustand/constate 细粒度 selector + 审计 jotai 实际用量再渲染次数减少无效 renderMMedium
17Share layout 合并 getTranslations + 删 console.warn 热路径SSR 时延-10~30 ms SSRSLow

工作量：S < 0.5 d / M 0.5–2 d / L > 2 d。以上数值为静态审计估算，需以第 0 阶段基线复测修订。

Core Web Vitals 基线与目标

下表为 Lighthouse 实测基线 (2026-04-19) + 修复后分阶段目标。P0/P1/P2 对应优化方案的阶段。

指标 基线（最差页） P0 末 P1 末 最终 主要拉动修复项
Performance Score 28 ≥ 50 ≥ 80 ≥ 90 —
LCP 44.9 s < 15 s < 5 s < 2.5 s 重定向根治、大资源修、SSG、脚本策略
FCP 9.7 s < 4 s < 2 s < 1.8 s 重定向、字体瘦身、脚本下沉
TBT 2.4 s < 1 s < 0.4 s < 0.2 s 大 chunk 分包、unused JS 清除、高亮库合一
TTI 45.2 s < 18 s < 7 s < 3.8 s Provider 下沉、SSG、动态分包
CLS 0.145 < 0.1 < 0.08 < 0.05 strategy-studio 有布局抖动，需查字体 swap / 图片尺寸
主线程工作 45.8 s < 18 s < 6 s < 2 s 同 TBT；strategy-studio 主线程 46s 最严重
Unused JS 1.6 MB < 1 MB < 400 KB < 200 KB 路由级分包、barrel 重构、tree-shake
页面下载（最差页 /strategy-studio） 11.0 MB < 6 MB < 3 MB < 1.5 MB favicon 修、quick-search 分页、GIF→WebM、TradingView 下沉
TTFB 205 ms < 200 ms < 150 ms < 100 ms 启用 SSG + 边缘缓存（现为原站 SSR）

验证方式：每阶段完成后 用同一条 Lighthouse 命令重跑 5 个页面（docs/perf-baseline/$(date +%Y-%m-%d)/lh-*.json）， JSON 入库并与本基线 diff。任何指标回归 > 10% 阻塞该阶段收尾。

后续

© Minara Discover · 此报告为静态审计产物 · 建议阅读完后归档至 docs/perf-reports/ 保留版本。