Laravel adalah banyak hal. Tapi cepat bukan salah satunya. Mari pelajari beberapa trik perdagangan untuk membuatnya lebih cepat!
Tidak ada pengembang PHP yang tidak tersentuh Laravel hari-hari ini. Mereka adalah pengembang junior atau menengah yang menyukai pengembangan cepat yang ditawarkan Laravel, atau mereka adalah pengembang senior yang terpaksa mempelajari Laravel karena tekanan pasar.
Either way, tidak dapat disangkal bahwa Laravel telah merevitalisasi ekosistem PHP (saya, pasti, sudah lama meninggalkan dunia PHP jika Laravel tidak ada).
Cuplikan pujian diri (agak dibenarkan) dari Laravel
Namun, karena Laravel berusaha sekuat tenaga untuk membuat segalanya mudah bagi Anda, itu berarti bahwa di bawahnya ada banyak sekali pekerjaan untuk memastikan Anda memiliki kehidupan yang nyaman sebagai pengembang. Semua fitur “ajaib” Laravel yang sepertinya berfungsi memiliki lapisan demi lapisan kode yang perlu dikocok setiap kali fitur berjalan. Bahkan Pengecualian sederhana melacak seberapa dalam lubang kelinci (perhatikan di mana kesalahan dimulai, sampai ke kernel utama):
Untuk apa yang tampaknya merupakan kesalahan kompilasi di salah satu tampilan, ada 18 pemanggilan fungsi untuk dilacak. Saya pribadi menemukan 40, dan mungkin ada lebih banyak lagi jika Anda menggunakan pustaka dan plugin lain.
Intinya, secara default ini berlapis-lapis kode, membuat Laravel lambat.
Seberapa lambat Laravel?
Sejujurnya, tidak mungkin menjawab pertanyaan ini karena beberapa alasan.
Pertama, tidak ada standar yang diterima, objektif, dan masuk akal untuk mengukur kecepatan aplikasi Web. Lebih cepat atau lebih lambat dibandingkan dengan apa? Dalam kondisi apa?
Kedua, aplikasi Web bergantung pada banyak hal (database, sistem file, jaringan, cache, dll.) sehingga konyol membicarakan kecepatan. Aplikasi web yang sangat cepat dengan database yang sangat lambat adalah aplikasi web yang sangat lambat. 🙂
Tapi ketidakpastian ini justru mengapa tolok ukur populer. Meskipun mereka tidak berarti apa-apa (lihat ini dan ini), mereka menyediakan beberapa kerangka acuan dan membantu kita agar tidak menjadi gila. Oleh karena itu, dengan beberapa sejumput garam siap, mari kita salah, gambaran kasar tentang kecepatan di antara kerangka kerja PHP.
Menggunakan GitHub yang agak terhormat ini sumberberikut adalah susunan kerangka kerja PHP jika dibandingkan:
Anda bahkan mungkin tidak memperhatikan Laravel di sini (bahkan jika Anda menyipitkan mata dengan sangat keras) kecuali Anda melemparkan kasing Anda tepat ke ujung ekor. Ya, teman-teman, Laravel datang terakhir! Sekarang, memang, sebagian besar “kerangka kerja” ini tidak terlalu praktis atau bahkan berguna, tetapi ini memberi tahu kita betapa lambatnya Laravel jika dibandingkan dengan yang lebih populer lainnya.
Biasanya, “kelambatan” ini tidak ditampilkan dalam aplikasi karena aplikasi web kita sehari-hari jarang mencapai angka tinggi. Tapi begitu mereka melakukannya (katakanlah, di atas 200-500 konkurensi), server mulai tersedak dan mati. Ini adalah waktu ketika membuang lebih banyak perangkat keras pada masalah tidak menguranginya, dan tagihan infrastruktur naik begitu cepat sehingga cita-cita tinggi Anda tentang komputasi awan runtuh.
Tapi hei, semangat! Artikel ini bukan tentang apa yang tidak bisa dilakukan, tapi tentang apa yang bisa dilakukan. 🙂
Kabar baiknya adalah, Anda dapat melakukan banyak hal untuk membuat aplikasi Laravel Anda berjalan lebih cepat. Beberapa kali cepat. Ya, jangan bercanda. Anda dapat membuat basis kode yang sama menjadi balistik dan menghemat beberapa ratus dolar untuk tagihan infrastruktur/hosting setiap bulan. Bagaimana? Mari kita mulai.
Empat jenis optimasi
Menurut pendapat saya, pengoptimalan dapat dilakukan pada empat level berbeda (dalam hal aplikasi PHP, yaitu):
- Tingkat bahasa: Ini berarti Anda menggunakan versi bahasa yang lebih cepat dan menghindari fitur/gaya pengkodean tertentu dalam bahasa yang membuat kode Anda lambat.
- Tingkat kerangka: Ini adalah hal-hal yang akan kami bahas dalam artikel ini.
- Tingkat infrastruktur: Menyetel manajer proses PHP, server web, basis data, dll.
- Tingkat perangkat keras: Pindah ke penyedia hosting perangkat keras yang lebih baik, lebih cepat, dan lebih kuat.
Semua jenis pengoptimalan ini ada tempatnya (misalnya, pengoptimalan PHP-fpm cukup kritis dan kuat). Namun fokus artikel ini adalah pengoptimalan murni tipe 2: yang terkait dengan kerangka kerja.
Ngomong-ngomong, tidak ada alasan di balik penomoran, dan itu bukan standar yang diterima. Saya baru saja membuat ini. Tolong jangan pernah mengutip saya dan berkata, “Kami membutuhkan pengoptimalan tipe-3 di server kami,” atau pimpinan tim Anda akan membunuh Anda, menemukan saya, dan kemudian membunuh saya juga. 😀
Dan sekarang, akhirnya, kami tiba di tanah perjanjian.
Daftar isi
Waspadai kueri basis data n+1
Masalah kueri n+1 adalah masalah umum saat ORM digunakan. Laravel memiliki ORM kuat yang disebut Eloquent, yang begitu indah, begitu nyaman, sehingga kita sering lupa untuk melihat apa yang sedang terjadi.
Pertimbangkan skenario yang sangat umum: menampilkan daftar semua pesanan yang dilakukan oleh daftar pelanggan tertentu. Ini sangat umum dalam sistem e-niaga dan antarmuka pelaporan apa pun secara umum di mana kita perlu menampilkan semua entitas yang terkait dengan beberapa entitas.
Di Laravel, kita mungkin membayangkan fungsi pengontrol yang melakukan pekerjaan seperti ini:
class OrdersController extends Controller
{
// ...
public function getAllByCustomers(Request $request, array $ids) {
$customers = Customer::findMany($ids);
$orders = collect(); // new collection
foreach ($customers as $customer) {
$orders = $orders->merge($customer->orders);
}
return view('admin.reports.orders', ['orders' => $orders]);
}
}
Manis! Dan yang lebih penting, elegan, cantik. 🤩🤩
Sayangnya, ini adalah cara yang buruk untuk menulis kode di Laravel.
Inilah alasannya.
Saat kami meminta ORM untuk mencari pelanggan tertentu, kueri SQL seperti ini dihasilkan:
SELECT * FROM customers WHERE id IN (22, 45, 34, . . .);
Yang persis seperti yang diharapkan. Akibatnya, semua baris yang dikembalikan disimpan dalam koleksi $customers di dalam fungsi pengontrol.
Sekarang kami mengulang setiap pelanggan satu per satu dan mendapatkan pesanan mereka. Ini mengeksekusi kueri berikut. . .
SELECT * FROM orders WHERE customer_id = 22;
. . . sebanyak jumlah pelanggan.
Dengan kata lain, jika kita perlu mendapatkan data pesanan untuk 1000 pelanggan, jumlah total kueri database yang dieksekusi adalah 1 (untuk mengambil semua data pelanggan) + 1000 (untuk mengambil data pesanan untuk setiap pelanggan) = 1001. Ini dari situlah nama n+1 berasal.
Bisakah kita berbuat lebih baik? Tentu! Dengan menggunakan apa yang dikenal sebagai pemuatan bersemangat, kita dapat memaksa ORM untuk melakukan GABUNG dan mengembalikan semua data yang diperlukan dalam satu kueri! Seperti ini:
$orders = Customer::findMany($ids)->with('orders')->get();
Struktur data yang dihasilkan adalah yang bersarang, tentu saja, tetapi data pesanan dapat dengan mudah diekstraksi. Permintaan tunggal yang dihasilkan, dalam hal ini, adalah seperti ini:
SELECT * FROM customers INNER JOIN orders ON customers.id = orders.customer_id WHERE customers.id IN (22, 45, . . .);
Satu kueri, tentu saja, lebih baik daripada seribu kueri tambahan. Bayangkan apa yang akan terjadi jika ada 10.000 pelanggan yang harus diproses! Atau amit-amit jika kami juga ingin memajang item yang ada di setiap pesanan! Ingat, nama tekniknya adalah eager loading, dan itu hampir selalu merupakan ide yang bagus.
Cache konfigurasi!
Salah satu alasan fleksibilitas Laravel adalah banyaknya file konfigurasi yang merupakan bagian dari framework. Ingin mengubah bagaimana/di mana gambar disimpan?
Nah, ubah saja file config/filesystems.php (setidaknya saat penulisan). Ingin bekerja dengan banyak driver antrean? Jangan ragu untuk mendeskripsikannya di config/queue.php. Saya baru saja menghitung dan menemukan bahwa ada 13 file konfigurasi untuk berbagai aspek framework, memastikan Anda tidak akan kecewa apa pun yang ingin Anda ubah.
Mengingat sifat PHP, setiap kali permintaan Web baru masuk, Laravel bangun, mem-boot semuanya, dan mem-parsing semua file konfigurasi ini untuk mengetahui cara melakukan sesuatu secara berbeda kali ini. Kecuali itu bodoh jika tidak ada yang berubah dalam beberapa hari terakhir! Membangun kembali konfigurasi pada setiap permintaan adalah pemborosan yang dapat (sebenarnya, harus) dihindari, dan jalan keluarnya adalah perintah sederhana yang ditawarkan Laravel:
php artisan config:cache
Apa yang dilakukan adalah menggabungkan semua file konfigurasi yang tersedia menjadi satu dan cache ada di suatu tempat untuk pengambilan cepat. Lain kali ada permintaan Web, Laravel hanya akan membaca file tunggal ini dan melanjutkan.
Yang mengatakan, caching konfigurasi adalah operasi yang sangat rumit yang dapat meledak di wajah Anda. Gotcha terbesar adalah setelah Anda mengeluarkan perintah ini, fungsi env() memanggil dari mana saja kecuali file konfigurasi akan mengembalikan null!
Masuk akal jika Anda memikirkannya. Jika Anda menggunakan caching konfigurasi, Anda memberi tahu kerangka kerja, “Anda tahu, saya pikir saya telah mengatur semuanya dengan baik dan saya 100% yakin saya tidak ingin mereka berubah.” Dengan kata lain, Anda mengharapkan lingkungan tetap statis, untuk itulah file .env.
Dengan demikian, berikut adalah beberapa aturan caching konfigurasi yang berlapis besi, sakral, dan tidak dapat dipatahkan:
Kurangi layanan yang dimuat secara otomatis
Agar membantu, Laravel memuat banyak sekali layanan saat aktif. Ini tersedia di file config/app.php sebagai bagian dari kunci array ‘penyedia’. Mari kita lihat apa yang saya miliki dalam kasus saya:
/*
|--------------------------------------------------------------------------
| Autoloaded Service Providers
|--------------------------------------------------------------------------
|
| The service providers listed here will be automatically loaded on the
| request to your application. Feel free to add your own services to
| this array to grant expanded functionality to your applications.
|
*/
'providers' => [
/*
* Laravel Framework Service Providers...
*/
IlluminateAuthAuthServiceProvider::class,
IlluminateBroadcastingBroadcastServiceProvider::class,
IlluminateBusBusServiceProvider::class,
IlluminateCacheCacheServiceProvider::class,
IlluminateFoundationProvidersConsoleSupportServiceProvider::class,
IlluminateCookieCookieServiceProvider::class,
IlluminateDatabaseDatabaseServiceProvider::class,
IlluminateEncryptionEncryptionServiceProvider::class,
IlluminateFilesystemFilesystemServiceProvider::class,
IlluminateFoundationProvidersFoundationServiceProvider::class,
IlluminateHashingHashServiceProvider::class,
IlluminateMailMailServiceProvider::class,
IlluminateNotificationsNotificationServiceProvider::class,
IlluminatePaginationPaginationServiceProvider::class,
IlluminatePipelinePipelineServiceProvider::class,
IlluminateQueueQueueServiceProvider::class,
IlluminateRedisRedisServiceProvider::class,
IlluminateAuthPasswordsPasswordResetServiceProvider::class,
IlluminateSessionSessionServiceProvider::class,
IlluminateTranslationTranslationServiceProvider::class,
IlluminateValidationValidationServiceProvider::class,
IlluminateViewViewServiceProvider::class,
/*
* Package Service Providers...
*/
/*
* Application Service Providers...
*/
AppProvidersAppServiceProvider::class,
AppProvidersAuthServiceProvider::class,
// AppProvidersBroadcastServiceProvider::class,
AppProvidersEventServiceProvider::class,
AppProvidersRouteServiceProvider::class,
],
Sekali lagi, saya hitung, dan ada 27 layanan yang terdaftar! Sekarang, Anda mungkin membutuhkan semuanya, tetapi kecil kemungkinannya.
Misalnya, saya kebetulan sedang membangun REST API saat ini, yang berarti saya tidak memerlukan Penyedia Layanan Sesi, Penyedia Layanan Tampilan, dll. Dan karena saya melakukan beberapa hal dengan cara saya dan tidak mengikuti default kerangka kerja , saya juga dapat menonaktifkan Penyedia Layanan Autentikasi, Penyedia Layanan Paginasi, Penyedia Layanan Terjemahan, dan seterusnya. Secara keseluruhan, hampir setengahnya tidak diperlukan untuk kasus penggunaan saya.
Perhatikan baik-baik aplikasi Anda. Apakah perlu semua penyedia layanan ini? Tapi demi Tuhan, tolong jangan mengomentari layanan ini secara membabi buta dan mendorong produksi! Jalankan semua tes, periksa hal-hal secara manual pada mesin dev dan staging, dan menjadi sangat paranoid sebelum Anda menarik pelatuknya. 🙂
Bijaklah dengan tumpukan middleware
Saat Anda memerlukan beberapa pemrosesan khusus dari permintaan Web yang masuk, membuat middleware baru adalah jawabannya. Sekarang, sangat menggoda untuk membuka app/Http/Kernel.php dan menempelkan middleware di tumpukan web atau api; dengan begitu, itu menjadi tersedia di seluruh aplikasi dan jika tidak melakukan sesuatu yang mengganggu (seperti masuk atau memberi tahu, misalnya).
Namun, seiring berkembangnya aplikasi, kumpulan middleware global ini dapat menjadi beban diam-diam pada aplikasi jika semua (atau sebagian besar) darinya ada di setiap permintaan, bahkan jika tidak ada alasan bisnis untuk itu.
Dengan kata lain, berhati-hatilah di mana Anda menambahkan/menerapkan middleware baru. Akan lebih nyaman untuk menambahkan sesuatu secara global, tetapi penalti kinerjanya sangat tinggi dalam jangka panjang. Saya tahu rasa sakit yang harus Anda alami jika Anda menerapkan middleware secara selektif setiap kali ada perubahan baru, tetapi rasa sakit itu akan saya terima dan rekomendasikan!
Hindari ORM (kadang-kadang)
Sementara Eloquent membuat banyak aspek interaksi DB menjadi menyenangkan, itu mengorbankan kecepatan. Sebagai seorang mapper, ORM tidak hanya harus mengambil catatan dari database tetapi juga memberi contoh objek model dan menghidrasi (mengisinya) dengan data kolom.
Jadi, jika Anda melakukan $users = User::all() sederhana dan ada, katakanlah, 10.000 pengguna, framework akan mengambil 10.000 baris dari database dan secara internal melakukan 10.000 new User() dan mengisi propertinya dengan data yang relevan . Ini adalah sejumlah besar pekerjaan yang dilakukan di belakang layar, dan jika database adalah tempat aplikasi Anda menjadi hambatan, terkadang melewati ORM adalah ide yang bagus.
Ini terutama berlaku untuk kueri SQL yang kompleks, di mana Anda harus melewati banyak rintangan dan menulis penutupan setelah penutupan dan masih berakhir dengan kueri yang efisien. Dalam kasus seperti itu, lebih disukai melakukan DB::raw() dan menulis kueri secara manual.
Lewat ini studi kinerja, bahkan untuk sisipan sederhana Eloquent jauh lebih lambat karena jumlah catatan meningkat:
Gunakan caching sebanyak mungkin
Salah satu rahasia terbaik pengoptimalan aplikasi Web adalah caching.
Untuk yang belum tahu, caching berarti melakukan prakomputasi dan menyimpan hasil yang mahal (mahal dalam hal penggunaan CPU dan memori), dan hanya mengembalikannya saat kueri yang sama diulang.
Misalnya, di toko e-niaga, mungkin menemukan dari 2 juta produk, sebagian besar orang tertarik pada produk yang baru tersedia, dalam kisaran harga tertentu, dan untuk kelompok usia tertentu. Mengkueri database untuk informasi ini adalah hal yang sia-sia — karena kueri tidak sering berubah, lebih baik menyimpan hasil ini di tempat yang dapat kita akses dengan cepat.
Laravel memiliki dukungan bawaan untuk beberapa jenis caching. Selain menggunakan driver caching dan membangun sistem caching dari awal, Anda mungkin ingin menggunakan beberapa paket Laravel yang memfasilitasi penyimpanan model, cache kueridll.
Namun harap dicatat bahwa di luar kasus penggunaan tertentu yang disederhanakan, paket caching prebuilt dapat menyebabkan lebih banyak masalah daripada yang mereka selesaikan.
Lebih suka caching dalam memori
Saat Anda melakukan cache sesuatu di Laravel, Anda memiliki beberapa opsi tempat menyimpan perhitungan yang dihasilkan yang perlu di-cache. Opsi ini juga dikenal sebagai driver cache. Jadi, meskipun mungkin dan sangat masuk akal untuk menggunakan sistem file untuk menyimpan hasil cache, sebenarnya bukan itu yang dimaksud dengan caching.
Idealnya, Anda ingin menggunakan cache dalam memori (sepenuhnya berada di RAM) seperti Redis, Memcached, MongoDB, dll., sehingga di bawah beban yang lebih tinggi, caching berfungsi sebagai penggunaan vital daripada menjadi hambatan itu sendiri.
Sekarang, Anda mungkin berpikir bahwa memiliki disk SSD hampir sama dengan menggunakan stik RAM, tetapi itu bahkan tidak mendekati. Bahkan informal tolak ukur menunjukkan bahwa RAM mengungguli SSD 10-20 kali lipat dalam hal kecepatan.
Sistem favorit saya dalam hal caching adalah Redis. Dia sangat cepat (100.000 operasi baca per detik adalah umum), dan untuk sistem cache yang sangat besar, dapat dikembangkan menjadi a gugus dengan mudah.
Cache rute
Sama seperti konfigurasi aplikasi, rute tidak banyak berubah dari waktu ke waktu dan merupakan kandidat ideal untuk caching. Ini terutama benar jika Anda tidak tahan dengan file besar seperti saya dan akhirnya membagi web.php dan api.php Anda menjadi beberapa file. Satu perintah Laravel mengemas semua rute yang tersedia dan membuatnya berguna untuk akses di masa mendatang:
php artisan route:cache
Dan ketika Anda akhirnya menambahkan atau mengubah rute, cukup lakukan:
php artisan route:clear
Pengoptimalan gambar dan CDN
Gambar adalah inti dari sebagian besar aplikasi Web. Secara kebetulan, mereka juga merupakan konsumen bandwidth terbesar dan salah satu alasan terbesar untuk aplikasi/situs web yang lambat. Jika Anda hanya menyimpan gambar yang diunggah secara naif di server dan mengirimkannya kembali dalam tanggapan HTTP, Anda membiarkan peluang pengoptimalan besar-besaran berlalu begitu saja.
Rekomendasi pertama saya adalah tidak menyimpan gambar secara lokal — ada masalah kehilangan data yang harus dihadapi, dan bergantung pada wilayah geografis tempat pelanggan Anda berada, transfer data bisa sangat lambat.
Alih-alih, cari solusi seperti Cloudinary yang secara otomatis mengubah ukuran dan mengoptimalkan gambar dengan cepat.
Jika itu tidak memungkinkan, gunakan sesuatu seperti Cloudflare untuk menyimpan dan menyajikan gambar saat disimpan di server Anda.
Dan bahkan jika itu tidak memungkinkan, mengutak-atik perangkat lunak server web Anda sedikit untuk mengompres aset dan mengarahkan browser pengunjung ke cache, membuat banyak perbedaan. Berikut tampilan cuplikan konfigurasi Nginx:
server {
# file truncated
# gzip compression settings
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied any;
gzip_vary on;
# browser cache control
location ~* .(ico|css|js|gif|jpeg|jpg|png|woff|ttf|otf|svg|woff2|eot)$ {
expires 1d;
access_log off;
add_header Pragma public;
add_header Cache-Control "public, max-age=86400";
}
}
Saya menyadari bahwa pengoptimalan gambar tidak ada hubungannya dengan Laravel, tetapi ini adalah trik yang sangat sederhana dan kuat (dan sering diabaikan) yang tidak dapat membantu saya sendiri.
Pengoptimalan pemuat otomatis
Pemuatan otomatis adalah fitur yang rapi dan tidak terlalu tua di PHP yang bisa dibilang menyelamatkan bahasa dari malapetaka. Meskipun demikian, proses menemukan dan memuat kelas yang relevan dengan menguraikan string namespace yang diberikan membutuhkan waktu dan dapat dihindari dalam penerapan produksi yang menginginkan kinerja tinggi. Sekali lagi, Laravel memiliki solusi satu perintah untuk ini:
composer install --optimize-autoloader --no-dev
Berteman dengan antrian
Antrian adalah cara Anda memproses sesuatu ketika ada banyak hal, dan masing-masing membutuhkan waktu beberapa milidetik untuk menyelesaikannya. Contoh yang bagus adalah mengirim email — kasus penggunaan yang tersebar luas di aplikasi web adalah menembakkan beberapa email pemberitahuan saat pengguna melakukan beberapa tindakan.
Misalnya, dalam produk yang baru diluncurkan, Anda mungkin ingin pimpinan perusahaan (sekitar 6-7 alamat email) diberi tahu setiap kali seseorang melakukan pemesanan di atas nilai tertentu. Dengan asumsi bahwa gateway email Anda dapat menanggapi permintaan SMTP Anda dalam 500 ms, kita berbicara tentang menunggu pengguna selama 3-4 detik sebelum konfirmasi pesanan dimulai. Bagian UX yang sangat buruk, saya yakin Anda akan melakukannya setuju.
Obatnya adalah menyimpan pekerjaan saat masuk, memberi tahu pengguna bahwa semuanya berjalan dengan baik, dan memprosesnya (beberapa detik) kemudian. Jika terjadi kesalahan, pekerjaan yang diantrekan dapat dicoba beberapa kali sebelum dinyatakan gagal.
Kredit: Microsoft.com
Meskipun sistem antrean sedikit memperumit penyiapan (dan menambahkan beberapa overhead pemantauan), ini sangat diperlukan dalam aplikasi Web modern.
Pengoptimalan aset (Laravel Mix)
Untuk aset front-end apa pun di aplikasi Laravel Anda, harap pastikan ada pipeline yang mengkompilasi dan mengecilkan semua file aset. Yang sudah nyaman dengan sistem bundler seperti Webpack, Gulp, Parcel, dll, tidak perlu repot, tapi jika belum melakukan ini, Campuran Laravel adalah rekomendasi yang solid.
Mix adalah pembungkus yang ringan (dan menyenangkan, sejujurnya!) di sekitar Webpack yang menangani semua file CSS, SASS, JS, dll., untuk produksi. File .mix.js tipikal bisa sekecil ini dan masih bekerja dengan sangat baik:
const mix = require('laravel-mix');
mix.js('resources/js/app.js', 'public/js')
.sass('resources/sass/app.scss', 'public/css');
Ini secara otomatis menangani impor, minifikasi, pengoptimalan, dan seluruh shebang saat Anda siap untuk produksi dan menjalankan npm run production. Mix menangani tidak hanya file JS dan CSS tradisional, tetapi juga komponen Vue dan React yang mungkin Anda miliki dalam alur kerja aplikasi Anda.
Info lebih lanjut di sini!
Kesimpulan
Optimalisasi kinerja lebih merupakan seni daripada sains — mengetahui bagaimana dan seberapa banyak yang harus dilakukan lebih penting daripada apa yang harus dilakukan. Yang mengatakan, tidak ada habisnya berapa banyak dan apa yang dapat Anda optimalkan dalam aplikasi Laravel.
Tapi apa pun yang Anda lakukan, saya ingin memberi Anda beberapa saran perpisahan — pengoptimalan harus dilakukan jika ada alasan yang kuat, dan bukan karena kedengarannya bagus atau karena Anda paranoid tentang kinerja aplikasi untuk 100.000+ pengguna padahal kenyataannya hanya ada 10.
Jika Anda tidak yakin apakah Anda perlu mengoptimalkan aplikasi Anda atau tidak, Anda tidak perlu menendang sarang lebah pepatah. Aplikasi kerja yang terasa membosankan tetapi melakukan apa yang harus dilakukan sepuluh kali lebih diinginkan daripada aplikasi yang telah dioptimalkan menjadi mesin super hibrida mutan tetapi kadang-kadang gagal.
Dan, bagi pemula untuk menjadi master Laravel, lihat ini kursus online.
Semoga aplikasi Anda berjalan jauh lebih cepat! 🙂
