Oh My Zsh and Zsh Shell: Plugin Initialization Latency and Loading Sequence

Answer first

The most accurate way to measure per-plugin cost is Zsh's built-in profiler, zprof, combined with a one-at-a-time bisection of the plugins array. Oh My Zsh itself has no built-in deferred-loading mechanism, so the practical options are: lazy-load the few plugins that wrap heavy tools (nvm, pyenv, conda), fix the completion dump so compinit doesn't rebuild every launch, or move to a plugin manager with a documented "turbo"/defer mode if you truly need post-prompt loading.

Confirmed facts vs. likely explanation

Confirmed: OMZ works by sourcing oh-my-zsh.sh from your .zshrc, which iterates the plugins=(...) array and sources each plugin's *.plugin.zsh file synchronously, in listed order. Order matters mainly for plugins that override widgets or highlighting — community plugins like zsh-syntax-highlighting must load last or features silently break.

Likely explanation (not confirmed for your setup): OMZ core is rarely the bottleneck. The usual culprits are plugins that spawn subprocesses at load time — nvm, pyenv, rbenv, conda init blocks — and compinit rebuilding ~/.zcompdump on every launch instead of using its cache. Which one applies to you is a measurement question, not a guess.

Step 1: Measure

Add profiling around your entire startup:

# Top of ~/.zshrc
zmodload zsh/zprof

# ... existing OMZ config ...

# Bottom of ~/.zshrc
zprof

Open a new shell and read the table — it shows per-line/per-function time, so the dominant plugin or init block stands out immediately. For a quick total, run:

time zsh -i -c exit

Run this before and after every change so each fix is quantified, not vibes.

Step 2: Bisect the plugins array

Temporarily set plugins=(), measure, then re-add plugins one at a time. This isolates the slow contributor without disturbing anything else in the framework's flow. If startup is fast with an empty array but slow with everything, the cost is additive across many small plugins; if one plugin causes a jump, that's your target.

Step 3: Check compinit

OMZ caches the completion dump and normally rebuilds it roughly daily. If zprof shows compinit dominating every launch, the dump is likely stale or corrupted. Regenerate it once:

rm -f ~/.zcompdump && compinit

Don't delete it repeatedly — that forces the slow rebuild you're trying to avoid.

Deferring non-essential plugins

There is no documented OMZ setting for post-prompt loading. What works in practice:

• Lazy-load the heavy tool, not the plugin. For nvm, replace eager init with a shim that only loads on first use of node/npm/npx. This typically removes the single largest delay. Caveat: non-interactive scripts that assume node is on PATH immediately can break.
• Disable OMZ auto-update checks (DISABLE_AUTO_UPDATE=true) if network-touching update prompts add latency — at the cost of remembering to update manually.
• If you genuinely need deferred sourcing, that means switching plugin managers (e.g., one with a documented wait/turbo mode that sources plugins after the prompt renders). That's a bigger change than most setups need; do it only after zprof shows the remaining cost is spread across many plugins rather than one fixable offender.

One thing worth checking

If zprof shows no single dominant entry but total time is still high, share how many plugins you have and whether any of them wrap version managers — that determines whether bisection or lazy-loading is the right next move.