Tips Optimasi Laravel untuk Dashboard Admin dan CMS

Dashboard admin dan CMS punya pola trafik yang beda dengan halaman publik. Query-nya lebih banyak, tabelnya sering besar, dan satu halaman bisa memanggil data dari beberapa relasi sekaligus. Kalau mulai terasa lambat, jangan langsung pasang cache di semua tempat. Biasanya ada beberapa titik yang lebih masuk akal untuk dibereskan dulu.

1. Mulai dari query yang benar-benar dipakai

Jangan menebak. Aktifkan Laravel Debugbar di lokal atau gunakan Telescope pada environment yang aman untuk melihat query, waktu eksekusi, dan jumlah query per request. Halaman daftar artikel, pengguna, pesanan, atau log aktivitas biasanya cepat menunjukkan masalahnya.

Ilustrasi ini merangkum konteks utama agar pembaca lebih cepat memahami topik sebelum masuk ke detail.

DB::listen(function ($query) {
    logger($query->sql, $query->bindings);
});

Kapan dipakai: saat halaman admin terasa berat tetapi CPU server masih terlihat normal. Sering kali biangnya query berulang, bukan spesifikasi server.

2. Hindari N+1 query dengan eager loading

Ini masalah klasik pada tabel admin. Misalnya Anda menampilkan 50 artikel, lalu setiap baris memanggil penulis dan kategori. Tanpa eager loading, Laravel bisa menjalankan lebih dari 100 query tambahan.

$posts = Post::with(['author:id,name', 'category:id,name'])
    ->latest()
    ->paginate(25);

Pilih kolom yang memang dipakai. Mengambil seluruh kolom relasi untuk sekadar menampilkan nama penulis itu boros, terutama jika tabel user menyimpan banyak metadata.

Ringkasan visual membantu menghubungkan pembahasan dengan contoh penerapan di lingkungan operasional.

Kapan dipakai: pada listing, tabel relasional, halaman detail dengan banyak widget, dan komponen Blade yang mengakses relasi di dalam loop.

3. Paginate data, jangan ambil semuanya

Admin kadang meminta tabel “semua data” karena terdengar praktis. Di produksi, itu bisa jadi jebakan ketika data sudah puluhan ribu baris. Gunakan paginate() untuk halaman yang perlu nomor halaman, atau simplePaginate() jika total data tidak penting.

$users = User::select('id', 'name', 'email', 'created_at')
    ->orderByDesc('id')
    ->simplePaginate(50);

Untuk tabel yang sering dibuka ulang, pertimbangkan cursor pagination. Ia lebih stabil untuk data yang terus masuk, seperti audit log atau transaksi.

Kapan dipakai: hampir selalu untuk listing CMS. Pengecualian hanya untuk data kecil seperti daftar role atau pengaturan statis.

4. Jangan paksa pencarian SQL dengan wildcard di semua kolom

Pencarian LIKE %kata% pada tabel besar akan makin mahal, apalagi jika digabung banyak kolom dan relasi. Untuk pencarian admin sederhana, batasi kolom dan tambahkan indeks yang relevan. Kalau kebutuhan pencariannya sudah mirip mesin pencari, pindahkan ke Laravel Scout dengan Meilisearch atau Typesense.

$query->where(function ($q) use ($keyword) {
    $q->where('title', 'like', $keyword.'%')
      ->orWhere('slug', 'like', $keyword.'%');
});

Prefix search biasanya lebih ramah indeks dibanding wildcard di depan. Memang tidak selalu cocok untuk semua UX, tapi cukup efektif untuk pencarian judul atau slug di CMS.

Kapan dipakai: ketika fitur pencarian mulai lambat di tabel artikel, produk, pelanggan, atau arsip dokumen.

5. Tambahkan indeks berdasarkan pola filter nyata

Indeks bukan hiasan schema. Lihat filter yang paling sering dipakai admin: status, tanggal publikasi, author, tenant, atau kombinasi status dan tanggal. Dari situ baru tentukan indeks.

