Belajar Tailwind CSS - Performance Optimization & Tree-shaking

#Pendahuluan

Tailwind secara default sudah hemat: JIT hanya membangkitkan kelas yang terpakai. Tapi di project besar, kualitas konfigurasi content dan strategi penyajian tetap menentukan. Episode 14 membahas optimasi performa: content yang efisien, critical CSS, split CSS, dan analisis ukuran bundle.

Setiap kilobyte CSS menunda first render. Tujuan kita: memastikan CSS yang dikirim hanya yang dibutuhkan halaman itu, pada waktu yang tepat, dan bisa diukur seiring waktu agar tidak membengkak diam-diam.

#Konfigurasi content yang Efisien

JIT memindai file di content dan membangkitkan setiap kelas yang ditemukan. Content yang terlalu luas — misalnya memasukkan node_modules atau seluruh repo — memperlambat build dan bisa menghasilkan kelas yang tidak diinginkan. Sempitkan selalu:

Content yang tepat sasaran

module.exports = {
  content: [
    "./index.html",
    "./src/**/*.{html,js,ts,jsx,tsx}",
    "./src/**/*.{vue,svelte,astro}",
  ],
};

Satu sumber nama kelas saja sudah cukup. Jangan memasukkan file dist atau node_modules:

Glob yang harus dihindari

node_modules/**           -> jangan
dist/**                   -> jangan
src/**/*.map              -> jangan

Pola glob ./src/**/*.{html,js,ts,jsx,tsx} adalah contoh yang baik: sempit, jelas, dan mencakup semua file yang berisi markup.

#Critical CSS dan Split CSS

#Critical CSS

CSS di atas fold ditampilkan lebih dulu agar first paint cepat. Pendekatan umum: inline critical CSS di <head> dan muat sisanya secara async:

media="print" mencegah browser memblokir render untuk file yang belum dibutuhkan, lalu onload menggantinya menjadi all saat selesai dimuat. Ini mengurangi render-blocking secara drastis.

#Split CSS per Route

Untuk SPA atau multi-page, pisahkan CSS per route/bundle. Utility yang hanya dipakai di halaman admin tidak perlu dikirim ke halaman publik. Di framework seperti Next.js, CSS yang di-import per halaman otomatis dipisahkan; di project tanpa framework, jalankan build terpisah:

Split CSS per area

npx tailwindcss -i src/styles.css -o dist/public.css --content ./public/**/*.html
npx tailwindcss -i src/admin.css -o dist/admin.css --content ./admin/**/*.html

Setiap halaman hanya menerima CSS untuk kelas yang benar-benar digunakannya.

#Menganalisis Ukuran Bundle

Ukuran yang tidak diukur tidak bisa dioptimasi. Alat bantu analisis:

Flag --analyze bawaan Tailwind untuk melihat utilitas apa yang paling banyak berkontribusi.
source-map-explorer untuk memetakan isi bundle hasil bundler.
webpack-bundle-analyzer atau @next/bundle-analyzer untuk framework.

Contoh memakai flag analyze:

Analisis output CSS

npx tailwindcss -i src/styles.css -o dist/output.css --analyze

Output-nya menampilkan utility dengan ukuran terbesar — biasanya karena kombinasi variants seperti hover:, md:, dan dark: yang melipatgandakan deklarasi.

Tip

Waspadai utility yang dihasilkan dalam jumlah besar karena kombinasi variants. Satu text-xs di markup bisa menjadi puluhan baris CSS setelah dikalikan dengan variants dan breakpoint. Batasi variants yang benar-benar dipakai.

#Menjaga Performa Seiring Pertumbuhan

Optimasi bukan acara sekali jalan. Setiap fitur baru berpotensi menambah utility, variants, atau arbitrary values yang tidak pernah dibayangkan saat konfigurasi pertama ditulis. Karena itu, jadikan pengukuran bagian dari workflow, bukan pengecualian yang dilakukan menjelang rilis.

Beberapa kebiasaan yang menjaga CSS tetap ramping di project yang tumbuh:

Jalankan --analyze secara berkala, misalnya setiap rilis, lalu catat ukuran output sebagai baseline yang bisa dibandingkan antar versi.
Tinjau variants yang aktif di config: variants yang tidak dipakai tetap dibangkitkan untuk setiap utility yang terpakai.
Hindari arbitrary values yang berulang: nilai yang dipakai di banyak tempat sebaiknya menjadi token atau utility custom.
Pastikan pipeline CI memakai budget ukuran CSS dari episode 20, sehingga pembengkakan tertangkap otomatis sebelum merge.

Dengan pengukuran yang rutin, pertumbuhan CSS menjadi keputusan sadar, bukan akumulasi tak terlihat. Tim tahu kapan harus merapikan utility lama, kapan utility baru layak ditambahkan, dan kapan split CSS perlu dirombak ulang karena pola pemakaian berubah. Setiap kali tim berhasil memangkas ukuran, catat alasannya agar kebiasaan baik itu bisa ditiru di area lain.

Sebagai pegangan, target yang sehat adalah CSS total tetap di bawah ambang budget dan halaman tidak menunggu stylesheet besar sebelum first render.

Kedua angka itu bisa dipantau otomatis; begitu pemantauan berjalan, optimasi bukan lagi tebakan melainkan keputusan berbasis data.

#Penutup

Episode 14 mempertajam performa: content yang sempit membuat JIT efisien, critical CSS dan split CSS mengurangi render-blocking, dan alat analisis membuat pertumbuhan ukuran tetap terpantau.

Inti yang harus dibawa pulang:

Sempitkan content ke file yang benar-benar memuat nama kelas.
Jangan sertakan node_modules atau direktori build di content.
Inline critical CSS dan muat sisanya secara async.
Split CSS per route atau area agar pengguna tidak menerima kelas yang tak terpakai.
--analyze bawaan menampilkan utility terbesar di output.
Ukur ukuran bundle secara berkala agar tidak membengkak diam-diam.

Di episode 15 selanjutnya kita akan membahas component API patterns — pengenalan class-variance-authority untuk komponen berbasis variants, pola utility wrapper memakai clsx dan tailwind-merge, serta pengujian output class dalam unit test.