Pengecil HTML

Minify dan kompres HTML dalam satu tempat

HTML minifier ini menghilangkan semua yang tidak dibutuhkan browser untuk merender halaman Anda — komentar, whitespace redundan, dan baris baru serta indentasi di antara tag — sehingga file yang Anda kirim secara fisik lebih kecil tapi tampil dan berperilaku persis sama. Tempel markup Anda atau seret file .html dan hasil terkompresi langsung muncul, lengkap dengan byte dan persentase tepat yang berhasil Anda hemat.

Alat ini sekaligus berfungsi sebagai kompresor HTML dan HTML beautifier: satu toggle membalik antara meng-minify sebuah halaman dan meng-un-minify-nya, sehingga alat yang sama yang memadatkan markup Anda juga bisa mengembalikan halaman yang sudah di-minify menjadi kode yang rapi dan terindentasi. Semua berjalan di browser Anda — tanpa upload, tanpa akun, tanpa batas.

Apa yang dihapus — dan apa yang tidak pernah disentuh

Saat Anda minify HTML, alat ini menghapus komentar (<!-- … -->), memampatkan rangkaian whitespace, memangkas jarak antar tag tingkat blok, memampatkan atribut boolean (disabled="disabled" menjadi disabled) dan bisa secara opsional membuang tag penutup redundan seperti </li> dan </td>. Comment kondisional (<!--[if IE]>) selalu dipertahankan.

Yang terpenting, prosesnya aman. Isi <pre>, <textarea>, <script>, dan <style> dilindungi sebelum apa pun dihapus, dan spasi tunggal di antara elemen inline — tautan, <span>, <strong> — dipertahankan, sehingga teks Anda tidak pernah menyatu. Ini model keamanan yang sama dipakai HTMLMinifier milik kangax, library minifikasi HTML yang paling banyak dipakai, dipelihara di GitHub dengan lebih dari 5.000 star. Nilai atribut yang berkutip juga dilindungi, sehingga sebuah title dengan spasi ganda tetap persis seperti ditulis.

Minify atau beautify — alat dua arah yang sesungguhnya

Perlu membaca halaman yang sudah dipadatkan jadi satu baris? Alihkan ke mode Beautify untuk meng-unminify HTML: alat ini mengindentasi ulang markup, menempatkan tag pada barisnya masing-masing, dan membuat strukturnya mudah dipindai kembali. Pilih indentasi 2 spasi, 4 spasi, atau tab agar sesuai gaya proyek Anda.

Karena minify dan beautify bisa dibalik, Anda bisa menempel HTML produksi yang ter-minify, membacanya, mengubahnya, dan meng-minify-nya lagi — semuanya tanpa meninggalkan halaman atau menginstal apa pun. Alat seperti PrettyDiff dan Prettier melakukan pemformatan HTML serupa, tapi memerlukan Node.js atau ekstensi browser. Alat ini bekerja langsung di browser apa pun di perangkat apa pun, termasuk seluler, tanpa pengaturan apa pun.

Lihat byte yang Anda hemat — termasuk gzip

Bilah statistik melaporkan ukuran asli, ukuran keluaran, serta byte dan persentase yang dihemat, sehingga Anda selalu tahu persis seberapa kecil HTML Anda. Ukuran diukur dalam byte UTF-8 nyata, bukan hitungan karakter, sehingga cocok dengan yang benar-benar disajikan server Anda.

Alat ini juga menampilkan angka gzipped yang dihitung lokal di browser Anda. Minifikasi dan gzip saling menumpuk — minify sumbernya dulu, lalu biarkan host Anda mengompresnya — dan melihat kedua angka membuat keuntungan gabungannya jelas. Google PageSpeed Insights dan web.dev sama-sama merekomendasikan melakukan keduanya. Kebanyakan HTML minifier pesaing hanya menampilkan jumlah byte minified; alat ini juga menampilkan estimasi gzip, yang merupakan angka yang benar-benar menentukan seberapa cepat halaman Anda dimuat lewat jaringan.

Minify CSS dan JavaScript inline dengan aman

Halaman dunia nyata membawa styling dan perilaku inline. Aktifkan Minify inline CSS dan setiap blok <style> dikompres dengan cara yang sama seperti CSS minifier khusus — komentar dan whitespace dihapus, dengan string, url(), dan calc() dilindungi agar tidak ada yang rusak.

