TARAYICILAR (BROWSER) NASIL ÇALIŞIR ?

Chrome Web Sayfasını Ekrana Nasıl Çizer ?

Chrome adres çubuğuna bir URL yazdınız, web sayfasına gittiniz veya Google’da bir kelime aratıp , gelen sonuçları bir liste halinde gördüğünüz bu ekranlar tarayıcı tarafından nasıl çiziyor ?

Onur Dayıbaşı

Published in

Frontend Development With JS

6 min readOct 12, 2020

Öncelikle Tarayıcılar nasıl çalışır konusunda önceden yazdığım yazılara bakmak için Giriş, Temel Bilgiler, Chrome Multi-Process Mimari, Chrome Navigasyon nasıl gerçekleşiyor yazılarımı okuyabilirsiniz.

Not: Ayrıca Chrome Nasıl Çalışır Yazı Serisine bu linkten erişebilirsiniz.

Şimdi gelelim Renderer Process bir web sayfasını ekranda nasıl çizdiğine. Tab içerisindeki tüm işlemlerden Renderer Process sorumludur.

Main Thread JS işletilmesi (Web Worker ve Service Worker ayrı thread),
Compositor ve Raster Thread sayfayı efektif , sorunsuz şekilde çizmesi
HTML, CSS, JS görüntülenecek bir Web sayfasına dönüştürülmesi
Bu sayfadaki kullanıcı input(etkileşimlerinin) alınması ve işletilmesi

https://developers.google.com/web/updates/2018/09/inside-browser-part3 Renderer Process -Threads

1. Rendering & JS Engine

Tarayıcıların en önemli parçalarından bir taneside bu Renderer Process kısmıdır. Bu kısımda tarayıcılar Rendering Engine, JS Engine kullanır. Kısaca üzerinde bir çok komite ve şirketin geliştirdiği Tarayıcıları bir diğerinin önüne geçirebilecek performans kazançları bu engine tarafından gerçekleştirilir.

Not: Bu yarışı Chrome önde götürdüğü için Microsoft Edge, Opera kendi yapılarını Blink ve V8 Engine taşımışlardır.

Rendering Engine (Motorları)

Chrome, Opera, Edge → Blink Rendering Engine, (fork of WebKit)
Safari → Webkit
IE → Trident
Firefox → Gecko

JS Engine (Motorları)

Chrome , Opera, Edge — V8
Firefox — SpiderMonkey
IE — Chakra
Safari — JavaScriptCore

2. Ana Akış

Render Motorunun ana akışını incelersek.

Parsing: HTML parse edilerek DOM (Document Object Model) oluşur. Aynı and CSS parse edilerek bu DOM nesnelerinin nasıl görsellikte olacağı ile ilgili kuralların olduğu Style Rules oluşturulur.
JS Updates: Bu aşamadan sonra işletin JS kodu DOM ve Style Rules güncellemeler ve değişiklikler yapabilir
Merging: DOM Ağacındaki elemanlar + Style Rules (stil kuralları) birleştirilerek Render Ağacı oluşturulur. Bu ağacı hangi elemanın hangi sırada hangi stilde ve boyutlarda ekrana çizileceği ile ilgili bilgileri içerir.
Layout: Render Ağacı oluştuktan sonra bunun hangi büyüklükte bir ekran içerisine (Masaüstü, Tablet, Cep Telefonu vb..) çizileceği ve mevcut CSS Layout bilgilerine göre elemanların ekrandaki pozisyonlarının ne olacağı hesaplanarak bu bilgilerde ağaça eklenir.
Painting: Son aşamada ise bu Render Ağacı elemanlarının ekrana çizilmesi ve boyanması işlemi gerçekleştirilir. Burada elemanların çizilme öncelikleri, transparency gibi kavramlar devreye girer.

https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/#The_main_flow

3. Parsing

DOM Oluşturulması

Browser Process → Renderer Process IPC ile Navigasyon Commit mesajı gönderdiğinde Renderer Process Main Thread bu HTML Parse etmeye başlar. En sonunda sayfa için DOM (Document Object Modeli) ortaya çıkarır.

JS ile DOM API üzerinden bu model ile iletişim kurup, bu modelde istenen değişiklikleri gerçekleştirebilirsiniz. Bu konuda DOM API Kullanım Yöntemleri ile ilgili yazmış olduğum yazı dizisini okuyabilirsiniz.

HTML dokümanından DOM oluşturma HTML Standard belirtildiği gibi gerçekleştirilir. Tarayıcılar bu standartlara göre DOM Tree oluşturur ama burada herhangi bir hata olması durumunda tarayıcılar hata vermez bunun nedeni HTML Spec bu hataları iyi bir şekilde ele almak için tasarlanmış olmasıdır. (An introduction to error handling and strange cases in the parser)

HTML dökümanın içerisinde ayrıca farklı kaynaklarda bulunan JS, CSS, Image, Video vb.. dosyalar bulunur. Main Thread bir yandan HTML parse ederken bir yandan da diğer kaynakların Network veya Cache yüklenmesi için ilgili Process çağırır. Tüm bu işlemler performans için async ve olabildiğince paralel bir şekilde gerçekleştirilmeye çalışılır.

