Belajar Fullstack Developer - Performance & Optimization Lanjutan

#Pendahuluan

Ini episode terakhir dari 28 — dan optimasi adalah tema yang pantas menutupnya, karena ia menyentuh semua yang sudah kalian pelajari: rendering (episode 3), data fetching (episode 8), caching (episode 15), keamanan (episode 16), dan observability (episode 24). Episode ini membahas performance & optimization lanjutan — bukan trik cepat, tapi metodologi: mengukur, menemukan penyebab sebenarnya, dan menerapkan perbaikan yang tepat.

Aturan pertamanya: optimasi tanpa pengukuran adalah tebakan. Setiap bagian dimulai dari ukuran — bukan intuisi.

#Metodologi: Ukur → Temukan → Perbaiki → Ukur Lagi

Disiplinnya: satu perubahan, satu pengukuran. Menerapkan tiga optimasi sekaligus membuat kalian tidak tahu mana yang bekerja (atau mana yang merusak).

#1. Profiling: Menemukan Penyebab Sebenarnya

"Lambat" bukanlah diagnosis. Alat profiling membedah di mana waktu benar-benar terpakai:

Contoh pembuka mata yang klasik:

EXPLAIN ANALYZE
SELECT * FROM "Note"
WHERE organization_id = 'org-1'
ORDER BY created_at DESC
LIMIT 10;
-- tanpa index:  Seq Scan ... 1800 ms
-- dengan index:  Index Scan ... 3 ms

Satu baris output Seq Scan vs Index Scan menjelaskan lebih banyak daripada seminggu menebak. 600x perbedaan dari satu index — itulah kenapa profiling selalu pertama.

#2. Bundle Size: Menyusutkan JavaScript

Bundle yang gemuk memperlambat waktu interaksi (INP) meski server cepat. Tiga senjata utama:

Dynamic import — muat kode berat hanya saat dibutuhkan:

const MarkdownEditor = dynamic(() => import("@/components/markdown-editor"), {
  loading: () => <EditorSkeleton />,
})

Tree-shaking — jangan import seluruh library:

// JANGAN — menarik seluruh lodash
import _ from "lodash"
// BAIK — hanya yang dipakai
import orderBy from "lodash/orderBy"

Pemeriksaan terus-menerus — jadikan ukuran bagian dari CI:

pnpm build && pnpm next bundle-analyzer

Ingat aturan emas episode 3 dan 8: semakin banyak di server (Server Components), semakin sedikit yang harus dikirim ke browser. Sebagian besar "optimasi bundle" di aplikasi Next.js sebenarnya adalah "pindahkan ke server".

#3. Tuning Database: Index dan Query

Di episode 22 kita membahas scaling; di sini detail tuning-nya. Tiga pola yang paling berdampak:

Composite index sesuai urutan query — kolom yang difilter = dulu, lalu yang di-ORDER BY:

CREATE INDEX idx_notes_org_created
  ON "Note" (organization_id, created_at DESC);

Hindari SELECT * di query panas — ambil hanya kolom yang dirender:

const notes = await prisma.note.findMany({
  where: { organizationId },
  select: { id: true, title: true, createdAt: true },
  take: 20,
})

Waspadai N+1 — jangan query dalam loop. Pola episode 8 (include relasi) atau query terpisah lalu gabung di memori, bukan query per baris:

// JANGAN
const notes = await prisma.note.findMany({ where: { organizationId } })
const authors = await Promise.all(notes.map((n) => prisma.user.findUnique({ where: { id: n.authorId } })))
 
// BAIK — satu query dengan relasi
const notes = await prisma.note.findMany({
  where: { organizationId },
  include: { author: true },
})

#4. Workflow Tuning Produksi yang Terukur

Optimasi bukan peristiwa sekali — ia proses berulang. Workflow produksi yang sehat:

1. Baseline di observability: catat p95, p99, LCP, INP saat ini.
2. Cari anomali (dari dashboard episode 24): halaman lambat, query mahal, bundle besar.
3. Profil lapisan tersangka dengan alat yang tepat (tabel di atas).
4. Terapkan satu perbaikan — index, caching (episode 15), atau perpindahan ke server.
5. Ukur ulang & bandingkan dengan baseline. Pertahankan jika terbukti, kembalikan jika tidak.

Timeline nyatanya: kebanyakan kemenangan besar datang dari 3-4 perbaikan terukur per kuartal — bukan pesta optimasi mingguan.

#Praktik: Tuning Produksi

Selesaikan dengan urutan berikut:

1. Catat baseline dari dashboard observability: p95, LCP, error rate.
2. Ambil halaman paling lambat → profiling di tiap lapisan (DevTools → tracing → EXPLAIN ANALYZE).
3. Terapkan satu perbaikan yang paling berdampak (kemungkinan: composite index atau mengurangi bundle).
4. Ukur ulang; bandingkan dengan baseline.
5. Ulangi: langkah 2-4 sampai p95/LCP masuk target yang kalian tetapkan.

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s total: %{time_total}s\n" \
  http://localhost:3000/notes

#Penutup: Perjalanan Belajar Fullstack Kalian

Inti episode ini — dan seluruh seri:

• Optimasi = metodologi berulang (ukur → temukan → perbaiki → ukur), bukan trik.
• Profil dulu di lapisan yang tepat: DevTools, tracing, EXPLAIN ANALYZE.
• Bundle size dikendalikan oleh dynamic import, tree-shaking, dan memindahkan kerja ke server.
• Tuning database: composite index, pilih kolom, hindari N+1.
• Jangan premature optimize — biarkan data berbicara.

Kalian mulai dari create-next-app dan prisma init di episode 0. Sekarang kalian telah melewati 28 episode: frontend dan backend, auth dan database, queue dan real-time, security dan scaling, AI dan observability. Kalian bukan lagi pemula — kalian fullstack developer. Terus bangun, terus ukur, dan sampai jumpa di proyek berikutnya!