Improve treasury end date load speed

[ECWireless]

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

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.50	≈ 0.52	≈ 0.51	≈ 0.51	≥ 0.90	⚠️ Needs improvement
First Contentful Paint (FCP)	1.8 s	1.8 s	1.8 s	1.8 s ✅	≤ 1.8 s	✅ Excellent
Largest Contentful Paint (LCP)	22.0 s	21.9 s	21.9 s	≈ 21.9 s ❌	≤ 2.5 s	🚨 Severe delay
Speed Index	1.8 s	1.8 s	1.8 s	1.8 s ✅	≤ 3.0 s	✅ Excellent
Cumulative Layout Shift (CLS)	0.00	0.00	0.00	0.00 ✅	≤ 0.10	✅ Excellent
Total Blocking Time (TBT)	~3.2 s	~3.3 s	~3.4 s	≈ 3.3 s ❌	≤ 0.2 s	🚨 Poor
Time to Interactive (TTI)	~31 s	~32 s	~32 s	≈ 32 s ❌	≤ 4 s	🚨 Poor
Total Transfer Size	~5.5 MB	~5.4 MB	~5.4 MB	≈ 5.4 MB ❌	< 2 MB	🚨 Heavy

---

🩺 Diagnosis Summary

✅ The good

• FCP and Speed Index are both strong (≈ 1.8 s) — the initial shell paints quickly.
• CLS = 0 → layout is stable.
• Server response time is fast and consistent.

⚠️ The bad

• LCP ≈ 22 s: the main treasury content doesn’t appear until all client-side data and JS finish loading.
• TBT ≈ 3 s, TTI ≈ 32 s: JS parsing and hydration keep the main thread busy for a long time.
• JS transfer ≈ 4 MB: excessive bundle weight is the root cause.

---

🧩 Probable Root Causes

1. Client-side data fetching — treasury values or balances load only after hydration, delaying the largest visible element.
2. Large client bundle — expensive logic or libraries included in the initial route bundle.
3. Hydration cost — the component tree mounts all at once after load.
4. Third-party scripts — analytics or embeds run before interactivity.

---

🛠️ Recommended Actions (ordered by impact)

Priority	Goal	Recommended Actions
1️⃣ Server-render treasury data	Show main content instantly	• Fetch treasury data via getServerSideProps or ISR (revalidate interval). • Avoid client-only fetch on initial load.
2️⃣ Reduce JS bundle size	Lower TBT / improve responsiveness	• Run @next/bundle-analyzer. • Lazy-load non-critical UI (e.g., secondary tables or wallet logic). • Convert reusable components to Server Components.
3️⃣ Optimize hydration	Lower INP & TTI	• Break large components into smaller chunks. • Use React.startTransition for state updates. • Memoize expensive effects.
4️⃣ Defer analytics	Free up main thread	• Load analytics with strategy:"afterInteractive".
5️⃣ Maintain light assets	Keep total < 2 MB	• Remove unused libraries and polyfills. • Images are already optimized.

---

🎯 Target Benchmarks

Metric	Current	Target	Δ
LCP	21.9 s	≤ 2.5 s	−89 %
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.51 → 0.93–0.95 after server-rendering data and slimming the JS bundle.

---

📈 Additional Steps

• Move treasury data fetching to the server with ISR or getServerSideProps.
• Add @vercel/analytics to confirm improvements via field data (LCP/INP/CLS).
• Run Lighthouse after each major change to track progress.
• Automate Lighthouse runs in CI for regression detection.

---

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