Daftar dashboard cepat dengan 100k baris: apa yang dilakukan terlebih dulu

Mengapa layar daftar melambat saat data tumbuh

Sebuah layar daftar biasanya terasa baik sampai suatu saat tidak lagi. Pengguna mulai melihat jeda kecil yang menumpuk: scroll tersendat, halaman macet sebentar setelah setiap pembaruan, filter butuh detik untuk merespons, dan Anda melihat spinner setelah setiap klik. Kadang tab browser tampak beku karena thread UI sibuk.

100k baris adalah titik yang sering menonjol karena menekan setiap bagian sistem sekaligus. Dataset itu masih wajar untuk database, tapi cukup besar untuk membuat ketidakefisienan kecil menjadi jelas di browser dan di jaringan. Jika Anda berusaha menampilkan semuanya sekaligus, layar sederhana berubah menjadi pipeline berat.

Tujuannya bukan merender semua baris. Tujuannya membantu seseorang menemukan apa yang mereka butuhkan dengan cepat: 50 baris yang tepat, halaman berikutnya, atau irisan sempit berdasarkan filter.

Membagi pekerjaan menjadi empat bagian membantu:

• Jaringan: berapa banyak byte yang Anda kirim, dan seberapa sering.
• Database: berapa banyak data yang dipindai, diurutkan, dan diagregasi per permintaan.
• Rendering browser: berapa banyak node DOM yang Anda buat, ukur, dan cat.
• Kerja JavaScript: seberapa sering Anda merender ulang, menghitung ulang kolom, atau mengkalkulasi hasil.

Jika salah satu bagian mahal, keseluruhan layar terasa lambat. Kotak pencarian sederhana bisa memicu request yang mengurutkan 100k baris, mengembalikan ribuan record, lalu memaksa browser merender semuanya. Begitulah mengetik menjadi lag.

Saat tim membangun tool internal dengan cepat (termasuk menggunakan platform vibe-coding seperti Koder.ai), layar daftar sering kali tempat pertama di mana pertumbuhan data nyata memperlihatkan celah antara “bekerja pada dataset demo” dan “terasa instan setiap hari.”

Pilih target kinerja yang tepat

Sebelum mengoptimalkan, putuskan apa arti cepat untuk layar ini. Banyak tim mengejar throughput (memuat semuanya) padahal pengguna sebenarnya butuh latensi rendah (melihat sesuatu berubah dengan cepat). Sebuah daftar bisa terasa instan meskipun tidak pernah memuat semua 100k baris, selama merespons cepat terhadap scroll, sort, dan filter.

Target praktis adalah waktu ke baris pertama, bukan waktu hingga terisi penuh. Pengguna percaya halaman ketika mereka melihat 20–50 baris pertama dengan cepat dan interaksi tetap mulus.

Apa yang diukur (dan kenapa)

Pilih beberapa angka kecil yang bisa Anda lacak setiap kali mengubah sesuatu:

• Waktu ke baris pertama setelah membuka halaman atau mengganti filter
• Waktu bagi filter atau sort untuk menampilkan hasil yang diperbarui
• Ukuran respons (perkiraan ukuran payload JSON)
• Query lambat (terutama COUNT(*) dan SELECT yang lebar)
• Lonjakan main-thread browser (stutter saat scroll, lag mengetik)

Ini berkaitan langsung dengan gejala umum. Jika CPU browser melonjak saat Anda menggulir, frontend melakukan terlalu banyak kerja per baris. Jika spinner menunggu namun scroll baik-baik saja setelahnya, biasanya masalah ada di backend atau jaringan. Jika request cepat tapi halaman tetap membeku, hampir selalu masalah rendering atau pemrosesan berat di sisi klien.

Tes cepat frontend vs backend

Coba satu eksperimen sederhana: pertahankan UI sama, tapi batasi backend sementara agar hanya mengembalikan 20 baris dengan filter yang sama. Jika jadi cepat, bottleneck Anda adalah ukuran beban atau waktu query. Jika masih lambat, periksa rendering, formatting, dan komponen per-barus.

