A saved Workspaces App can hold several Workspaces as tabs, each containing its own arrangement of apps. For example, six Workspaces with eight app instances each add up to 48 app instances that need to be started and context loaded with just one Workspace restoration.
Within each Workspace, some apps may be visible side by side, while others sit behind app tabs - these are apps the user may not need yet. io.Connect Desktop provides three loading strategies: load everything immediately, load visible apps first and the rest in background batches, or load visible apps first and the rest when activated. Configure the default under "details" → "loading" → "loadingStrategy" in the Workspaces App definition.
| Strategy | What it does | What you pay |
|---|---|---|
"direct" |
All apps start loading immediately. | CPU usage spikes when opening the Workspace, because all apps start loading at the same time. |
"delayed" |
Visible apps load first, then the invisible apps load in batches at set intervals until all are loaded. Loading time for the visible apps improves because of the reduced startup CPU load. | Memory. All apps still end up loaded and taking up memory, even the ones that stay unused. |
"lazy" |
Visible apps load first; the rest load only when the user activates them. Same startup CPU benefit, and apps the user never opens are never loaded at all. | The wait moves into the user’s workflow. The docs note this “may be inconvenient if loading the app takes too long.” |
The practical read for a large Workspace:
"direct"is the wrong default at this size - you are concentrating the entire startup cost into one moment."lazy"gives the biggest reduction in work, and is the right choice when a lot of the tabs genuinely go untouched in a session. There’s a tradeoff: the first activation of an initially unloaded app tab, becomes a load, and users notice that. If your apps are slow to start, lazy trades a problem they tolerate once at startup for one they hit repeatedly during the day."delayed"is the middle ground and is often the better fit for a heavy Workspace whose tabs mostly do get used. It spreads the startup CPU without deferring work into the user’s path, Apps may already be loaded by the time users switch to them, depending on the batch settings and how quickly users navigate. Tune it with"initialOffsetInterval"(initial period in milliseconds before batch loading starts),"interval"(milliseconds between batches) and"batch"(number of apps per batch).
Each strategy trades startup load, memory use and waiting time differently. Choose between them on startup CPU, memory, and which delay your users will accept.
Check the initially visible apps.
With "lazy" and "delayed", the selected app in each tab group loads first. For example, if a Workspace has four panels with three app tabs each, the four selected apps load first. The other eight load in background batches with "delayed", or when the user selects their tabs with "lazy".
Tip: See what is loading during testing.
In a development environment, set "showDelayedIndicator": true under "loading" in the Workspaces App definition. Tabs for apps that haven’t loaded yet display a Zzz indicator. Restore the same Workspace with each strategy and watch what happens:
- With
"delayed", the indicators should disappear as the background batches load. - With
"lazy", an indicator should remain until you activate that tab and its app loads.
This is a quick way to check that the strategy behaves as expected. The indicator is for development and testing, not end users.
Keep saved Workspace state lean
A Workspace’s size depends on more than its app count. Apps may also save state with each window. If that state includes large defaults or the same data repeated across many windows, the saved layout can become unnecessarily large. Review what each app persists and keep only what is needed to restore the user’s work. Measure the effect on layout size and restore time before and after changes.
Hibernation
"hibernation" ( also under "details") is the related lever for Workspaces that are open but idle: apps in a hibernated Workspace are closed and loaded again in the same configuration when the user activates it, freeing system resources in the meantime. Rules available are "InsufficientSystemMemory", "WorkspaceIdleTime" and "MaximumActiveWorkspaces". Note it carries the same shape of tradeoff as lazy loading - resuming a hibernated Workspace means reloading its apps.
Before enabling hibernation in production, check what happens to unsaved edits, selections, background work and authentication when the apps close and reopen. Restoring the same Workspace configuration does not necessarily mean every app restores its internal state. Also measure resume time: a short idle threshold may save resources but cause users to wait repeatedly as they switch between Workspaces.