Web Sistemleri - Katman 3
Tarayıcı, HTML ve CSS’ten piksel üretmek için bir render hattı kullanır. Bu hattın aşamalarını bilmek, “neden yeniden çizildi?” sorularını cevaplandırır.
Bu içerik; DOM, CSSOM, layout ve paint kavramlarını birbirine bağlayan çalışan bir zihin modeli sunar.
Genel bakış
HTML’den piksele: tek cümlelik model
Render hattını ezberlemek yerine, bir girdi → ara yapı → çıktı akışı olarak düşün:
HTML ve CSS parse edilir,
tarayıcı içeride ağaçlar üretir, sonra bu ağaçlardan geometry (nerede?) ve
paint (nasıl görünüyor?)
bilgisi çıkarır ve en sonda GPU üzerinde katmanları birleştirip ekrana basar.
Bu sayfanın sonunda şu iki soruyu “refleks” gibi cevaplayabileceksin: (1) “Bu değişiklik layout tetikler mi?” (2) “Yalnızca composite ile çözebilir miyim?”
Pipeline
Render hattının ana basamakları
“DOM/CSSOM/Render Tree/Layout/Paint/Composite” kulağa çok geliyor; ama her biri net bir iş yapar. Aşağıdaki listeyi neden-sonuç zinciri olarak oku.
-
Parse (HTML → DOM)Tokenizer + parser; etiketler bir DOM ağacına dönüşür. Bu, “sayfanın yapısıdır”.
-
Parse (CSS → CSSOM)CSS kuralları hesaplanır ve bir CSSOM ağacı oluşur. Bu, “kuralların haritasıdır”.
-
Style / CascadeDOM + CSSOM birleşir, her node için computed style çıkar (kalıtım, specificity, cascade).
-
Layout (Reflow)Her kutunun boyutu/konumu hesaplanır. “Bu eleman nerede duruyor?” sorusunun cevabıdır.
-
Paint (Repaint)Piksel komutları hazırlanır: text, border, background, shadow… Sonuç: “ne çizilecek?” listesi.
-
CompositeKatmanlar GPU’da birleştirilir. Transform/opacity gibi değişiklikler bazen sadece burada çözülür.
Zihin modeli
DOM ≠ ekranda gördüğün şey
DOM “belge yapısıdır”; ekrandaki pikseller ise çoğu zaman render tree ve onun
altındaki layout/paint sonuçlarıdır.
Örneğin display: none olan bir node DOM’da vardır ama
render tree’ye girmez;
buna karşılık visibility: hidden node’u render
tree’de kalır (yer kaplar) ama çizilmez.
Hızlı kural
“Yer kaplama” ile “görünürlük” farklıdır. Layout’u tetikleyen şey genelde
geometryyi etkileyen değişikliklerdir
(ölçü, akış, font metrikleri, container genişliği vb.).
Performans
Hangi değişiklik neyi tetikler?
Bir UI “yavaş” hissediyorsa çoğunlukla sorun layout veya paint maliyetidir. Ama bazı animasyonlar yalnızca composite ile akıcı yapılabilir.
-
Layout tetikleyenler
width/height,padding/margin,font-size,display, container genişliği/akış değişimleri. -
Paint tetikleyenler
background,color,box-shadow,border-radiusgibi görünümü değiştirip geometry’yi sabit bırakanlar. -
Composite ile çözülebilenler
transformveopacityçoğu senaryoda layout/paint’e girmeden GPU’da birleştirilir. Akıcı animasyonların “kral yolu” budur.
Anti-pattern: Layout Thrashing
JS içinde ölçüm (örn.
getBoundingClientRect) ve
yazma (style değişimi)
işlemlerini “sırayla karıştırırsan” tarayıcı layout’u tekrar tekrar yapmak zorunda kalabilir.
Çözüm: ölçümleri topla, sonra yazmaları tek fazda uygula (batch).
Pratik
DevTools ile render maliyetini okumak
Tahmin etmek güzel; ama profesyonel seviyede “kanıt” gerekir. Performance paneli, Frames/Timings ve Layout/Paint işaretleri; hangi fazın pahalı olduğunu gösterir. Buradaki hedef “hangi butona basılır” ezberi değil; grafiği gördüğünde hangi aşamaya bakacağını bilmektir.
Mini kontrol listesi: bir animasyon/etkileşim kötü hissediyorsa hızlıca şuraya bak.
-
FPS / Frame time16.6ms (60fps) bütçesini aşıyor musun? Aşıyorsan “hangi faz” şişiyor?
-
Layout sayısıBir etkileşimde çok layout görüyorsan thrashing veya geniş etki alanı vardır.
-
Paint alanıBüyük paint bölgeleri: shadow/blur/filters veya çok geniş invalidation olabilir.
-
Composite fırsatıAnimasyonu
transform/opacityile taşımayı deneyebilir misin?
Bağlantılar
Katman 3’te sonraki adımlar
- Sekme, process izolasyonu ve sandbox mantığı: render hattı “nerede” çalışıyor?
- Network katmanındaki gecikmeler, render’ın algısını nasıl etkiler? (TTFB, cache, TLS)
- Input → handler → DOM değişimi → render: gecikme nerede birikir?
- Veri geldikten sonra UI güncellemesi hangi aşamalardan geçer?