Minify inline JS merapikan blok <script> secara konservatif: menghapus komentar dan memampatkan indentasi tapi sengaja mempertahankan baris baru, sehingga JavaScript yang mengandalkan automatic semicolon insertion tidak bisa rusak. Skrip yang ditandai sebagai JSON, template, atau tipe non-JavaScript lainnya terdeteksi dan dibiarkan tidak tersentuh. Pendekatan gabungan ini mengungguli menjalankan alat terpisah seperti CSS Minifier dan JS Minifier secara berurutan, karena masing-masing bisa salah membaca konteks saat diterapkan pada file HTML campuran.

Bagaimana ini dibandingkan dengan HTMLMinifier.com, Minifier.org, dan Willpeavy

HTML minifier pesaing paling populer — HTMLMinifier.com, Minifier.org, dan HTML minifier Willpeavy.com — semuanya memproses HTML Anda di sisi server. Setiap potongan yang Anda tempel dikirim lewat jaringan ke server pihak ketiga. Untuk HTML uji publik ini tidak masalah; untuk pekerjaan klien, halaman yang belum dirilis, atau HTML apa pun yang menyertakan token autentikasi, konten privat, atau data formulir, ini risiko privasi nyata. Minifycode.com punya keterbatasan yang sama.

Alat ini berjalan sepenuhnya di browser Anda. JavaScript yang meng-minify HTML Anda diunduh sekali saat halaman dimuat, lalu berjalan secara lokal — tidak ada server yang terlibat, tidak ada data yang dikirim. Untuk situs WordPress, alat ini menutup celah yang tidak dijangkau plugin seperti WP Rocket, LiteSpeed Cache, dan Autoptimize: potongan template individual, blok kustom, dan email HTML yang melewati minifikasi otomatis plugin. Gunakan sebagai pengecekan cepat sebelum melakukan commit perubahan template, atau sebagai minifier utama untuk proyek yang tidak memakai sistem build.

Apa yang sebenarnya dihapus minifikasi — perspektif spesifikasi HTML

Spesifikasi HTML5 membuat beberapa kategori konten benar-benar inert, yang justru dimanfaatkan minifikasi. Text node hanya-whitespace di antara elemen tingkat blok — baris baru dan spasi yang membuat indentasi sumber mudah dibaca — diabaikan saat layout. Parser HTML browser membuatnya sebagai text node DOM, tapi model box CSS membuang text node hanya-whitespace yang muncul di antara box blok, sehingga memampatkannya tidak berdampak apa pun pada rendering. Komentar HTML (<!-- … -->) di-parse menjadi node Comment yang tidak terlihat oleh render tree dan tidak pernah bisa di-style, diseleksi, atau dijangkau kebanyakan JavaScript (kecuali kode secara eksplisit memanggil document.createNodeIterator dengan filter SHOW_COMMENT, yang hampir tidak pernah dilakukan kode produksi).

Tag penutup opsional adalah target aman lain yang didefinisikan aturan parsing HTML5. Spesifikasi secara eksplisit mencantumkan elemen yang tag penutupnya boleh dihilangkan saat tag berikutnya yang spesifik membuat penutupannya tidak ambigu: </li> saat <li> lain menyusul, </p> sebelum elemen tingkat blok, </td> sebelum <td> lain atau </tr>, dan serupa untuk </dt>, </dd>, </th>, </tr>, </colgroup>, </tbody>, </tfoot>, </thead>, </head>, </body>, dan </html>. Semua browser utama menerapkan aturan penghilangan ini dan sudah melakukannya jauh sebelum HTML5 difinalisasi. Optimasi atribut boolean sama amannya: spesifikasi HTML mendefinisikan atribut boolean berdasarkan keberadaan nama atributnya saja — disabled, checked, readonly, required, multiple, novalidate, dan lainnya. Nilainya tidak relevan; disabled="", disabled="disabled", disabled="false", dan disabled polos semuanya identik. Minifier mereduksi semua bentuk itu menjadi nama atribut telanjang, biasanya menghemat 8–12 byte per atribut boolean.

Penghapusan kutip atribut valid menurut spesifikasi HTML5 saat nilai atribut tidak mengandung spasi, kutip ganda, kutip tunggal, backtick, tanda sama dengan, atau kurung siku. Nilai seperti class=container, id=header, dan type=text adalah HTML tanpa kutip yang sepenuhnya legal. Minifier konservatif melewatkan optimasi ini karena satu karakter khusus yang terlewat merusak parsing; pengaturan agresif di library seperti html-minifier-terser menerapkannya dengan pengecekan kelas karakter pada setiap nilai sebelum memutuskan.

Ukuran HTML, HTTP, dan bagaimana minifikasi cocok dengan rantai pengiriman

