Files

OG T d91958eab7

E2E Health Check / e2e-health (push) Successful in 16s

Details

Lighthouse 測試結果:
- Performance Score: 84% ✅
- LCP: 4.4s (需優化，非 Replay 問題)
- FCP: 0.9s ✅
- CLS: 0 ✅ 優秀
- TBT: 10ms ✅ 優秀

結論: Sentry Replay 採用 Lazy Loading，對初始載入影響極低

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

2026-03-31 16:13:44 +08:00

2.6 KiB

Raw Blame History

#127 Sentry Session Replay 效能評估報告

測試日期: 2026-03-31 16:09 (台北時間) 測試工具: Lighthouse 13.0.3 測試 URL: https://awoooi.wooo.work Replay 配置: replaysSessionSampleRate=0.1, replaysOnErrorSampleRate=1.0

效能指標摘要

指標	數值	目標	狀態	說明
Performance Score	84%	>80%	✅ 通過	整體良好
LCP (Largest Contentful Paint)	4.4s	<2.5s	⚠️ 需優化	最大內容渲染較慢
FCP (First Contentful Paint)	0.9s	<1.8s	✅ 優秀	首次繪製快速
CLS (Cumulative Layout Shift)	0	<0.1	✅ 優秀	無佈局偏移
TBT (Total Blocking Time)	10ms	<200ms	✅ 優秀	阻塞時間極短
Speed Index	3.0s	<3.4s	✅ 通過	視覺完成速度
TTI (Time to Interactive)	4.4s	<3.8s	⚠️ 需優化	可交互時間較長

Sentry Replay 影響分析

觀察結果

Lazy Loading: Sentry SDK 採用延遲載入策略
- 初次頁面載入時未觀察到 Sentry 相關網路請求
- Replay 模組僅在需要時動態載入

採樣率配置:

replaysSessionSampleRate: 0.1,  // 10% 隨機 session
replaysOnErrorSampleRate: 1.0,  // 100% 錯誤 session

Bundle 影響:
- 未觀察到顯著的 JavaScript bundle 增加
- 未影響 TBT (Total Blocking Time)

結論

Sentry Session Replay 對初始載入效能影響極低

原因:

Lazy loading 策略
10% 採樣率避免大量 session 錄製
異步載入不阻塞主線程

LCP/TTI 優化建議 (非 Replay 相關)

LCP 和 TTI 較慢的根因分析:

Dashboard API 請求延遲
- 多個並行 API 請求 (health, incidents, approvals)
- 建議: 實作 API 聚合或 BFF 合併端點
SSR/ISR 優化
- 當前完全 CSR (Client-Side Rendering)
- 建議: 評估 ISR (Incremental Static Regeneration) 可行性
圖片/字體優化
- 確認 VT323 字體使用 font-display: swap
- 確認關鍵圖片使用 priority 預載

測試詳情

{
  "performance_score": 0.84,
  "lcp": 4400.75,
  "fcp": 945.25,
  "cls": 0,
  "tbt": 11,
  "speed_index": 2969.08,
  "tti": 4402.80
}

建議後續行動

#	行動	優先度	預估工時
1	API 聚合端點 (BFF 合併)	P2	2h
2	ISR 評估與實作	P3	4h
3	字體 preload 優化	P3	30min

Replay 相關: 維持現有配置，無需調整

報告生成: Claude Code (#127 Replay Performance Evaluation)

2.6 KiB Raw Blame History