# Performance Enhancements in io.Connect Desktop Across Versions

**URL:** <https://community.interop.io/t/performance-enhancements-in-io-connect-desktop-across-versions/705>\
**Category:** io.Connect Desktop\
**Tags:** performance-tuning\
**Created:** [September 21, 2026, 1:11pm UTC](https://community.interop.io/t/performance-enhancements-in-io-connect-desktop-across-versions/705 "2026-09-21T13:11:29Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![toni.petrov](https://yyz2.discourse-cdn.com/flex028/user_avatar/community.interop.io/toni.petrov/32/17_2.png) [@toni.petrov](https://community.interop.io/u/toni.petrov)\
**Post date:** [September 21, 2026, 1:11pm UTC](https://community.interop.io/t/performance-enhancements-in-io-connect-desktop-across-versions/705/1 "2026-09-21T13:11:29Z")

</div>

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](https://docs.interop.io/desktop/developers/configuration/system/index.html#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](https://docs.interop.io/desktop/getting-started/changelog/platform/10-0/index.html)

## 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](https://docs.interop.io/desktop/capabilities/windows/workspaces/overview/index.html)

### 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:

```auto
{
    "layouts": {
        "restoreDefaultGlobalOnStartup": false
    }
}

```

The default Layout can then be restored programmatically when appropriate:

```auto
const defaultLayout = await io.layouts.getDefaultGlobal();

if (defaultLayout) {
    await io.layouts.restore(defaultLayout);
}

```

See [Default Global Layout](https://docs.interop.io/desktop/capabilities/windows/layouts/overview/index.html)

### 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.

See [In-memory Layout store](https://docs.interop.io/desktop/capabilities/windows/layouts/overview/index.html)

## 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](https://docs.interop.io/manager/configuration/platform/index.html).

## 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](https://docs.interop.io/desktop/getting-started/changelog/platform/9-4/index.html#new_features-clearing_electron_cache_from_previous_versions)

## 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](https://docs.interop.io/desktop/getting-started/changelog/platform/9-7/index.html#new_features-web_page_search_settings)

## 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](https://docs.interop.io/desktop/getting-started/changelog/9-7/index.html).

## 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](https://docs.interop.io/desktop/getting-started/changelog/platform/9-0/index.html#new_features-preload_scripts)

## 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](https://docs.interop.io/desktop/getting-started/changelog/platform/9-2/index.html#improvements__bug_fixes)

## 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](https://docs.interop.io/desktop/capabilities/insights/overview/index.html).