HTML hampir selalu menjadi sumber daya pertama yang diambil browser saat memuat halaman. Browser tidak bisa menemukan CSS, JavaScript, gambar, atau font sampai ia mem-parse setidaknya <head> dokumen HTML — sehingga respons HTML berada di jalur kritis setiap sumber daya berikutnya. File HTML yang lebih besar berarti lebih banyak byte sebelum parser bisa mengeluarkan preload link pertama atau menemukan stylesheet, yang menunda First Contentful Paint (FCP) dan berkontribusi pada Time to First Byte (TTFB) yang lebih tinggi seperti dirasakan klien (karena server harus mengirim lebih banyak byte sebelum konten bermakna pertama tiba). Inilah mengapa Lighthouse dan PageSpeed Insights Google sama-sama menandai HTML yang belum di-minify di samping CSS dan JavaScript yang belum di-minify.

Di bawah HTTP/1.1, setiap koneksi TCP membawa overhead untuk jabat tangan tiga arah, negosiasi TLS, dan TCP slow-start, yang berarti beberapa kilobyte pertama dari setiap koneksi adalah yang paling mahal. File HTML yang membengkak melampaui satu atau dua ukuran initial congestion window TCP (masing-masing sekitar 14 KB) memaksa server menunggu ACK sebelum mengirim data lebih lanjut, menambah satu round-trip penuh latensi. HTTP/2 mengurangi ini dengan stream multipleks dan kompresi header HPACK, tapi body HTML — tidak seperti header — tidak dikompresi oleh lapisan protokol; kompresi body masih bergantung pada GZIP atau Brotli di level content-encoding. Bahkan dengan Brotli diaktifkan (yang mencapai kompresi 15–25% lebih baik daripada GZIP pada teks HTML), minifikasi tetap aditif: ia menghapus byte redundan sebelum algoritma kompresi berjalan, yang sedikit memperbaiki baik rasio kompresi maupun beban dekompresi yang harus dilakukan browser. File HTML 100 KB yang menjadi 22 KB setelah gzip mungkin menjadi 19 KB setelah minifikasi — keuntungan yang tampak sederhana namun bertambah besar di ribuan kunjungan halaman per hari.

Interaksi antara minifikasi dan CDN edge caching juga relevan. Saat CDN menyimpan sebuah respons, ia menyimpan byte yang sudah terkompresi. Respons origin yang di-minify-lalu-dikompresi menempati lebih sedikit ruang penyimpanan edge cache, yang bisa mengurangi eviction cache untuk kumpulan URL berkardinalitas tinggi (misalnya halaman produk e-commerce dengan banyak parameter URL). Untuk HTML yang tidak bisa di-cache — halaman yang dipersonalisasi, dasbor yang sudah login — minifikasi langsung mengurangi byte yang harus dikirim origin lewat jaringan pada setiap permintaan, tanpa keuntungan caching yang mengimbangi biaya melewatkannya.

Minifikasi CSS dan JavaScript inline: trade-off dan teknik

Sumber daya inline menghadirkan trade-off berbeda dibanding file yang ditautkan secara eksternal. File .css atau .js eksternal bisa di-cache browser secara independen dari HTML; pada kunjungan berulang file disajikan dari cache disk lokal dan menghasilkan nol byte jaringan. Blok <style> atau <script> inline adalah bagian dari dokumen HTML, sehingga jika bagian mana pun dari HTML berubah, seluruh dokumen harus diambil ulang — browser tidak bisa meng-cache sebagian dari respons HTML. Ini trade-off fundamental dari inlining: Anda menghemat satu permintaan HTTP pada pemuatan pertama tapi mengorbankan kemampuan cache independen. Untuk sumber daya yang sering berubah, penaltinya berlipat ganda di setiap kunjungan halaman.

Terlepas dari peringatan itu, inlining CSS kritis adalah teknik performa yang banyak direkomendasikan. Sifat render-blocking stylesheet eksternal berarti browser harus mengambil, mem-parse, dan menerapkan file CSS sebelum bisa menggambar apa pun. Meng-inline hanya CSS yang dibutuhkan untuk merender konten di atas lipatan — biasanya 5–15 KB — menghilangkan permintaan render-blocking itu dan bisa secara dramatis memperbaiki Largest Contentful Paint (LCP). Alat seperti Critical (Node.js) dan PurgeCSS mengotomatiskan ekstraksinya; CSS inline yang dihasilkan sebaiknya juga di-minify sebagai bagian dari langkah build yang sama. Saat Anda meng-minify CSS inline, minifier memperpendek nilai properti di mana spesifikasi mengizinkannya: #ffffff menjadi #fff, font-weight: normal menjadi font-weight: 400, dan margin: 10px 10px 10px 10px memampat menjadi margin: 10px. Mikro-optimasi ini kecil secara individual tapi bermakna secara kolektif di blok CSS besar.

