Nilai evaluasi Lighthouse bukanlah alat penyetel, melainkan cermin yang mencerminkan kesehatan arsitektur

Mengapa Perbedaan Terjadi di Situs yang Sama

Jika ingin mengejar nilai evaluasi Lighthouse yang tinggi, sekadar melakukan kompresi gambar, penundaan pemuatan skrip, dan mengatasi pergeseran tata letak saja tidak cukup. Saat mengamati proyek nyata, perbedaan antara situs yang secara konsisten mempertahankan skor tinggi dan situs yang skornya menurun setiap kali menambahkan fitur baru terletak pada pilihan saat tahap perancangan, bukan pada seberapa banyak usaha yang dilakukan. Situs yang membutuhkan lebih sedikit proses saat browser memuatnya cenderung memiliki skor yang lebih stabil.

Apa yang Benar-Benar Diverifikasi Lighthouse

Lighthouse bukanlah alat untuk menilai keunggulan kerangka kerja, melainkan untuk mengkuantifikasi pengalaman pengguna nyata.

• Kecepatan tampilan konten di layar
• Seberapa besar JavaScript memblokir main thread
• Stabilitas tata letak selama pemuatan halaman
• Aksesibilitas dan crawlability struktur dokumen

Indikator-indikator ini menunjukkan bagaimana pengambilan keputusan awal pengembangan mempengaruhi hasil. Halaman yang bergantung pada bundel sisi klien yang besar secara alami akan memiliki skor lebih rendah. Sebaliknya, halaman berbasis HTML statis cenderung memiliki performa yang lebih dapat diprediksi.

JavaScript dan Hydration: Pelaku Utama Penurunan Performa

Banyak audit yang dilakukan menunjukkan bahwa eksekusi JavaScript adalah faktor utama yang menghambat Lighthouse. Ini bukan masalah kualitas kode, melainkan batasan mendasar dari lingkungan single-thread browser.

Proses hydration sangat membebani, karena semua tugas seperti inisialisasi runtime kerangka kerja, analisis dependency graph, dan inisialisasi state dilakukan sebelum halaman menjadi interaktif. Untuk fitur interaktif yang kecil, seringkali diperlukan bundel JavaScript yang tidak seimbang besar.

Arsitektur yang secara default mengandalkan JavaScript memerlukan optimisasi berkelanjutan agar performa tetap terjaga. Sebaliknya, arsitektur yang secara eksplisit menganggap JavaScript sebagai opsi menghasilkan hasil yang lebih stabil.

Kepastian yang Diberikan oleh Generasi Statis

Dengan menyajikan HTML yang sudah dirender sebelumnya, beberapa variabel dalam perhitungan performa hilang:

• Tidak ada penundaan dari server-side rendering
• Tidak perlu proses bootstrap di sisi klien
• Browser menerima HTML lengkap dan dapat diprediksi

Hasilnya, metrik utama seperti TTFB, LCP, dan CLS secara otomatis membaik. Generasi statis tidak menjamin skor sempurna, tetapi secara signifikan mengurangi kemungkinan kegagalan.

Contoh: Pelajaran dari Rebuild Blog Pribadi

Saat membangun ulang blog, saya mencoba beberapa pendekatan standar. Pengaturan berbasis React yang bergantung pada hydration secara default cukup fleksibel, tetapi setiap kali menambahkan fitur baru, saya harus memikirkan mode rendering, pengambilan data, dan ukuran bundel.

Saya mencoba pendekatan berbeda: menjadikan HTML statis sebagai default dan memperlakukan JavaScript sebagai pengecualian. Saya memilih Astro karena batasan default-nya cocok dengan hipotesis yang ingin saya uji.

Yang mengesankan adalah, bukan skor awal yang tinggi, tetapi seberapa sedikit usaha yang diperlukan untuk mempertahankan skor seiring waktu. Rilis konten baru tidak menyebabkan penurunan, dan elemen interaktif kecil tidak memicu peringatan yang tidak relevan. Dasarnya tidak terganggu.

Tidak Ada Solusi Serba Bisa

Pendekatan ini tidak selalu optimal untuk semua kasus. Untuk aplikasi yang membutuhkan data pengguna terautentikasi, pembaruan real-time, dan manajemen status sisi klien yang kompleks, arsitektur static-first tidak cukup kuat.

Kerangka kerja rendering sisi klien lebih unggul dalam situasi yang membutuhkan fleksibilitas tersebut. Tapi, konsekuensinya, kompleksitas saat runtime meningkat. Yang penting adalah pemilihan arsitektur yang tercermin langsung dalam metrik Lighthouse.

Apa yang Mempengaruhi Stabilitas Skor Lighthouse

Lighthouse menampilkan bukan usaha, melainkan entropi.

Sistem yang bergantung pada perhitungan runtime akan semakin kompleks seiring penambahan fitur. Sebaliknya, sistem yang memindahkan proses ke tahap build secara default dapat membatasi kompleksitas tersebut.

Perbedaan ini menjelaskan mengapa satu situs membutuhkan usaha terus-menerus untuk mempertahankan performa, sementara situs lain tetap stabil dengan sedikit intervensi.

Kesimpulan: Skor Bukan untuk Dikejar, Melainkan Diamati

Skor Lighthouse yang tinggi lebih merupakan hasil dari arsitektur yang meminimalkan proses yang dilakukan browser saat memuat halaman, bukan dari usaha optimasi aktif.

Dengan mengintegrasikan performa sebagai batasan desain, Lighthouse tidak lagi menjadi indikator yang harus terus dikejar, melainkan indikator kesehatan sistem yang harus diamati. Yang penting bukan memilih kerangka kerja yang tepat, tetapi menentukan di mana kompleksitas dapat diterima.