Diller

Kritik Oluşturma Yolu

Tarayıcının baytlardan görünür piksellere uzanan adım adım işlem hattı — DOM, CSSOM, render ağacı, düzen ve boyama — CSS ile JavaScript'in oluşturmayı neden engellediği, üç optimizasyon aracı ve bu yolun FCP, LCP ve Googlebot oluşturma sürecini nasıl etkilediği. Oluşturmayı engelleyen kaynakların merkezi.

İlk yayın tarihi: 26 Haz 2026 · Son güncelleme: 9 Ağu 2026 · Advanced
Diller
AIYazanAI v2

Kritik oluşturma yolu (CRP), tarayıcının ilk pikseli boyayabilmeden önce bağımlılık sırasına göre yaptığı çalışmadır: HTML'yi DOM olarak ayrıştırır, CSS'yi CSSOM olarak ayrıştırır, ikisini bir render ağacında birleştirir, düzeni hesaplar ve ardından boyama yapar. Bu, katı ve tek seferlik bir zamanlama değil, yararlı bir zihinsel modeldir. İki unsur yolu farklı biçimlerde engeller: CSS, geçerli olduğunda boyamayı engeller (CSSOM oluşturulana kadar tarayıcı oluşturma yapmaz); senkron JavaScript ise DOM ayrıştırmasını engeller (ayrıştırıcı her betikte tamamen durur). CRP'yi optimize etmek üç değişkeni en aza indirmek anlamına gelir: kritik kaynakların sayısı, kritik yol uzunluğu (ağ gidiş-dönüşleri) ve kritik baytlar. FCP, CRP'nin tamamlanmasını izleyen bir kilometre taşıdır, ancak tek başına tam bir teşhis değildir; uzun bir CRP, LCP'yi de geciktirebilir ve her ikisi de Core Web Vitals açısından önem taşır. Bu yol Googlebot için de önemlidir: Web Rendering Service, durum bilgisi tutmayan ve soğuk önbellekle çalışan başsız Chromium kullanır. Bu nedenle engelleyici kaynaklar, gerçek bir tarayıcıya benzer biçimde onun oluşturma sürecini de yavaşlatır; ancak kullanıcılarla tam eşdeğerlik ve sıralama etkisi yalnızca bundan kanıtlanamaz. Kritik CSS/JS robots.txt içinde engellenmemelidir. Bu merkez, işlem hattını açıklar ve oluşturmayı engelleyen kaynaklara yönlendirir.

TL;DR — Kritik oluşturma yolu, tarayıcının baytlardan ilk boyamaya uzanan işlem hattıdır: HTML → DOM, CSS → CSSOM, DOM + CSSOM → render tree → layout → paint. Birbirinden farklı iki engel vardır: CSS oluşturmayı engeller (CSSOM oluşturulana kadar boyama yapılmaz), senkron JavaScript ise DOM oluşturmayı engeller (ayrıştırıcı her betikte durur). Üç değişkeni en aza indirerek optimize edin: kritik kaynaklar, kritik yol uzunluğu (gidiş-dönüşler) ve kritik baytlar. FCP, CRP’nin tamamlanmasını izler (tam bir teşhis değil, bir kilometre taşıdır); TTFB ile FCP arasındaki büyük fark, oluşturmayı engelleyen varlıklara işaret eder ve uzun bir CRP, LCP’yi de geciktirebilir. Googlebot’un Web Rendering Service hizmeti, durum bilgisi tutmayan ve fiilen soğuk önbellekle çalışan başsız Chromium kullanır. Bu nedenle engelleyici kaynaklar, gerçek bir tarayıcıyı yavaşlattıkları gibi onun oluşturma sürecini de yavaşlatır; kritik CSS/JS de robots.txt içinde engellenmemelidir. Kullanılabilecek araçlar: kritik CSS’yi satır içine alma, kritik olmayan CSS’yi medya sorgularıyla eşzamansız yükleme, JS için defer ve preload (yalnızca kritik yolda bulunduğunu doğruladığınız kaynaklar için).

Beş adımlı işlem hattı (baytlardan piksellere)