Contoh: layar Orders internal terasa lambat saat Anda mengetik di pencarian. Jika API mengembalikan 5.000 baris dan browser memfilter semuanya di setiap penekanan tombol, mengetik akan lag. Jika API butuh 2 detik karena COUNT pada filter tanpa index, Anda akan menunggu sebelum baris apa pun berubah. Perbaikan berbeda, keluhan pengguna sama.

Dasar frontend: jaga rendering tetap murah

Browser sering menjadi bottleneck pertama. Sebuah daftar bisa terasa lambat padahal API cepat, hanya karena halaman berusaha mewarnai terlalu banyak hal. Aturan pertama sederhana: jangan merender ribuan baris di DOM sekaligus.

Bahkan sebelum menambah virtualisasi penuh, buat setiap baris ringan. Baris dengan pembungkus bersarang, ikon, tooltip, dan style kondisional kompleks di setiap sel akan menguras saat scroll dan setiap pembaruan. Pilih teks polos, beberapa badge kecil, dan satu atau dua elemen interaktif per baris.

Tinggi baris yang stabil membantu lebih dari yang terlihat. Ketika setiap baris sama tinggi, browser bisa memprediksi layout dan scroll tetap mulus. Baris dengan tinggi variabel (deskripsi yang membungkus, catatan yang bisa diperluas, avatar besar) memicu pengukuran ekstra dan reflow. Jika Anda perlu detail tambahan, pertimbangkan panel samping atau area yang bisa diperluas sekali saja, bukan baris multiline penuh.

Formatting juga biaya yang diam-diam. Tanggal, mata uang, dan pekerjaan string berat bertambah ketika diulang di banyak sel.

Aturan praktis singkat

Jika sebuah nilai tidak terlihat, jangan hitung dulu. Cache hasil formatting yang mahal dan hitung sesuai permintaan, misalnya ketika baris menjadi terlihat atau saat pengguna membuka baris.

Langkah cepat yang sering memberi peningkatan nyata:

• Batasi render awal ke halaman kecil (atau window virtual) dari baris
• Pertahankan tinggi baris tetap dan hindari sel multi-baris
• Pindahkan UI berat (tooltip, menu) ke hover atau klik
• Memoize atau cache formatting tanggal dan mata uang per baris
• Hindari merender ulang semua baris saat hanya satu filter berubah

Contoh: tabel Invoices internal yang memformat 12 kolom mata uang dan tanggal akan tersendat saat scroll. Mencache nilai terformat per invoice dan menunda pekerjaan untuk baris di luar layar bisa membuatnya terasa instan, bahkan sebelum kerja backend yang lebih dalam.

Virtualisasi: cara menggulir 100k baris dengan mulus

Virtualisasi berarti tabel hanya menggambar baris yang benar-benar terlihat (plus buffer kecil di atas dan bawah). Saat Anda menggulir, elemen DOM yang sama dipakai ulang dan data diganti di dalamnya. Itu menjaga browser dari mencoba mewarnai puluhan ribu komponen baris sekaligus.

Virtualisasi cocok saat Anda punya daftar panjang, tabel lebar, atau baris berat (avatar, chip status, menu aksi, tooltip). Juga berguna saat pengguna sering menggulir dan mengharapkan tampilan kontinu yang mulus daripada pindah halaman demi halaman.

Di mana virtualisasi bisa rumit

Ini bukan sulap. Beberapa hal sering mengejutkan:

• Tinggi baris variabel (teks membungkus, baris yang bisa diperluas) bisa merusak scroll mulus kecuali Anda mengukur tinggi atau menjaga ukuran baris konsisten.
• Header sticky dan kolom sticky bisa konflik dengan container yang tervirtualisasi jika layout mengandalkan CSS kompleks.
• Navigasi keyboard (up/down, page up/down, fokus dalam sel) butuh perhatian ekstra agar fokus tidak loncat ke baris yang belum di-mount.
• Aksi massal butuh aturan jelas: pilih baris yang terlihat, pilih seluruh filter, atau pilih seluruh dataset.

Pendekatan paling sederhana adalah membosankan: tinggi baris tetap, kolom yang dapat diprediksi, dan tidak terlalu banyak widget interaktif di tiap baris.