JS Updates

HTML parser <script> tag bulduğunda parse işlemine ara verilip, JS dosyasının çalıştırılması gerçekleştirilir. Bunun nedeni JS içerisindeki bir takım kodların DOM yapısını değiştirebilecek olmasıdır.

https://developers.google.com/web/updates/2018/09/inside-browser-part3 (DOM Tree)

4. Style Calculation (Render Ağacı Oluşturma)

DOM tek başına ekrandaki elemanların güzel görünmeleri için yeterli değildir. Bunun için CSS tarafından parse edilerek oluşturulan (style rules) işlenerek Render ağacı dediğimiz Computed Style oluşması gerekir. Bu her bir DOM elemanın CSS Selector ile match eşlenmesi ile oluşur.

https://developers.google.com/web/updates/2018/09/inside-browser-part3 (Style Calculation)

Örneğin Chrome DevTools açtığımızda Sol kısımda DOM Tree, Sag kısımda Style ve Computed kısmını görebilirsiniz. Style belli bir hiyerarşi ile işletilir. Elemandan, Class selector, Tag selector olacak şekilde (stilde !important vermişseniz bu öncelik değişebilir)

Chrome Dev Tool (DOM Tree, Style, Computed)

5. Layout

Renderer Process dokümanın yapısı ve her bir elemanın ekrana nasıl çizileceği ile ilgili stilleri biliyor ama bunlar ekrana çizim için yeterli koşullar değildir.

Tarayıcının çalıştırdığı ekran büyüklüğü(Masaüstü, Tablet, Cep telefonu)
HTML elemanlarının yayılımı konusunda belirttiğiniz Layout yapıları (Grid, Flex, Float vb..)
CSS kurallarının elemanlarının üzerindeki Layout etkilemesi ekranda rendering yapısı hiç dahil edilmemesidisplay: none veya katılsa bile ekrana çizilmemesi visibility: hidden veya pseudo code sınıfları ile elemanın öncesinde eklenmesi p::before{content:"Hi!"} vb..

Sizin DOM elemanlarının ekrana hangi pozisyona ve hangi boyutlarda çizileceğini etkiler. Layout aşamasında tüm bu bilgiler işlenerek Render ağacındaki elemanların pozisyonları (x,y) ve sınırlayıcı çerçevesi(bounding box) belirlenir.

https://developers.google.com/web/updates/2018/09/inside-browser-part3 (Layout Ağacı)

Aynı zamanda sayfa Layout sırasında yazılarının ilgili çerçeve içerisine sığmadığı durumlarda nasıl davranacağı CSS göre belirlenmesi gerekir. Satır aşağıya mı kayacak, line-break yoksa … şeklinde 3 nokta mı gösterilecek

white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;

https://developers.google.com/web/updates/2018/09/inside-browser-part3 (Text Line Wrap)

6. Paint

DOM , computed style ve Layout bilgileri bulunuyor ama hala sayfa rendering(ekran çizimi) için hazır değildir. Çünkü bazı elemanlar üst üste gelebilir . Örneğin bir popup, hover, menu açtığınızda bunlar en üstte görüntülenir. Bunu yapabilmek için çizim yapılacak elemanlara z-index değerleri atanır. Bu aşamada bu elemanların hangi sıra ile çizileceği belirlenerek bir sıraya konulur.

Aşağıdaki resimde gösterildiği gibi bu aşamada (paint records) boyama kayıtları oluşturulur.

https://developers.google.com/web/updates/2018/09/inside-browser-part3 (Paint Records)

7. Compositing

Ana akışı anlatırken bu compositing, rasterization yapısından bahsetmemiştik. Bu kısım painting işleminin içerisinde de düşünebilir. Her neyse artık elimizde çizim için her türlü bilgi var ve bu bilgilerin rasterize edilerek pixel lere dönüştürülmesi lazım.

Burda bazı işlemleri daha hızlı yapabilmek için ;

Scroll
Animation
Ekran içerisinde Drag-Drop

Bu ekran parçalarını Layer halinde rasterize eder. Buna ara bir adım da diyebiliriz. Örneğin Chrome DevTools içerisinde Layers tabına bastığınızda ilgili katmanları görebilirsiniz.

Main Thread, ekrana çizilecek elemanların, painting record hangi layer içerisinde olacağını hesaplar örneğin Slide Menu bir Layer, Scrolling Area ayrı bir Layer gibi..

https://developers.google.com/web/updates/2018/09/inside-browser-part3 (Layer Tree)

Layer ağacı ve boyama sırası oluşturulduktan sonra Main Thread → bu bilgileri → Compositor Thread geçirir. Compositor Thread bu bilgiler doğrultusunda ekranı rasterization tile bölerek render edilmesi için bu bilgileri → Raster Thread geçirir. Raster Thread bu bilgiler ile GPU rendering işlemlerini çalıştırır.