Belajar Livewire - Performance & Production Optimization

#Pendahuluan

Komponen yang berfungsi belum tentu siap produksi. Aplikasi Livewire yang lambat biasanya bukan karena framework-nya, melainkan karena cara pemakaiannya: query yang boros, state yang terlalu banyak, atau caching yang tidak ada sama sekali. Di episode ini kita merangkai semua teknik performa yang sudah disinggung — dan menambah lapisan yang wajib dilakukan sebelum deploy.

Pola pikir yang benar: ukur dulu, optimasi kemudian. Jangan menebak mana yang lambat — ukur payload, jumlah query, dan waktu render. Setelah punya data, terapkan teknik yang tepat di titik yang benar.

#Query Efficiency

#Eager loading untuk menghindari N+1

Aturan yang sudah dibahas di series Laravel berlaku penuh di Livewire:

#[Computed]
public function posts()
{
    return Post::paginate(20); // user query per post!
}

#[Computed]
public function posts()
{
    return Post::with('author:id,name')->paginate(20);
}

Setiap kali komponen me-render (dan re-render), query dijalankan ulang — jadi efisiensi query adalah prioritas nomor satu.

#Hindari query berulang dalam satu render

Gunakan #[Computed] agar query dijalankan sekali per request, berapa pun kali dipakai (episode 6):

#[Computed]
public function totalRevenue()
{
    return Revenue::sum('total');
}

#Batasi dengan pagination

Jangan pernah Post::all() di halaman data. paginate(20) + $posts->links() (episode 11) membatasi kerja server sekaligus payload.

#Caching

#Cache Laravel untuk data jarang berubah

Data agregat yang tidak berubah setiap detik layak di-cache:

use Illuminate\Support\Facades\Cache;
 
#[Computed]
public function totalRevenue()
{
    return Cache::remember('revenue.total', now()->addMinutes(5), function () {
        return Revenue::sum('total');
    });
}

#Cache pada #[Computed] (v4)

Di Livewire v4, computed property mendukung cache eksplisit dengan TTL:

#[Computed]
public function topProducts()
{
    return Cache::remember('top-products', 300, function () {
        return Product::orderBy('sales', 'desc')->limit(5)->get();
    });
}

Cache yang tepat memindahkan beban dari database ke memori — dan di aplikasi Livewire yang sering me-render ulang, dampaknya langsung terasa. Jangan lupa membatalkan cache saat data berubah (misalnya di hook updated atau setelah simpan).

#Lazy Loading dan Batching

Kombinasikan teknik dari episode 14 dan 16:

• Komponen berat → lazy atau defer agar tidak memblokir initial render.
• Data yang dipakai sesaat → wire:init daripada query di mount().
• Polling → interval realistis (5-30 detik), bukan 1 detik.
• v4 membundel request: beberapa lazy/deferred component bisa dimuat sekaligus (bundle), mengurangi jumlah request paralel.

#Konfigurasi Produksi Laravel

Sebelum deploy, jalankan optimization Laravel:

php artisan optimize
php artisan view:cache
php artisan event:cache
php artisan config:cache

• config:cache — melindungi config sekaligus mempercepat boot.
• route:cache — mempercepat resolusi route (jalankan terpisah bila perlu).
• view:cache — meng-kompilasi Blade termasuk view Livewire.

#OPcache untuk PHP

Pastikan OPcache aktif di PHP (wajib di produksi):

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0

Dengan validate_timestamps=0, OPcache tidak mengecek timestamp file — lebih cepat, tapi berarti perubahan kode baru berlaku setelah php-fpm di-restart (pola standar deploy).

#Mengukur Payload dan DOM Diff

Kurang berguna mengoptimasi tanpa tahu angkanya. Tiga cara mengukur:

#1. Network tab (browser)

• Buka DevTools → Network.
• Perhatikan ukuran response request livewire/update — snapshot besar = state boros.
• Perhatikan jumlah request per interaksi.

#2. Laravel Debugbar

composer require barryvdh/laravel-debugbar --dev

Menampilkan jumlah query, waktu render, dan memory per request — cara tercepat menemukan N+1 dan query mahal.

#3. Inspeksi snapshot

Di response livewire/update, periksa bagian snapshot JSON: semakin besar data, semakin besar state yang dikirim bolak-balik. Jika besar, pindahkan nilai turunan ke #[Computed].

Tanda-tanda yang harus segera dikoreksi:

• Request livewire/update dengan response ratusan KB → pindah ke computed + lazy.
• Ratusan query identik per request → eager loading.
• Halaman pertama lambat padahal query cepat → lazy/defer komponen berat.

#Checklist Sebelum Deploy

• Eager loading di semua list (with()) — tidak ada N+1.
• #[Computed] untuk nilai turunan; tidak ada query berulang per render.
• Cache untuk data jarang berubah + invalidation yang benar.
• Pagination di semua halaman data.
• Lazy/defer untuk komponen berat; polling interval realistis.
• php artisan optimize + OPcache aktif.
• Debugbar hanya aktif di development (APP_DEBUG=false di produksi).
• Ukur payload snapshot & jumlah query sebagai baseline.

#Pitfall Umum

• Optimasi tanpa pengukuran: membuang waktu di tempat yang salah. Ukur dulu.
• Cache tanpa invalidation: data basi di UI lebih buruk dari query lambat.
• Post::all() di komponen: membengkakkan payload dan mengulur render.
• OPcache validate_timestamps=1 di produksi: masih mengecek file per request — buang kecepatannya.
• Mengabaikan ukuran snapshot: state membengkak diam-diam seiring fitur bertambah.

#Penutup

Inti yang harus dibawa pulang:

• Prioritaskan query: eager loading, computed, pagination.
• Cache data jarang berubah dengan Cache::remember + invalidation yang benar.
• Lazy/defer komponen berat; realistis dalam polling.
• Jalankan php artisan optimize dan aktifkan OPcache sebelum deploy.
• Ukur payload, query, dan render time — optimasi berdasarkan data, bukan tebakan.

Di episode 22 — episode terakhir — kita akan membahas SFC & refleksi akhir: single-file components untuk project skala kecil-menengah, rekap seluruh perjalanan episode 0-21, checklist production lengkap, dan sumber resmi untuk terus berkembang. Sampai jumpa di episode 22!