Skor Lighthouse bukan hasil dari optimasi, melainkan cermin yang mencerminkan esensi arsitektur

Skor Lighthouse tinggi dan rendah menunjukkan perbedaan yang mencolok ketika dibandingkan. Situs dengan skor tinggi tidak selalu merupakan situs yang menghabiskan waktu paling banyak untuk optimasi, melainkan situs dengan desain sederhana yang tidak membuat browser bekerja terlalu berat.

Apa yang Ditunjukkan Metrik Performa

Lighthouse tidak mengukur peringkat alat atau kerangka kerja. Yang dievaluasi adalah hasil nyata:

• Kecepatan pengguna melihat konten yang bermakna
• Durasi JavaScript menempati thread utama
• Stabilitas tata letak selama tahap pemuatan
• Aksesibilitas dan crawlability struktur dokumen

Metrik-metrik ini (TTFB, LCP, CLS) adalah konsekuensi berantai dari keputusan yang dibuat pada tahap implementasi. Khususnya, metrik ini langsung berhubungan dengan volume komputasi yang diproses browser saat runtime.

Arsitektur yang bergantung pada bundel sisi klien berukuran besar akan menghasilkan skor rendah yang tak terhindarkan. Sebaliknya, situs yang berfokus pada HTML statis dengan logika sisi klien minimal dapat mencapai performa yang dapat diprediksi dan stabil.

Keserakahan JavaScript: Penjahat Sebenarnya di Balik Penurunan Performa

Ada masalah umum yang ditemukan di sebagian besar proyek audit. Yaitu eksekusi JavaScript.

Ini bukan masalah kualitas kode, melainkan berasal dari batasan fundamental lingkungan single-thread browser. Runtime kerangka kerja, pemrosesan hidrasi, penyelesaian dependensi, inisialisasi status—semuanya membuang-buang waktu hingga halaman menjadi interaktif.

Bahkan fitur interaktif minimal sering kali memerlukan ukuran bundel yang tidak proporsional besar. Arsitektur yang menganggap JavaScript secara default memerlukan penyesuaian berkelanjutan untuk mempertahankan performa.

Sebaliknya, arsitektur yang memposisikan JavaScript sebagai opt-in eksplisit cenderung menghasilkan hasil yang lebih stabil. Perbedaan filosofi ini tercermin jelas dalam skor Lighthouse.

Pemrosesan Waktu Build Menghilangkan Ketidakpastian

Output yang dirender sebelumnya menghapus beberapa variabel dari persamaan performa:

• Tidak ada biaya server-side rendering saat permintaan
• Tidak ada bootstrap sisi klien untuk menampilkan konten
• Browser menerima HTML yang dapat diprediksi dan lengkap

Hasilnya, metrik seperti TTFB, LCP, dan CLS secara alami membaik. Meskipun bukan jaminan skor sempurna, ini membatasi kemungkinan kegagalan secara signifikan.

Belajar dari Contoh Nyata

Dalam proyek rekonstruksi blog pribadi, beberapa pendekatan dipertimbangkan. Setup berbasis React dengan hidrasi yang diharapkan fleksibel, namun memerlukan perhatian berkelanjutan terhadap performa. Setiap penambahan fitur baru memicu pertanyaan ulang tentang strategi rendering, metode pengambilan data, dan ukuran bundel.

Sebaliknya, mencoba pendekatan dengan HTML statis sebagai titik awal dan JavaScript sebagai pengecualian menghasilkan hasil yang dramatis. Memilih Astro karena desain kendalanya selaras dengan hipotesis yang ingin divalidasi.

Yang mengejutkan bukan skor awal, melainkan stabilitas performa seiring waktu:

• Publikasi konten baru tidak menyebabkan penurunan skor
• Elemen interaktif kecil tidak menghasilkan peringatan berantai
• Baseline tidak mudah terdegradasi

Dalam arsitektur ini, skor Lighthouse bukan tujuan yang harus dikejar, melainkan konsekuensi alami.

Realitas Trade-off

Penting untuk diperhatikan bahwa pendekatan ini bukan solusi universal. Arsitektur berpusat statis tidak cocok untuk aplikasi yang sangat dinamis dan stateful. Dalam skenario di mana data pengguna terautentikasi, pembaruan real-time, dan manajemen status sisi klien yang kompleks sangat penting, kompleksitas implementasi meningkat.

Kerangka kerja yang mengasumsikan rendering sisi klien menawarkan fleksibilitas untuk persyaratan ini. Tradeoff adalah peningkatan kompleksitas runtime.

Yang penting adalah bukan pendekatan mana yang lebih baik, melainkan fakta bahwa pilihan arsitektur secara langsung berhubungan dengan metrik Lighthouse.

Bagaimana Skor Menjadi Stabil, Mengapa Menurun

Lighthouse mengungkapkan bukan hasil upaya optimasi, melainkan kompleksitas sistem.

Sistem yang bergantung pada komputasi runtime mengakumulasi kompleksitas seiring penambahan fitur. Sistem yang memundurkan pekerjaan ke waktu build secara default menekan kompleksitas tersebut.

Perbedaan ini menjelaskan mengapa beberapa situs memerlukan penyesuaian performa berkelanjutan, sementara situs lain tetap stabil dengan intervensi minimal.

Pilihan Esensial

Skor Lighthouse tinggi biasanya bukan hasil penyesuaian dengan alat optimasi agresif. Skor tersebut muncul secara alami dari arsitektur yang meminimalkan beban pemrosesan browser saat pemuatan awal.

Meskipun alat dan tren berubah, prinsip fundamental tidak berubah. Membuat performa sebagai batasan pada tahap desain, bukan tujuan yang dikejar. Dengan berbuat demikian, skor Lighthouse berubah dari tujuan yang harus dikejar menjadi indikator yang sekadar diamati.

Perubahan ini tidak berkaitan dengan pertanyaan “kerangka kerja mana yang dipilih”, melainkan penilaian “di mana kompleksitas diizinkan”.