Apa arti sebenarnya dari skor Lighthouse: Pemilihan arsitektur menentukan stabilitas

Skor tinggi Lighthouse telah lama dipercaya sebagai hasil dari proses optimasi yang menyeluruh. Diperkirakan bahwa ini adalah akumulasi dari tuning individual seperti kompresi gambar, penundaan pemuatan skrip, penanganan pergeseran tata letak, dan penyesuaian plugin. Namun, jika kita melihat data nyata, hipotesis ini tidak sesuai dengan kenyataan. Situs yang secara konsisten mempertahankan skor tinggi bukanlah yang paling merepotkan, melainkan yang memiliki beban proses browser yang lebih ringan.

Beban kerja browser menentukan performa

Yang diukur Lighthouse bukanlah keunggulan kerangka kerja, melainkan hasil nyata.

• Kecepatan tampilan konten (TTFB, LCP)
• Waktu JavaScript menguasai thread utama
• Stabilitas tata letak selama pemuatan (CLS)
• Aksesibilitas dan keterindeksan struktur

Metode pengukuran ini diputuskan di bawah lapisan optimasi semata. Terutama, ini terkait langsung dengan jumlah komputasi yang diproses browser saat runtime.

Jika situs bergantung pada bundel klien yang besar agar berfungsi, skor rendah tidak dapat dihindari. Sebaliknya, jika menggunakan HTML statis sebagai dasar dan meminimalkan proses di sisi klien, performa menjadi jauh lebih dapat diprediksi dan stabil.

Eksekusi JavaScript sebagai faktor penghambat terbesar

Banyak audit dan proyek menunjukkan bahwa eksekusi JavaScript adalah penyebab paling umum dari penurunan skor Lighthouse. Ini bukan masalah kualitas kode, melainkan pilihan arsitektur.

JavaScript dijalankan dalam lingkungan single-thread. Proses seperti runtime kerangka kerja, hidrasi, analisis dependensi, dan inisialisasi status memakan waktu hingga halaman menjadi interaktif. Bahkan untuk fitur kecil, seringkali diperlukan bundel yang tidak seimbang besar.

Arsitektur yang menganggap JavaScript sebagai default membutuhkan usaha berkelanjutan untuk menjaga performa. Sebaliknya, arsitektur yang secara eksplisit menganggap JavaScript sebagai opsi opsional cenderung menghasilkan hasil yang lebih stabil.

Mengurangi ketidakpastian melalui output statis

HTML yang dihasilkan sebelumnya menghilangkan beberapa variabel dari rumus performa.

• Tidak ada biaya rendering sisi server saat permintaan
• Tidak perlu bootstrap di sisi klien
• Browser menerima HTML lengkap dan dapat diprediksi

Dari sudut pandang Lighthouse, ini meningkatkan indikator seperti TTFB, LCP, dan CLS tanpa tuning khusus. Meskipun generasi statis tidak menjamin skor sempurna, ini secara signifikan mempersempit pola kegagalan.

Contoh implementasi: migrasi dari React

Saat membangun ulang blog pribadi, saya mempertimbangkan beberapa pendekatan termasuk setup hidrasi berbasis React. Pendekatan ini fleksibel dan fungsional, tetapi membutuhkan pengawasan terus-menerus untuk menjaga performa. Setiap penambahan fitur memerlukan peninjauan ulang strategi rendering, pengambilan data, dan ukuran bundel.

Sebagai alternatif, saya mencoba pendekatan berbasis HTML statis dan memperlakukan JavaScript sebagai solusi luar biasa. Pilihan ini menggunakan Astro, karena batasan defaultnya sesuai dengan hipotesis yang ingin diuji.

Yang menarik bukanlah peningkatan skor awal, melainkan seberapa kecil penurunan performa seiring waktu. Tidak ada penurunan setelah rilis konten baru, dan penambahan elemen interaktif kecil tidak menyebabkan peringatan berantai. Ini menunjukkan stabilitas arsitektur di tingkat dasar, di mana baseline sulit untuk tergerus.

Realitas trade-off

Pendekatan ini tidak universal. Arsitektur yang mengutamakan statis tidak cocok untuk aplikasi yang sangat dinamis dan kompleks dalam pengelolaan status. Skenario seperti data pengguna yang terautentikasi, pembaruan real-time, dan pengelolaan status klien yang rumit justru menjadi batasan.

Kerangka kerja yang mengandalkan rendering klien lebih fleksibel dalam situasi ini, tetapi harus menanggung kompleksitas saat runtime. Yang penting bukan satu metode lebih unggul, melainkan bahwa trade-off tersebut tercermin langsung dalam angka Lighthouse.

Akar penyebab stabilitas skor dan kerentanannya

Yang diungkap Lighthouse bukanlah hasil dari usaha, melainkan akumulasi dari kompleksitas yang berkembang.

Sistem yang bergantung pada runtime akan semakin kompleks seiring penambahan fitur. Sistem yang memusatkan proses saat build secara default mengendalikan kompleksitas ini. Perbedaan ini menjelaskan mengapa beberapa situs membutuhkan upaya terus-menerus untuk performa, sementara yang lain tetap stabil dengan sedikit intervensi.

Kesimpulan: stabilitas berasal dari arsitektur

Skor Lighthouse yang tinggi jarang merupakan hasil tuning agresif. Biasanya, ini muncul secara alami dari arsitektur yang meminimalkan proses yang harus dilakukan browser saat muatan awal.

Alat akan terus berkembang seiring waktu, tetapi prinsip dasarnya tetap sama. Jika performa bukan tujuan utama, melainkan batasan saat desain, Lighthouse bukanlah sesuatu yang harus dikejar, melainkan indikator yang diamati. Perubahan ini lebih berkaitan dengan memilih tempat yang sengaja menerima kompleksitas, bukan sekadar memilih kerangka kerja yang tepat.