Kenapa aplikasi buatan AI-mu terasa lambat (dan apa yang bisa kamu lakukan)

Aplikasi buatan AI-mu berfungsi. Tombol-tombolnya menuju ke tempat yang seharusnya, layarnya rapi, datanya tersimpan. Tapi ada yang terasa kurang pas. Halaman butuh sedetik lebih lama untuk memuat. Daftar berisi lima puluh item menggantung sesaat. Mengklik “save” membuatmu menunggu, lalu menunggu sedikit lagi, lalu bertanya-tanya apakah kamu harus mengkliknya lagi. Tak ada yang rusak — ia hanya terasa lambat.

Kalau kamu founder non-teknis yang merilis dengan AI app builder, ini salah satu momen “aku nggak tahu apa yang salah” yang paling umum. Kabar baiknya, 80% aplikasi buatan AI yang lambat itu lambat karena segelintir alasan yang sama. Tak satu pun menuntutmu belajar cara kerja database. Semuanya punya perbaikan yang bisa kamu minta ke AI builder-mu dalam bahasa sederhana.

Tulisan ini adalah contekannya.

Kenapa “lambat” biasanya empat hal

Saat pengguna bilang sebuah aplikasi terasa lambat, mereka hampir tak pernah memaksudkan “server-nya kurang bertenaga.” Mereka memaksudkan salah satu dari empat hal:

1. First paint-nya lambat — mereka mengklik tautan dan menatap layar kosong selama dua detik sebelum ada yang muncul.
2. Daftar yang panjang terasa lamban — scrolling, memfilter, atau memuat “semua proyek saya” butuh lebih lama daripada scrolling Instagram.
3. Sebuah aksi butuh terlalu lama tanpa memberi tahu apa yang terjadi — mereka mengklik “save” atau “send” dan tak ada yang merespons secara terlihat.
4. Database ditanyai terlalu banyak pertanyaan — halaman yang menampilkan data dari beberapa tempat mengambil tiap bagian secara terpisah dan menumpuk waktu tunggunya.

Itu saja. Hampir setiap aplikasi buatan AI yang lambat yang pernah saya lihat itu lambat karena salah satu dari empat alasan itu. Inilah cara mengenali masing-masing dan apa yang harus diminta ke builder-mu.

Alasan lambat #1: first paint

Seperti apa kelihatannya: kamu mengklik tautan ke aplikasimu, bilah URL selesai memuat, tapi halamannya putih selama satu atau dua detik sebelum ada yang muncul.

Apa yang biasanya menyebabkannya: aplikasi memuat setiap potongan JavaScript yang mungkin ia butuhkan sebelum menampilkan apa pun kepadamu. AI app builder cenderung mem-bundle dengan murah hati — lebih baik menyertakan sesuatu daripada melewatkannya — dan bundle itu makin besar seiring makin banyak fitur yang kamu tambahkan.

Apa yang diminta ke AI builder-mu: “Pemuatan halaman pertama terasa lambat. Bisakah kamu memecah bundle JavaScript berdasarkan route supaya halaman utama tidak perlu mengunduh seluruh bagian admin?” Atau, lebih sederhana: “Tambahkan lazy loading untuk route yang bukan halaman utama.” Sebagian besar framework modern mendukung ini dalam satu atau dua baris konfigurasi. AI tahu caranya — kamu tinggal meminta.

Sekalian saja: “Apakah ada gambar besar di landing page yang bisa kita optimalkan?” Foto hero 4 MB akan menjatuhkan kecepatan yang dirasakan lebih dari masalah kode mana pun.

Alasan lambat #2: daftar yang panjang

Seperti apa kelihatannya: kamu punya daftar — proyek, kontak, post, apa saja — dan begitu ia melewati empat puluh atau lima puluh item, scrolling tersendat atau memfilter butuh jeda yang terasa.

Apa yang biasanya menyebabkannya: aplikasi me-render setiap item ke halaman sekaligus, bahkan yang tak bisa kamu lihat. Dengan sepuluh item itu tak masalah. Dengan lima ratus, browser tersedak.

Apa yang diminta ke AI builder-mu: “Daftar proyek lambat saat ada banyak item. Bisakah kita menambahkan pagination, atau memvirtualisasi daftarnya supaya hanya baris yang terlihat yang di-render?” Pagination (“tampilkan 20 per halaman, dengan tombol next/previous”) adalah perbaikan termudah. Virtualisasi (“hanya render apa yang ada di layar saat pengguna scroll”) terasa lebih mulus tapi sedikit lebih banyak kerja. Keduanya tak masalah.

Kalau daftar juga punya pencarian atau filter: “Bisakah filter pencarian terjadi di server alih-alih di browser?” Filter di sisi server berarti browser hanya pernah menyimpan baris yang cocok, bukan seluruh dataset.

Alasan lambat #3: penantian sunyi

Seperti apa kelihatannya: kamu mengklik “save” atau “send” atau “generate.” Tak ada yang terlihat terjadi. Dua detik kemudian, layar diperbarui dan kamu sadar ia bekerja selama itu.

Apa yang biasanya menyebabkannya: aplikasi sedang mengerjakan pekerjaan nyata — menyimpan ke database, memanggil API — tapi AI builder tidak menambahkan loading state. Jadi dari sudut pandangmu, klik itu tak melakukan apa-apa.

