Improve Governance page load speed without cache

[ECWireless]

🧪 Performance Benchmark Report — https://explorer.livepeer.org/voting/

Date: 2025-11-12
Environment: Lighthouse v13.0.1 (mobile emulation, slow-4G, 4× CPU slowdown)
Runs: 3 consecutive

---

📊 Median Results (3-run average)

Metric	Run 1	Run 2	Run 3	Median	“Good” Threshold	Status
Performance Score	≈ 0.55	≈ 0.57	≈ 0.56	≈ 0.56	≥ 0.90	⚠️ Needs work
First Contentful Paint (FCP)	2.2 s	1.9 s	2.0 s	2.0 s	≤ 1.8 s	⚠️ Slightly slow
Largest Contentful Paint (LCP)	13.9 s	13.8 s	13.3 s	≈ 13.7 s ❌	≤ 2.5 s	🚨 Severe delay
Speed Index	2.2 s	1.9 s	2.1 s	2.1 s ✅	≤ 3.0 s	✅ Good
Cumulative Layout Shift (CLS)	0.00	0.00	0.00	0.00 ✅	≤ 0.10	✅ Excellent
Total Blocking Time (TBT)	3.4 s	3.2 s	3.3 s	≈ 3.3 s ❌	≤ 0.2 s	🚨 Poor
Time to Interactive (TTI)	31 s	32 s	33 s	≈ 32 s ❌	≤ 4 s	🚨 Poor
Total Transfer Size	5.4 MB	5.5 MB	5.5 MB	≈ 5.5 MB ❌	< 2 MB	🚨 Heavy

---

🩺 Diagnosis Summary

✅ The Good

• Server response and initial paint are reasonable (≈ 2 s FCP).
• Layout stability is perfect (0 CLS).
• Speed Index ≈ 2 s → visual load is fast once LCP finally renders.

⚠️ The Bad

• LCP ≈ 13–14 s – the hero element or first major content loads extremely late.
• ~4 MB of JavaScript blocking the main thread.
• TTI > 30 s & TBT ≈ 3 s → page is effectively unresponsive for users after visual paint.
• Suspense/data-fetch hydration and graph/contract widgets likely defer LCP.

---

🧩 Probable Root Causes

1. Large client bundle: heavy component tree or charting/contract logic shipped upfront.
2. Late-loading hero section: delayed render of voting widget or GraphQL data fetch.
3. Hydration cost: React mounts large dynamic tree (charts, delegators, wallet context).
4. Third-party scripts: analytics or embed scripts running before interactivity.

---

🛠️ Recommended Actions (ordered by impact)

Priority	Goal	Actions
1️⃣ Improve LCP to < 2.5 s	Render critical content early	• Server-render the vote header & hero stats. • Defer non-critical charts using next/dynamic({ ssr:false }).
2️⃣ Cut bundle size by > 70 %	Lower JS blocking time	• Run @next/bundle-analyzer. • Move heavy UI to Server Components. • Lazy-load rarely used widgets (voting modals, charts).
3️⃣ Defer client work	Lower TBT/INP	• Load analytics afterInteractive. • Use React.startTransition for updates. • Split hydration via smaller islands.
4️⃣ Cache data server-side	Speed up LCP & TTI	• Pre-render vote stats (ISR revalidate 10–30 s). • Parallelize GraphQL fetches.
5️⃣ Trim assets	Reduce transfer size	• Drop unused libs and polyfills. • Verify images are compressed and cached.

---

🎯 Target Benchmarks

Metric	Current	Target	Δ
LCP	13.7 s	≤ 2.5 s	−82 %
TBT	3.3 s	≤ 0.2 s	−94 %
TTI	32 s	≤ 4 s	−88 %
JS transfer	4.0 MB	≤ 0.5 MB gz	−88 %
CLS	0.00	≤ 0.10	Maintain ✅

Expected result: overall Lighthouse Performance Score ≈ 0.56 → 0.93–0.95 once bundle size and LCP are optimized.

---

📈 Additional Steps

• Add @vercel/analytics to start collecting real LCP/INP/CLS field data.
• Automate Lighthouse runs in CI for regression alerts.
• Re-test after lazy-loading graphs / reducing bundle size.

---

Compiled from 3 Lighthouse v13 mobile runs on 2025-11-12.

[ECWireless]

Closing this, as the CI has been added in #487 , and the main non-cache load speeds users have identified are the home and orchestrators page (rather than this page), which is addressed in #487 as well