Statik HTML sayfasından ağır bir JS uygulamasına kadar her sayfa, bağımlılık sırasına göre aynı açıklayıcı modelden geçer: Her adım kendinden öncekine bağlıdır. Ancak tarayıcılar bunu kelimenin tam anlamıyla beş katı ve tek seferlik aşama olarak çalıştırmaz. Baytlar geldikçe HTML aşamalı biçimde ayrıştırılıp oluşturulur; motorlar yeni HTML, CSS veya DOM değişiklikleri geldikçe bu çalışmaların bazı bölümlerini işlem hattına alabilir, örtüştürebilir ya da yeniden çalıştırabilir. Bu modeli, garanti edilmiş evrensel bir motor zamanlaması olarak değil, bağımlılıkları anlamaya yarayan zihinsel bir model olarak değerlendirin.

1. HTML → DOM. web.dev, nesne modeli oluşturma sürecini “Bytes → characters → tokens → nodes → object model.” şeklinde açıklar. Tarayıcı “reads the raw bytes of HTML off the disk or network, and translates them to individual characters,” ardından bunları belirteçlere ayırır, belirteçleri nesnelere dönüştürür ve bir ağaçta birbirine bağlar. “The final output of this entire process is the Document Object Model (DOM) of our simple page, which the browser uses for all further processing.”

2. CSS → CSSOM. CSS tamamen aynı yolu izler: “The CSS bytes are converted into characters, then tokens, then nodes, and finally they are linked into a tree structure known as the ‘CSS Object Model’ (CSSOM).” En önemlisi, “The CSSOM and DOM are independent data structures”; bunlar paralel olarak oluşturulan iki ayrı ağaçtır.

3. DOM + CSSOM → render tree. “The DOM and CSSOM trees combine to form the render tree,” ve bu ağaç “captures all the visible DOM content on the page.” display: none ile visibility: hidden arasındaki fark da burada önem kazanır: display: none, öğeyi render tree’den tamamen kaldırır; visibility: hidden ise öğeyi ağaçta tutar (öğe layout içinde hâlâ yer kaplar) fakat hiçbir şey çizmez.

4. Layout. “Layout computes the exact position and size of each object.” Bunun çıktısı, “a ‘box model,’ which precisely captures the exact position and size of each element within the viewport.”

5. Paint. “The last step is paint, which takes in the final render tree and renders the pixels to the screen.”

6. Composite ve display. Boyanmış katmanlar birleştirilir (composited) ve sonuç ekrana çizilir; pikselleri gerçekten görünür kılan adım budur. Bazı CSS özellikleri (transform ve opacity gibi), layout veya paint işlemleri tekrarlanmadan yalnızca bu adımı yeniden çalıştırabilir. Bu nedenle bunları canlandırmak daha düşük maliyetlidir. Evidence for this claim The browser constructs the DOM and CSSOM, combines them into a render tree, performs layout, and paints pixels. Scope: web.dev explanation of the browser's critical rendering path. Confidence: high · Verified: web.dev: Constructing the object model

Kritik oluşturma yolu, bu işlem hattının ilk boyamadan önce tamamlanması gereken bölümüdür. web.dev’in ifadesiyle bunu optimize etmek, “all about understanding what happens in these intermediate steps between receiving the HTML, CSS, and JavaScript bytes and the required processing to turn them into rendered pixels.”

İki tür engelleme, iki farklı mekanizma

Çoğu SEO yazısının bulanıklaştırdığı bu ayrımın tam olarak doğru anlaşılması önemlidir.

CSS, geçerli olduğunda oluşturmayı (boyamayı) engeller. “By default, CSS is treated as a render-blocking resource, which means that the browser won’t render any processed content until the CSSOM is constructed.” Hem HTML hem de CSS oluşturmayı engeller; tarayıcı, hem DOM’ye hem de CSSOM’ye sahip olana kadar oluşturmayı bekletir. Bu durum, mevcut ortamda gerçekten geçerli olan stil sayfaları için geçerlidir. media koşulu eşleşmeyen bir <link> (örneğin normal ekran ziyaretinde media="print") oluşturmayı engellemez; ancak tarayıcı dosyayı yine de indirir. Geçerlilik yükleme anında sabitlenmez: İlk oluşturmayı engellemeyen bir stil sayfası, medya koşulu, viewport veya DOM değiştiğinde daha sonra uygulanmaya başlayabilir ve yeni bir style/layout/paint turunu tetikleyebilir. Dolayısıyla <head> içindeki tek bir yavaş ve geçerli stil sayfası bile ilk boyamanın tamamını rehin alır. İnsanların unuttuğu nokta budur: Betiklere takılıp CSS’yi göz ardı ederler.

