Performance: Accelerate Initial Network Health Checks

[AjayiMike]

Is your feature request related to a problem? Please describe.

When the application first loads, there is a noticeable delay as it validates the status of all available testnet networks. While we have implemented a progressive, tiered loading system (selected -> priority -> others), the overall process of checking each network's RPC endpoints can still feel slow to the end user. This is primarily dependent on the response times of the public RPCs for each network.

Describe the solution you'd like

We would like to optimize the network validation process to make the UI feel faster and more responsive. This is an open-ended performance task, and we are open to various solutions.

Here are some potential avenues for improvement that a contributor could explore:

1. Reduce RPC Timeouts: The current timeout for checking an RPC endpoint is 15 seconds (see RPC_TEST_TIMEOUT in src/lib/networks/index.ts). This is very generous. Reducing this to a more aggressive value (e.g., 5 seconds) could significantly speed up the process by failing unresponsive RPCs faster, but this would also mean that we'll end up with a reduced number of active networks. The optimal value would need testing.

2. Increase Concurrency: The validation for "priority" and "other" networks is done in batches (Promise.all for priority, forEach for others). We could explore increasing the concurrency of these checks, perhaps using a queue or batching mechanism to run more testRPCEndpoint calls in parallel without overwhelming the browser.

3. Centralized Health Check Service: A more advanced but highly effective solution would be to move the health checks to the backend. cron job an create an endpoint that fetches the status of all networks, caches the results for a short period (e.g., 10 minutes), and serves this cached status to all clients. This would mean only our server validates the RPCs, not every single user's browser, drastically reducing the load and perceived wait time.

4. Smarter RPC Selection: Instead of treating all public RPCs from chainid.network equally, we could introduce a "primary" high-quality RPC (e.g., from a provider like Alchemy or Infura) for popular networks and use the others as fallbacks.

Describe alternatives you've considered

N/A

Additional context

This is a fantastic opportunity for someone interested in frontend performance optimization.

• Core Logic: The main client-side orchestration happens in the initializeNetworks function within src/lib/store/networksStore.ts.
• RPC Validation: The actual RPC test happens in the testRPCEndpoint and filterWorkingRPCs functions in src/lib/networks/index.ts.
• Open to Ideas: We welcome other creative solutions to this problem. If you have a different approach, please feel free to propose it in the issue comments before starting work.

Improving this flow will make a significant difference to the user experience of the entire application.