Reduce redundant site API requests during Atomic wait#108624
Closed
Reduce redundant site API requests during Atomic wait#108624
Conversation
During the entrepreneur setup flow's loading screen, the app polls
GET /rest/v1.2/sites/{id} every 1 second while waiting for the site
to become Atomic. This generates 25+ identical requests over ~60s,
each returning ~62KB.
Two changes:
1. Use exponential backoff (3s → 6s → 12s, capped at 15s) in
waitForLatestSiteData instead of a fixed 1s interval. This
reduces requests from ~25 to ~6 with no UX impact since the
user is on a loading screen.
2. Eliminate a redundant dual-fetch in useSite(). Previously, both
the SITE_STORE resolver (v1.1) and a Redux requestSite dispatch
(v1.2) fired simultaneously on mount, making two requests for
the same data. Now, useSite waits for the SITE_STORE resolver
to complete and syncs its result to the Redux store via
receiveSite, falling back to requestSite only if the resolver
fails.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Jetpack Cloud live (direct link)
Automattic for Agencies live (direct link)
|
Contributor
|
This PR modifies the release build for the following Calypso Apps: For info about this notification, see here: PCYsg-OT6-p2
To test WordPress.com changes, run |
bf4c614 to
1f8b38d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
During the entrepreneur setup flow's loading screen (waitForAtomic step), the app aggressively polls
GET /rest/v1.2/sites/{id}every 1 second while waiting for the site to become Atomic. This generates 25+ identical requests over ~60 seconds, each returning ~62KB of data — all just to check a single boolean (is_wpcom_atomic).Additionally, when the processing step mounts, two independent code paths in
useSite()fire simultaneous requests for the same site data:GET /rest/v1.1/sites/{id}?force=wpcomGET /rest/v1.2/sites/{id}This PR addresses both issues:
1. Exponential backoff for
waitForLatestSiteDataFile:
client/landing/stepper/hooks/use-wait-for-atomic.tsChanged from a fixed 1s polling interval to exponential backoff starting at 3s, doubling each iteration, capped at 15s (3s → 6s → 12s → 15s → 15s...). This reduces requests from ~25 to ~6 with negligible UX impact since the user is on a loading screen anyway. This matches the pattern already used by
waitForPluginInstall.2. Deduplicate dual-fetch in
useSite()File:
client/landing/stepper/hooks/use-site.tsPreviously,
useSite()triggered two independent fetch paths on mount:useSelect→ SITE_STOREgetSite()resolver → v1.1 API requestuseEffect→ ReduxrequestSite()→ v1.2 API requestNow, the hook waits for the SITE_STORE resolver to complete first. If it succeeds, the site data is synced to the Redux store via
receiveSite()— no second network request. If the resolver fails, it falls back torequestSite()as before.Test plan
🤖 Generated with Claude Code