My Neovim takes roughly 113ms to fire up.

THIS IS FAST.

However, I don’t lazy load anything. Being a Lazy.nvim user, it’s kind of a shame I’m not actually making use of my plugin manager's flagship feature.

But then again, it takes 113ms for nvim to start, what is there to gain here?

Let’s say I drop it to 50ms.
I gained 60ms which means that if I’m going to spend 30 minutes to actually reduce it, I’d have to open Neovim 15,929 times to get my time back 🤣. With an average of probably 5 times a day, it would take me about 9 years...

Still reading? GOOD. You’re as crazy as I am, let’s speed things up!

​

The Slow Startup Struggle

There are a few factors affecting startup times:

• Your hardware - we’re not going to deal with that.
• Your Neovim release - that’s up to you.
• And finally - Plugins. Vanilla users will most likely experience a sub 25ms startup time.
  Everything beyond that is a (sometimes bloated) list of plugins.

0. Lose redundant plugins!

This cool plugin dropping your code on the ground like sand? Not helping you in the 99.99% times you’re not showing it off to a colleague. Don’t ask me how I know.

Yeah this duck running around lines of code isn’t helping either.

Cleanup useless plugins or those you're not really using anymore because you stopped working with Java.

1. Clock Your Startup

First, let’s see how slow things really are: nvim --startuptime startup.log

This creates a detailed log. Open the log and look for the total time at the bottom. This is our baseline.

2. Meet Your New Best Friend: Lazy

​Lazy isn’t just another plugin manager. It’s your speed demon sidekick. Install it, then use its built-in profiler:

:Lazy profile (Or :Lazy and Ctrl+p)

This shows you the overall time it took to load things up, including a breakdown of the booting profile.
To find the criminals in the list, hit Ctrl-s, changing the sort based on time taken to load a process.

Aside from Treesitter which I’m not necessarily going to touch first, UI enhancers like noice.nvim and nvim-notify seem to take an extra 30ms to load, do I really need them? If I do, is there anything to do about it?

3. Lazy Loading: Your Secret Weapon

Here’s the key: Don’t load everything at once. Use Neovim events!

Events are triggers, like opening a file or entering insert mode. Use them to load plugins only when needed.

For example: { "hrsh7th/nvim-cmp", event = "InsertEnter" } loads the completion plugin only when you start typing. Sneaky and effective, and this is one example of MANY.

Learn more about optional events with :help events!

4. Optimize the Heavy Hitters

Found some other plugins eating up time? Let’s tackle them:

• Treesitter: Load languages on demand. While I don’t necessarily recommend this, you could shift the loading of Treesitter to BufReadPre by adding:
  ​event = { "BufReadPre" }, (:help BufReadPre) for example.
• LSP: Initialize servers for open files only event = { "BufReadPost", "BufNewFile" },
• Telescope: Defer file indexing.
  Telescope side note: if Telescope takes time to load it's usually because of extensions!
• Markdown plugins like my beloved obisidian.nvim can be given the ft=markdown config which will automatically lazy load it on .md files only

5. Let me confuse you

Lazy loading isn’t always the best approach for every plugin in your system.

While it can improve initial file opening times, it may introduce latency when you start interacting with the file and delay the appearance of diagnostics.

Consider the user experience:

• Do you want semantic highlighting to appear with a noticeable delay?
• The LSP and its associated information are critical for many editor features, so it’s often beneficial to have them available as soon as possible.
• At the latest, consider initializing these components on buffer events to balance between performance and functionality.

With this approach, you’ll slash startup times without sacrificing your favorite Neovim superpowers.

Thank you for reading, as always, feel free to reply to this post directly with questions and comments!