Minifikasi JavaScript inline lebih konservatif dibanding apa yang dilakukan alat khusus seperti Terser atau esbuild pada file .js mandiri. Mangling nama variabel — mengganti longVariableName dengan a — memerlukan minifier membangun analisis scope penuh dari kode, yang hanya aman saat seluruh bundle JS diproses sebagai satu kesatuan. Meng-minify satu blok skrip inline secara terisolasi tidak bisa dengan aman mengubah nama identifier karena skrip itu mungkin membaca dari atau menulis ke variabel global yang dipakai skrip eksternal lain yang dimuat di tempat lain pada halaman. Akibatnya, minifikasi JS inline yang aman menghapus komentar, memampatkan whitespace, dan menghilangkan titik koma yang tidak perlu, tapi membiarkan identifier utuh. Penghapusan kode mati — menghapus cabang yang tidak pernah bisa dieksekusi — juga sama-sama tidak mungkin dilakukan tanpa analisis seluruh program. Untuk minifikasi JS maksimal, pindahkan kode ke file eksternal dan jalankan lewat pipeline bundle penuh Terser; gunakan minifikasi JS inline untuk menangani kode lem sisa dan skrip analitik yang harus tetap inline.

Minifikasi HTML dalam toolchain build dan penghematan dunia nyata

Build tool JavaScript modern menangani minifikasi HTML sebagai bagian dari pipeline output produksinya. html-minifier-terser — penerus yang aktif dipelihara dari html-minifier asli milik kangax — adalah library Node.js paling banyak dipakai untuk tugas ini. Opsi utamanya memetakan langsung ke teknik-teknik di atas: removeComments, collapseWhitespace, removeOptionalTags, collapseBooleanAttributes, removeAttributeQuotes, minifyCSS, dan minifyJS. Webpack menerapkannya lewat html-webpack-plugin dikombinasikan dengan html-minimizer-webpack-plugin, yang membungkus html-minifier-terser dan berjalan pada setiap file HTML yang dihasilkan. Vite meng-minify HTML pada build produksi memakai htmlnano di baliknya, dengan level preset dari aman hingga agresif. Astro — static site generator yang dipakai membangun alat ini — menjalankan htmlnano pada output SSG secara default, sehingga setiap halaman yang dihasilkan secara statis di-minify tanpa konfigurasi eksplisit apa pun. Pengguna Rollup bisa menambahkan @rollup/plugin-html dan merangkainya dengan transformasi minifikasi.

Build development sengaja melewatkan minifikasi. Sumber HTML yang mudah dibaca esensial untuk memeriksa DOM di DevTools browser, mencocokkan elemen dengan baris sumber, dan mendiagnosis bug tata letak tanpa beban kognitif menguraikan markup terkompresi. Berbeda dari JavaScript — yang punya standar source map matang (file .map) yang memungkinkan DevTools menampilkan kode asli sebelum di-minify — HTML tidak punya spesifikasi source map yang setara. HTML yang di-minify di produksi karena itu benar-benar lebih sulit di-debug di panel Elements browser, alasan lain untuk hanya menerapkan minifikasi pada build produksi dan tetap menyimpan salinan yang di-beautify untuk pemeriksaan.

Dari segi penghematan dunia nyata, minifikasi saja biasanya mengurangi ukuran HTML mentah sebesar 5–15%. Halaman produk e-commerce besar yang penuh komentar template hasil CMS, spasi trailing di setiap baris, dan atribut boolean yang verbose bisa turun dari 80 KB menjadi 68 KB — sekitar 15% — sebelum kompresi. Setelah GZIP, penghematannya menyempit karena algoritma LZ77 gzip sudah sangat efektif mengompres pola whitespace berulang: halaman 80 KB yang belum di-minify mungkin gzip menjadi 18 KB dan halaman 68 KB yang sudah di-minify mungkin gzip menjadi 16 KB — selisih 2 KB. Penghematan terkompresi itu nyata tapi lebih kecil secara persentase dibanding keuntungan tak terkompresi. Untuk Brotli, selisihnya serupa. Di mana minifikasi konsisten memberi hasil di luar perhitungan byte-yang-dihemat adalah pada kecepatan parsing: tokenizer HTML browser memproses lebih sedikit karakter, yang sedikit mengurangi Time to Interactive (TTI) pada dokumen sangat besar, dan mengurangi memori puncak yang dialokasikan untuk buffer parse awal — terukur pada perangkat seluler memori-rendah yang sudah tertekan menjalankan skrip dan layout secara bersamaan.