IntersectMBO / IntersectMBO/govtool

🚀 Performance Optimization Initiative

Open
#4,005 0 comments 1 reaction 0 assignees View on GitHub
Dominant language
HTML
Stars
21
Forks
29
Avg merge
2d 22h
Merged PRs (30d)
7

Description

## 🚀 Performance Optimization Initiative

**Summary:**
User perception of application speed is critical for overall experience. There’s a noticeable gap between sub-second and 1+ second load times, especially on the Cardano GovTool. We should make performance a priority for both user satisfaction and future scalability.

---

### Action Items

#### 1. Address Frontend Performance Bottlenecks
- Review and resolve major issues reported by Lighthouse, especially those impacting LCP, FCP, TTI, and CLS.
- Optimize asset loading, code splitting, and reduce JS/CSS bundle sizes.
- Investigate lazy-loading and defer non-critical resources.

#### 2. Caching & Pre-rendering
- Implement caching, pre-rendering, or server-side rendering (SSR) wherever applicable.
- Consider static generation for pages/data that do not change often.

#### 3. API Response Caching
- Cache API responses wherever possible to avoid redundant computations.
- Explore HTTP cache headers, CDN caching, and in-memory caches for frequently accessed endpoints.

#### 4. Background Aggregation & Pre-computation
- Offload heavy aggregations and stats generation to background jobs/workers.
- Pre-compute and store network/chain stats at regular intervals.

#### 5. Prefer Memory/Storage over Real-time Compute
- Where feasible, cache or pre-calculate results (even periodically) rather than on-the-fly.
- Use background jobs for periodic updates of costly computations.

---

### Cardano GovTool Specific Suggestions

1. **Governance Actions:**
- Few in number; precompute details/stats and update every 10–20s (block time).

2. **DRep Data:**
- DRep stats/details can also be precomputed and refreshed regularly.

3. **Regular User States:**
- Cache regular users’ last known state (voting power, actions, votes, etc.) and show immediately on load.
- Update data in background when new info becomes available.

4. **Non-Wallet connected Pages:**
- Precompute and update all public data each block period (10–20s).
- Serve instantly from cache—current data volume is manageable.

---

**Goal:**
Achieve perceived sub-second load times for core user interactions, minimize time-to-interactive, and deliver a smooth, modern user experience.

---

**Let’s discuss prioritization and implementation steps in this thread!**

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.