INP Presentation Delay: DOM Boyutu, Layout İşlemi ve Rendering Optimizasyonu

Presentation delay kaynaklı Interaction to Next Paint (INP) sorunları

Bu sayfa, Interaction to Next Paint (INP) serimizin bir parçasıdır. INP, bir kullanıcı etkileşiminden sonraki görsel güncellemeye kadar geçen toplam süreyi ölçer. Presentation delay, input delay ve processing time'ın ardından gelen INP'nin üçüncü ve son aşamasıdır. INP konusunda yeniyseniz, önce INP sorunlarını tespit etme ve düzeltme rehberimizi okuyun.

Bu makalede presentation delay'e odaklanıyoruz: neyin neden olduğu, Interaction to Next Paint'i nasıl etkilediği ve INP puanlarınızı iyileştirmek için nasıl optimize edileceği.

Kısaca: Interaction to Next Paint (INP), bir kullanıcının bir sayfa ile etkileşime girdikten sonra görsel bir değişikliği görmesinin ne kadar sürdüğünü ölçer. Bu INP 3 bileşene ayrılabilir: "input delay", "processing time" ve "presentation delay."

Presentation delay, toplam INP'ye en büyük katkıda bulunan bileşendir ve ortalama olarak toplam INP süresinin yaklaşık %42'sini oluşturur. Bu, rendering pipeline'ınızı optimize etmenin ve HTML yapınızı sadeleştirmenin web sitenizin INP puanını önemli ölçüde etkileyebileceği anlamına gelir.

Presentation Delay: Hiç bir düğmeye tıklayıp sonucu görmek için neden bir an fazla beklediğinizi merak ettiniz mi? İşte bu, Interaction to Next Paint (INP) in iş başındaki halidir. Presentation delay, etkileşim sürecinin son adımıdır; tıklamanız işlendikten sonra ancak herhangi bir görsel değişiklik görmeden önce devreye girer.

Presentation delay'i anlamak

Presentation, bir etkileşimin son aşamasıdır. Presentation delay, tarayıcının etkileşimi takip eden görsel güncellemeleri render etmesi için geçen süreyi temsil eder. Presentation delay, etkileşimin event handler'ları çalışmayı bitirdiğinde başlar ve bir sonraki kare (görsel değişiklikleri içeren) boyanana kadar devam eder. Presentation delay, layout'un karmaşıklığı, DOM'un boyutu ve gereken rendering işinin miktarı gibi çeşitli faktörlerden etkilenebilir.

Interaction to Next Paint (INP) 3 alt bölüme ayrılabilir: "Input Delay", "Processing Time" ve "Presentation Delay".

Presentation delay ve INP

Presentation delay, INP'nin son aşamasıdır. Ortalama olarak, presentation delay toplam INP süresinin yaklaşık %42'sini oluşturur ve bu da onu yavaş etkileşimlere en büyük katkıda bulunan tek bileşen yapar.

CoreDash'ta her saat milyonlarca Core Web Vitals veri noktası topluyoruz. Bu verilere göre, presentation delay Interaction to Next Paint'in %42'sini oluşturur. Bu, processing time'dan (%40) ve input delay'den (%18) daha fazladır. En büyük katkıda bulunan olmasına rağmen, presentation delay genellikle optimize edilmesi en zor aşamadır çünkü uygulama kodunuz yerine tarayıcının rendering pipeline'ını içerir.

Presentation delay örneği: Telefonunuzda bir e-ticaret sitesinde yeni bir çift ayakkabı aradığınızı hayal edin. Daha fazla detay görmek için bir ürün görselini tıklıyorsunuz. Ancak telefonunuz biraz eski ve yetişmekte zorlanıyor. Görsele tıklıyorsunuz (Etkileşim). Telefon, isteği işlemek ve ekranı güncellemek için biraz zaman alıyor (Processing Time). Web sitesinin daha büyük görsel ve detaylarla yeni sayfayı render etmesi gerekiyor. Son olarak, yeni ürün detaylarının ve görselin ekranınızda görünmesi fark edilir bir süre alıyor (Presentation Delay). INP'deki bu gecikme kullanıcılar için sinir bozucu olabilir ve bu yüzden düzeltmek önemlidir.

Yüksek presentation delay'e ne sebep olur?

