- Critical CSS adalah hanya CSS minimum yang diperlukan untuk merender area yang "terlihat pertama kali (above the fold)" pada halaman, dan jika di-inline ke HTML maka Core Web Vitals seperti FCP (First Contentful Paint) dapat ditingkatkan
- Di-inline ke
<head> HTML agar browser bisa merender konten lebih cepat tanpa menunggu seluruh stylesheet selesai dimuat
- Memiliki manfaat seperti peningkatan kecepatan muat yang dirasakan, kenaikan skor Lighthouse, serta peningkatan SEO dan UX
- CSS yang tidak esensial dapat dimuat dengan
<link> di akhir <body>, atau lazy loading dengan JavaScript untuk optimasi performa lebih lanjut
- Perlu diperhatikan bahwa pengguna harus menyesuaikan sendiri jalur link CSS dan referensi aset
Critical CSS Generator
- Critical CSS Generator adalah alat yang mengekstrak hanya kode CSS minimum yang benar-benar dibutuhkan dari sebuah halaman web, sehingga memungkinkan ekstraksi CSS yang dioptimalkan untuk tujuan penggunaan
- Critical CSS adalah aturan CSS minimum yang diperlukan untuk memberi style pada area yang pertama kali terlihat di halaman
- Pendekatan ini membantu meningkatkan performa dan Core Web Vitals (seperti FCP) karena browser dapat langsung menampilkan konten utama tanpa menunggu semua stylesheet selesai dimuat
Mengapa harus digunakan?
- Kecepatan awal loading yang terasa lebih cepat
- Peningkatan skor Lighthouse
- Peningkatan SEO dan pengalaman pengguna
đ§ Cara menerapkan
Langkah 1: Inline Critical CSS
Langkah 2: Lazy load CSS non-esensial (cara dasar)
Langkah 3 (opsional): Memuat style secara asinkron dengan JavaScript
- Setelah halaman selesai dimuat, gunakan JavaScript untuk memuat CSS non-esensial secara dinamis
- Dapat meningkatkan performa saat kecepatan jaringan lambat
- Semua
<link> CSS non-esensial yang ada di <head> harus dihapus
window.addEventListener("DOMContentLoaded", function () {
console.log("â
Page loaded, now loading non-critical stylesheets...");
let stylesheets = [
// "/css/vendors.min.css",
// "/css/style.min.css",
];
let loadedCount = 0;
function checkAllStylesLoaded() {
loadedCount++;
if (loadedCount === stylesheets.length) {
console.log("â
All non-critical stylesheets loaded...");
}
}
stylesheets.forEach(function (href) {
var link = document.createElement("link");
link.rel = "stylesheet";
link.href = href;
link.onload = checkAllStylesLoaded;
link.onerror = () => console.warn(`Failed to load stylesheet: ${href}`);
document.head.appendChild(link);
});
});
1 komentar
Komentar Hacker News
Akan keren kalau juga mendukung responsif; saya selalu akhirnya tetap mengedit stylesheet secara manual karena sulit melakukan dedupe critical style untuk layout responsif. Karena ukuran critical CSS itu penting, akan bagus juga kalau ada opsi untuk down-compile hal-hal seperti variabel CSS. Dan saya tidak merekomendasikan saran menaruh tag
<link>untuk CSS non-kritis tepat sebelum</body>, karena CSS harus didapat secepat mungkin; cara itu menunda penemuan CSS sehingga unduhannya juga terlambat. Sebagai gantinya saya merekomendasikan kombinasi preload dan noscript:<link rel="preload" href="styles.css" as="style" onload="this.rel='stylesheet'"><noscript><link rel="stylesheet" href="styles.css"></noscript>Saya penasaran apakah metode preload yang menulis kode JS seperti ini akan terblokir jika CSP tidak mengizinkan unsafe-inline
Saya tidak ingin memakai cara memuat CSS dengan hack JS; saat stylesheet diterapkan, seluruh halaman bisa mengalami perhitungan ulang layout/style, dan browser tetap akan mengambil stylesheet dengan cepat meski ada di bagian bawah halaman
Efek serupa juga bisa didapat hanya dengan kombinasi atribut prefetch, hint header HTTP, dan CDN; tidak perlu terus-menerus rebuild critical CSS. Kalau memakai CDN seperti CF dengan benar, hasilnya sangat cepat
Sepertinya benar, saya juga berencana menambahkan opsi seperti ini. Saya sempat mencoba opsi
DOMContentLoadedalih-alihbefore body, dan itu bekerja cukup baik untuk UX maupun Lighthouse, bahkan di ponsel lama dan jaringan lambatSangat setuju soal dukungan responsif
Menurut saya ini terasa seperti optimasi prematur. Mungkin ada nilainya kalau CSS sangat rumit atau resource yang dimuat sangat banyak, tetapi dalam kebanyakan situasi lebih efisien menulis CSS, HTML, dan JS dengan rapi, dan pendekatan ini bisa jadi tidak perlu atau malah merugikan
Sangat berguna. Saya sering menangani situs WordPress sebagai freelancer, dan sering sekali CSS/JS-nya sudah benar-benar berantakan karena melewati banyak developer/agensi; saya benar-benar ingin mencoba alat seperti ini
Justru semakin rumit CSS atau semakin banyak resource, semakin kecil efek bersih optimasinya. Yang ditargetkan di sini adalah optimasi RTT latency; makin besar critical CSS, makin tinggi biaya optimasinya, jadi keuntungan bersihnya mengecil
Kalau ini 12 tahun lalu, saya pasti akan membayar untuk alat seperti ini. Dulu saya punya CSS dalam jumlah sangat besar yang terakumulasi selama bertahun-tahun, dan sulit mengetahui aturan mana yang kritis
Untuk banyak situs ini memang bisa jadi optimasi prematur, tetapi untuk situs yang sensitif terhadap klik seperti berita/media, pemuatan halaman yang âinstanâ sangat penting. Begitu lewat 1 detik saja, bounce rate dan pendapatan iklan turun. HuffPost juga pernah mencoba optimasi ini 10 tahun lalu
Melihat kondisi frontend development saat ini, rasanya ini sudah keterlaluan. Alat seperti Lighthouse membuat orang terobsesi mengoptimalkan demi angka-angka yang tidak berarti, hasilnya kompleksitas build bertambah sementara pengguna nyata pun sering tidak merasakannya, tetapi pengembangan jadi lebih merepotkan. Di saat yang sama saya juga sering melihat situs yang penuh error UI/state management yang sangat mendasar. Menyebalkan
CSS, HTML, dan JS yang rapi memang jawabannya, tetapi kadang kita mewarisi proyek berantakan atau memakai template, dan bahkan saat saya sendiri yang mengembangkan pun desainnya bisa saja jadi kusut
Bagi saya, cara memuat CSS adalah hal yang wajib dipertimbangkan sejak tahap awal pengembangan. Kami sering kehilangan klien karena skor page speed web kami rendah, dan performa sangat penting karena memengaruhi SEO. Saya sampai mendesain ulang optimasi halaman sendiri demi mendapat 100 di Google Lighthouse; urutan dan cara loading CSS/JS harus direncanakan dari awal supaya tidak perlu banyak tambal-sulam belakangan. Kami bahkan memisahkan CSS di atas/bawah fold dan menyisipkannya inline di tempat yang tepat, dan JS di bawah fold bahkan tidak dievaluasi sampai pengguna scroll ke sana. Semua saran Lighthouse kami terapkan. Sistem sebelumnya memuat seluruh CSS situs di semua halaman (3~4MB), dan JS-nya bahkan lebih parah; itu akibat tidak ada desain optimasi dari awal. Kami masih memakai sistem itu jadi saya tidak bisa menyebut namanya, tetapi secara internal terus jadi masalah. Kalau targetnya performa, menurut saya tidak ada konsep optimasi prematur; semuanya harus dipikirkan dari awal. Hasilnya, performa 100 di semua klien termasuk mobile, dan kami unggul dibanding kompetitor. Saya mencoba alat ini di situs saya, tetapi karena hampir semuanya sudah diterapkan, tidak ada efek lagi karena memang nyaris tak ada yang tersisa untuk dioptimalkan
Di halaman saya yang dibuat dengan framework Astro, HTML-nya 27.52KB (6.1KB setelah kompresi), JS di bawah 10KB, dan critical CSS 57KB (7KB setelah kompresi). Situs serupa bisa mencapai 100KB~1MB. Kalau dibangun dengan rapi, tanpa inline css/js pun sudah cukup cepat hanya dengan resource hints. Dengan kombinasi nginx+HTTP/2+edge cache, performa 100/100 tetap bisa dicapai tanpa critical CSS/inline js. Tambahan 7KB di setiap halaman terasa tidak efisien. Dari sisi implementasi, SPA/edge caching jauh lebih ramah lingkungan dan cepat, dan tidak perlu mengirim HTML seberat Elementor. Baterai ponsel itu terbatas, jadi tidak ada alasan mengirim data yang tidak perlu
Ini trik yang bagus, tetapi dalam situasi di mana CDN dan HTTP/2 sudah umum, optimasi seperti ini pada akhirnya hanya memboroskan bandwidth. Angka benchmark memang naik sedikit, tetapi di dunia nyata biasanya hanya mempercepat sekitar 10~20ms saja
Menyertakan critical CSS di semua halaman bukan selalu jawaban yang tepat. Memakainya secara selektif hanya untuk kunjungan pertama (saat belum ada cache) atau halaman awal sesi juga bisa menghindari data bloat yang tidak perlu
Atas permintaan klien saya mencari alat ekstraksi critical css, tetapi tidak menemukan yang punya fitur yang saya inginkan, jadi akhirnya saya membagikan solusi buatan sendiri dengan Puppeteer. Kita bisa menentukan berapa lama harus menunggu setelah halaman dimuat. Saya juga sempat memakai layanan berbayar, tetapi tidak puas lalu meminta refund. Masukan sangat diterima, dan untuk sekarang saya buka gratis
Penasaran apakah masalahnya ada pada alat yang sudah ada seperti paket penthouse
Kalau memasukkan situs tanpa CSS, muncul error
Apakah kodenya terbuka? Saya juga ingin memakainya sebagai plugin Vite/Astro
Saya ingin tanya apakah ini versi UI dari penthouse, karena banyak nilai konfigurasinya mirip
Cara ini malah bisa jadi kontraproduktif. Akan muncul FOUC (flash of unstyled content) yang sangat konsisten, dan kalau layout berubah di tengah saat pengguna sedang menekan sesuatu, itu bisa sangat mengganggu. Ini bukan sekadar masalah estetika, tetapi masalah usability yang nyata
Saya juga sempat menyesuaikan beberapa style setelah menerapkan cara ini, tetapi pada akhirnya tetap bisa dioptimalkan sampai CLS (cumulative layout shift) 0. Saat anggaran kecil dan memakai template dengan banyak library, ini sangat berguna
Bukankah tujuan awalnya justru mencegah FOUC tanpa memblokir css network request?
Pendekatan ini lebih bermakna jika diasumsikan pada page view pertama tidak ada cache css sama sekali. Dalam praktiknya ada trade-off antara berbagai faktor seperti rasio pengunjung baru/kembali, pengaturan cache css, CDN, 103 early hints, dan critical css/initial congestion window
Saat mengukur performa di localhost, pengaruh CSS hampir tidak terasa. Bahkan jika CSS dihapus sepenuhnya, peningkatannya kurang dari 7ms, dan itu pun masih dalam margin error pengukuran
Ketika saya memakai alat ini di situs saya, elemen debugging yang sebenarnya tidak perlu malah ikut terekstrak ke CSS; misalnya
body::afteruntuk grid overlay situs juga ikut masuk (saya bahkan lupa itu masih ada, dan baru sadar sekarang)Saya lebih suka menulis HTML yang tetap menyampaikan makna dengan baik bahkan tanpa CSS. Dengan begitu, struktur dokumen yang jadi terlalu rumit bisa dicegah sejak awal
Idenya sendiri segar, jadi saya sempat mencobanya di situs pribadi, tetapi muncul error CSS yang hilang dari library penthouse
{"error":true,"name":"Error","message":"css should not be empty" ...}