Schema::table('posts', function (Blueprint $table) {
    $table->index(['status', 'published_at']);
    $table->index('author_id');
});

Jangan asal mengindeks semua kolom. Terlalu banyak indeks memperlambat proses insert dan update. Untuk CMS yang sering menyimpan draft otomatis, efeknya bisa terasa.

Kapan dipakai: setelah query profiling menunjukkan full table scan atau filter tertentu selalu mahal.

6. Cache data referensi dan widget ringkasan

Data seperti daftar kategori, role, menu, konfigurasi situs, atau angka ringkasan dashboard tidak perlu dihitung ulang setiap request. Cache-kan dengan TTL yang masuk akal, lalu hapus cache saat datanya berubah.

$stats = Cache::remember('dashboard:stats', now()->addMinutes(5), function () {
    return [
        'published_posts' => Post::where('status', 'published')->count(),
        'draft_posts' => Post::where('status', 'draft')->count(),
    ];
});

Lima menit biasanya aman untuk kartu statistik operasional. Tetapi jangan cache data permission per pengguna dengan key umum; itu bisa membuat pengguna melihat data yang bukan haknya.

Kapan dipakai: untuk data yang sering dibaca, jarang berubah, atau agregasinya cukup mahal.

7. Pindahkan pekerjaan berat ke queue

Import CSV, resize gambar, kirim email massal, generate laporan Excel, dan sinkronisasi API pihak ketiga jangan dikerjakan di request web. Pengguna hanya butuh konfirmasi bahwa proses sudah dimulai; sisanya biarkan worker yang mengurus.

GenerateMonthlyReport::dispatch($month, $user->id);

Pastikan queue worker dipantau lewat Supervisor, systemd, atau Horizon jika memakai Redis. Queue yang bagus di kode tetapi tidak ada worker-nya tetap akan terlihat seperti fitur rusak.

Kapan dipakai: saat proses bisa lebih dari beberapa detik, berpotensi timeout, atau tidak wajib selesai sebelum halaman dibalas.

8. Optimalkan upload dan pengolahan gambar

CMS sering melambat bukan karena database, melainkan karena satu request mengunggah gambar besar lalu membuat banyak thumbnail. Batasi ukuran file, kompres di background, dan simpan file di object storage bila trafik mulai naik.

Jika memakai Spatie Media Library atau proses image sendiri, buat conversion melalui queue. Untuk gambar artikel, beberapa ukuran yang benar-benar dipakai jauh lebih sehat daripada membuat belasan varian “jaga-jaga”.

Kapan dipakai: ketika editor sering mengunggah foto dari ponsel atau tim konten mengelola katalog dengan banyak gambar.

9. Rapikan konfigurasi dan deploy Laravel untuk produksi

Hal dasar ini sering terlewat pada server baru. Jalankan cache konfigurasi, route, dan view saat deploy. Pastikan APP_DEBUG=false, gunakan OPcache PHP, dan jangan menjalankan composer dengan dependency development di server produksi.

php artisan config:cache
php artisan route:cache
php artisan view:cache
composer install --no-dev --optimize-autoloader

Catatan kecil: jangan gunakan config:cache bila aplikasi masih membaca env() langsung di luar file konfigurasi. Nilainya bisa membuat perilaku aplikasi membingungkan setelah deploy.

Kapan dipakai: pada setiap deployment produksi, terutama aplikasi admin yang dipakai sepanjang jam kerja.

10. Ukur setelah mengubah sesuatu

Optimasi yang tidak diukur mudah berubah jadi pekerjaan kosmetik. Catat waktu respons halaman penting, jumlah query, penggunaan memori, dan waktu job queue sebelum serta sesudah perubahan. Satu perbaikan kecil pada query listing bisa lebih berdampak daripada memindahkan seluruh aplikasi ke server yang lebih mahal.

Mulailah dari halaman yang paling sering dipakai tim: daftar konten, editor, pencarian, dan dashboard ringkasan. Itu biasanya memberi hasil paling cepat dan paling terasa oleh pengguna.