Presentation delay, event handler'larınız bittikten sonra ve pikseller ekranda görünmeden önce tarayıcının yaptığı tüm işi kapsar. Bu; stil yeniden hesaplama, layout hesaplama, painting ve compositing işlemlerini içerir. Yüksek presentation delay'e birçok faktör katkıda bulunur:

Büyük DOM boyutu

Büyük veya derin iç içe geçmiş DOM, yüksek presentation delay'in en yaygın nedenlerinden biridir. Tarayıcının bir etkileşimden sonra sayfanın görsel durumunu her güncellemesi gerektiğinde, stilleri yeniden hesaplaması, layout'u hesaplaması ve etkilenen öğeleri yeniden boyaması gerekir. Bu adımların her birinin maliyeti, etkilenen DOM düğümlerinin sayısıyla orantılı olarak artar.

Google, DOM'unuzu 1.400 öğenin altında, maksimum 32 seviye derinlikte ve üst düğüm başına en fazla 60 alt öğeyle tutmanızı önerir. DOM'unuz bu eşikleri aştığında, tarayıcı her etkileşimden sonra stil yeniden hesaplama ve layout hesaplama için önemli ölçüde daha fazla zaman harcar.

Şu senaryoyu düşünün: bir kullanıcı, bir container öğesinde CSS sınıfını değiştiren bir düğmeye tıklıyor. Bu container'ın 5.000 alt düğümü varsa, tarayıcı yalnızca birkaç öğe görsel olarak değişse bile potansiyel olarak hepsinin stillerini yeniden hesaplamak zorundadır. Bu stil yeniden hesaplaması, bir sonraki boyamadan önce senkron olarak gerçekleşir ve doğrudan presentation delay'i artırır.

DOM'unuzu azaltmak için belirli teknikler hakkında aşırı DOM boyutunu düzeltme rehberimizi okuyun.

Aşırı layout işlemi

Layout ("reflow" olarak da bilinir), tarayıcının sayfadaki her görünür öğenin konumunu ve boyutlarını hesapladığı süreçtir. DOM'u değiştiren veya geometriyi etkileyen CSS özelliklerini (width, height, margin, padding, top, left) değiştiren bir etkileşimden sonra, tarayıcı güncellenen kareyi boyamadan önce layout işlemi gerçekleştirmelidir.

İki kalıp, presentation delay için özellikle zararlıdır:

Zorunlu senkron layout, JavaScript'in layout'u geçersiz kılan bir DOM değişikliğinden sonra bir layout özelliğini (offsetHeight veya getBoundingClientRect() gibi) okuduğunda gerçekleşir. Tarayıcı, doğru bir değer döndürmek için event handler'ınız içinde senkron olarak layout gerçekleştirmek zorunda kalır. Bu layout işlemi daha sonra processing time'ın bir parçası olur, ancak sonraki DOM değişiklikleri tarafından tetiklenen ek layout işlemi presentation delay'in bir parçası olur.

Layout thrashing, bir döngü içinde DOM'a yazma ve ardından layout özelliklerini okuma kalıbının tekrarlanmasıdır. Her okuma, tarayıcıyı layout'u yeniden hesaplamaya zorlar ve her yazma layout'u tekrar geçersiz kılar. Bu, etkileşim başına onlarca hatta yüzlerce gereksiz layout hesaplamasına neden olabilir. İşte bir layout thrashing örneği ve nasıl düzeltileceği:

// BAD: Layout thrashing inside a loop
function resizeItems() {
  const items = document.querySelectorAll('.item');
  items.forEach(item => {
    // Read (forces layout)
    const parentWidth = item.parentElement.offsetWidth;
    // Write (invalidates layout)
    item.style.width = parentWidth + 'px';
  });
}

// GOOD: Batch reads, then batch writes
function resizeItems() {
  const items = document.querySelectorAll('.item');
  // Read all values first
  const widths = Array.from(items).map(
    item => item.parentElement.offsetWidth
  );
  // Then write all values
  items.forEach((item, i) => {
    item.style.width = widths[i] + 'px';
  });
}

Single Page Application'larda client-side rendering

HTML'in client-side rendering'i, özellikle Single Page Application'larda (SPA'larda) presentation delay'i önemli ölçüde etkileyebilir. Bir kullanıcı etkileşimi rota değişikliği veya büyük bir UI güncellemesi tetiklediğinde, SPA framework'ü şunları yapmalıdır:

