A new product release tends to focus on the big things: new features and important bug fixes. But alongside those changes, the io.Connect team continuously works on easy to miss improvements to areas such as startup time, application and Workspace loading, memory and resource usage, and diagnostics.
In this article, we’ll go through some of the performance-related improvements introduced in io.Connect Desktop over the past few years, what they address, and highlight whether you get the benefit automatically or need to do something to take advantage of it.
The performance-related changes described below fall into these categories.
Automatic after upgrade
These improvements are part of the platform. Developers generally do not need to enable them, but must upgrade to a version that contains them.
Requires configuration
These capabilities are available in the platform but must be enabled or adjusted in the system or application configuration.
Requires application changes
These improvements depend on how an application initializes, renders, loads data, manages subscriptions, or uses the io.Connect APIs.
Primarily useful for diagnostics
These capabilities help teams measure performance and locate bottlenecks. They do not improve performance by themselves.
Architecture and platform startup
Simplified architecture in version 10.0
Type: Automatic after upgrade
One of the most substantial changes arrived with io.Connect Desktop 10.0. The platform architecture was simplified by removing the separate Gilding executable and its associated Gateway overhead from the default architecture.
Web Groups also became the default window-management implementation.
These changes reduce the number of components involved in starting and running the platform. The Seed Project model introduced with the newer architecture also simplifies how customized io.Connect Desktop distributions are built and maintained.
With io.Connect Desktop 10.0 and later you can select between two platform modes: Default and Advanced. The default mode is lighter because it omits visual integration with native apps and classic groups, so consider which to use (default mode also can run on macOS).
Developer action: Upgrade to a supported 10.x version and compare startup and baseline resource usage with the previous deployment.
See io.Connect Desktop Documentation - Changelog > Platform > io.Connect Desktop 10.0
Loading Global Layouts and Workspaces
Large Global Layouts and Workspaces can trigger many application launches, authentication requests, preload scripts, and data requests at the same time.
Several platform features can reduce or redistribute this initial workload.
Workspace loading strategies
Type: Requires configuration
io.Connect Desktop supports three loading strategies for Workspace applications:
-
"direct"— applications are loaded immediately; -
"delayed"— applications are loaded in batches; -
"lazy"— applications are loaded when required.
The strategy can be configured under the "loading" property in the definition of the Workspaces App.
When it helps:
-
A Workspace contains many applications.
-
Only one or two applications need to be visible initially.
-
Applications make expensive authentication or data requests.
-
Restoring the Workspace causes a large CPU or network spike.
Trade-off: Delayed or lazy loading improves the time required to reach the initial usable state, but applications loaded later will not be immediately available.
Developer action: Compare direct, delayed, and lazy loading with a representative Workspace.
See Workspaces loading strategies
Disabling automatic restoration of the default Global Layout
Type: Requires configuration
A default Global Layout can be restored automatically when io.Connect Desktop starts. This is useful when users require the same collection of applications every day, but it also means that platform startup immediately triggers Layout restoration and application startup.
To disable automatic restoration, use the following configuration:
{
"layouts": {
"restoreDefaultGlobalOnStartup": false
}
}
The default Layout can then be restored programmatically when appropriate:
const defaultLayout = await io.layouts.getDefaultGlobal();
if (defaultLayout) {
await io.layouts.restore(defaultLayout);
}
In-memory Layout store
Type: Requires configuration
Available since io.Connect Desktop 9.4, the in-memory Layout store allows users and applications to perform normal Layout operations without persisting the Layouts across platform sessions. This is useful when you have your own custom Layout service which imports Layouts on system startup and exports them on system shutdown allowing you to persist Layouts across user sessions.
io.Manager
Local caching of io.Manager data
Type: Requires configuration
Available since io.Connect Desktop 9.4, io.Manager caching allows data received from io.Manager to be persisted locally. The platform can use the cache during connection interruptions or when opening an io.Manager session takes too long. The relevant configuration is placed under the "server" top-level key.
Developer action: Define how stale the cached configuration is allowed to be. Caching should support an availability requirement, not conceal a consistently slow or unreliable io.Manager deployment.
See io.Manager platform configuration.
Electron cache management
Handling cache from previous platform versions
Type: Requires configuration
Since 9.4 io.Connect Desktop can clear Electron cache from previous versions on startup, preventing cache bloat.
Developer action: Follow the documented cache-handling options rather than manually deleting arbitrary folders from a user installation.
See io.Connect Desktop Documentation - Changelog > Platform > io.Connect Desktop 9.4
Window pooling
Pre-warmed Web Page Search windows
Type: Requires configuration
Version 9.7 introduced window pooling for the Web Page Search application. Instances can be prepared in advance so that a window does not have to be created from scratch every time it is requested.
Developer action: Treat pooling as an architectural pattern for applications that must appear with very low latency.
Trade-off: Pre-warmed or hidden windows still consume resources. Pooling can reduce launch latency while increasing baseline memory consumption.
See io.Connect Desktop Documentation - Changelog > Platform > io.Connect Desktop 9.7
Rendering
Critical CSS injection support for faster first contentful paint
Type: Requires configuration
io.Connect Desktop supports injecting CSS files and preload scripts into applications.
Version 9.7 added the ability to mark these resources as critical. If a critical resource cannot be injected, the failure is treated as a critical error instead of allowing the application to continue in an incomplete state.
See Critical Preload Scripts and Injected Styles.
Preload scripts
Improved preload handling
Version 9.0 improved preload-script loading. The "useBase64PreloadScripts" property allows you to control how io.Connect Desktop will import preload scripts.
See io.Connect Desktop Documentation - Changelog > Platform > io.Connect Desktop 9.0
Library initialization
Improved .NET initialization handling
Type: Automatic after upgrade
Version 9.2 improved .NET library initialization for timeout-related corner cases.
See io.Connect Desktop Documentation - Changelog > Platform > io.Connect Desktop 9.2
Observability with io.Insights
Type: Primarily useful for diagnostics
io.Insights is based on OpenTelemetry and can provide metrics, traces, and logs for the io.Connect environment.
Depending on the platform version and configuration, teams can observe information such as:
-
system CPU usage;
-
platform CPU usage;
-
application memory usage;
-
platform and application operations;
-
user journeys and application activity.
Observability does not improve performance automatically. Its purpose is to establish where time and resources are being consumed.
Developer action: Use io.Insights alongside application-level instrumentation to answer specific questions:
-
Which application consumes the most memory?
-
Does CPU usage increase when a particular Layout is restored?
-
Does one app take substantially longer to initialize?
-
Does memory increase after repeatedly opening and closing a Workspace?
-
Is the behavior specific to one machine or common across the deployment?
See the io.Insights documentation.