Menurunkan LCP Situs Kontraktor dari 4,2 ke 1,8 Detik Tanpa Ganti Framework

Situs lama kami terlihat baik-baik saja di laptop kantor. Lighthouse hijau, desain rapi, konten lengkap.

Lalu kami membuka Google Search Console.

Datanya berbeda. Di perangkat mobile, sebagian besar pengunjung menunggu lebih dari empat detik sebelum konten utama muncul. Empat detik. Padahal mereka calon klien proyek konstruksi yang sedang membandingkan vendor di tab sebelah. Mengacu pada dokumentasi resmi LCP di web.dev, ambang "baik" adalah 2,5 detik atau kurang — dan kami jauh dari itu. Dari sinilah perjalanan menurunkan LCP situs kontraktor kami dimulai, bukan sebagai proyek teknis abstrak, tetapi sebagai upaya menyelamatkan calon konversi yang diam-diam pergi.

Kenapa angka ini penting? Karena kecepatan bukan soal kenyamanan estetis, melainkan soal uang dan kepercayaan. Sebuah penelitian tentang dampak waktu muat halaman terhadap conversion rate e-commerce menunjukkan korelasi nyata antara load time yang lebih lambat dan peningkatan bounce rate serta penurunan konversi — dan bagian diskusinya bahkan menyinggung konteks pengguna Indonesia. Kami mengangkat tema ini karena terlalu banyak panduan performa di luar sana yang berhenti di teori "kompres gambar, pakai CDN" tanpa menunjukkan keputusan nyata di lapangan. Artikel ini berbagi proses, trade-off, dan angka asli dari situs produksi kami, lengkap dengan apa yang gagal sebelum akhirnya berhasil.

TL;DR: LCP turun dari 4,2s ke 1,8s tanpa mengganti tech stack. Pemenang terbesar bukan satu trik ajaib, melainkan urutan perbaikan yang benar — TTFB dulu, baru hero image, baru render-blocking resources.

1. Diagnosis: Mengukur di Lapangan, Bukan di Laptop

Sebelum menyentuh satu baris kode pun, kami berhenti dan bertanya: data mana yang sebenarnya kami percaya?

Kesalahan pertama yang hampir kami lakukan adalah mengandalkan skor Lighthouse di mesin development. Itu lab data — satu kali muat di jaringan cepat dengan cache bersih. Yang menentukan ranking adalah field data: pengalaman pengguna asli di perangkat dan jaringan mereka yang sebenarnya, dikumpulkan lewat Chrome UX Report (CrUX) selama jendela 28 hari.

Jadi kami mulai dari dua sumber:

• Google Search Console → laporan Core Web Vitals untuk melihat halaman berstatus "Poor".
• PageSpeed Insights → membandingkan lab data dan field data per halaman penting.

Temuannya menohok.

Halaman beranda kami hijau di lab, merah di field.

Dan penyebabnya bukan gambar. Bukan font. Bukan animasi. Melainkan waktu respons server yang lambat — hal yang selama ini tidak pernah kami curigai.

Memahami Empat Fase LCP

LCP bukan satu angka tunggal; ia adalah hasil dari rantai peristiwa. Memahami ini mengubah cara kami memprioritaskan perbaikan.

Fase	Apa yang terjadi	Kontribusi ke LCP kami (sebelum)
Time to First Byte (TTFB)	Server merespons permintaan awal	~1,4 detik
Resource load delay	Jeda sebelum browser mulai memuat elemen LCP	~0,9 detik
Resource load time	Elemen LCP (hero image) selesai diunduh	~1,3 detik
Element render delay	Browser menampilkan elemen ke layar	~0,6 detik

Begitu rantai ini terlihat jelas, prioritas jadi obvious: TTFB adalah fondasi. Percuma mengoptimalkan gambar kalau cat-nya sendiri mulai terlambat.

2. Perbaikan: Urutan yang Benar Mengalahkan Trik Pintar

Bab ini adalah inti dari menurunkan LCP situs kontraktor kami. Bukan daftar tips acak, tetapi urutan keputusan yang sengaja kami susun dari leverage terbesar ke terkecil.

Kami sempat tergoda mengikuti saran umum di internet.

"Kompres hero image dulu, itu paling cepat."

Kami coba. LCP hanya turun sekitar 30%. Mengecewakan.

Lalu kami balik urutannya: perbaiki TTFB lebih dulu, baru sentuh gambar. Gain-nya langsung jauh lebih besar. Urutan benar-benar penting, dan ini pelajaran yang tidak kami temukan di kebanyakan tutorial.

Langkah demi Langkah (HowTo)