Virtualisasi plus pagination (tanpa membingungkan pengguna)

Anda bisa menggabungkan keduanya: gunakan pagination (atau load more berbasis cursor) untuk membatasi apa yang Anda ambil dari server, dan virtualisasi untuk menjaga rendering murah di dalam slice yang diambil.

Pola praktis adalah mengambil ukuran halaman normal (sering 100 sampai 500 baris), virtualisasi dalam halaman itu, dan tawarkan kontrol yang jelas untuk berpindah halaman. Jika menggunakan infinite scroll, tambahkan indikator Loaded X of Y yang terlihat agar pengguna mengerti mereka belum melihat semuanya.

Pilihan pagination yang tetap cepat

Jika Anda butuh layar daftar yang tetap bisa digunakan saat data tumbuh, pagination biasanya default paling aman. Ia dapat diprediksi, bekerja baik untuk alur admin (review, edit, approve), dan mendukung kebutuhan umum seperti mengekspor "halaman 3 dengan filter ini" tanpa kejutan. Banyak tim akhirnya kembali ke pagination setelah mencoba scrolling yang lebih canggih.

Infinite scroll bisa terasa enak untuk browsing kasual, tapi punya biaya tersembunyi. Orang kehilangan orientasi, tombol kembali sering tidak mengembalikan ke posisi yang sama, dan sesi panjang bisa menumpuk memori saat lebih banyak baris dimuat. Jalan tengahnya adalah tombol Load more yang masih menggunakan halaman, sehingga pengguna tetap terorientasi.

Offset vs keyset pagination

Offset pagination adalah pendekatan klasik page=10&size=50. Sederhana, tapi bisa melambat pada tabel besar karena database harus melewati banyak baris untuk mencapai halaman yang lebih jauh. Juga bisa terasa aneh saat baris baru masuk dan item bergeser antar halaman.

Keyset pagination (sering disebut cursor pagination) meminta "50 baris berikutnya setelah item terakhir yang terlihat," biasanya menggunakan id atau created_at. Ini cenderung tetap cepat karena tidak perlu menghitung dan melewati begitu banyak kerja.

Aturan praktis:

• Gunakan offset untuk daftar yang lebih kecil, dataset stabil, dan ketika Anda harus lompat ke nomor halaman tertentu.
• Gunakan keyset untuk daftar sangat besar, insert yang sering, dan navigasi Next/Previous.

Menampilkan total tanpa membayar mahal setiap kali

Pengguna suka melihat total, tapi count all matching rows penuh bisa mahal dengan filter berat. Opsi termasuk cache count untuk filter populer, memperbarui count di background setelah halaman dimuat, atau menampilkan count perkiraan (mis. "10.000+").

Contoh: layar Orders internal bisa menampilkan hasil instan dengan keyset pagination, lalu mengisi total tepat hanya ketika pengguna berhenti mengubah filter selama satu detik.

Jika Anda membangun ini di Koder.ai, anggap perilaku pagination dan count sebagai bagian dari spesifikasi layar sejak awal, supaya query backend dan state UI yang digenerate tidak saling bertentangan nanti.

Filtering dan pencarian yang terasa instan

Kebanyakan layar daftar terasa lambat karena dimulai terlalu terbuka: memuat semuanya, lalu meminta pengguna mempersempit. Balik urutan itu. Mulai dengan default yang masuk akal yang mengembalikan set kecil dan berguna (misalnya: 7 Hari Terakhir, Item Saya, Status: Open), dan buat pilihan All time menjadi eksplisit.

Pencarian teks adalah jebakan umum lain. Jika Anda menjalankan query pada setiap penekanan tombol, Anda membuat antrean request dan UI yang berkedip. Debounce input pencarian sehingga Anda hanya men-query setelah pengguna berhenti sejenak, dan batalkan request lama saat request baru dimulai. Aturan sederhana: jika pengguna masih mengetik, jangan panggil server dulu.

