Background Throttling optimized for High-Performance Desktop Apps

While the launch of the Here Enterprise Browser and our exciting new brand marks a significant milestone, we remained focused on strengthening the core foundations that power it. Today, we are thrilled to introduce a powerful new capability in our Chromium-based Container that addresses a critical challenge many of our users face: managing background throttling.

This new feature empowers developers to ensure their applications perform reliably even when running in the background, without sacrificing the performance benefits of Chromium's default throttling. Best of all, by implementing this in the Container layer, we’ve ensured that the capabilities are also available in Workspace and in Here™ Enterprise Browser.

Let's dive into how this new option works and how it can help you maintain the efficiency and reliability of your applications.

What is Chromium's Background Throttling?

Chromium's background throttling is a feature designed to optimize browser performance and enhance user experience by managing the resource consumption of background tabs. When a tab is not actively viewed by the user, Chromium reduces its access to CPU and network resources. This is achieved through a combination of techniques, including limiting the execution of JavaScript tasks and deferring the loading of certain resources. The primary goal is to conserve battery life on mobile devices and reduce overall system load, ensuring that the active tab runs smoothly and efficiently.

Background throttling in Chromium works by imposing stricter limits on background tabs compared to foreground ones. For example, background tabs have reduced timers for JavaScript execution and are subject to stricter quotas on resource usage. This prevents background processes from consuming excessive CPU cycles, which can lead to slower performance and increased power consumption. By intelligently managing these resources, Chromium ensures that users experience faster load times and smoother interactions with the tabs they are actively using, while still allowing background tabs to perform necessary tasks in a limited capacity.

Limitations of Chromium Background Throttling

While Chromium's background throttling is beneficial for optimizing resource usage, it can pose challenges for high-performance desktop applications such as real-time trading and market data applications. Built on Chromium, our Container is widely used in financial services for creating complex, multi-window desktop applications. Certain windows or views in these applications may require consistent and reliable performance, even when they are not actively in focus.

Consider a simple example of an alarm clock app. The user sets a time in this app, puts it in the background (by minimizing the window, changing to a different page or tab, or simply has another window on top), and when the specified time is reached, a notification is supposed to fire. With Chromium's default background throttling behavior, the alarm clock app could be throttled when it is not in the foreground, potentially causing the alarm notification to be delayed or missed entirely. This could lead to significant problems, especially with time-sensitive applications, such as trading applications, where missing an alert or notification can have serious consequences.

New Throttling Controls

To address these challenges, we have introduced new options for Windows and Views. These throttling controls allow developers to manage the background behavior of their applications more effectively, ensuring that critical functions remain reliable even when not in the foreground.

For Windows, the throttling option includes three statuses:
Enabled: This is the default state where background throttling is active, optimizing resource usage.
Scheduler-Disabled: This state disables throttling of the JavaScript context in the render process, ensuring continuous code execution even in the background. This is crucial for applications that need to raise IAB messages or handle other background tasks.
Disabled: Completely turns off all forms of throttling, including both scheduler and painter throttling. This ensures that both code execution and frame rendering occur as if the window were in the foreground at all times.

For Views, the throttling option includes:

Enabled: The default state where background throttling is active.
Scheduler-Disabled: Disables throttling of the JavaScript context, ensuring that critical tasks are not delayed. This does not affect painter throttling, which means frame rendering might still be throttled.

The difference in throttling options between Windows and Views is due to the distinct nature of scheduler throttling and painter throttling:

Scheduler Throttling: Refers to the throttling of the JavaScript context in the render process, affecting code execution in background Views and Windows. For example, it impacts the ability of an application provider to raise IAB messages in background Views or Tabs.
Painter Throttling: Refers to the throttling of render frames being generated and outputted. This affects how the content is drawn on the screen, and end-users can notice this when navigating to a throttled View that needs to re-render or when APIs like requestAnimationFrame do not resolve promptly.

For Views, painter throttling always remains in effect, which means we will not generate new frame requests for hidden content and callbacks, such as window.requestAnimationFrame, until the content is shown again. This behavior aligns with Chrome and we expect that allowing developers to disable this type of throttling may cause performance and stability issues for the apps running in those views.

By setting a view, such as our alarm clock example, to scheduler-disabled, we can ensure that we receive our alarm clock notification without delay. This fine-tuned control over throttling allows developers to balance the need for resource optimization with the necessity of maintaining reliable background operations for crucial application features.

Best Practices and Recommendations

While we are introducing this very powerful and useful feature, we do not recommend customers use it in all cases. The advantage of what we are providing is that we can target specific elements not to throttle, thereby maintaining the overall performance benefits of Chromium's throttling while narrowly targeting just the specific parts that need to remain active. This approach helps optimize resource usage effectively without compromising the reliability of critical background processes.

Documentation & Resources

To learn more visit our documentation page for a how to guide, and further instructions on how to customize your throttle controls.

Have questions or want to get in touch with someone on our support team? Email us at support@here.io with subject ‘Background Throttling’ for further assistance.