Sonraki boyamayla etkileşimi optimize edin

Web sitenizin Interaction to Next Paint metriğini nasıl optimize edeceğinizi öğrenin.

Yayınlanma tarihi: 19 Mayıs 2023, Son güncelleme tarihi: 2 Eylül 2025

Interaction to Next Paint (INP), bir sayfanın kullanıcı etkileşimlerine genel olarak yanıt verme oranını değerlendiren kararlı bir Core Web Vitals metriğidir. Bu değerlendirmeyi yapmak için kullanıcının sayfayı ziyaret ettiği süre boyunca meydana gelen tüm uygun etkileşimlerin gecikmesini gözlemler. Nihai INP değeri, gözlemlenen en uzun etkileşimdir (bazen aykırı değerler göz ardı edilir).

İyi bir kullanıcı deneyimi sunmak için web sitelerinin Interaction to Next Paint değerinin 200 milisaniye veya daha az olması gerekir. Kullanıcılarınızın büyük çoğunluğu açısından bu hedefe ulaşmak için mobil ve masaüstü cihazlarda bölümlendirilmiş sayfa yüklemelerinin 75. yüzdelik dilim eşiğini ölçebilirsiniz.

İyi INP değerleri 200 milisaniye veya daha az, kötü değerler 500 milisaniyeden fazla, bu ikisi arasındaki değerler ise iyileştirilmesi gereken değerlerdir.
INP eşikleri

Web sitesine bağlı olarak, etkileşimler az olabilir veya hiç olmayabilir. Örneğin, çoğunlukla metin ve resimlerden oluşan, etkileşimli öğelerin az olduğu veya hiç olmadığı sayfalar. Metin düzenleyiciler veya oyunlar gibi web sitelerinde ise yüzlerce, hatta binlerce etkileşim olabilir. Her iki durumda da INP yüksek olduğunda kullanıcı deneyimi risk altındadır.

INP'yi iyileştirmek zaman ve çaba gerektirir ancak karşılığında daha iyi bir kullanıcı deneyimi elde edersiniz. Bu kılavuzda, INP'yi iyileştirmenin bir yolu ele alınacaktır.

INP'nin düşük olmasına neden olan sorunu bulma

Yavaş etkileşimleri düzeltebilmek için web sitenizin INP'sinin zayıf mı yoksa iyileştirilmesi mi gerektiğini gösteren verilere ihtiyacınız vardır. Bu bilgileri edindikten sonra laboratuvara geçerek yavaş etkileşimleri teşhis etmeye başlayabilir ve çözüme ulaşabilirsiniz.

Sahada yavaş etkileşimleri bulma

İdeal olarak, INP'yi optimize etme yolculuğunuz alan verileriyle başlar. Gerçek Kullanıcı İzleme (RUM) sağlayıcısından alınan alan verileri, en iyi ihtimalle size yalnızca bir sayfanın INP değerini değil, aynı zamanda INP değerinden hangi etkileşimin sorumlu olduğunu, etkileşimin sayfa yükleme sırasında mı yoksa sonrasında mı gerçekleştiğini, etkileşim türünü (tıklama, tuşa basma veya dokunma) ve diğer değerli bilgileri vurgulayan bağlamsal verileri de sağlar.

Saha verilerini almak için bir RUM sağlayıcısı kullanmıyorsanız INP saha verileri kılavuzu, boşlukları doldurmaya yardımcı olması için Chrome Kullanıcı Deneyimi Raporu (CrUX) verilerini görüntülemek üzere PageSpeed Insights'ı kullanmanızı önerir. CrUX, Core Web Vitals programının Google veri kümesidir ve INP dahil milyonlarca web sitesi için metriklerin üst düzey bir özetini sunar. Ancak CrUX, sorunları analiz etmenize yardımcı olmak için genellikle bir RUM sağlayıcıdan alacağınız içerik verisini sağlamaz. Bu nedenle, sitelerin mümkün olduğunda bir RUM sağlayıcı kullanmasını veya CrUX'te bulunanları desteklemek için kendi RUM çözümlerini uygulamasını öneririz.

Laboratuvarda yavaş etkileşimleri teşhis etme