Filter terasa cepat juga ketika jelas. Tampilkan chip filter di dekat atas tabel agar pengguna melihat apa yang aktif dan bisa menghapusnya dengan satu klik. Gunakan label chip yang manusiawi, bukan nama field mentah (mis. Owner: Sam daripada owner_id=42). Ketika seseorang bilang "hasil saya menghilang," biasanya ada filter yang tak terlihat.

Polanya yang menjaga daftar besar responsif tanpa membuat UI rumit:

• Default ke filter sempit dan rentang tanggal pendek
• Debounce pencarian teks dan batalkan request yang sedang berjalan
• Tampilkan chip filter dan aksi Clear all
• Tawarkan saved views untuk pekerjaan umum
• Tangguhkan filter mahal sampai setidaknya satu filter penyempit dipilih

Saved views adalah pahlawan tak terlihat. Daripada mengajari pengguna membangun kombinasi filter satu kali yang sempurna setiap kali, berikan beberapa preset yang cocok dengan alur kerja nyata. Tim ops mungkin berpindah antara Failed payments today dan High-value customers. Itu bisa satu klik, langsung dimengerti, dan lebih mudah dijaga cepat di backend.

Jika Anda membangun tool internal di builder yang digerakkan chat seperti Koder.ai, perlakukan filter sebagai bagian alur produk, bukan tambahan. Mulai dari pertanyaan paling umum, lalu desain view default dan saved views berdasarkan itu.

Query shaping: kirim lebih sedikit, hitung lebih sedikit

Layar daftar jarang membutuhkan data yang sama seperti halaman detail. Jika API Anda mengembalikan segala sesuatu tentang segala sesuatu, Anda membayar dua kali: database melakukan lebih banyak kerja, dan browser menerima serta merender lebih dari yang bisa digunakan. Query shaping adalah kebiasaan hanya meminta apa yang diperlukan daftar saat ini.

Mulai dengan mengembalikan hanya kolom yang dibutuhkan untuk merender tiap baris. Untuk kebanyakan dashboard, itu id, beberapa label, status, pemilik, dan timestamps. Teks besar, blob JSON, dan field terkomputasi bisa menunggu hingga pengguna membuka baris.

Hindari join berat untuk first paint. Join baik ketika mengenai index dan mengembalikan hasil kecil, tapi menjadi mahal ketika Anda join banyak tabel lalu mengurutkan atau memfilter berdasarkan data join. Pola sederhana: ambil daftar dari satu tabel dengan cepat, lalu muat detail terkait sesuai permintaan (atau batch-load untuk baris yang terlihat saja).

Batasi opsi pengurutan dan urutkan berdasarkan kolom yang diindeks. "Sort by anything" terdengar membantu, tapi sering memaksa sort lambat pada dataset besar. Pilih beberapa opsi yang dapat diprediksi seperti created_at, updated_at, atau status, dan pastikan kolom-kolom itu diindeks.

Hati-hati dengan agregasi sisi-server. COUNT(*) pada set yang difilter besar, DISTINCT pada kolom lebar, atau perhitungan total halaman bisa mendominasi waktu respons.

Pendekatan praktis:

• Bentuk respons daftar ke 5–10 field
• Ambil detail baris hanya saat baris dibuka
• Izinkan 2–4 opsi sort, semua didukung oleh index
• Perlakukan COUNT dan DISTINCT sebagai opsional; cache atau perkirakan bila mungkin

Jika Anda membangun tool internal di Koder.ai, definisikan query daftar ringan terpisah dari query detail saat perencanaan, supaya UI tetap snappy saat data tumbuh.

Taktik database untuk tabel besar

Jika Anda ingin layar daftar tetap cepat pada 100k baris, database harus melakukan lebih sedikit kerja per permintaan. Kebanyakan daftar lambat bukan karena "terlalu banyak data," melainkan pola akses data yang salah.

Mulai dengan index yang cocok dengan apa yang pengguna lakukan sebenarnya. Jika daftar biasanya difilter oleh status dan diurutkan oleh created_at, Anda ingin index yang mendukung kedua hal itu, dalam urutan tersebut. Kalau tidak, database bisa memindai jauh lebih banyak baris dari yang diharapkan lalu mengurutkannya, yang cepat menjadi mahal.