Ini sebenarnya bukan masalah performa. Ini masalah performa yang dirasakan, dan masalah itu sering lebih menyakitkan daripada yang sungguhan. Aksi 200 milidetik tanpa feedback terasa lebih lambat daripada aksi 2 detik dengan spinner, karena otak pengguna berada dalam kegelapan.

Apa yang diminta ke AI builder-mu: “Tambahkan loading state ke setiap tombol yang memicu sebuah aksi. Tampilkan spinner atau teks ‘Menyimpan…’ selagi ia bekerja, dan nonaktifkan tombolnya supaya pengguna tidak bisa double-click.” Ini perbaikan performa dengan ROI tertinggi di aplikasi mana pun dan harganya nyaris tak ada.

Sekalian saja: “Untuk aksi yang sudah kita tahu hasilnya, bisakah kita memperbarui UI secara optimistis — tampilkan perubahannya seketika dan kembalikan kalau server menolaknya?” Optimistic update adalah alasan kenapa tombol “like” di aplikasi sosial terasa seketika bahkan saat sinyal ponselmu jelek sekali.

Alasan lambat #4: database yang cerewet

Seperti apa kelihatannya: halaman yang menampilkan daftar item, masing-masing dengan info tambahan — seperti daftar proyek dengan jumlah tugas di tiap proyek — butuh jauh lebih lama untuk memuat daripada daftar biasa.

Apa yang biasanya menyebabkannya: halaman memuat proyek-proyek dalam satu query, lalu memuat jumlah tugas untuk tiap proyek dalam query terpisah. Sepuluh proyek? Sebelas query. Seratus proyek? Seratus satu. Ini disebut “N+1 query,” dan ini bug performa database yang paling umum di aplikasi buatan AI karena AI mengoptimalkan untuk kode yang terbaca jelas, bukan kode yang berjalan efisien.

Apa yang diminta ke AI builder-mu: “Halaman ini membuat satu query per item. Bisakah kita mengambil semua data terkait dalam satu query — sebuah join atau agregat?” Kamu tidak perlu tahu arti kedua kata itu. AI tahu. Menunjukkan halaman lambatnya dan mengatakan “Saya rasa ini punya masalah N+1” biasanya sudah cukup.

Kamu bisa mengenali masalah N+1 tanpa tools apa pun: buka halamannya, hitung berapa lama ia butuh, lalu tambahkan sepuluh kali lipat lebih banyak item ke daftar yang mendasarinya. Kalau halaman sekarang sepuluh kali lebih lambat, kamu punya N+1. Kalau hanya sedikit lebih lambat, kamu tidak punya.

Sepatah kata soal optimasi prematur

Sebuah jebakan yang dijatuhi builder baru: mencoba membuat setiap halaman cepat sebelum ada yang memakai aplikasi. Jangan.

Pekerjaan performa punya biaya nyata. Menambahkan pagination ke daftar yang hanya akan pernah punya dua puluh baris itu usaha terbuang. Mengoptimalkan halaman yang dimuat dua kali sehari itu usaha terbuang. Memecah bundle untuk internal tool dengan tiga pengguna itu usaha terbuang. Waktu yang tepat untuk memperbaiki halaman lambat adalah saat kamu bisa menyebut halamannya, aksinya, dan seseorang yang terganggu olehnya.

Jadi bangun secara normal dulu. Rilis. Perhatikan bagaimana ia dipakai. Saat ada yang terasa lambat bagi orang sungguhan — termasuk kamu — cocokkan gejalanya dengan salah satu dari empat kategori di atas dan minta perbaikan spesifik itu. Kamu akan mendapat aplikasi yang lebih cepat tanpa menghabiskan seminggu untuk infrastruktur yang tak akan pernah disadari penggunamu.

Cara berbicara dengan AI builder-mu soal kecepatan

Pola yang berhasil: jelaskan gejalanya, bukan solusinya. AI jauh lebih baik dalam memilih perbaikan yang tepat daripada yang kamu duga, asalkan ia tahu apa yang sebenarnya salah.

Prompt bagus untuk disalin:

• “Saat saya membuka halaman pengaturan, ada jeda satu detik sebelum ada yang muncul. Bisakah kita cari tahu apa yang memblokir render pertama?”
• “Dashboard butuh lebih lama untuk memuat daripada halaman utama meskipun ia menampilkan lebih sedikit data. Bisakah kita lihat bagaimana ia mengambil datanya?”
• “Saat saya mengklik ‘save changes’ di halaman profil, tak ada yang terjadi selama dua detik. Tambahkan loading state dan pastikan tombolnya tidak bisa di-double-click.”
• “Uji daftar ini dengan 500 item palsu dan beri tahu saya di mana perlambatannya.”

Yang terakhir itu kurang dihargai. Meminta AI menghasilkan data uji dan mencoba sendiri halamannya adalah salah satu hal paling berguna yang bisa kamu lakukan. Ia sering menemukan titik lambat sebelum penggunamu menemukannya — dan mengusulkan perbaikan di respons yang sama.

Kecepatan di aplikasi buatan AI bukan soal sihir. Ia soal mengetahui masuk ke kategori mana dari empat itu masalahmu, dan meminta perbaikan yang tepat dengan kata-kata yang jelas. Lakukan itu, dan “terasa lambat” menjadi “terasa baik-baik saja” dengan segelintir perubahan kecil yang tertarget — bukan penulisan ulang.