docs(qa): #127 Sentry Replay 效能評估報告
All checks were successful
E2E Health Check / e2e-health (push) Successful in 16s

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>
This commit is contained in:
OG T
2026-03-31 16:13:44 +08:00
parent d5c1d75238
commit d91958eab7
2 changed files with 101 additions and 1 deletions

View File

@@ -5,10 +5,11 @@
---
## 📍 當前狀態 (2026-03-31 16:00 台北)
## 📍 當前狀態 (2026-03-31 16:20 台北)
| 項目 | 狀態 |
|------|------|
| **#127 Replay 效能評估** | ✅ **完成** (Lighthouse 84% - Replay 影響極低) |
| **Phase 22 P0** | ✅ **leWOOOgo 模組化修復** (`8313a37` - OpenClaw/GitHub/Health Services) |
| **#126 Frontend Replay UI** | ✅ **完成** (`2f02f15` - UXAuditCard + useUXAudit hook) |
| **K0 基礎穩定化** | ✅ **低風險完成** (K0.1/3/4/6/7) |

View File

@@ -0,0 +1,99 @@
# #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 影響分析
### 觀察結果
1. **Lazy Loading**: Sentry SDK 採用延遲載入策略
- 初次頁面載入時未觀察到 Sentry 相關網路請求
- Replay 模組僅在需要時動態載入
2. **採樣率配置**:
```typescript
replaysSessionSampleRate: 0.1, // 10% 隨機 session
replaysOnErrorSampleRate: 1.0, // 100% 錯誤 session
```
3. **Bundle 影響**:
- 未觀察到顯著的 JavaScript bundle 增加
- 未影響 TBT (Total Blocking Time)
### 結論
**Sentry Session Replay 對初始載入效能影響極低**
原因:
- Lazy loading 策略
- 10% 採樣率避免大量 session 錄製
- 異步載入不阻塞主線程
---
## LCP/TTI 優化建議 (非 Replay 相關)
LCP 和 TTI 較慢的根因分析:
1. **Dashboard API 請求延遲**
- 多個並行 API 請求 (health, incidents, approvals)
- 建議: 實作 API 聚合或 BFF 合併端點
2. **SSR/ISR 優化**
- 當前完全 CSR (Client-Side Rendering)
- 建議: 評估 ISR (Incremental Static Regeneration) 可行性
3. **圖片/字體優化**
- 確認 VT323 字體使用 font-display: swap
- 確認關鍵圖片使用 priority 預載
---
## 測試詳情
```json
{
"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)*