Perbaikan yang biasanya memberi kemenangan terbesar:

• Tambah index komposit yang mencerminkan filter + sort umum (mis. tenant_id, status, created_at).
• Pilih keyset (cursor) pagination daripada halaman OFFSET yang dalam. OFFSET membuat database melangkahi banyak baris hanya untuk melewatinya.
• Anggap total count sebagai opsional. Total tepat bisa lambat pada set yang difilter besar. Cache count, precompute, atau tampilkan "10,000+" saat angka tepat tidak diperlukan.
• Jaga baris tetap tipis. Jangan select field teks besar, JSON blob, atau object nested untuk daftar.
• Bentuk query agar hanya mengembalikan apa yang UI render: beberapa kolom yang diperlukan untuk tabel, plus cursor next-page.

Contoh sederhana: tabel Orders internal yang menampilkan nama pelanggan, status, jumlah, dan tanggal. Jangan join setiap tabel terkait dan tarik full order notes untuk view daftar. Kembalikan hanya kolom yang dipakai di tabel, dan muat sisanya di request terpisah saat pengguna mengklik order.

Jika Anda membangun dengan platform seperti Koder.ai, pertahankan pola pikir ini meskipun UI digenerate dari chat. Pastikan endpoint API yang dihasilkan mendukung cursor pagination dan field yang selektif, sehingga kerja database tetap dapat diprediksi saat tabel tumbuh.

Rencana langkah-demi-langkah untuk mempercepat layar daftar yang ada

Jika halaman daftar terasa lambat hari ini, jangan mulai dengan menulis ulang semuanya. Mulai dengan mengunci bagaimana penggunaan normal terlihat, lalu optimalkan jalur itu.

Rencana lima langkah praktis

1. Tentukan view default. Pilih filter default, urutan, dan kolom yang terlihat. Daftar melambat bila mencoba menampilkan segalanya secara default.

2. Pilih gaya paging yang sesuai penggunaan. Jika pengguna biasanya melihat beberapa halaman pertama, pagination klasik sudah cukup. Jika orang melompat jauh (halaman 200+) atau Anda butuh performa stabil tak peduli sejauh apa mereka pergi, gunakan keyset pagination (berdasarkan sort stabil seperti created_at plus id).

3. Tambahkan virtualisasi untuk body tabel. Bahkan jika backend cepat, browser bisa kewalahan saat merender terlalu banyak baris sekaligus.

4. Buat pencarian dan filter terasa instan. Debounce mengetik agar Anda tidak mengirim request pada setiap penekanan tombol. Simpan state filter di URL atau store bersama sehingga refresh, tombol kembali, dan berbagi view bekerja andal. Cache hasil sukses terakhir supaya tabel tidak berkedip kosong.

5. Ukur, lalu tuning query dan index. Log waktu server, waktu database, ukuran payload, dan waktu render. Lalu pangkas query: select hanya kolom yang Anda tunjukkan, terapkan filter lebih awal, dan tambahkan index yang cocok dengan filter + sort default Anda.

Contoh: dashboard support internal dengan 100k tiket. Default ke Open, ditugaskan ke tim saya, urutkan berdasarkan terbaru, tampilkan enam kolom, dan hanya ambil ticket id, subject, assignee, status, dan timestamps. Dengan keyset pagination dan virtualisasi, Anda menjaga database dan UI tetap dapat diprediksi.

Jika Anda membangun tool internal di Koder.ai, rencana ini cocok untuk workflow iterasi-dan-cek: sesuaikan view, uji scroll dan pencarian, lalu tuning query sampai halaman tetap snappy.

Kesalahan umum yang membuat daftar merangkak

Cara tercepat membuat layar daftar terasa rusak adalah memperlakukan 100k baris seperti halaman data biasa. Sebagian besar dashboard lambat memiliki beberapa jebakan yang bisa diprediksi.

Satu yang besar adalah merender semuanya lalu menyembunyikannya dengan CSS. Meski terlihat hanya 50 baris yang terlihat, browser tetap membayar untuk membuat 100k node DOM, mengukurnya, dan me-repaint saat scroll. Jika butuh daftar panjang, render hanya apa yang pengguna bisa lihat (virtualisasi) dan buat komponen baris sederhana.