1. Perbaiki TTFB ke bawah 200ms. Kami pindah ke hosting dengan respons lebih cepat, mengaktifkan caching server-side, dan meletakkan CDN di depan HTML. Fondasi dulu.
2. Pasang fetchpriority="high" pada hero image. Memberi sinyal ke browser bahwa elemen ini prioritas. Tim Google Flights melaporkan perbaikan ratusan milidetik hanya dari atribut HTML ini.
3. Hentikan lazy-loading pada elemen LCP. Ini kesalahan paling umum: menunda permintaan justru pada gambar yang waktunya sedang kita ukur. Pastikan elemen LCP tidak punya loading="lazy".
4. Konversi gambar ke format modern. Hero image kami diubah ke WebP/AVIF, target di bawah 100KB. Format modern memangkas ukuran 30–40%.
5. Inline critical CSS, defer sisanya. Mengeluarkan CSS yang menghambat render dari jalur kritis sehingga konten utama tampil lebih dulu.
6. Audit script pihak ketiga. Setiap tag analitik, widget chat, dan pixel iklan menambah latensi. Kami buang yang tidak esensial.

Setelah keenam langkah, LCP field data kami stabil di 1,8 detik pada persentil ke-75 mobile.

Apa yang Tidak Berhasil

Demi kejujuran teknis: preload terlalu banyak resource sekaligus malah memperlambat, karena semuanya berebut bandwidth. Kami juga sempat mengejar skor Lighthouse 100 yang ternyata tidak berkorelasi dengan perbaikan field data. Pelajarannya — validasi selalu ke data lapangan sebelum menyatakan sebuah optimasi berhasil.

Untuk perspektif praktis lain dengan contoh before/after dari proyek produksi, panduan komunitas seperti Core Web Vitals Optimization: A Practical Guide oleh Umesh Malik di Dev.to cukup melengkapi pendekatan kami, terutama soal mengukur lewat library web-vitals ketimbang hanya Lighthouse.

3. Hasil dan Dampak Bisnis

Bab ini menjawab pertanyaan yang sebenarnya penting bagi pemilik bisnis: angka teknis tadi berubah jadi apa?

Karena CrUX memakai jendela bergulir 28 hari, perubahan baru terlihat penuh di Search Console sekitar empat hingga enam minggu setelah deploy. Kami menahan diri untuk tidak menarik kesimpulan terlalu cepat.

Metrik	Sebelum	Sesudah
LCP (field, p75 mobile)	4,2 detik	1,8 detik
Status Core Web Vitals	Poor	Good
Halaman "Poor" di GSC	Mayoritas	Nol

Yang berubah bukan sekadar warna hijau di dashboard. Halaman layanan kami mulai lebih sering muncul untuk pencarian lokal, dan durasi sesi pengunjung meningkat. Bagi perusahaan kontraktor yang mengandalkan calon klien menemukan portofolio proyek secara organik, ini selisih antara ditemukan atau terlewat. Anda bisa melihat sendiri bagaimana halaman layanan kami sekarang dimuat di Nikifour sebagai contoh penerapan langsung.

Pertanyaan yang Sering Diajukan

Berapa skor LCP yang dianggap baik di 2026?
Di bawah atau sama dengan 2,5 detik pada persentil ke-75 untuk halaman terpenting Anda, diukur dari field data.

Apakah PageSpeed Insights saja cukup?
Tidak. Gunakan untuk audit cepat, tetapi kombinasikan dengan data CrUX atau Real User Monitoring untuk gambaran pengguna nyata.

Apa perbaikan yang memberi gain tercepat?
Berurutan: kompres hero image → buang script pihak ketiga berat → pasang CDN dan caching → kecilkan ukuran bundle JS. Tapi jika TTFB Anda lambat, perbaiki itu lebih dulu.

Apakah harus ganti framework untuk memperbaiki LCP?
Tidak. Seluruh perbaikan di studi kasus ini dilakukan tanpa mengganti tech stack. Sebagian besar masalah LCP bersifat arsitektur pemuatan, bukan pilihan framework.

Berapa lama hasilnya terlihat?
Sekitar empat sampai enam minggu, mengikuti jendela bergulir 28 hari CrUX.

Performa adalah Janji, Bukan Sekadar Angka

Pada akhirnya, seluruh upaya ini bermuara pada satu hal yang sering kami lupakan saat sibuk mengejar skor.

Bukan algoritma yang menunggu di ujung sana.

Tapi orang.

"Users don't care how hard it is to build. They care whether it works for them."

Kalimat itu sejalan dengan pendekatan desain berpusat pengguna yang dipopulerkan oleh Don Norman, ilmuwan kognitif yang menciptakan istilah "user experience" dan menulis The Design of Everyday Things. Relevansinya dengan tema kita langsung: LCP bukan metrik untuk memuaskan algoritma, melainkan ukuran apakah pengalaman yang kita bangun benar-benar bekerja untuk orang yang menunggu di ujung koneksi mereka. Norman mengingatkan bahwa desain yang baik adalah desain yang tak terlihat — pengguna tidak memikirkan kecepatan, mereka hanya merasa situsnya "enak".

Itulah esensi menurunkan LCP situs kontraktor: bukan mengejar nilai sempurna di lab, tetapi menghormati waktu dan kesabaran calon klien yang sedang memutuskan apakah akan mempercayakan proyek mereka kepada kita.

Angka 1,8 detik hanyalah cara kami mengukur janji itu.