JavaScript, DOM oluşturmayı (ayrıştırmayı) engeller. Google’ın PageSpeed belgelerine göre “whenever the parser encounters a script it has to stop and execute it before it can continue parsing the HTML,” ve “in the case of an external script the parser is also forced to wait for the resource to download.” Sonuç olarak “By default JavaScript blocks DOM construction and thus delays the time to first render.” Bununla birlikte, ayrıştırıcının durması ağın boşta kaldığı anlamına gelmez. Tarayıcılar, ana ayrıştırıcı bir betikte takılıyken yaklaşan kaynakları (görseller, diğer betikler ve stil sayfaları) keşfedip getirmeyi sürdüren ikincil bir preload tarayıcısı çalıştırır. Engeli gidermek için async/defer kullanılır; ancak async yalnızca indirme engelini kaldırır. Betik geldiğinde yine ana iş parçacığında çalışır. Bu nedenle ayrıştırmanın bitmesini bekleyen ve sırayı koruyan defer, CRP açısından genellikle daha güvenlidir. Evidence for this claim CSS is render-blocking by default, while parser-blocking scripts stop DOM construction until execution completes. Scope: Default stylesheet and synchronous script behavior in the critical rendering path. Confidence: high · Verified: web.dev: Render-blocking CSS web.dev: Adding interactivity with JavaScript

Üç optimizasyon aracı

web.dev, CRP optimizasyonunu üç değişkenin en aza indirilmesi olarak çerçeveler: “To deliver the fastest possible time to first render, we need to minimize three variables: The number of critical resources. The critical path length. The number of critical bytes.” “A critical resource is a resource that could block initial rendering of the page.”

  • Kritik kaynakların sayısını azaltın — bunları ortadan kaldırın, indirmelerini erteleyin veya eşzamansız olarak işaretleyin. İlk boyamadan önce tamamlanması zorunlu olan daha az kaynak bırakın.
  • Kritik yol uzunluğunu azaltın — bu uzunluk “a function of the dependency graph between the critical resources.” Zinciri getirmek için gereken ağ gidiş-dönüşlerini azaltın.
  • Kritik baytları azaltın — “the fewer critical bytes the browser has to download, the faster it can process content.” Küçültün, sıkıştırın ve bölün.

Pratikte bunun anlamı şudur: Kritik (ekranın üst kısmındaki) CSS’yi <head> içinde satır içine alın ve tam stil sayfasını eşzamansız yükleyin; kritik olmayan CSS’nin kapsamını medya sorgularıyla belirleyin (<link rel="stylesheet" media="print"> indirilir ancak boyamayı engellemez); zorunlu olmayan JavaScript için defer kullanın ve gerekeceğini bildiğiniz kaynakları preload edin. Bu, Ahrefs LCP rehberimde verdiğim LCP tavsiyesinin aynısıdır: “you want to rearrange the order in which the resources are downloaded and processed”. Kritik CSS’yi satır içine almak da “takes the part of the CSS needed to load the content users see immediately and then applies it directly into the HTML.” Buna yalnızca “kritik oluşturma yolu” adını vermemiştim; altta yatan mekanizma budur.

preload ile fetchpriority farklı işler yapar; ikisini birbirine karıştırmayın. preload, bir kaynağı normalde keşfedileceği zamandan önce getirmeye zorlar. Bu, HTML ayrıştırıcısının önceden göremediği, CSS veya JavaScript içinde gizli kaynaklar için yararlıdır. fetchpriority hiçbir şeyi getirmez; yalnızca tarayıcının zaten yapacağı bir isteğin öncelik ipucunu değiştirir. Hiçbiri bedelsiz değildir: Yanlış URL, as türü veya kimlik bilgisi moduyla kullanılan bir preload boşa gidebilir ya da tarayıcının zaten yapacağı isteği yineleyebilir. Çok fazla kaynağı yüksek öncelikli işaretlemek de sıralama avantajını ortadan kaldırır; tarayıcı, CDN ve protokol davranışları gerçek faydayı etkiler. preload özelliğini yalnızca waterfall ile test ettiğiniz sayfanın kritik yolunda bulunduğunu doğruladığınız bir kaynak için kullanın ve kazanç varsaymak yerine önceki ve sonraki durumu başka bir trace ile doğrulayın.

