Studi Kasus Nalesha: Container Query Bikin 1 Product Card Adaptif di 4 Slot Tanpa Duplikasi CSS 2026

TL;DR: Saat redesign Nalesha pada Maret 2026, kami mengganti 4 varian komponen product card dengan 1 komponen yang merespons lebar parent via CSS Container Query. CSS modul berkurang 62%, time-to-build halaman landing baru turun dari 4 jam ke 90 menit, dan tidak ada regresi visual selama 60 hari di produksi.

Sebelum container query, sistem product card di Nalesha punya 4 file: ProductCardHero.tsx, ProductCardGrid.tsx, ProductCardSidebar.tsx, ProductCardRelated.tsx. Masing-masing dengan CSS terpisah dan logika props yang mirip tapi tidak sama. Setiap kali tim marketing minta tambahan badge atau ribbon, ada 4 file yang harus diubah.

Solusinya bukan menambah library, tapi merangkul fitur CSS yang baru dewasa di 2026: Container Query. Artikel ini menjelaskan bagaimana migrasinya dijalankan dan pelajaran apa yang berlaku untuk e-commerce lain di Indonesia.

Masalah Awal: Komponen Sama, Slot Beda

Nalesha jual parfum lokal dengan 6 kategori. Halaman utama menampilkan produk di 4 lokasi dengan lebar yang sangat berbeda:

Media query global tidak bisa membantu di sini. Saat viewport mobile 360 px, sidebar tidak muncul tapi grid card tetap 165 px sementara related tetap 280 px. Tidak ada min-width viewport yang bisa membedakan keduanya.

Implementasi Container Query

Parent setiap slot dideklarasikan sebagai container:

.product-grid-wrapper { container-type: inline-size; container-name: pcard; }
.product-sidebar-wrapper { container-type: inline-size; container-name: pcard; }
.product-hero-wrapper { container-type: inline-size; container-name: pcard; }

Komponen card merespons via responsive design berbasis parent:

.product-card {
  display: flex;
  flex-direction: column;
  padding: 12px;
}

@container pcard (min-width: 280px) {
  .product-card { padding: 16px; }
  .product-card .price { font-size: 1.125rem; }
}

@container pcard (min-width: 600px) {
  .product-card {
    flex-direction: row;
    gap: 24px;
  }
  .product-card img { width: 240px; }
}

Satu komponen, satu file CSS, 3 breakpoint container. Tidak ada prop variant, tidak ada conditional render.

Hasil Setelah 60 Hari Produksi

Per Mei 2026, metrik yang dipantau:

Yang tidak terduga adalah dampak ke kecepatan tim. Designer Nalesha tidak perlu lagi mengirim 4 mockup berbeda untuk satu konsep. Mereka cukup beri 2 ekstrem (sempit dan lebar), developer menentukan breakpoint container di tengah.

Pertanyaan Umum

Apakah Container Query mempengaruhi performa rendering?

Tidak signifikan. Browser mengoptimasi via CSS containment. Per pengukuran kami di Nalesha, total layout time per frame tidak berbeda statistik vs media query biasa.

Bagaimana dengan SSR di Next.js?

Container Query adalah CSS native, jadi tidak ada masalah hydration. SSR dan SSG bekerja normal, browser yang menerapkan style berdasarkan ukuran container saat render.

Bagaimana kalau client browser tidak support?

Per Mei 2026 dukungan global di atas 92% (caniuse.com). Untuk 8% sisanya, gunakan fallback @supports not (container-type: inline-size) dengan layout dasar yang aman.

Cocok untuk dashboard internal?

Sangat cocok. Dashboard biasanya punya widget yang dipakai di kolom 3, kolom 12, dan modal expand. Container Query membuat widget jadi reusable tanpa prop size.

Mulai dari Komponen yang Paling Sering Berubah Layout

Audit dulu komponen mana yang punya 3 atau lebih varian visual. Card, banner, dan widget adalah kandidat terbaik. Komponen layout level halaman (navbar, footer) biasanya cukup dengan media query biasa karena memang merespons viewport.

Referensi: MDN Container Queries dan studi panjang dari web.dev.