Belajar Neovim - Profile & Performance Optimization Startup Time

#Pendahuluan

Setelah di episode 22 sebelumnya kita membahas debugging menggunakan nvim-dap — mengubah Neovim menjadi debugger interaktif untuk menelusuri bug — pada episode kali ini kita akan beralih dari sisi fitur ke sisi rasa: kecepatan. Banyak orang yang sudah menginstall puluhan plugin lalu mengeluh Neovim "terasa berat", padahal masalahnya bukan di plugin-nya, melainkan karena plugin-plugin itu dimuat semua di awal, tanpa strategi.

Di episode 9 kita sudah membangun fondasi lazy.nvim dan menyentuh konsep lazy-loading dasar. Episode 23 ini adalah level berikutnya: kita akan belajar mengukur secara objektif berapa lama Neovim butuh untuk bangun (--startuptime dan :Lazy profile), menginterpretasi hasilnya seperti seorang SRE membaca grafik latensi, lalu menerapkan teknik lazy-loading tingkat lanjut — event, cmd, keys, dan ft — untuk menjaga startup time tetap di bawah 50ms meskipun config kalian berisi 50+ plugin.

Kenapa ini penting di dunia kerja nyata? Seorang engineer membuka dan menutup editor puluhan kali sehari, apalagi saat menjalankan perintah-perintah cepat di terminal. Setiap 100ms yang kalian hemat di startup berarti ratusan milidetik waktu menunggu per hari — dan saat menunggu editor, alur berpikir kalian ikut terputus. Anggap saja seperti mesin mobil: penyetelan mesin (tuning) yang baik bukan membuat mobil lebih kencang, tapi memastikan tidak ada energi yang terbuang sia-sia.

#Pembahasan Utama

#Mengapa Startup Time Menjadi Metrik yang Wajib Diukur?

Prinsip yang sama dengan observability di dunia server: kalian tidak bisa mengoptimalkan sesuatu yang tidak kalian ukur. Teori bahwa "config saya cepat" tanpa data hanyalah tebakan. Di sisi lain, banyak juga yang mengorbankan fitur hanya demi mengejar angka startup yang kecil — padahal 10 plugin yang aktif saat dibutuhkan tetap bisa terasa cepat asalkan di-lazy-load dengan benar.

Sasaran yang realistis untuk Neovim modern dengan banyak plugin:

Target realistis episode ini: di bawah 50ms dengan 50+ plugin. Bukan 5ms, karena di bawah 50ms manusia sudah tidak bisa membedakannya dengan mata telanjang — itulah sweet spot antara fitur dan kecepatan.

#Mengukur dengan nvim --startuptime

Cara paling mendasar dan tersedia sejak lama adalah flag --startuptime. Ia menulis log waktu setiap langkah boot ke file yang kalian tentukan:

nvim --startuptime /tmp/startup.log && head -n 30 /tmp/startup.log

Perhatikan cara menulisnya: --startuptime ditulis sebelum membuka file. Jika kalian tulis setelah nama file, flag tidak akan dikenali. Lalu lihat bagian atas lognya:

times in msec
 clock    self+sourced   self:  sourced script
 clock    self:  sourced script
  0.011  0.011:  sourcing /usr/bin/nvim
  0.361  0.350:  sourcing /usr/share/nvim/runtime/filetype.lua
  0.459  0.098:  sourcing /usr/share/nvim/runtime/syntax/synload.vim
  0.557  0.098:  sourcing /usr/share/nvim/runtime/syntax/syntax.vim
  1.120  0.563:  sourcing /usr/share/nvim/runtime/filetype.vim
  2.245  0.743:  sourcing /usr/share/nvim/runtime/ftplugin.vim
  4.872  0.640:  sourcing /usr/share/nvim/runtime/plugin/gzip.vim
  5.590  0.418:  sourcing /usr/share/nvim/runtime/plugin/netrwPlugin.vim
  ...
 81.412  1.120:  sourcing /home/user/.config/nvim/plugin/lualine.lua
 84.290  0.211:  sourcing /home/user/.config/nvim/plugin/telescope.lua
 95.118  0.998:  sourcing /home/user/.config/nvim/plugin/treesitter.lua
...
Total time: 137.421 msec

Ada tiga kolom penting yang perlu kalian pahami:

• clock — kumulatif waktu sejak Neovim mulai berjalan (milidetik). Ini menunjukkan di mana kita berada dalam timeline boot.
• self — waktu murni yang dihabiskan untuk memuat file ini sendiri (tanpa file yang di-source olehnya).
• self+sourced — self ditambah seluruh file yang ikut di-source oleh file tersebut.

Setiap kali selesai mengubah config, jadikan ritual: jalankan perintah di atas, buka lognya, dan tanyakan satu pertanyaan — "kenapa file ini harus dimuat di detik pertama?"

#Mengukur dengan :Lazy profile

--startuptime memberi kalian detail mentah, tapi untuk mengetahui berapa lama setiap plugin menyumbang waktu, gunakan profiler bawaan lazy.nvim. Buka Neovim lalu jalankan:

:Lazy profile

