Portal properti itu unik: foto besar, peta interaktif, filter dinamis, dan listing yang jumlahnya bisa ribuan. Saat membahas Core Web Vitals, saya suka menyamakan halaman listing seperti etalase—kalau pintunya berat dibuka, orang pergi sebelum sempat melihat isinya. Rujukan praktis tentang metrik dan cara berpikirnya bisa kamu baca di artikel DEV ini: panduan Core Web Vitals yang praktis. Di tulisan ini, kita akan membedah taktik yang benar-benar kepakai di portal properti (gambar, rendering, caching, UX mobile) untuk membantu optimasi core web vitals tanpa mengorbankan bisnis.
Secara akademik, relevansi web vitals makin kuat karena tooling dan metrik performa kini dipakai sebagai “bahasa bersama” antara engineering, produk, dan growth. Ada pembahasan menarik soal ekosistem web performance tooling dan pentingnya web vitals yang bisa kamu jadikan landasan konseptual di studi tentang web performance tooling dan web vitals. Kami mengangkat tema ini karena di proptech—terutama situs yang menghubungkan pembeli, penjual, dan agen—setiap detik keterlambatan berarti niat pengguna memudar, dan itu bisa dihindari dengan disiplin engineering.
Kesimpulan cepat (kalau kamu cuma punya 60 detik):
Portal properti yang “terasa cepat” biasanya menang di empat hal: gambar yang smart, rendering yang tepat (SSR/ISR/CSR sesuai konteks), caching berlapis, dan UX mobile yang tidak bikin layout shift. Mulai dari mengukur, lalu perbaiki “bottleneck” paling mahal—biasanya LCP dari hero image dan INP dari filter. Sisanya tinggal konsistensi.
1. Kenali Medan Tempur: CWV untuk Portal Properti
Sebelum optimasi, pahami dulu pola beban portal properti: LCP sering tersandung gambar hero atau grid listing, CLS muncul saat badge “Promo/Hot” datang belakangan, dan INP hancur karena filter/checkbox yang men-trigger render berat. Ini bukan soal “mengejar skor” semata; ini soal perceived performance yang berpengaruh ke trust.
Tiga metrik yang paling sering jadi biang kerok
- LCP (Largest Contentful Paint): biasanya hero image, kartu listing terbesar, atau peta.
- CLS (Cumulative Layout Shift): elemen yang “lompat” saat font, gambar, atau komponen iklan/CTA telat muncul.
- INP (Interaction to Next Paint): interaksi filter, sort, pencarian lokasi, dan klik kartu listing.
Target realistis (bukan idealis)
| Metrik | Target “sehat” (rule-of-thumb) | Titik rawan di portal properti | Taktik cepat |
|---|---|---|---|
| LCP | ≤ 2.5s | hero/grid listing/peta | optimasi gambar, preloading, SSR/ISR |
| CLS | ≤ 0.1 | badge, font, skeleton tidak stabil | ukuran tetap, font strategy, placeholder |
| INP | ≤ 200ms | filter, autocomplete, map drag | debouncing, memecah task, caching data |
Catatan: detail taktik umum CWV juga banyak dibahas di web.dev, misalnya ringkasan cara paling efektif memperbaiki CWV di Top ways to improve Core Web Vitals.
2. Strategi Gambar: LCP Hampir Selalu Dimulai dari Foto
Kalau portal kamu penuh foto rumah/apartemen, maka 80% kerja optimasi core web vitals biasanya dimulai dari pipeline gambar. Gambar besar = bagus untuk jualan, tapi juga bisa jadi “jangkar” yang menenggelamkan LCP.
Format, ukuran, dan responsive images
Prinsipnya: kirim file sekecil mungkin yang tetap terlihat bagus untuk viewport pengguna.
- Gunakan AVIF/WebP (fallback ke JPEG) dan quality adaptif.
- Pastikan
srcset/sizesbenar untuk grid listing. - Terapkan device-aware strategy untuk mobile vs desktop.
Jika stack kamu Next.js, internal referensi DEV yang relevan untuk strategi gambar adalah: Optimizing images with next/image dan versi yang lebih advanced: Advanced image optimization in React/Next.js.
Preload yang tepat (dan jangan “kebablasan”)
- Preload hanya elemen LCP (biasanya 1 gambar hero atau 1 gambar listing teratas).
- Untuk halaman listing, prioritaskan 1–2 kartu teratas; sisanya lazy-load.
Checklist gambar untuk portal properti
- [ ] Gambar hero punya dimensi fix dan placeholder (blur/solid) agar CLS aman.
- [ ] CDN image dengan auto format + auto compress.
- [ ] Thumbnail listing disajikan dalam ukuran sesuai grid (hindari 2000px untuk kartu 320px).
- [ ] Peta/Street View tidak ikut “mencuri” bandwidth di first render.
3. SSR vs ISR vs CSR: Pilih Rendering Berdasarkan Niat Pengguna
Tidak semua halaman portal properti harus diperlakukan sama. Optimasi core web vitals yang efektif justru dimulai dari keputusan rendering yang “tepat guna”. Kuncinya: bedakan halaman yang butuh cepat tampil vs halaman yang butuh data super dinamis.
Peta keputusan rendering (praktis)
| Jenis halaman | Rendering yang sering paling masuk akal | Alasan |
|---|---|---|
| Homepage / landing kota | ISR | konten semi-statis, bisa revalidate |
| Listing hasil pencarian | SSR + caching | bergantung query, butuh cepat dan relevan |
| Detail properti | ISR/SSR hybrid | detail bisa di-cache, tapi harga/status bisa berubah |
| Dashboard agen | CSR | autentikasi, data real-time |
Taktik SSR/ISR yang sering “langsung ngaruh”
- Turunkan TTFB dengan caching di edge (CDN/Reverse proxy) + kompresi.
- Render above-the-fold dulu (grid awal, CTA, ringkasan).
- Komponen berat (peta, galeri full, rekomendasi) di-defer.
Kalau kamu butuh contoh implementasi dan pola pikir untuk Next.js, internal link DEV yang relevan: Optimizing Next.js Websites for Core Web Vitals.
4. Caching Berlapis: Browser → Edge → Aplikasi → Database
Caching itu bukan “aktifkan lalu selesai”. Caching yang bagus punya strategi invalidasi, TTL yang realistis, dan paham pola akses pengguna (banyak browse, sedikit aksi). Untuk portal properti, caching yang tepat bisa jadi perbedaan antara filter terasa instan vs terasa “berat”. Ini adalah salah satu pilar optimasi core web vitals.
Lapisan caching yang sebaiknya kamu audit
-
Browser cache:
Cache-Control,ETag,stale-while-revalidate. - CDN/Edge cache: cache HTML untuk ISR/SSR tertentu, cache API GET.
- App cache: in-memory/Redis untuk query populer (mis. area + harga).
- DB cache/index: indeks yang sesuai, query plan stabil.
Untuk bacaan caching yang mudah diikuti di DEV, lihat: Unlocking the power of caching atau pembahasan lintas layer: Caching strategies across application layers.
Pola caching yang cocok untuk listing properti
- Cache hasil agregasi (mis. jumlah listing per kecamatan + rentang harga).
- Cache “hot queries” (lokasi populer) dengan TTL pendek.
- Gunakan stale-while-revalidate agar UI cepat sambil data diperbarui.
Hindari jebakan klasik
- TTL terlalu lama untuk data sensitif (status “sold/rented”).
- Invalidation tanpa strategi (cache busting membabi-buta).
- Cache key yang tidak memasukkan parameter filter lengkap.
5. UX Mobile: Menang di Interaksi, Bukan Sekadar Loading
Mobile adalah arena utama portal properti. Pengguna scroll, zoom, buka galeri, balik ke listing, lalu coba filter lagi. Kalau interaksi terasa lambat, skor bisa bagus tapi pengalaman tetap buruk. Jadi optimasi core web vitals harus menyentuh UX, bukan hanya pipeline asset.
INP: cara membuat filter terasa “ringan”
- Debounce input (mis. 150–300ms) untuk pencarian lokasi.
- Optimistic UI: tampilkan perubahan state cepat, sinkronkan data belakangan.
- Pecah pekerjaan berat menjadi beberapa microtasks (hindari long task).
- Virtualisasi list (mis. hanya render kartu yang terlihat) untuk grid panjang.
CLS: stabilkan layout dari awal
- Selalu set
width/height(atau aspect-ratio) untuk gambar. - Gunakan font loading strategy yang aman (hindari “lompat”).
- Skeleton harus punya ukuran yang sama dengan konten final.
Dua “trik” yang underrated untuk portal properti
- Back/forward cache (bfcache) friendly: jangan memblokir navigasi balik dengan script berat.
- Prefetch cerdas: prefetch detail properti saat kartu masuk viewport (secukupnya).
6. Praktik Implementasi: Playbook 7 Hari untuk Performa yang Terukur
Bagian ini sengaja dibuat operasional—bukan teori. Kamu bisa jalankan ini untuk situs proptech apa pun, termasuk situs layanan pemasaran jual-beli properti seperti Era Integrity Indonesia yang mengandalkan foto, listing, dan funnel konsultasi.
Hari 1–2: Ukur dulu, lalu pilih 1 target utama
- Audit dengan Lighthouse + CrUX/field data.
- Tentukan 1 halaman paling bernilai: homepage, listing, atau detail.
- Catat baseline LCP/CLS/INP + waterfall.
Hari 3–4: Bereskan gambar dan resource kritikal
- Konversi format (AVIF/WebP), atur sizing, lazy-load.
- Preload 1 resource LCP.
- Hilangkan resource yang menghambat render (CSS/JS tidak perlu).
Hari 5: Rancang ulang rendering & caching
- Pindahkan halaman semi-statis ke ISR.
- Tambahkan caching untuk API GET + edge caching.
- Pastikan cache key lengkap.
Hari 6–7: Tuntaskan INP & stabilitas layout
- Debounce, virtualize, pecah long task.
- Stabilkan layout (aspect-ratio, skeleton stabil, font strategy).
- Lakukan regression test di perangkat low-end.
7. FAQ (yang biasanya ditanyakan tim produk & engineering)
Apakah Core Web Vitals sama dengan “website cepat”?
Tidak selalu. CWV mengukur aspek pengalaman tertentu. Website bisa “cepat” di lab tapi buruk di field kalau jaringan dan device pengguna bervariasi.
Lebih baik fokus LCP dulu atau INP dulu?
Untuk portal properti, umumnya LCP dulu (karena gambar). Setelah itu, INP untuk membuat filter/scroll terasa responsif.
Apakah SSR selalu lebih cepat?
Tidak. SSR bisa meningkatkan TTFB kalau backend lambat. SSR plus caching sering jadi kombinasi yang paling aman.
Berapa kali harus audit performa?
Minimal setiap release besar. Idealnya otomatis: CI performance budget + monitoring field.
Apakah optimasi ini relevan untuk SEO?
Relevan. CWV adalah sinyal pengalaman pengguna, dan perbaikan performa biasanya menurunkan bounce dan meningkatkan engagement.
Checklist Ringkas (copy-paste ke tiket sprint)
- LCP: optimasi gambar hero, preload 1 resource kritikal, kurangi render-blocking.
- CLS: dimensi media fix, skeleton stabil, font strategy aman.
- INP: debounce input, virtualisasi list, pecah long task, optimasi event handler.
- Caching: browser + edge + app, TTL & invalidation jelas.
- Rendering: SSR/ISR/CSR sesuai tipe halaman.
Momentum: Performa yang Menang di Kepercayaan
Sebagai penutup, mengakhiri artikel ini dengan satu prinsip yang sering dilupakan: performa bukan proyek sekali jadi—ini kebiasaan. Tom DeMarco (tokoh berpengaruh di rekayasa perangkat lunak dan manajemen proyek) pernah dikenal dengan prinsip tentang pentingnya pengukuran untuk pengendalian proses: kutipan Tom DeMarco di Wikiquote. Artinya sederhana: tanpa metrik, kita hanya menebak-nebak. Dalam konteks portal properti, metrik CWV membuat diskusi lintas tim (engineering–produk–bisnis) jadi objektif.
Kalau kamu menerapkan langkah-langkah di atas secara iteratif—mulai dari gambar, rendering, caching, hingga UX mobile—kamu akan merasakan perubahan yang nyata: halaman lebih cepat, interaksi lebih mulus, dan funnel lebih “bersih”. Dan ya, pada akhirnya ini adalah praktik optimasi core web vitals yang membantu pengalaman pengguna dan hasil bisnis berjalan searah.
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "Optimasi Core Web Vitals untuk Portal Properti",
"description": "Panduan langkah demi langkah untuk meningkatkan LCP, CLS, dan INP di portal properti melalui optimasi gambar, SSR/ISR, caching, dan UX mobile.",
"totalTime": "P7D",
"supply": [
{ "@type": "HowToSupply", "name": "Akses Lighthouse / PageSpeed Insights" },
{ "@type": "HowToSupply", "name": "Akses data field (CrUX/monitoring RUM)" }
],
"tool": [
{ "@type": "HowToTool", "name": "Chrome DevTools (Performance & Network)" },
{ "@type": "HowToTool", "name": "CDN/Reverse Proxy untuk caching" }
],
"step": [
{
"@type": "HowToStep",
"name": "Ukur baseline Core Web Vitals",
"text": "Audit 1–3 halaman paling bernilai (homepage, listing, detail). Catat LCP/CLS/INP dari lab dan field data. Tentukan satu target utama untuk sprint.",
"url": "https://www.eraintegrityindonesia.com/"
},
{
"@type": "HowToStep",
"name": "Optimasi gambar untuk menurunkan LCP",
"text": "Gunakan AVIF/WebP, pastikan sizing responsif (srcset/sizes), preload hanya resource LCP, dan lazy-load gambar di bawah fold. Pastikan dimensi gambar stabil untuk mencegah CLS."
},
{
"@type": "HowToStep",
"name": "Tentukan strategi rendering (SSR/ISR/CSR)",
"text": "Pilih ISR untuk halaman semi-statis, SSR + caching untuk hasil pencarian yang bergantung query, dan CSR untuk halaman yang butuh autentikasi/real-time."
},
{
"@type": "HowToStep",
"name": "Terapkan caching berlapis",
"text": "Aktifkan browser cache yang tepat, edge caching untuk HTML/API GET, dan app cache untuk query populer. Pastikan cache key lengkap dan invalidation jelas."
},
{
"@type": "HowToStep",
"name": "Perbaiki interaksi mobile untuk INP",
"text": "Debounce input pencarian, virtualisasi list, pecah long task, dan optimasi event handler. Uji di perangkat low-end dan jaringan lambat untuk memastikan interaksi tetap responsif."
},
{
"@type": "HowToStep",
"name": "Validasi dan cegah regresi",
"text": "Lakukan pengukuran ulang, tetapkan performance budget di CI, dan pantau metrik field. Ulangi siklus optimasi setiap release besar."
}
]
}
Top comments (0)