Problem
When loading QRScout, users see a "Loading..." screen for several seconds before the app becomes usable. This delay occurs because the Statsig SDK needs to fetch configuration from remote servers before the app can render.
The StatsigProvider in src/app.tsx uses useClientAsyncInit, which blocks rendering while making network requests to Statsig's servers (featureassets.org, prodregistryv2.org, api.statsigcdn.com). The default timeout is 10 seconds, meaning users on slow or unreliable networks could wait up to 10 seconds before seeing anything useful.
This is particularly problematic for FRC scouting scenarios where network connectivity at competition venues is often poor or congested.
Current Usage
Looking at the codebase, Statsig appears to be used only for analytics event tracking (via @statsig/web-analytics), not for feature flags or dynamic configuration that would need to block the initial render. The app would function correctly without Statsig being fully initialized.
Potential Solutions
The simplest fix would be to render the app immediately without waiting for Statsig, then initialize the SDK in the background. This way, analytics events fired before initialization completes would either be queued or dropped (which is acceptable for analytics-only usage), but users would see the app instantly.
Another option would be to reduce the initialization timeout to something much shorter (like 1-2 seconds) so the app becomes usable quickly even if Statsig fails to initialize.
A more involved solution would be to lazy-load the entire Statsig integration so it doesn't block the critical rendering path at all.
Problem
When loading QRScout, users see a "Loading..." screen for several seconds before the app becomes usable. This delay occurs because the Statsig SDK needs to fetch configuration from remote servers before the app can render.
The StatsigProvider in
src/app.tsxusesuseClientAsyncInit, which blocks rendering while making network requests to Statsig's servers (featureassets.org, prodregistryv2.org, api.statsigcdn.com). The default timeout is 10 seconds, meaning users on slow or unreliable networks could wait up to 10 seconds before seeing anything useful.This is particularly problematic for FRC scouting scenarios where network connectivity at competition venues is often poor or congested.
Current Usage
Looking at the codebase, Statsig appears to be used only for analytics event tracking (via
@statsig/web-analytics), not for feature flags or dynamic configuration that would need to block the initial render. The app would function correctly without Statsig being fully initialized.Potential Solutions
The simplest fix would be to render the app immediately without waiting for Statsig, then initialize the SDK in the background. This way, analytics events fired before initialization completes would either be queued or dropped (which is acceptable for analytics-only usage), but users would see the app instantly.
Another option would be to reduce the initialization timeout to something much shorter (like 1-2 seconds) so the app becomes usable quickly even if Statsig fails to initialize.
A more involved solution would be to lazy-load the entire Statsig integration so it doesn't block the critical rendering path at all.