1. Neyin değiştiğini belirlemek için virtual DOM diffing algoritmasını çalıştırmak
2. Ortaya çıkan DOM mutasyonlarını gerçek DOM'a uygulamak
3. Etkilenen tüm öğeler için stil yeniden hesaplama ve layout tetiklemek
4. Güncellenen kareyi boyamak

React uygulamalarında, virtual DOM reconciliation süreci processing time'ın bir parçasıdır, ancak ortaya çıkan DOM mutasyonları ve bunların rendering maliyeti presentation delay'e dahildir. Bileşen ağacınız ne kadar çok DOM düğümü üretirse, reconciliation ve sonraki rendering işlemi o kadar pahalı olur.

React ve Next.js uygulamalarında bunu azaltmak için:

• Aynı props'ları alan alt bileşenlerin gereksiz yeniden render'larını önlemek için React.memo() kullanın.
• Pahalı yeniden render'ları tetikleyen değerler için useDeferredValue() kullanarak React'in daha acil güncellemelere öncelik vermesini sağlayın.
• Bileşen ağaçlarını sığ tutun. Derin iç içe geçmiş bileşen hiyerarşileri derin iç içe geçmiş DOM üretir ve bu da hem reconciliation hem de tarayıcı rendering maliyetini artırır.
• Uzun listeler için sanallaştırma kütüphaneleri (react-window veya @tanstack/react-virtual gibi) kullanarak DOM'un yalnızca görünür öğeleri içermesini sağlayın.

Presentation delay'i azaltmak

Artık nedenleri anladığımıza göre, presentation delay'i en aza indirmek için en etkili stratejileri inceleyelim.

DOM boyutunu en aza indirin

Presentation delay için en etkili optimizasyon, DOM'unuzu küçük tutmaktır. İşte pratik teknikler:

• Kullanılmayan HTML öğelerini, özellikle derin iç içe geçmiş wrapper div'leri kaldırın.
• Uzun listeler için liste sanallaştırması kullanın (yalnızca görünür öğeleri ve küçük bir tampon bölgeyi render edin).
• Mümkün olduğunda derin iç içe geçmiş yapıları düzleştirin.
• Layout için iç içe geçmiş div'ler yerine CSS Grid ve Flexbox kullanın.

// Virtualize long lists to reduce DOM size
// Before: 10,000 items in the DOM
<ul>
  {allItems.map(item => <li key={item.id}>{item.name}</li>)}
</ul>

// After: only visible items in the DOM (using react-window)
import { FixedSizeList } from 'react-window';

<FixedSizeList
  height={600}
  itemCount={allItems.length}
  itemSize={50}
  width="100%"
>
  {({ index, style }) => (
    <div style={style}>{allItems[index].name}</div>
  )}
</FixedSizeList>

Ekran dışı içeriği gecikmeli render etmek için content-visibility kullanın

CSS content-visibility özelliği, tarayıcıya kullanıcı yakınına kaydırana kadar ekran dışı içeriğin render'lanmasını atlamasını söyler. Bu, stil yeniden hesaplama ve layout kapsamını sayfanın görünür bölümüyle sınırlayarak etkileşimler sırasındaki rendering iş yükünü azaltır.

/* Apply content-visibility to sections below the fold */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

/* Apply to individual items in long lists */
.list-item {
  content-visibility: auto;
  contain-intrinsic-size: auto 80px;
}

contain-intrinsic-size özelliği, tarayıcının içeriği render etmeden kaydırma çubuğu boyutunu doğru hesaplayabilmesi için tahmini bir yükseklik sağlar. Bu, kullanıcı kaydırdığında ve içerik görünür hale geldiğinde layout kaymalarını önler.

Rendering maliyetini azaltan daha fazla CSS optimizasyon stratejisi için kullanılmayan CSS'i kaldırma rehberimize bakın.

Etkileşimler tarafından tetiklenen layout işlemini en aza indirin

Etkileşimler tasarlarken, layout tetiklemeyen CSS özelliklerini tercih edin. transform ve opacity gibi özellikler, layout veya paint tetiklemeden GPU compositor tarafından işlenebilir. top, left, width veya height animasyonu yerine transform: translate() ve transform: scale() kullanın.

Tarayıcıya bir öğenin animasyonlu olacağını belirtmek için CSS will-change özelliğini kullanın. Bu, tarayıcının öğe için ayrı bir compositor katmanı oluşturmasına olanak tanır ve render'ını sayfanın geri kalanından izole eder:

/* Promote elements to their own compositor layer */
.animated-element {
  will-change: transform, opacity;
}

