Possible performance improvements
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 11
- Forks
- 26
- Avg merge
- 11h 58m
- Merged PRs (30d)
- 16
Description
### Is your feature request related to a problem?
Not a specific problem, but general performance issues.
### Describe the solution you'd like
- [ ] All results in `/lib/api/contracts` can be cached, as they probably change infrequently and are called very often.
- [ ] Move `useChartData()` fetching to `getStaticProps()`
- [ ] Move independent calls to `Promise.all()`, instead of doing them sequentially.
- [ ] Re-enable ENS pre-fetching in apollo queries (or at least investigate why this was disabled/commented out)
- [ ] Add dynamic imports for OrchestratorList, ExplorerChart. these are big components with dependencies that will then be loaded when scrolled into view. This significantly reduces initial JS payload.
### Describe alternatives you've considered
_No response_
### Additional context
_No response_
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by inspecting /lib/api/contracts, useChartData(), getStaticProps(), the Apollo queries, and the OrchestratorList and ExplorerChart components. Measure current request timing and initial JavaScript payload, then evaluate each listed optimization; done means the selected improvements are implemented and their performance impact is verified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, frontend, performance
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100