Outputnya adalah tabel yang mengelompokkan waktu boot per plugin:

Plugin                            Loaded at    Load time
plugins/colorscheme.lua           0.8ms        1.4ms
plugins/which-key.lua             3.1ms        0.9ms
plugins/lualine.lua               78.2ms       6.8ms
plugins/telescope.lua             81.4ms       0.2ms
plugins/treesitter.lua            95.1ms       8.2ms
plugins/cmp.lua                   98.6ms       3.4ms
plugins/lsp.lua                   101.7ms      12.1ms
...
Total startup time: 137.421ms

Baca cara pakainya seperti seorang SRE membaca pprof: cari plugin dengan Loaded at yang paling awal dan Load time yang paling besar sekaligus. Dua plugin itu adalah tersangka utama. Pelengkapnya, :Lazy stats (atau :Lazy load) menunjukkan jumlah hit/loading per plugin di sesi berjalan — membantu kalian melihat plugin mana yang sebenarnya dipakai dan mana yang hanya "dipasang lalu dilupakan".

#Teknik Lazy-Loading Tingkat Lanjut

Di episode 9 kita tahu lazy.nvim bisa memuat plugin secara malas. Yang akan kita perdalam di sini adalah empat trigger lazy-loading yang membentuk "senjata utama" performa:

Prinsipnya satu: jangan pernah memuat kode yang belum dibutuhkan. Sebuah plugin hanya boleh dieksekusi ketika pengguna (atau sistem) benar-benar memintanya. Mari kita lihat contoh spec yang lengkap untuk masing-masing trigger, dibungkus dalam satu code-group agar mudah dibandingkan.

{
  "folke/which-key.nvim",
  event = "VeryLazy",          -- dimuat setelah startup selesai
  opts = {},
},
{
  "nvim-lualine/lualine.nvim",
  event = "VeryLazy",          -- statusline tidak perlu di milidetik pertama
  dependencies = { "nvim-tree/nvim-web-devicons" },
  opts = {},
},

{
  "nvim-telescope/telescope.nvim",
  cmd = "Telescope",                    -- :Telescope baru dimuat
  dependencies = { "nvim-lua/plenary.nvim" },
  keys = {
    { "<leader>ff", "<cmd>Telescope find_files<CR>", desc = "Find Files" },
    { "<leader>fg", "<cmd>Telescope live_grep<CR>", desc = "Live Grep" },
    { "<leader>fb", "<cmd>Telescope buffers<CR>", desc = "Buffers" },
  },
},
{
  "williamboman/mason.nvim",
  cmd = "Mason",                        -- UI installer cukup dimuat saat dipanggil
  build = ":MasonUpdate",
  opts = {},
},

{
  "stevearc/oil.nvim",
  keys = {
    { "-", "<cmd>Oil<CR>", desc = "Open parent directory" },
  },
  opts = {},
},
{
  "folke/flash.nvim",
  keys = {
    { "s", mode = { "n", "x", "o" }, function() require("flash").jump() end, desc = "Flash Jump" },
    { "S", mode = { "n", "x", "o" }, function() require("flash").treesitter_search() end, desc = "Treesitter Flash" },
  },
  opts = {},
},

{
  "mrcjkb/rustaceanvim",
  ft = { "rust" },                      -- hanya dimuat saat buffer .rs terbuka
  opts = {},
},
{
  "windwp/nvim-ts-autotag",
  ft = { "html", "xml", "jsx", "tsx", "vue" },
},
{
  "jose-elias-alvarez/typescript-tools.nvim",
  ft = { "javascript", "typescript", "javascriptreact", "typescriptreact" },
  opts = {},
}

Perhatikan pola penting di contoh di atas: keys dan cmd bisa berdiri sendiri sebagai trigger — jika kalian mendefinisikan keys, lazy.nvim akan membuatkan keymap-nya sekaligus, dan plugin baru dimuat saat keymap itu ditekan. Tidak perlu menulis vim.keymap.set manual untuk plugin yang dikelola lazy.nvim. Ini adalah perilaku yang membedakan lazy.nvim dari plugin manager lain: keymap dan lazy-loading adalah satu hal yang sama.

#Mematikan Plugin Bawaan yang Tidak Terpakai

Selain plugin pihak ketiga, Neovim juga membawa plugin runtime bawaan (netrw, gzip, zipPlugin, tarPlugin, tohtml, dll). Walaupun kecil, bersama-sama mereka menyumbang beberapa milidetik dan tidak pernah kalian pakai — netrw khususnya sering ter-load di detik-detik awal karena menjadi fallback file explorer. lazy.nvim menyediakan cara resmi untuk mematikan mereka lewat performance.rtp:

{
  "folke/lazy.nvim",
  performance = {
    rtp = {
      disabled_plugins = {
        "netrwPlugin",   -- pakai oil.nvim / neo-tree sebagai gantinya
        "gzip",
        "zipPlugin",
        "tarPlugin",
        "tohtml",
        "matchit",
      },
    },
  },
},

Setelah ini, --startuptime kalian akan menunjukkan baris-baris plugin/netrwPlugin.vim dan sejenisnya hilang dari log. Hemat milidetik demi milidetik — itu cara kerja penyetelan yang serius.