/* Toggle visibility with opacity instead of display */
.modal {
  opacity: 0;
  pointer-events: none;
  transform: translateY(10px);
  transition: opacity 0.2s, transform 0.2s;
}

.modal.active {
  opacity: 1;
  pointer-events: auto;
  transform: translateY(0);
}

Uzun presentation delay'leri tespit etmek

Uzun presentation delay'leri tespit etmek için Chrome'un performans profil aracını kullanabilirsiniz. DevTools'u açın (Ctrl+Shift+I), Performance sekmesine gidin, kayda başlayın ve sayfa ile etkileşime geçin.

Ardından bir etkileşimin zaman çizelgesini analiz edebilir ve presentation delay dahil olmak üzere farklı aşamaları görselleştirebilirsiniz. Event handler'lar bittikten sonra gerçekleşen rendering güncellemelerini inceleyerek, uzun bir presentation delay'e katkıda bulunan darboğazları belirleyebilirsiniz. Zaman çizelgesinde büyük "Recalculate Style", "Layout" ve "Paint" girişlerini arayın. Bunlar, tarayıcının presentation delay aşamasında yaptığı işi temsil eder.

RUM verileriyle presentation delay'i tespit etmek

Long Animation Frames (LoAF) ile presentation delay'i ölçmek

Long Animation Frames (LoAF) API'si, kullanıcı etkileşimleri sırasında meydana gelenler dahil olmak üzere rendering gecikmelerinin nedenleri hakkında ayrıntılı bilgiler sağlar. API, processing time'ı presentation delay'den ayırmanıza ve hangi script'lerin rendering darboğazlarına katkıda bulunduğunu belirlemenize yardımcı olan zamanlama verileri sunar.

Presentation delay'i anlamak için temel LoAF özellikleri şunlardır:

• renderStart: tarayıcının rendering aşamasını (stil yeniden hesaplama, layout, paint) başlattığı zaman
• styleAndLayoutStart: stil ve layout hesaplamasının başladığı zaman
• duration: long animation frame'in toplam süresi
• blockingDuration: frame'in ne kadarının script'ler tarafından bloklandığı

Script çalıştırmanın sonu ile frame'in sonu arasındaki fark, saf rendering maliyetini, yani presentation delay'i temsil eder. Bu veriyi nasıl gözlemleyeceğiniz ve kaydedeceğiniz aşağıda gösterilmektedir:

// Measure presentation delay using LoAF API
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 50) {
      const scriptEnd = Math.max(
        ...entry.scripts.map(s => s.startTime + s.duration)
      );
      const presentationDelay = (
        entry.startTime + entry.duration
      ) - Math.max(scriptEnd, entry.renderStart);

      console.log('Presentation delay breakdown:', {
        totalDuration: entry.duration,
        renderStart: entry.renderStart,
        styleAndLayoutStart: entry.styleAndLayoutStart,
        estimatedPresentationDelay: presentationDelay,
        scriptCount: entry.scripts.length
      });
    }
  }
});

observer.observe({
  type: 'long-animation-frame',
  buffered: true
});

CoreDash gibi RUM araçları, LoAF verilerini entegre eder ve script atıf verileri gibi long animation frame'ler hakkında ek bilgiler sağlar. Bu araçlar, hangi script'lerin ve DOM değişikliklerinin rendering gecikmelerine katkıda bulunduğunu anlamanıza yardımcı olur, böylece kod tabanınızı daha iyi yanıt verebilirlik için optimize edebilirsiniz.

Diğer INP aşamalarını keşfedin

Presentation delay, Interaction to Next Paint'in yalnızca bir parçasıdır. INP puanlarınızı tam olarak optimize etmek için diğer iki aşamayı da ele almalısınız:

• Input Delay: Event handler'ların çalışmaya başlamasından önceki bekleme süresini en aza indirin. Input delay, toplam INP süresinin yaklaşık %18'ini oluşturur.
• Processing Time: Toplam INP süresinin yaklaşık %40'ını oluşturan event handler çalıştırmasını optimize edin.

Kapsamlı bir teşhis iş akışı için INP sorunlarını bulma ve düzeltme rehberimize bakın. Ek rendering optimizasyon stratejileri için aşırı DOM boyutunu düzeltme ve kullanılmayan CSS'i kaldırma rehberlerimizi inceleyin. Tam genel bakış için INP ana sayfasına dönün.