perf: Two-phase HTTP client init to avoid macOS Keychain blocking#12208
Merged
anthonyshew merged 1 commit intomainfrom Mar 9, 2026
Merged
perf: Two-phase HTTP client init to avoid macOS Keychain blocking#12208anthonyshew merged 1 commit intomainfrom
anthonyshew merged 1 commit intomainfrom
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Build the reqwest HTTP client in two phases to remove ~200ms of macOS Keychain enumeration from the critical path: Phase 1 (instant): Build a client with bundled Mozilla CAs (webpki-roots). Available immediately for any early callers. Phase 2 (background): Build a full client with system Keychain CAs (native-roots) on a background thread. Once ready, all subsequent requests use this client, supporting corporate proxy CAs. This is transparent to all users — standard HTTPS works immediately via Phase 1, and corporate proxy environments get full CA support once Phase 2 completes (~200ms later, well before any remote cache or API request is made).
anthonyshew
force-pushed
the
perf/two-phase-http-client
branch
from
60b79b1 to
85c12f0
Compare
Contributor
Coverage Report
|
Contributor
Author
|
The Windows partition flake occurred because the Chocolatey CDN flakes, as it is known for doing. Merging past this. |
github-actions bot
added a commit
that referenced
this pull request
Mar 9, 2026
## Release v2.8.15-canary.11 Versioned docs: https://v2-8-15-canary-11.turborepo.dev ### Changes - release(turborepo): 2.8.15-canary.10 (#12205) (`a9bbb9e`) - perf: Race parallel git subprocesses against filesystem walk for optimal index construction (#12206) (`9fef3f5`) - perf: Two-phase HTTP client init to avoid macOS Keychain blocking (#12208) (`892cb1b`) --------- Co-authored-by: Turbobot <turbobot@vercel.com>
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
1 participant
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
Splits HTTP client initialization into two phases to remove ~200ms of macOS Keychain enumeration from the critical path.
spawn_blocking. Once ready,get_or_init()returns this client instead.Why
reqwest::Client::builder().build()withrustls-tls-native-rootstakes ~200ms on macOS becauserustls-native-certsenumerates the system Keychain via the Security framework. This was on the critical path duringactivate(), adding 200ms to everyturbo run.No HTTP request is made in the first 200ms of a run — remote cache requests happen after index construction (~350ms+) and telemetry flushes at shutdown (~1000ms+). The full client is always ready before it's needed.
Impact
~100ms wall clock improvement on macOS (the HTTP init now fully overlaps with index construction instead of partially overlapping). On Linux, the native-root loading is already fast (<20ms), so this is a no-op.
What changes
Cargo.tomlreqwest/rustls-tls-webpki-rootsfeaturelib.rsbuild_http_client_webpki_only()(webpki-only, instant)shared_http_client.rsOnceLocks:fast_client(Phase 1) andnative_client(Phase 2).get_or_init()prefers native if ready, falls back to fast.Corporate proxy support
Corporate environments with custom root CAs are fully supported. The Phase 2 client loads all system CAs, including custom ones installed in the macOS Keychain. Since Phase 2 completes ~200ms after
activate()and the earliest HTTP request happens ~350ms+ into the run, the full client is always available when needed.