#Studi Kasus: Membawa 50+ Plugin di Bawah 50ms

Mari kita gabungkan semua teknik di atas dalam satu studi kasus. Config referensi memiliki 54 plugin. Berikut perbandingan sebelum dan sesudah optimasi:

Dari ~210ms menjadi ~38ms tanpa kehilangan satu pun fitur. Rahasianya bukan menghapus plugin, tapi menunda semuanya. Perhatikan bahwa nvim-cmp di-trigger oleh event = "InsertEnter" — completion hanya dibutuhkan saat kalian mulai mengetik, bukan saat membuka buffer. Inilah pola pikir yang harus kalian internalisasi.

#Diff: Dari Eager Menuju Lazy

Berikut contoh diff nyata ketika sebuah spec diubah dari eager-loaded menjadi lazy-loaded — pola yang akan sering kalian terapkan:

 {
   "nvim-telescope/telescope.nvim",
   dependencies = { "nvim-lua/plenary.nvim" },
-  config = function()                      # [!code --:3]
-    require("telescope").setup({})
-  end,
+  cmd = "Telescope",                    # [!code ++:1]
+  keys = {                              # [!code ++:4]
+    { "<leader>ff", "<cmd>Telescope find_files<CR>", desc = "Find Files" },
+    { "<leader>fg", "<cmd>Telescope live_grep<CR>", desc = "Live Grep" },
+  },
+  opts = {},                            # [!code ++:1]
 }

#Kesalahan Umum (Common Pitfalls)

1. Over-lazy-loading yang merusak plugin. Tidak semua plugin aman di-lazy-load. Plugin yang perlu mendaftarkan autocmd atau command sejak awal (misalnya plugin yang membungkus nvim_create_autocmd untuk event tertentu) akan kehilangan fungsinya jika di-lazy-load terlalu telat. Solusinya: kenali kebutuhan plugin, dan untuk yang butuh hadir lebih awal gunakan event = "VeryLazy" — bukan cmd atau keys.

2. Menyalahgunakan vim.defer_fn. Banyak yang mencoba "menipu" startup dengan vim.defer_fn(function() require("plugin").setup() end, 0). Ini tidak memindahkan pekerjaan keluar dari startup — ia hanya menundanya beberapa milidetik, lalu dieksekusi di depan UI kalian saat pertama kali berinteraksi, menciptakan freeze yang membingungkan. Kalau memang butuh asinkron, gunakan event yang tepat (UiEnter, VeryLazy), bukan menunda kerja sinkron.

3. Lazy-loading LSP yang terlalu agresif. Memicu server LSP berdasarkan keys (misalnya baru jalan saat gd ditekan) membuat goto-definition terasa lambat dan hover terputus-putus. LSP sebaiknya di-trigger oleh event = { "BufReadPre", "BufNewFile" } atau per ft, karena buffer sudah terbuka sebelum kalian sempat menekan apa pun.

4. ft yang tidak pernah terpicu. Lazy-loading berbasis filetype gagal diam-diam jika deteksi filetype terganggu — misalnya filetype off di config, atau buffer dibuka tanpa extension (:e file tanpa ekstensi). Verifikasi dengan :set filetype? saat buffer terbuka.

5. Mengoptimasi tanpa data. Paling umum dan paling parah: menghapus plugin atau menebak-nebak tanpa menjalankan --startuptime dan :Lazy profile dulu. Selalu ukur, baru ubah, lalu ukur lagi — itu siklus observability yang benar.

#Checklist Audit Startup

Jadikan daftar ini sebagai kebiasaan setiap kali menambah plugin baru:

#Penutup

Pada episode 23 ini kita telah belajar bahwa kecepatan bukanlah keberuntungan, melainkan hasil pengukuran dan disiplin. Kita memahami cara membaca nvim --startuptime dan :Lazy profile untuk menemukan penyumbang waktu terbesar, lalu menghancurkannya dengan empat trigger lazy-loading — event, cmd, keys, dan ft — sampai akhirnya config dengan 54 plugin bisa startup di bawah 50ms tanpa kehilangan fitur apa pun.

Poin terpenting yang bisa kalian bawa pulang: lazy-loading adalah pola pikir, bukan sekadar opsi config. Setiap plugin baru yang kalian tambahkan harus menjawab satu pertanyaan sebelum di-pasang: "kapan plugin ini benar-benar dibutuhkan?" Selama kalian konsisten dengan pertanyaan itu, performa config akan terjaga seiring bertambahnya jumlah plugin.

Di episode 24 selanjutnya, kita akan membawa perjalanan ini ke level berikutnya: mengelola dotfiles — menyimpan seluruh config Neovim ke repository Git, memastikan config kalian berjalan di Linux, macOS, dan Windows dengan satu kode sumber, dan mengotomatiskan bootstrap di laptop atau server baru. Sebuah skill yang akan menyelamatkan kalian setiap kali berpindah mesin. Sampai jumpa di episode berikutnya, dan jangan lupa — ukur dulu sebelum mengubah!