Caching di Production

Setiap rilis kode baru ke production sebaiknya disertai ritual yang sama: membekukan struktur bootstrap aplikasi agar request pertama sehabis deploy tidak menanggung biaya pemuatan ulang seluruh konfigurasi, rute, dan template. Melebihi sekadar performa, ritual ini adalah bagian dari kebenaran deployment — cache yang lupa dibangun ulang membuat aplikasi menjalankan kode lama di tengah kode baru. Chapter ini menyusun urutan ritual tersebut dari sisi deployment: mulai dari autoloader Composer hingga satu perintah optimize yang mengerjakan semuanya dengan urutan yang sudah dijamin benar. Pembahasan mendalam tiap jenis cache sudah kita selesaikan di section Performa; di sini fokusnya adalah kapan dan bagaimana semuanya diterapkan dalam satu rilis.

Autoloader yang Tidak Menyusuri Direktori #

Langkah pertama bukan perintah artisan, melainkan Composer. Secara default, autoloader PSR-4 mencari kelas dengan menyusuri direktori berdasar namespace — murah, tetapi tetap berupa kerja pencarian. Flag --optimize membangun classmap lengkap: setiap kelas dipetakan ke berkasnya, sehingga require menjadi langsung:

composer dump-autoload --optimize

Output yang Dihasilkan (baris titik dipangkas agar muat):

Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi

  INFO  Discovering packages.

  laravel/pail ..................................................... DONE
  laravel/pao ....................................................... DONE
  laravel/sanctum ................................................... DONE
  laravel/tinker .................................................... DONE
  nesbot/carbon ..................................................... DONE
  nunomaduro/collision ............................................. DONE
  nunomaduro/termwind ............................................... DONE

Generated optimized autoload files containing 6920 classes

Hasilnya: 6.920 kelas terpetakan ke lokasi pastinya. Di server produksi, flag ini menyatu dengan instalasi dependency lewat composer install --no-dev --optimize-autoloader yang sudah kita bahas di Production Environment — flag --no-dev membuang paket development seperti PHPUnit sekaligus memangkas jumlah kelas yang dipetakan.

php artisan optimize: Ritual dalam Satu Perintah #

Tiga perintah cache utama — config:cache, route:cache, view:cache — bisa dipanggil satu per satu. Namun Laravel menyediakan pintasan yang menjalankan semuanya dengan urutan yang sudah ditangani framework:

php artisan optimize

Output yang Dihasilkan:

   INFO  Caching framework bootstrap, configuration, and metadata.

  config ......................................................... 7.01ms DONE
  events ......................................................... 0.98ms DONE
  routes ......................................................... 8.52ms DONE
  views .......................................................... 63.49ms DONE

Urutan pada output bukan kebetulan: config selalu dibekukan lebih dulu, disusul events, routes, lalu views. Urutan ini penting karena perintah-perintah berikutnya mem-boot aplikasi — dengan config yang baru saja dibekukan, route:cache dan event:cache dijamin membangun cache di atas konfigurasi terbaru, bukan yang basi. Bila kita menjalankan perintah secara manual, disiplin yang sama harus kita jaga sendiri: ubah .env lebih dulu, lalu config:cache, baru route:cache.

Empat berkas hasil ritual ini bisa kita periksa setelahnya:

ls -la bootstrap/cache/

Output yang Dihasilkan:

total 80
-rw-rw-r--  1 z z   14 Sep 30 13:56 .gitignore
-rw-r--r--  1 z z 22411 Oct 13 22:50 config.php
-rw-r--r--  1 z z  111 Oct 13 22:50 events.php
-rwxr-xr-x  1 z z  963 Oct 13 22:50 packages.php
-rw-r--r--  1 z z  9151 Oct 13 22:50 routes-v7.php
-rwxr-xr-x  1 z z  22575 Oct 13 22:50 services.php

Perilaku tiap bekuan berbeda satu sama lain — dan di sinilah letak kehati-hatian deployment:

Baris terakhir tabel sering disalahpahami. View cache memang ikut dibangun oleh optimize, tetapi Blade memeriksa waktu modifikasi berkas pada setiap request — mengubah template di server langsung memicu kompilasi ulang. Sebaliknya, config.php dan routes-v7.php dipakai apa adanya selama berkasnya ada: perubahan kode tanpa pembangunan ulang membuat aplikasi diam-diam menjalankan versi lama, jebakan yang sudah kita buktikan di Config Cache dan akan menghantui kita lagi di bab rollback.

Kapan Tidak Mengoptimalkan #

Di mesin development, ritual ini justru kontraproduktif. Config yang terkunci membuat setiap eksperimen .env tampak “tidak berefek”, dan route cache membuat route baru yang kita tulis seolah tidak terdaftar — kelambatan belajar, bukan kecepatan. Kedua perintah itu tetap mau berjalan di environment local tanpa komplain, sehingga disiplinnya murni milik kita: optimize hanya hidup di dalam skrip deployment, tidak pernah diketik manual di laptop. Aset frontend pun tidak butuh cache-clear tambahan: Vite memberi nama berkas dengan hash konten, sehingga HTML lama yang mengarah ke aset lama tetap valid dan aset baru terbaca begitu HTML baru dirender, selengkapnya di Asset Optimization .

Membongkar Semuanya: optimize:clear #

Sisi lawan ritual adalah optimize:clear — membongkar keempat bekuan sekaligus, berguna saat debugging produksi atau menjalankan sesuatu di luar mode deployment:

php artisan optimize:clear

Output yang Dihasilkan:

   INFO  Clearing cached bootstrap files.

  config ......................................................... 0.86ms DONE
  cache ......................................................... 10.22ms DONE
  compiled ....................................................... 0.82ms DONE
  events ......................................................... 0.46ms DONE
  routes ......................................................... 0.44ms DONE
  views .......................................................... 2.83ms DONE

Enam baris tersebut membersihkan config, route, view, dan event cache sekaligus berkas bootstrap packages.php/services.php (label cache dan compiled). Ritual kini utuh: satu perintah untuk membangun, satu perintah untuk membongkar, dan pemahaman tentang berkas mana yang membatalkan dirinya secara otomatis. Cerita deployment berikutnya justru tentang apa yang terjadi setelah ritual ini selesai — melihat hasilnya di log dan memantau aplikasi yang baru saja kita rilis, dibahas di Logging dan Monitoring di Production .