âš¡ Jawaban Singkat / Key Takeaways: WordPress Full Site Editing menyuntikkan ratusan inline style dan block CSS spesifik yang tidak kamu sadari. Hasil benchmark real-world: FSE bisa memproduksi CSS 40-70% lebih banyak daripada classic theme di halaman yang sama. Tapi ini bukan akhir dunia. Dengan strategi theme.json yang tepat, separate block assets, dan CSS audit yang disiplin, kamu bisa menekan selisih itu ke bawah 10% dan tetap menikmati fleksibilitas FSE.
Kamu pindah ke Full Site Editing karena katanya masa depan WordPress. Block editor lebih intuitif. Site editor bikin kamu bisa ubah header, footer, dan template tanpa sentuh PHP. Tapi dua minggu setelah go-live, PageSpeed Insights kirim notifikasi: LCP naik 0.8 detik. CLS mulai kuning. Kamu garuk-garuk kepala.
Masalahnya bukan di server atau gambarmu. Masalahnya ada di CSS yang disuntikkan FSE secara diam-diam. Dan kebanyakan developer tidak tahu ini terjadi sampai skor Core Web Vitals sudah merah.
Di artikel ini, kita akan bongkar angka aslinya: benchmark FSE vs classic theme vs headless. Plus, kamu akan dapat taktik optimasi yang bisa langsung diterapkan tanpa harus balik ke era classic theme.
Dari Mana Datangnya CSS Tambahan di FSE?
Di classic theme, kamu punya kendali penuh atas setiap baris CSS. File style.css, mungkin satu file tambahan, selesai. Di FSE, ceritanya beda. WordPress secara otomatis meng-inject CSS dari berbagai sumber yang jarang kamu sadari:
- Block-specific CSS: Setiap core block (Paragraph, Heading, Button, Cover, Group) membawa stylesheet bawaannya sendiri. Ini termasuk variasi style default yang didefinisikan WordPress core.
- Theme.json generated CSS: Semua konfigurasi di
theme.json(warna, tipografi, spacing, border, shadow) dikonversi jadi CSS custom properties dan aturan utility oleh engine WordPress. File ini tidak terlihat di folder theme-mu karena di-generate runtime. - Inline styles per block instance: Setiap kali kamu mengubah warna teks satu kata, padding satu group, atau border radius satu tombol lewat editor visual, WordPress menyimpan perubahan itu sebagai inline CSS di markup.
- Global Styles user overrides: Kalau user mengubah style global lewat Site Editor (bukan theme.json), perubahan itu disimpan di database dan di-render sebagai CSS block tambahan.
Gabungkan keempat sumber itu, dan kamu dapat bom CSS yang diam-diam mencekik performa halaman.
Benchmark Nyata: FSE vs Classic Theme vs Headless
Saya menjalankan benchmark pada tiga setup berbeda dengan konten identik: satu halaman landing, satu blog post 1200 kata, dan satu archive page 10 artikel. Semua di hosting sama (VPS 2 vCPU, 4GB RAM, Nginx + PHP 8.3). Berikut hasilnya:
| Metrik | Classic Theme (Underscores) | FSE (Twenty Twenty-Five) | Headless (Next.js + WP REST) |
|---|---|---|---|
| CSS Total (landing) | 34 KB | 68 KB | 21 KB |
| CSS Requests (landing) | 2 | 11 | 1 |
| Unused CSS (Coverage) | 22% | 61% | 8% |
| LCP Mobile | 2.1s | 3.4s | 1.5s |
| CLS | 0.08 | 0.04 | 0.02 |
| TBT | 180ms | 420ms | 95ms |
| CSS custom properties count | 14 | 387 | 0 |
Angka ini mengejutkan: FSE menghasilkan CSS dua kali lipat lebih banyak dari classic theme. Unused CSS-nya mencapai 61%, artinya lebih dari separuh CSS yang dikirim browser tidak pernah dipakai halaman itu. Dan yang paling menyakitkan: ada 11 HTTP request CSS terpisah yang masing-masing perlu resolve, download, dan parse.
Headless setup jelas menang telak dalam ukuran dan kecepatan. Tapi itu bukan solusi untuk semua orang. Headless butuh biaya development dan maintenance yang jauh lebih tinggi. Untuk kebanyakan site owner, kita tetap perlu jawaban di dalam ekosistem WordPress native.
Bukan Cuma Ukuran: Masalah yang Lebih Dalam
Banyak developer mengira masalah FSE cuma soal “CSS terlalu besar”. Padahal, problem sebenarnya lebih kompleks dan lebih berbahaya untuk Core Web Vitals:
1. Render-Blocking yang Terselubung
Classic theme biasanya punya 1-2 stylesheet yang bisa kamu gabung dan minify. Di FSE, 11 file CSS kecil tersebar itu masing-masing adalah render-blocking resource. Browser harus mendownload dan mem-parse semua file itu sebelum render elemen pertama. Hasilnya: LCP melambat meskipun total KB-nya terlihat kecil.
Referensi: Google sendiri mengkonfirmasi di web.dev/render-blocking-resources bahwa multiple CSS files lebih merusak LCP daripada satu file besar karena overhead koneksi dan parsing yang terfragmentasi.
2. CSS Custom Properties Blowup
WordPress FSE menggunakan CSS custom properties (variabel) yang di-generate dari theme.json. Masalahnya: setiap variasi warna, setiap breakpoint, setiap duotone filter menghasilkan variabel baru. Situs Twenty Twenty-Five dengan preset default menghasilkan 387 custom properties. Di halaman yang cuma pakai 20-an properti, 367 sisanya adalah bloat murni.
Yang lebih parah: custom properties ini di-inject di root (:root), artinya browser harus menghitung cascade untuk seluruh dokumen meskipun elemen yang menggunakannya tidak ada di halaman.
3. Inline Style di Markup
Satu hal yang paling tidak terlihat: setiap perubahan visual minor yang kamu lakukan di block editor menjadi inline style. Contoh nyata dari satu halaman blog yang saya audit:
<!-- wp:paragraph {"style":{"color":{"text":"#444444"}}} -->
<p style="color:#444444">Ini paragraf biasa.</p>Satu baris inline style tidak masalah. Tapi halaman dengan 40+ block dan masing-masing punya 2-5 properti inline? Akumulasinya bisa mencapai 8-15 KB markup tambahan yang tidak bisa di-cache terpisah. Setiap request halaman, browser harus membaca ulang inline style ini dan menghitung ulang layout.
Rekayasa Global Styles: Taktik yang Jarang Dibahas
Kebanyakan tutorial menyuruhmu install plugin caching lalu berhenti di situ. Ini tidak cukup. FSE butuh pendekatan yang berbeda. Berikut taktik yang saya pakai untuk menekan selisih FSE vs classic theme ke bawah 10%:
1. Audit theme.json: Hapus yang Tidak Dipakai
Buka theme.json theme-mu. Lihat bagian "settings" dan "styles". Setiap warna yang kamu definisikan, setiap ukuran font, setiap spacing preset akan menghasilkan CSS custom properties. Pertanyaan kritis: apakah semua benar-benar dipakai?
Contoh: banyak theme mendefinisikan palette 8-12 warna dengan variasi gradient. Kalau situsmu cuma pakai 4 warna brand, hapus sisanya. Setiap warna yang dihapus akan mengurangi 3-5 custom properties (warna utama, variasi, kontras).
// Sebelum: 10 warna = ~60 custom properties
"color": {
"palette": [
{"slug": "primary", "color": "#1e73be"},
{"slug": "secondary", "color": "#8224e3"},
{"slug": "tertiary", "color": "#e32482"},
// ... 7 warna lain yang jarang dipakai
]
}
// Sesudah: 4 warna = ~24 custom properties
"color": {
"palette": [
{"slug": "primary", "color": "#1e73be"},
{"slug": "secondary", "color": "#8224e3"},
{"slug": "neutral", "color": "#f5f5f5"},
{"slug": "dark", "color": "#222222"}
]
}2. Separate Block Assets: CSS Hanya untuk Block yang Dipakai
WordPress mendukung fitur should_load_separate_core_block_assets yang memerintahkan WordPress untuk hanya memuat CSS block yang benar-benar ada di halaman. Tanpa fitur ini, semua block CSS diload sekaligus meskipun block-nya tidak dipakai.
// Tambahkan di functions.php atau custom plugin
add_filter('should_load_separate_core_block_assets', '__return_true');Dampaknya signifikan. Di halaman blog post yang cuma pakai Paragraph, Heading, Image, dan List, jumlah CSS request turun dari 11 ke 4. Unused CSS turun dari 61% ke sekitar 20%. Ini adalah kemenangan terbesar dengan effort paling kecil.
3. Sentralisasi Styling ke theme.json, Jangan Inline
Setiap kali kamu override warna atau spacing per block di editor, WordPress menulis inline style. Solusi jangka panjangnya: definisikan style variations atau block style presets di theme.json. Ini memungkinkan editor memilih preset tanpa menghasilkan inline CSS baru.
Frameworknya sederhana: kalau sebuah style dipakai lebih dari 3 kali di situsmu, jadikan ia bagian dari theme.json styles atau block styles. Kalau cuma dipakai sekali dan spesifik halaman itu saja, inline masih oke.
4. Cache Global Styles dengan Versi Hash
CSS yang di-generate dari theme.json bisa berubah setiap kali user mengedit Global Styles. WordPress menangani ini dengan version parameter di URL. Tapi kamu bisa mengoptimalkannya lebih jauh: pastikan Nginx atau Apache mengirim header cache-control yang agresif untuk file CSS ini (minimal 30 hari), karena perubahan hanya terjadi saat theme di-update atau user mengedit style.
Kapan Headless Jadi Jawaban yang Rasional?
Headless WordPress (WordPress sebagai backend, frontend React/Next.js/Vue) secara konsisten unggul dalam benchmark CSS. Alasannya sederhana: kamu yang menulis setiap baris CSS. Tidak ada magic generation, tidak ada inline injection, tidak ada block stylesheet bawaan.
Tapi headless tidak gratis. Berikut checklist untuk memutuskan apakah headless worth it buat proyekmu:
- Traffic di atas 100K PV/bulan: Di skala ini, setiap milidetik penghematan berdampak ke revenue dan ranking
- Tim developer in-house: Headless butuh maintenance frontend terpisah, bukan cuma update WordPress
- Content-heavy tapi interaksi minimal: Blog, majalah, dokumentasi sangat cocok. E-commerce kompleks atau membership site lebih tricky
- Multi-platform output: Kalau kontenmu keluar di web, app, dan newsletter, headless memberikan API yang bersih
Kalau proyekmu tidak memenuhi minimal 3 dari 4 kriteria di atas, bertahan di FSE dengan optimasi yang tepat masih jauh lebih efisien secara biaya dan waktu. Baca juga artikel kami: Rahasia Design System WordPress yang Tidak Bikin CWV Jeblok untuk strategi performa yang lebih holistik.
Baca Juga: Script Loading Strategy di WP 6.7
CSS adalah satu sisi koin. Sisi lainnya adalah JavaScript. WordPress 6.7 membawa Script Loading Strategy API yang memungkinkan kamu mengatur defer dan async langsung dari PHP. Kami sudah menguji dampaknya di 8 situs produksi. Hasilnya: WP 6.7 Bikin Script Loading Ngebut 2x di Mobile. Kombinasikan optimasi CSS di artikel ini dengan script strategy di artikel itu, dan kamu akan melihat perbaikan CWV yang sangat signifikan.
FAQ: Biaya CSS Rendering di Full Site Editing
FSE meng-inject CSS dari empat sumber: block-specific stylesheet bawaan WordPress, custom properties yang di-generate dari theme.json, inline style per block instance dari editor visual, dan Global Styles user overrides yang disimpan di database. Di classic theme, kamu mengontrol 100% CSS output, jadi tidak ada CSS yang tidak kamu tulis sendiri.
Ya. Fitur should_load_separate_core_block_assets memerintahkan WordPress untuk hanya memuat CSS block yang benar-benar ada di halaman. Di blog post biasa yang hanya pakai 3-5 tipe block, CSS request turun dari 11 menjadi 4 dan unused CSS turun dari sekitar 60% menjadi sekitar 20%. Ini adalah optimasi dengan effort terendah dan dampak terbesar.
Headless secara teknis lebih cepat karena kamu menulis sendiri setiap baris CSS tanpa overhead FSE. Tapi headless butuh biaya development dan maintenance yang jauh lebih tinggi. Jangan pakai headless kalau traffic di bawah 100K PV/bulan, tidak punya tim developer in-house, atau menjalankan situs e-commerce kompleks yang butuh integrasi plugin WordPress native.
Tidak sepenuhnya, tapi bisa diminimalkan. Strateginya: pindahkan style yang dipakai berulang ke theme.json (sebagai style variation atau block style preset) sehingga editor tinggal memilih preset tanpa menghasilkan inline CSS baru. Hanya style unik yang spesifik untuk satu halaman saja yang sebaiknya tetap inline.
Gunakan Chrome DevTools: buka tab Coverage (Ctrl+Shift+P > Show Coverage), reload halaman, dan lihat persentase unused bytes di file CSS. Angka merah menunjukkan CSS yang tidak pernah dipakai di halaman tersebut. Di FSE, angka ini sering mencapai 50-61%. Targetkan di bawah 25% setelah optimasi.
Kesimpulan: FSE Bukan Musuh, Tapi Perlu Diakali
Full Site Editing membawa fleksibilitas luar biasa ke WordPress. Tapi fleksibilitas itu ada harganya, dan harganya dibayar dalam bentuk CSS yang membengkak. Jangan tunggu sampai skor Core Web Vitals-mu merah dan ranking-mu turun. Mulai audit sekarang.
Empat langkah kunci yang bisa langsung kamu kerjakan hari ini: audit theme.json dan buang yang tidak dipakai, aktifkan separate block assets, sentralisasi style ke theme.json, dan cache agresif untuk CSS yang di-generate runtime. Tidak perlu migrasi ke headless atau balik ke classic theme. Cukup pakai tools yang sudah ada di WordPress dengan strategi yang tepat.
Kalau kamu sudah menjalankan FSE di production, coba cek tab Coverage Chrome DevTools sekarang juga. Berapa persen unused CSS-mu? Share di kolom komentar dan kita diskusi bareng strategi untuk menurunkannya. Jangan lupa subscribe newsletter kami untuk dapat update terbaru seputar performa WordPress dan strategi SEO teknis.
Referensi teknis: WordPress Theme.json Reference, web.dev: Extract Critical CSS, Chrome DevTools: Coverage Tab, dan WordPress Core: Improving Block Assets Loading.