Core Web Vitals bağlantısı (SEO açısından)

CRP’nin yalnızca geliştiricileri ilgilendirmemesinin nedeni budur.

  • FCP, CRP’nin tamamlanmasını izler; ancak tam bir teşhis değil, bir kilometre taşıdır. First Contentful Paint, tarayıcı ilk içeriği boyadığında tetiklenir. Bu nedenle uzun bir kritik oluşturma yolu genellikle geç FCP olarak görünür. Ancak FCP yalnızca gözlemlenen bir boyama olayıdır; gecikmeye işlem hattının hangi aşamasının yol açtığını tek başına göstermez ve hızlı FCP, her bağımlılığın sorunsuz tamamlandığını garanti etmez. Geç FCP’yi yoldaki bir şeyin yavaş olduğuna dair sinyal olarak değerlendirin, ardından ne olduğunu trace ile bulun.
  • LCP gecikmeyi devralabilir. Abby Hamilton (Dentsu) bunu iyi ifade ediyor: “Optimizing the critical rendering path will typically have the largest impact on Largest Contentful Paint (LCP) since it’s specifically focused on how long it takes for pixels to appear on the screen.” web.dev şu teşhis ipucunu verir: “A large delta between TTFB and FCP could indicate that the browser needs to download a lot of render-blocking assets.” Bu fark, temel neden tespiti değil, CRP için bir ön kontroldür. Bir şeyi düzeltmeden önce waterfall veya trace ile doğrulayın.
  • TBT/INP, JavaScript’in etkisini hisseder. Kritik yoldaki betikler ana iş parçacığı için yarışır; boyamadan sonraki uzun görevler etkileşimi olumsuz etkiler.

Hem LCP hem de FCP, tarayıcının yolu ne kadar hızlı tamamladığından etkilenir. LCP, Google’ın sıralama sinyali olarak kullandığı bir Core Web Vital’dır; tarayıcı iç işleyişiyle arama arasındaki bağlantı budur. Bununla birlikte saha sonuçları ve belirli sıralama etkileri yalnızca hızlı bir laboratuvar trace’iyle değil, kendi kanıtlarıyla (CrUX/Search Console verileri) değerlendirilmelidir.

Googlebot nasıl etkilenir?

Google’ın Web Rendering Service (WRS) hizmeti, insanların kafasını karıştıran bölümdür. Google “processes JavaScript web apps in three main phases: Crawling, Rendering, Indexing,” ve “Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript”; bunun için “an evergreen version of Chromium.” kullanır. Gerçek Chrome ile aynı oluşturma motorudur. Bu nedenle engelleyici kaynaklar, gerçek bir tarayıcıyı yavaşlattıkları gibi Googlebot’un oluşturma sürecini de yavaşlatır. Bu, ortak mimariden çıkarılan makul bir sonuçtur; her gecikmenin Googlebot’u her kullanıcıyla tamamen aynı biçimde etkilediği veya doğrudan dizine ekleme ya da sıralama cezasına dönüştüğü iddiası değildir. Google bu düzeyde bir eşdeğerlik yayımlamamıştır ve belirli bir sayfa için doğrulama yalnızca CRP denetimiyle değil, Search Console / dizine ekleme kanıtlarıyla yapılmalıdır.

İçselleştirilmesi gereken üç sonuç:

  • Oluşturma kuyruğu gecikme ekler. Sayfalar oluşturma kuyruğunda “a few seconds, but it can take longer than that” bekler. Yavaş bir CRP bu gecikmeyi büyütür.
  • WRS durum bilgisi tutmaz ve fiilen soğuk önbellekle çalışır. JavaScript SEO rehberimde belirttiğim gibi, “Google loads each page stateless like it’s a fresh load.” Google’ın kendi belgeleri de WRS’nin sayfa yüklemeleri arasında durum saklamadığını ve “may ignore caching headers,” olduğunu doğrular; bu durum “may lead WRS to use outdated JavaScript or CSS resources.” Dolayısıyla ağır bir kritik yolu sıcak önbellekle gizleyemezsiniz; her oluşturma esasen ilk ziyaret gibidir. (Bu, “Google kaynakları önbelleğe alır, dolayısıyla CRP yalnızca ilk ziyarette önemlidir” efsanesini de çürütür.)
  • Kritik kaynakları robots.txt içinde engellemeyin. WRS’nin doğru oluşturma yapabilmesi için CSS ve JS’nize erişmesi gerekir. JavaScript SEO rehberimde ifade ettiğim gibi: “Don’t block access to resources if they are needed to build part of the page or add to the content.” Bunları engellerseniz oluşturmayı tamamen bozabilirsiniz; Google bozuk bir sayfa görür.