İdeal olarak, yavaş etkileşimleriniz olduğunu gösteren alan verileriniz olduğunda laboratuvarda test yapmaya başlamak istersiniz. Saha verileri olmadığında, laboratuvarda yavaş etkileşimleri belirlemek için bazı stratejiler vardır. Bu stratejiler arasında, yaygın kullanıcı işlemleri akışlarını takip etmek ve bu süreçteki etkileşimleri test etmek yer alır. Ayrıca, kullanıcı deneyiminin bu önemli bölümünde yavaş etkileşimleri belirlemek için sayfa yüklenirken (ana iş parçacığının genellikle en yoğun olduğu zaman) sayfayla etkileşim kurmak da bu stratejiler arasındadır.

Etkileşimleri optimize etme

Yavaş bir etkileşim belirledikten ve laboratuvarda manuel olarak yeniden oluşturduktan sonraki adım, bu etkileşimi optimize etmektir.

Etkileşimler üç alt bölüme ayrılabilir:

  1. Kullanıcı sayfayla etkileşim başlattığında başlayan ve etkileşim için etkinlik geri çağırmaları çalışmaya başladığında sona eren giriş gecikmesi.
  2. Etkinlik geri çağırmalarının tamamlanması için gereken süreden oluşan işleme süresi.
  3. Etkileşimin görsel sonucunu içeren bir sonraki kareyi tarayıcının sunması için geçen süre olan sunum gecikmesi.
Ana mesaj dizisindeki örnek bir etkileşim. Kullanıcı, engelleme görevleri çalışırken giriş yapar. Giriş, bu görevler tamamlanana kadar geciktirilir. Ardından pointerup, mouseup ve tıklama etkinliği işleyicileri çalıştırılır, ardından bir sonraki kare sunulana kadar oluşturma ve boyama işlemleri başlatılır.
Bir etkileşimin yaşam döngüsü. Etkinlik işleyiciler çalışmaya başlayana kadar giriş gecikmesi yaşanır. Bu gecikme, ana iş parçacığındaki uzun süren görevler gibi faktörlerden kaynaklanabilir. Ardından, etkileşimin etkinlik işleyici geri çağırmaları çalıştırılır ve bir sonraki kare sunulmadan önce gecikme yaşanır.

Bu üç alt bölümün toplamı, toplam etkileşim gecikmesini verir. Bir etkileşimin her bir alt bölümü, toplam etkileşim gecikmesine bir miktar katkıda bulunur. Bu nedenle, etkileşimin her bir bölümünü mümkün olduğunca kısa sürede çalışacak şekilde nasıl optimize edebileceğinizi bilmek önemlidir.

Giriş gecikmesini belirleme ve azaltma

Kullanıcı bir sayfayla etkileşimde bulunduğunda bu etkileşimin ilk bölümü giriş gecikmesidir. Sayfadaki diğer etkinliklere bağlı olarak giriş gecikmeleri oldukça uzun olabilir. Bunun nedeni, ana iş parçacığında gerçekleşen etkinlik (komut dosyalarının yüklenmesi, ayrıştırılması ve derlenmesi nedeniyle olabilir), getirme işlemleri, zamanlayıcı işlevleri, hatta hızlı bir şekilde gerçekleşen ve birbiriyle çakışan diğer etkileşimler olabilir.

Bir etkileşimin giriş gecikmesinin kaynağı ne olursa olsun, etkileşimlerin etkinlik geri çağırmalarını en kısa sürede çalıştırmaya başlayabilmesi için giriş gecikmesini minimuma indirmeniz gerekir.

Başlatma sırasında komut dosyası değerlendirmesi ile uzun süren görevler arasındaki ilişki

Sayfa yaşam döngüsünde etkileşimin kritik bir yönü, başlangıç sırasında gerçekleşir. Sayfa yüklenirken başlangıçta oluşturulur ancak bir sayfanın oluşturulmuş olmasının, sayfanın yükleme işleminin tamamlandığı anlamına gelmediğini unutmamak önemlidir. Bir sayfanın tam olarak çalışır hale gelmesi için gereken kaynak sayısına bağlı olarak, kullanıcılar sayfa yüklenirken sayfayla etkileşim kurmaya çalışabilir.

Sayfa yüklenirken bir etkileşimin giriş gecikmesini uzatabilecek unsurlardan biri komut dosyası değerlendirmesidir. Bir JavaScript dosyası ağdan getirildikten sonra, tarayıcının bu JavaScript'i çalıştırabilmesi için yapması gereken işler vardır. Bu işler arasında, söz diziminin geçerli olup olmadığını kontrol etmek için bir komut dosyasını ayrıştırmak, bayt koduna derlemek ve son olarak yürütmek yer alır.

