Kamu menulis beberapa baris HTML, menambahkan sedikit CSS, mungkin secuil JavaScript, dan sedetik kemudian halaman yang sudah rapi muncul di layar. Rasanya instan dan agak ajaib. Padahal di balik satu momen itu, browser menjalankan rangkaian langkah yang sangat teratur untuk mengubah berkas teks biasa menjadi piksel berwarna yang tersusun di atas layar.
Rangkaian langkah itu punya nama: pipeline rendering. Memahaminya termasuk salah satu hal yang diam-diam bikin kamu jadi developer yang lebih baik. Begitu kamu bisa membayangkan cara kerja browser, banyak perilaku yang tadinya misterius tiba-tiba terasa masuk akal — kenapa halaman berkedip, kenapa satu perubahan CSS membuat scroll terasa berat, kenapa menggeser elemen dengan properti tertentu terasa mulus sementara properti lain malah tersendat. Artikel ini akan menelusuri seluruh pipeline secara perlahan, dengan bahasa yang sederhana, supaya kamu pulang dengan gambaran mental yang jernih.
Titik awal: cuma teks
Saat browser mengunduh sebuah halaman web, yang sebenarnya ia terima adalah teks. HTML kamu hanyalah deretan karakter yang panjang. CSS kamu juga deretan teks lain. Browser tidak bisa langsung menggambar deretan karakter — ia sama sekali tidak tahu di mana sebuah judul harus diletakkan atau warna apa sebuah tombol seharusnya, sampai ia benar-benar memahami teks itu dan menyusun sesuatu yang terstruktur darinya.
Jadi tugas pertamanya adalah parsing: membaca teks mentah lalu mengubahnya menjadi struktur data rapi yang bisa diolah browser. Ada dua struktur utama yang ia bangun, dan keduanya menjadi fondasi dari semua langkah berikutnya.
Membangun DOM
Browser membaca HTML kamu dari atas ke bawah lalu menyusunnya menjadi sebuah pohon objek yang disebut DOM — Document Object Model. Kata “pohon” di sini penting. Persis seperti pohon keluarga, setiap elemen punya induk dan bisa punya anak. Sebuah <article> mungkin memuat satu <h2> dan beberapa <p>; paragraf-paragraf itu adalah anak dari article, article adalah anak dari <body>, dan seterusnya.
Document
└── html
└── body
└── article
├── h2 ("Pipeline Rendering")
└── p ("Kamu menulis beberapa baris HTML...")Setiap kotak di pohon itu adalah sebuah node — objek hidup yang disimpan browser di memori. Inilah juga yang diajak bicara oleh JavaScript ketika kamu menulis sesuatu seperti document.querySelector('h2'). DOM bukanlah berkas HTML kamu; ia adalah representasi terstruktur dari HTML itu yang dibangun dan disimpan browser di dalam memori.
DOM itu model, bukan berkasmu
Banyak orang menyebut “DOM” padahal maksudnya “HTML”. Keduanya berkaitan, tapi tidak sama. HTML kamu adalah teks di dalam berkas. DOM adalah pohon objek yang dibangun browser dari teks itu, dan terus diperbarui selama JavaScript berjalan. Ubah DOM maka halaman ikut berubah; berkas HTML aslinya tetap utuh tak tersentuh.
Membangun CSSOM
Sambil menyusun struktur dari HTML, browser juga perlu memahami gaya tampilan. Ia membaca setiap stylesheet — berkas CSS eksternal, blok <style>, dan style inline — lalu membangun pohon kedua bernama CSSOM, yaitu CSS Object Model.
CSSOM meniru struktur DOM tapi membawa informasi gaya: font apa, warna apa, berapa banyak padding, dan seterusnya. Ia juga mengurus pewarisan (inheritance) dan cascading. Kalau kamu menetapkan warna di <body>, CSSOM akan menyimpulkan bahwa setiap paragraf di dalamnya mewarisi warna itu, kecuali ada aturan yang lebih spesifik menimpanya. Begitu CSSOM selesai, browser sudah tahu gaya final yang berlaku untuk setiap elemen.
| Struktur | Dibangun dari | Menggambarkan |
|---|---|---|
| DOM | HTML | Konten dan strukturnya |
| CSSOM | CSS | Gaya yang berlaku untuk konten itu |
Menggabungkannya menjadi render tree
Sekarang browser punya dua pohon: satu untuk konten (DOM) dan satu untuk gaya (CSSOM). Sendiri-sendiri, keduanya belum cukup untuk menggambar apa pun. Konten tanpa gaya tidak punya tampilan; gaya tanpa konten tidak punya apa pun untuk digambar. Maka browser menggabungkan keduanya menjadi pohon ketiga: render tree.
Render tree hanya memuat hal-hal yang benar-benar akan terlihat, masing-masing dipasangkan dengan gaya finalnya. Perbedaan ini penting. Beberapa node dari DOM tidak ikut masuk ke render tree. Elemen <head> menyimpan metadata, bukan konten yang terlihat, jadi ia ditinggalkan. Apa pun yang diberi display: none juga dibuang — ia tetap ada di DOM, JavaScript masih bisa melihatnya, tapi tidak menghasilkan apa pun di layar, jadi render tree melewatinya.
display: none vs visibility: hidden
Keduanya tampak mirip tapi berperilaku berbeda dalam pipeline. display: none mengeluarkan elemen sepenuhnya dari render tree — ia tidak memakan ruang sama sekali. visibility: hidden tetap mempertahankan elemen di render tree dan tetap menyisakan ruangnya; ia hanya digambar dalam keadaan tak terlihat. Perbedaan kecil itu mengubah cara langkah-langkah berikutnya memperlakukan elemen tersebut.
Layout: menghitung geometri
Render tree sudah tahu apa yang harus ditampilkan dan seperti apa tampilannya, tapi belum tahu di mana posisi semuanya dan seberapa besar ukurannya. Menentukan itu adalah tugas langkah layout (browser lawas dan banyak artikel menyebutnya reflow — ide yang sama, istilah berbeda).
Pada tahap layout, browser menghitung geometri persis setiap elemen yang terlihat: posisinya di halaman serta lebar dan tingginya dalam piksel. Di sinilah satuan persen, em, flex, grid, dan “isi lebar yang tersedia” semuanya diterjemahkan menjadi angka konkret. Sebuah width: 50% baru berarti setelah browser tahu seberapa lebar induknya yang sebenarnya, dan perhitungan itu terjadi di tahap layout.
Layout pada dasarnya saling terkait. Di mana sebuah elemen berada bergantung pada elemen di sekitarnya, dan ukuran sebuah wadah bergantung pada anak-anaknya. Maka satu perubahan kecil bisa merembet ke mana-mana: buat satu paragraf lebih tinggi, semua yang ada di bawahnya harus bergeser turun. Efek rembet inilah yang membuat layout bisa terasa mahal, dan itu membawa kita ke satu gagasan penting yang perlu kamu pegang.
Reflow vs repaint
Dua istilah ini sering muncul ketika orang membahas performa rendering: reflow dan repaint. Keduanya menjelaskan apa yang harus diulang browser saat ada perubahan di halaman, dan beban kerjanya sangat berbeda.
Sebuah reflow (proses layout ulang) terjadi ketika kamu mengubah sesuatu yang memengaruhi geometri — ukuran atau posisi. Mengubah lebar elemen, menambah teks yang membuat kotak jadi lebih tinggi, menyisipkan elemen baru, mengatur display — semua ini memaksa browser menghitung ulang posisi dan ukuran, sering kali untuk banyak elemen sekaligus karena efek rembet tadi. Reflow adalah yang paling berat di antara keduanya.
Sebuah repaint terjadi ketika kamu mengubah sesuatu yang murni visual dan tidak memengaruhi geometri — misalnya warna teks, warna latar, atau visibility. Elemen tetap di tempat yang sama dengan ukuran yang sama, jadi browser bisa melewati layout dan cukup mengisi ulang piksel yang terdampak. Lebih ringan daripada reflow, walau tetap bukan tanpa biaya.
| Perubahan yang kamu lakukan | Yang diulang browser | Biaya relatif |
|---|---|---|
| Mengubah lebar, tinggi, atau posisi | Reflow (layout) + repaint | Lebih tinggi |
| Menambah atau menghapus elemen yang terlihat | Reflow (layout) + repaint | Lebih tinggi |
| Mengubah warna teks atau latar | Repaint saja | Lebih rendah |
Mengubah visibility jadi hidden |
Repaint saja | Lebih rendah |
Intinya secara praktis: reflow hampir selalu memaksa repaint setelahnya (kalau geometri bergeser, pikselnya harus digambar ulang), tapi repaint tidak membutuhkan reflow. Menyentuh geometri adalah pilihan yang lebih mahal, jadi kalau kamu punya opsi, lebih baik pilih perubahan yang cukup memicu repaint saja.
Paint: mengisi piksel
Setelah layout menentukan posisi setiap kotak dan ukurannya, browser lanjut ke tahap paint. Di langkah inilah ia benar-benar mengisi piksel — menggambar huruf, warna latar, garis tepi (border), bayangan, gambar, dan setiap detail visual lainnya ke atas sebuah permukaan.
Bayangkan layout sebagai arsitek yang menggambar denah lengkap dengan ukuran presisi, dan paint sebagai tukang yang membubuhkan warna ke setiap permukaan sesuai denah itu. Paint tidak menentukan di mana posisi sesuatu — itu sudah ditetapkan layout. Ia hanya menentukan warna setiap piksel.
Untuk halaman yang rumit, proses paint bisa dipecah menjadi beberapa lapisan yang digambar terpisah, dan ini menyiapkan kita untuk langkah terakhir.
Compositing: menyatukan lapisan
Browser modern sering kali tidak menggambar seluruh halaman ke atas satu permukaan datar. Sebaliknya, ia memisahkan bagian-bagian halaman menjadi beberapa lapisan (layer) terpisah, menggambar tiap lapisan secara mandiri, lalu menumpuknya menjadi gambar akhir yang kamu lihat. Tahap menumpuk dan menyatukan itulah yang disebut compositing.
Analogi yang pas adalah cel animasi zaman dulu: ilustrator menggambar latar belakang yang diam di satu lembar, dan karakter yang bergerak di lembar transparan yang ditumpuk di atasnya. Untuk menganimasikan karakternya, kamu cukup menggambar ulang lembar atas dan menggesernya — latar belakang sama sekali tidak berubah. Lapisan di browser bekerja dengan cara yang mirip.
Inilah rahasia di balik animasi yang terasa mulus. Kalau sebuah elemen berada di lapisannya sendiri, browser bisa menggerakkan lapisan itu — menggesernya, menskalakannya, memudarkannya — tanpa mengulang layout atau bahkan menggambar ulang isi lapisannya. Ia cukup menyusun ulang lapisan yang sudah ada di posisi yang baru. Itu jauh lebih ringan daripada melakukan reflow dan repaint di setiap frame, dan itulah sebabnya menganimasikan properti tertentu terasa mulus sementara properti lain tersendat.
Sebagian properti tetap di jalur ringan, sebagian tidak
Sebagai patokan, menganimasikan posisi elemen lewat transform atau tingkat transparansinya lewat opacity sering kali bisa ditangani cukup oleh compositing — jalur yang ringan. Menganimasikan properti geometri seperti width, height, top, atau left memaksa reflow di setiap frame — jalur yang berat. Tujuan visualnya sama, tapi biayanya jauh berbeda. Di sini kita masih di tataran konsep; detail “cara menjaga animasi tetap mulus” yang lebih dalam masuk ke ranah performa web, yang merupakan topik tersendiri.
Seluruh pipeline dalam satu pandangan
Menyusun setiap langkah secara berurutan, inilah perjalanan dari teks menjadi piksel:
HTML ─► parse ─► DOM ─┐
├─► Render Tree ─► Layout ─► Paint ─► Composite ─► Piksel
CSS ─► parse ─► CSSOM ┘ (geometri) (isi) (tumpuk lapisan)Baca dari kiri ke kanan: dua aliran teks di-parse menjadi DOM dan CSSOM, keduanya menyatu jadi render tree, layout menghitung geometri, paint mengisi piksel, compositing menumpuk lapisan, dan frame jadi pun muncul di layar. Setiap perubahan terlihat yang kamu lakukan di halaman akan kembali masuk ke pipeline ini di suatu titik — dan seberapa jauh ke belakang ia masuk kembali itulah yang menentukan apakah perubahan tersebut ringan atau berat.
Rangkuman
Pipeline rendering adalah resep browser untuk mengubah kode menjadi gambar, dan sekarang kamu bisa membayangkan tiap tahapnya:
- Parsing membaca teks mentah HTML dan CSS kamu.
- DOM adalah pohon objek konten yang dibangun dari HTML; CSSOM adalah pohon informasi gaya yang dibangun dari CSS.
- Render tree menggabungkan keduanya dan hanya menyimpan yang benar-benar terlihat.
- Layout (reflow) menghitung geometri — di mana setiap elemen berada dan seberapa besar ukurannya.
- Paint mengisi piksel sesungguhnya: warna, teks, garis tepi, bayangan.
- Compositing menumpuk lapisan-lapisan yang digambar terpisah menjadi gambar akhir.
- Sebuah reflow mengulang geometri dan biayanya berat; sebuah repaint hanya mengisi ulang piksel dan lebih ringan; perubahan compositing adalah yang paling ringan.
Pegang gambaran ini di kepala dan browser pun berhenti menjadi kotak hitam misterius. Kamu akan mulai mengenali, hampir secara naluriah, mana perubahan yang ringan dan mana yang berat. Dari sini, langkah lanjutan yang wajar adalah performa web — di mana pemahaman tentang reflow, repaint, dan compositing ini kamu ubah menjadi teknik konkret untuk membangun halaman yang tetap cepat dan mulus, bahkan ketika banyak hal terjadi di layar sekaligus.