Bing’in eşdeğer bir “critical rendering path” belge dizisi yoktur; ancak bu ilke tarayıcı tabanlı tüm tarayıcı botları için evrenseldir. Bingbot’un JS oluşturma bütçesi Google’ınkinden daha kısıtlıdır; dolayısıyla yalın bir kritik yol, Bing’in keşif sürecinde daha fazla önem taşır, daha az değil.

Bir uç durum: Erken boyama, içeriğinizin hazır olduğunu kanıtlamaz

CRP modeli ekrana bir şey getirilmesini açıklar; bu şeyin gerçek içeriğiniz olacağını garanti etmez. İstemci tarafında oluşturulan uygulamalar çoğu zaman bir kabuğu (iskelet, yükleme durumu veya boş düzen) hızla boyayıp FCP’yi karşılar. Okurların ve Googlebot’un gerçekten önemsediği içerik ise bir JavaScript paketinin indirilmesini, çalıştırılmasını ve veri getirmesini hâlâ bekliyor olabilir. Böyle bir sayfadaki hızlı FCP yanıltıcı bir sinyaldir: Kritik oluşturma yolu içerik için değil, kabuk için tamamlanmıştır.

Sunucu tarafında oluşturulan veya statik olarak üretilen HTML, anlamlı içerik daha sonra eklenmek yerine başlangıç işaretlemesinde zaten bulunduğundan bu sorunu büyük ölçüde önler. JS ağırlıklı bir sayfayı denetliyorsanız FCP’de durmayın: O zaman damgasında ekranda gerçekte neyin göründüğünü (filmstrip veya trace bunu gösterir) birincil içeriğin görünür olduğu anla karşılaştırın ve bunları iki ayrı soru olarak ele alın.

SEO uzmanları CRP ile gerçekte nerede karşılaşır?

En yaygın temas noktası, PageSpeed Insights / Lighthouse içindeki “Eliminate render-blocking resources” denetimidir. Abby Hamilton iş akışını şöyle açıklar: “navigate to ‘Eliminate render-blocking resources’ under ‘Diagnostics,’ and expand the content to see a list of first-party and third-party resources blocking the first paint.” WebPageTest’te waterfall’u inceleyerek “Start Render” çizgisinden önce yüklenenleri bulun. Chrome DevTools’taki Coverage sekmesi ise erteleyebileceğiniz kullanılmayan CSS/JS’yi gösterir. Tek bir trace konusunda dikkatli olun: Üçüncü taraf bağlantı kurulumu, onaya bağlı betikler, service worker veya sıcak ve soğuk önbellek farkı, çalıştırmalar arasında neyin ne zaman keşfedildiğini değiştirebilir. Tek bir laboratuvar çalıştırması, her ziyaretçinin göreceklerinin garantisi değil, bir örnektir.

İlgili konular — sırada ne var?

Bu sayfa, oluşturmayı engelleyen kaynaklarla ilgili çalışmaların merkezidir. Ayrıntılı inceleme bunun altında yer alır:

  • Oluşturmayı engelleyen kaynaklar — bu sayfanın pratik ve denetim odaklı tamamlayıcısıdır: PageSpeed Insights, Lighthouse ve WebPageTest’te engelleyici CSS ile JavaScript’i tam olarak nasıl bulacağınızı; async ile defer arasındaki ayrıntılı farkı; kritik CSS’yi satır içine almayı; stil sayfalarının kapsamını medya sorgularıyla belirlemeyi ve “Eliminate render-blocking resources” uyarısını adım adım gidermeyi açıklar.

Bu yolun etkilediği metrikler için Core Web Vitals, Largest Contentful Paint (LCP) ve First Contentful Paint (FCP) sayfalarına bakın. Googlebot’un oluşturma adımının daha büyük işlem hattında nasıl çalıştığını öğrenmek için JavaScript SEO ve Arama Nasıl Çalışır? konu kümesine bakın.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.