Komut dosyasının boyutuna bağlı olarak bu çalışma, ana iş parçacığında uzun süren görevlere neden olabilir. Bu da tarayıcının diğer kullanıcı etkileşimlerine yanıt vermesini geciktirir. Sayfanızın, sayfa yükleme sırasında kullanıcı girişine yanıt vermeye devam etmesi için sayfa yükleme sırasında uzun süren görevlerin olasılığını azaltmak üzere neler yapabileceğinizi anlamanız önemlidir. Böylece sayfa hızlı kalır.

Etkinlik geri çağırma işlevlerini optimize etme

Giriş gecikmesi, INP'nin ölçtüğü değerin yalnızca ilk kısmıdır. Ayrıca, bir kullanıcı etkileşimine yanıt olarak çalışan etkinlik geri çağırmalarının mümkün olduğunca hızlı bir şekilde tamamlanmasını sağlamanız gerekir.

Ana iş parçacığına sık sık öncelik verin

Etkinlik geri çağırmalarını optimize etmek için en iyi genel tavsiye, bunlarda mümkün olduğunca az işlem yapmaktır. Ancak etkileşim mantığınız karmaşık olabilir ve yapay zekanın yaptığı işi yalnızca kısmen azaltabilirsiniz.

Web sitenizde bu durumun geçerli olduğunu fark ederseniz etkinlik geri çağırmalarındaki işleri ayrı görevlere bölmeyi deneyebilirsiniz. Bu sayede, toplu çalışma ana iş parçacığını engelleyen uzun göreve dönüşmez. Böylece, ana iş parçacığında bekleyecek diğer etkileşimler daha erken çalıştırılabilir.

setTimeout, görevleri bölmenin bir yoludur. Çünkü bu işleve iletilen geri çağırma, yeni bir görevde çalışır. setTimeout ifadesini tek başına kullanabilir veya daha ergonomik bir kullanım için ayrı bir işleve soyutlayabilirsiniz.

Ayrım gözetmeksizin yield etmek, hiç yield etmemekten daha iyidir. Ancak ana iş parçacığına yield etmenin daha ayrıntılı bir yolu vardır. Bu yöntem, yalnızca kullanıcı arayüzünü güncelleyen bir etkinlik geri çağırma işleminden hemen sonra yield etmeyi içerir. Böylece oluşturma mantığı daha erken çalıştırılabilir.

Oluşturma işleminin daha erken gerçekleşmesi için bekleme

Daha gelişmiş bir verim tekniği, etkinlik geri çağırmalarınızdaki kodu, yalnızca bir sonraki kare için görsel güncellemeleri uygulamak üzere gereken mantıkla sınırlayacak şekilde yapılandırmayı içerir. Diğer her şey sonraki bir göreve ertelenebilir. Bu sayede geri çağırmalar hafif ve hızlı kalır. Ayrıca, görsel güncellemelerin etkinlik geri çağırma kodunu engellemesine izin verilmediği için etkileşimlerin oluşturma süresi de kısalır.

Örneğin, siz yazarken metni biçimlendiren ancak yazdıklarınıza yanıt olarak kullanıcı arayüzünün diğer yönlerini de güncelleyen (ör. kelime sayısı, yazım hatalarını vurgulama ve diğer önemli görsel geri bildirimler) bir zengin metin düzenleyici düşünün. Ayrıca, uygulamadan çıkıp geri döndüğünüzde çalışmanızı kaybetmemeniz için uygulamanın yazdıklarınızı kaydetmesi de gerekebilir.

Bu örnekte, kullanıcının yazdığı karakterlere yanıt olarak aşağıdaki dört işlemin gerçekleşmesi gerekir. Ancak bir sonraki kare sunulmadan önce yalnızca ilk öğenin yapılması gerekir.

  1. Metin kutusunu kullanıcının yazdığı metinle güncelleyin ve gerekli biçimlendirmeleri uygulayın.
  2. Kullanıcı arayüzünün mevcut kelime sayısını gösteren bölümünü güncelleyin.
  3. Yazım hatalarını kontrol etmek için mantık çalıştırın.
  4. En son değişiklikleri kaydedin (yerel olarak veya uzak bir veritabanına).

Bunu yapmak için kullanılacak kod aşağıdaki gibi görünebilir:

textBox.addEventListener('input', (inputEvent) => {
  // Update the UI immediately, so the changes the user made
  // are visible as soon as the next frame is presented.
  updateTextBox(inputEvent);

  // Use `setTimeout` to defer all other work until at least the next
  // frame by queuing a task in a `requestAnimationFrame()` callback.
  requestAnimationFrame(() => {
    setTimeout(() => {
      const text = textBox.textContent;
      updateWordCount(text);
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

Aşağıdaki görselleştirmede, kritik olmayan güncellemelerin bir sonraki kareye kadar ertelenmesinin işlem süresini ve dolayısıyla genel etkileşim gecikmesini nasıl azaltabileceği gösterilmektedir.

İki senaryoda klavye etkileşiminin ve sonraki görevlerin tasviri. Üstteki şekilde, oluşturma açısından kritik görev ve sonraki tüm arka plan görevleri, bir kare sunma fırsatı gelene kadar eşzamanlı olarak çalışır. Alttaki şekilde, oluşturma açısından kritik çalışma önce çalışır, ardından yeni bir kareyi daha erken sunmak için ana iş parçacığına geçer. Arka plan görevleri bundan sonra çalışır.
Yüksek çözünürlüklü versiyonunu görmek için şekli tıklayın.

Önceki kod örneğinde bir requestAnimationFrame() çağrısı içinde setTimeout() kullanımı biraz karmaşık olsa da kritik olmayan kodun bir sonraki kareyi engellemesini önlemek için tüm tarayıcılarda çalışan etkili bir yöntemdir.

Düzen karmaşasından kaçının

Bazen zorunlu eşzamanlı düzen olarak adlandırılan düzen karmaşası, düzenin eşzamanlı olarak gerçekleştiği bir oluşturma performansı sorunudur. Bu durum, JavaScript'te stilleri güncelleyip aynı görevde okuduğunuzda ortaya çıkar. JavaScript'te düzen karmaşasına neden olabilecek birçok özellik vardır.

Chrome Geliştirici Araçları'nın performans panelinde gösterilen düzen karmaşasının görselleştirmesi.
Chrome Geliştirici Araçları'nın performans panelinde gösterilen bir düzen karmaşası örneği. Düzen çakışması içeren oluşturma görevleri, çağrı yığınının genellikle Stili Yeniden Hesapla veya Düzen olarak etiketlenen bölümünün sağ üst köşesinde kırmızı bir üçgenle gösterilir.

Düzen karmaşası, performans darboğazına neden olur. Tarayıcı, stilleri güncelleyip hemen ardından JavaScript'te bu stillerin değerlerini isteyerek eşzamanlı düzen çalışması yapmaya zorlanır. Aksi takdirde, etkinlik geri çağırmaları çalışmayı tamamladıktan sonra eşzamansız olarak çalıştırılmayı bekleyebilir.

Sunum gecikmesini en aza indirme

Bir etkileşimin sunum gecikmesi, etkileşimin etkinlik geri çağırmalarının çalışması tamamlandıktan sonra tarayıcının, ortaya çıkan görsel değişiklikleri gösteren bir sonraki kareyi boyayabildiği noktaya kadar olan süreyi işaretler.

DOM boyutunu küçültme

Bir sayfanın DOM'u küçük olduğunda oluşturma işlemi genellikle hızlı bir şekilde tamamlanır. Ancak DOM'lar çok büyük olduğunda oluşturma işi, artan DOM boyutuyla ölçeklendirme eğilimindedir. Oluşturma çalışması ile DOM boyutu arasındaki ilişki doğrusal değildir ancak büyük DOM'ların oluşturulması, küçük DOM'lara kıyasla daha fazla çalışma gerektirir. Büyük bir DOM iki durumda sorun yaratır:

  1. Sayfanın ilk oluşturma işlemi sırasında, büyük bir DOM'un sayfanın ilk durumunu oluşturmak için çok fazla çalışma gerektirdiği durumlarda.
  2. Büyük bir DOM'un, oluşturma güncellemelerinin çok maliyetli olmasına neden olabileceği ve bu nedenle tarayıcının bir sonraki kareyi sunması için gereken süreyi artırabileceği bir kullanıcı etkileşimine yanıt olarak.

Büyük DOM'ların önemli ölçüde azaltılamadığı durumlar olabileceğini unutmayın. DOM boyutunu küçültmek için DOM'unuzu düzleştirme veya ilk DOM boyutunuzu küçük tutmak için kullanıcı etkileşimleri sırasında DOM'a ekleme gibi yaklaşımlar olsa da bu teknikler yalnızca belirli bir noktaya kadar işe yarayabilir.

Ekran dışı öğeleri geç yüklemek için content-visibility kullanın

Hem sayfa yükleme sırasında hem de kullanıcı etkileşimlerine yanıt olarak oluşturma işi miktarını sınırlamanın bir yolu, CSS content-visibility özelliğini kullanmaktır. Bu özellik, öğeleri görüntü alanına yaklaştıkça geç oluşturur. content-visibility yöntemini etkili bir şekilde kullanmak için biraz pratik yapmak gerekebilir ancak sayfanızın INP'sini iyileştirebilecek daha kısa oluşturma süresi elde etmek için bu yöntemi araştırmaya değer.

JavaScript kullanarak HTML oluştururken performans maliyetlerine dikkat edin

HTML'nin olduğu yerde HTML ayrıştırma da vardır. Tarayıcı, HTML'yi DOM'a ayrıştırmayı tamamladıktan sonra stilleri uygulamalı, düzen hesaplamaları yapmalı ve ardından bu düzeni oluşturmalıdır. Bu kaçınılmaz bir maliyettir ancak HTML'yi nasıl oluşturduğunuz önemlidir.

Sunucu HTML gönderdiğinde, tarayıcıya akış olarak ulaşır. Akış, sunucudan gelen HTML yanıtının parçalar halinde ulaştığı anlamına gelir. Tarayıcı, bir akışı işleme şeklini optimize eder. Bunun için akışın parçalarını geldikçe kademeli olarak ayrıştırır ve parça parça oluşturur. Bu, tarayıcının sayfa yükleme sırasında düzenli ve otomatik olarak dolaylı bir şekilde verim sağladığı bir performans optimizasyonudur ve bu optimizasyonu ücretsiz olarak kullanabilirsiniz.

Herhangi bir web sitesine yapılan ilk ziyaret her zaman bir miktar HTML içerir. Yaygın bir yaklaşım, minimum düzeyde ilk HTML ile başlar ve ardından içerik alanını doldurmak için JavaScript kullanılır. Bu içerik alanında daha sonra yapılan güncellemeler de kullanıcı etkileşimlerinin sonucunda gerçekleşir. Bu genellikle tek sayfalık uygulama (SPA) modeli olarak adlandırılır. Bu kalıbın bir dezavantajı, istemcide JavaScript ile HTML oluşturarak yalnızca bu HTML'yi oluşturmak için JavaScript işlemenin maliyetini elde etmekle kalmaz, aynı zamanda tarayıcı bu HTML'yi ayrıştırmayı ve oluşturmayı tamamlayana kadar sonuç vermez.

Ancak SPA olmayan web sitelerinin bile etkileşimler sonucunda JavaScript aracılığıyla bir miktar HTML oluşturma işlemi içerebileceğini unutmamak gerekir. İstemcide büyük miktarda HTML oluşturmadığınız sürece bu genellikle sorun teşkil etmez. Aksi takdirde bir sonraki karenin sunumu gecikebilir. Ancak, HTML'yi tarayıcıda oluşturmaya yönelik bu yaklaşımın performans üzerindeki etkilerini ve JavaScript kullanarak çok fazla HTML oluşturuyorsanız web sitenizin kullanıcı girişine yanıt verme hızını nasıl etkileyebileceğini anlamak önemlidir.

Sonuç

Sitenizin INP'sini iyileştirmek yinelenen bir süreçtir. Sitedeki yavaş bir etkileşimi düzelttiğinizde, özellikle de web siteniz çok fazla etkileşim sağlıyorsa diğer yavaş etkileşimleri de bulmaya başlarsınız ve bunları da optimize etmeniz gerekir.

INP'yi iyileştirmenin anahtarı sürekliliktir. Zaman içinde sayfanızın duyarlılığını, kullanıcılara sunduğunuz deneyimden memnun kalacakları bir düzeye getirebilirsiniz. Kullanıcılarınız için yeni özellikler geliştirirken onlara özel etkileşimleri optimize etmek için de aynı süreçten geçmeniz gerekebilir. Zaman ve çaba gerektirse de buna değer.