Hi folks,Our team has been working on improving the performance of the Instant process to enhance the start-up time for third-party NTPs by utilizing the existing spare renderer.This task is mainly about passing the instant-process flag via WebPreferences instead of command-line. WebPreferences are applied while the RenderFrame gets created, so that we can do late-bind and change the currency then spare renderer can be used, since spare Renderer has no RenderFrame yet.We're also working out some details with site isolation. With the change to using the existing spare renderer, we want to ensure that other pages (for example same site but different origin) don't share the same process with NTPs that have specified instant process-related APIs.As a starting point, we're reaching out to the navigation-dev@ team for suggestions on the idea of the late-binding instant process flag. I greatly appreciate your time and assistance with this!--
You received this message because you are subscribed to the Google Groups "navigation-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to navigation-de...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/7145dfd2-4589-44e6-9d61-7a8a8a5e9f93n%40chromium.org.
Additionally, we are curious about how to test this change in the wild before fully enabling it. What is your typical flighting/rollout plan? Would you be able to run the experiment on your end?
Hi Alex,
We've completed the prototype. Here are the implementation details:
Add a Feature Flag
- Add a feature flag kInstantUsesSpareRenderer in the /components/ntp folder.
Pass Instant via WebPreferences Instead of a Command-Line Switch
- Add a new WebPreferences parameter enable_instant_api in web_preferences.mojom, and update the corresponding files:
- /third_party/blink/public/common/web_preferences/web_preferences.h
- /third_party/blink/public/common/web_preferences/web_preferences_mojom_traits.h
- /third_party/blink/common/web_preferences/web_preferences_mojom_traits.cc
- Add the FeatureList::IsEnabled(ntp::features::kInstantUsesSpareRenderer) check in ChromeContentBrowserClient::AppendExtraCommandLineSwitches() to skip the --instant-process command line.
- Set the enable_instant_api parameter value if it's an instant URL and the kInstantUsesSpareRenderer flag is enabled in ChromeContentBrowserClient::OverrideWebPreferences.
- Allow later installation and creation of the search box when enable_instant_api is enabled in ChromeRenderFrameObserver::DidClearWindowObject and ChromeContentRendererClient::RenderFrameCreated. Also, move WebSecurityPolicy::RegisterURLSchemeAsDisplayIsolated(chrome_search_scheme) to a later call in ChromeContentRendererClient::RenderFrameCreated.
Enable third party NTPs to use spare renderer
- Bypass the refusal to use the renderer process if ntp::features::kInstantUsesSpareRenderer is enabled inChromeContentBrowserClient::ShouldUseSpareRenderProcessHost.
- Skip the initial IsInstantCheck for Instant URLs using the spare renderer. InstantService::AddInstantProcess(content::RenderProcessHost* host) is called after content::SiteInstanceImpl::GetOrCreateProcess(). As a result, the first spare process doesn't get a chance to add the instant process ID, but RenderProcessHostImpl::MayReuseAndIsSuitable is called, hitting the NOTREACHED().
Add a new field (spare_was_taken = false) in RenderProcessHostImpl::MayReuseAndIsSuitable, RenderProcessHostImpl::IsSuitableHost, and ChromeContentBrowserClient::IsSuitableHost.
- Update ChromeContentBrowserClient::IsSuitableHost to return true if it's an instant URL and the spare render was taken.
Add a getter SiteInstanceProcessAssignment::process_assignment() so we can pass the spare was taken in RenderProcessHostImpl::MayReuseAndIsSuitable.With this change, we continue to adhere to the Process-Per-Site mode for third-party NTPs, ensuring there are no site-isolation violations.
If you think those are good. Next step, I will create a CL for you and site-isolation team to review.
- Existing Behavior: The first third-party NTP will create a process, and subsequent same-site third-party NTPs will share this process.
- New Behavior: The first third-party NTP will attempt to use a spare process if available. If a spare process exists, it will be used, and subsequent same-site third-party NTPs will reuse this spare process. If no spare process is available, it will follow the existing behavior by creating a new process and reusing it for subsequent same-site NTPs.
Additionally, we are curious about how to test this change in the wild before fully enabling it. What is your typical flighting/rollout plan? Would you be able to run the experiment on your end?
Thanks!On Friday, February 28, 2025 at 3:14:42 PM UTC-8 Wangsong Jin wrote:Hi Alex,Thank you for your response! I'm happy to hear you like the idea.
> "I'm assuming it's not going to be needed before any RenderFrames are created in the renderer"
Yes, the Instant process is used to expose the SearchBox API, which is not installed during process creation. Instead, it is created in RenderFrameCreated() and then installed as part of the navigation process.
(We can do WebPreferences instant process flag check in where SearchBox is Created and Installed).
We're in the process prototyping, and the late-binding instant process flag part works. However, we need to address some site-isolation issues with the change. Once we finalize the prototype, we will confirm with you and site-isolation team that it's something we can ship into Chromium. Please feel free to let me know if you have any other suggestions or questions.
Thanks,
Wangsong
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/1ecd24fe-12f2-4306-97e1-177556cf7174n%40chromium.org.