Pencarian juga bisa merusak performa secara diam-diam ketika setiap penekanan tombol memicu full table scan. Itu terjadi saat filter tidak didukung oleh index, saat Anda mencari di terlalu banyak kolom, atau saat Anda menjalankan query contains di field teks besar tanpa rencana. Aturan bagus: filter pertama yang sering dipakai pengguna harus murah di database, bukan hanya nyaman di UI.

Masalah umum lain adalah mengambil record penuh padahal daftar hanya butuh ringkasan. Sebuah baris daftar biasanya butuh 5–12 field, bukan seluruh objek, bukan deskripsi panjang, dan bukan data terkait. Menarik data ekstra meningkatkan kerja database, waktu jaringan, dan parsing frontend.

Export dan total bisa membekukan UI jika Anda menghitungnya di main thread atau menunggu request berat sebelum merespons. Jaga UI tetap interaktif: mulai ekspor di background, tampilkan progres, dan hindari menghitung ulang total pada setiap perubahan filter.

Terakhir, terlalu banyak opsi sort bisa berbalik merugikan. Jika pengguna bisa mengurutkan menurut kolom apa pun, Anda akan mengurutkan set besar di memori atau memaksa database ke rencana lambat. Batasi sort ke beberapa kolom yang diindeks, dan buat sort default cocok dengan index nyata.

Pengecekan cepat insting:

• Jika Anda bisa menggulir tanpa henti tanpa memuat, kemungkinan besar Anda merender terlalu banyak.
• Jika mengetik di pencarian lag, kemungkinan query Anda melakukan scanning.
• Jika API daftar mengembalikan JSON besar, Anda mengambil terlalu banyak data.
• Jika ekspor menggantung halaman, pekerjaan terjadi di tempat yang salah.
• Jika setiap sort lambat, indexing dan opsi sort perlu dipangkas.

Daftar periksa cepat dan langkah berikutnya

Perlakukan performa daftar sebagai fitur produk, bukan perbaikan sekali jadi. Sebuah layar daftar cepat hanya ketika terasa cepat saat orang nyata menggulir, memfilter, dan mengurut pada data nyata.

Gunakan daftar periksa ini untuk memastikan Anda memperbaiki hal yang tepat:

• First paint cepat: halaman memuat payload kecil dan segera menampilkan baris pertama.
• Scroll tetap mulus: virtualisasi menyala, CPU browser tidak melonjak, dan tinggi baris dapat diprediksi.
• Filter terasa responsif: mengetik atau memilih filter memperbarui hasil cepat, dan filter tidak reset saat Anda paginasi atau refresh.
• Pengurutan masuk akal: hanya izinkan sort yang didukung index atau field yang telah dihitung, dan pertahankan urutan konsisten antar halaman.
• Request dibentuk: API mengembalikan hanya kolom yang Anda tampilkan, plus ID stabil dan cursor, bukan objek penuh "untuk berjaga-jaga."

Pemeriksaan realitas sederhana: buka daftar, gulir selama 10 detik, lalu terapkan filter umum (mis. Status: Open). Jika UI membeku, masalah biasanya rendering (terlalu banyak DOM rows) atau transformasi sisi-klien berat (sorting, grouping, formatting) yang terjadi pada setiap pembaruan.

Langkah berikutnya, berurutan, supaya Anda tidak bolak-balik memperbaiki:

1. Ukur satu alur pengguna end-to-end (load, scroll, filter, sort) dan catat target waktu.
2. Aktifkan virtualisasi dan batasi formatting mahal di sel (tanggal, mata uang, avatar).
3. Pindahkan filtering dan sorting ke server, dan batasi opsi ke yang bisa cepat.
4. Perketat query dan payload, lalu ukur ulang.

Jika Anda membangun ini dengan Koder.ai (koder.ai), mulai di Planning Mode: tentukan kolom daftar, field filter, dan bentuk respons API terlebih dahulu. Lalu iterasi menggunakan snapshot dan rollback saat eksperimen memperlambat layar.