Oh, this was a huge tip. I think I managed to get mine down from ~1s to ~0.1s! Thanks for suggesting this as a path to happiness.

awesome stuff @nickytonline! went through this to help my insanely slow startup. went from ~1.4s to ~0.45s ~0.24s

thanks! 🔥

Good work

Good post

Some people online asked me why it didn't suggest fnm over nvm. It did, but I was used to nvm, so kept it. That said, now, I'm going to give fnm a go.

Schniz / fnm

🚀 Fast and simple Node.js version manager, built in Rust

Fast Node Manager (fnm)

🚀 Fast and simple Node.js version manager, built in Rust

Features

🌎 Cross-platform support (macOS, Windows, Linux)

✨ Single file, easy installation, instant startup

🚀 Built with speed in mind

📂 Works with .node-version and .nvmrc files

Installation

Using a script (macOS/Linux)

For bash, zsh and fish shells, there's an automatic installation script.

First ensure that curl and unzip are already installed on your operating system. Then execute:

curl -fsSL https://fnm.vercel.app/install | bash

Upgrade

On macOS, it is as simple as brew upgrade fnm.

On other operating systems, upgrading fnm is almost the same as installing it. To prevent duplication in your shell config file, pass --skip-shell to the install command:

curl -fsSL https://fnm.vercel.app/install | bash -s -- --skip-shell

Parameters

--install-dir

Set a custom directory for fnm to be installed. The default is $XDG_DATA_HOME/fnm (if $XDG_DATA_HOME is not defined it falls…

View on GitHub

There's no way I'd notice a sub-second delay when opening a new tab. It'd take me that long to go from the hotkey for "new tab" to starting to type into it, and my keystrokes would be buffered anyway. I just timed it and it takes about 750ms to start, but I include the kitchen sink for different environments.

It's different use cases, I guess, but I open most of the terminals I need in screen/tmux/zellij and flip between them, which takes essentially no time, rather than opening and closing new ones. RAM's cheap; I can afford to have a dozen shells active at once.

Lazy-loading environment variables from (relatively) expensive calls makes sense.

The wrappers you use are more of a problem:

npm() {
  nvm use default --silent

This means every time you switch to a different node version for a specific project and then run npm, you'll switch back to the default, which could mess up your whole day. I'm all for wrapping up commands like this (I do it myself to add a git cd command for example) but I don't like side-effects like this one. Also, if the default node version is a prerequisite for npm in this use case, I think it'd be better to use && to join the commands so it fails if nvm doesn't work for whatever reason.

I guess the take-home from your investigation is that node is a hog. Paint me surprised!

abc

Wow, this is an impressive speed boost! Using Claude Code’s lazy-loading wrappers for nvm, pyenv, and gcloud to cut startup from 770ms to 40ms is next-level productivity.