Sonraki boyamayla etkileşimi optimize edin

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

Sonraki Boyamayla Etkileşim (INP), kullanıcının sayfayı ziyaret ettiği süre boyunca gerçekleşen tüm uygun etkileşimlerin gecikmesini gözlemleyerek sayfanın kullanıcı etkileşimlerine genel olarak yanıt verme oranını değerlendiren kararlı bir Core Web Vitals metriğidir. Nihai INP değeri, gözlemlenen en uzun etkileşimdir (bazen aykırı değerler göz ardı edilir).

İyi bir kullanıcı deneyimi sağlamak için web sitelerinde Interaction to Next Paint metriğinin 200 milisaniye veya daha kısa olması gerekir. Kullanıcılarınızın çoğu için bu hedefe ulaştığınızdan emin olmak amacıyla, mobil ve masaüstü cihazlara göre segmentlere ayrılmış sayfa yüklemelerinin yüzde 75'lik dilimi iyi bir eşiktir.

İyi INP değerleri 200 milisaniye veya daha az, kötü değerler 500 milisaniyeden fazladır. Bu değerler arasındaki değerlerde iyileştirme yapılması gerekir.

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

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

INP'nin düşük olmasına neyin neden olduğunu öğrenme

Yavaş etkileşimleri düzeltmeden önce, web sitenizin INP'sinin düşük olup olmadığını veya iyileştirmeye ihtiyaç duyup duymadığını gösteren verilere ihtiyacınız vardır. Bu bilgilere sahip olduktan sonra, yavaş etkileşimleri teşhis etmeye başlamak için laboratuvara geçebilir ve bir çözüme doğru ilerleyebilirsiniz.

Sahadaki 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 gelen alan verileri, en iyi durumda size yalnızca bir sayfanın INP değerini değil, aynı zamanda INP değerinin kendisinden sorumlu olan belirli etkileşimin ne olduğunu, etkileşimin sayfa yükleme sırasında mı yoksa sonrasında mı gerçekleştiğini, etkileşimin türünü (tıklama, tuş basma veya dokunma) ve diğer değerli bilgileri vurgulayan bağlamsal veriler de sağlar.

Alan verileri almak için bir RUM sağlayıcı kullanmıyorsanız INP alan verileri kılavuzunda, boşlukları doldurmak amacıyla PageSpeed Insights aracılığıyla Chrome Kullanıcı Deneyimi Raporu'nu (CrUX) kullanmanızı önerilir. CrUX, Core Web Vitals programının resmi veri kümesidir ve INP dahil olmak üzere milyonlarca web sitesi için metriklerin üst düzey bir özetini sağlar. Ancak CrUX, sorunları analiz etmenize yardımcı olmak için genellikle bir RUM sağlayıcıdan alacağınız bağlamsal verileri sağlamaz. Bu nedenle, sitelerin mümkün olduğunda bir RUM sağlayıcı kullanmasını veya CrUX'ta mevcut olanları 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 saha verilerine sahip olduktan sonra laboratuvarda teste başlamak istersiniz. Saha verileri olmadığında, laboratuvarda yavaş etkileşimleri belirlemek için bazı stratejiler vardır. Bu tür stratejiler arasında, yaygın kullanıcı akışlarını takip etme ve bu süreçte etkileşimleri test etme, ayrıca kullanıcı deneyiminin bu önemli bölümünde yavaş etkileşimleri ortaya çıkarmak için yükleme sırasında sayfayla etkileşime geçme (ana iş parçacığı genellikle en yoğun olduğunda) yer alır.

Etkileşimleri optimize etme

Yavaş bir etkileşimi belirledikten ve laboratuvarda manuel olarak yeniden oluşturabildikten sonra, bir sonraki adım bu etkileşimi optimize etmektir. Etkileşimler üç aşamaya ayrılabilir:

  1. Kullanıcı sayfayla etkileşime geçtiğinde başlayan ve etkileşimle ilgili etkinlik geri çağırma işlevleri çalışmaya başladığında sona eren giriş gecikmesi.
  2. Etkinlik geri çağırmalarının tamamlanması için geçen süreyi içeren işleme süresi.
  3. Tarayıcının etkileşimin görsel sonucunu içeren bir sonraki kareyi sunması için geçen süre olan sunu gecikmesi.

Bu üç aşamanın toplamı, toplam etkileşim gecikmesidir. Bir etkileşimin her aşaması, toplam etkileşim gecikmesine belirli bir süreyle katkıda bulunur. Bu nedenle, etkileşimin her bölümünü mümkün olduğunca kısa sürede çalışacak şekilde nasıl optimize edebileceğinizi bilmeniz önemlidir.

Giriş gecikmesini tespit etme ve azaltma

Kullanıcı bir sayfayla etkileşime geçtiğinde bu etkileşimin ilk kısmı giriş gecikmesi olur. Sayfadaki diğer etkinliğe bağlı olarak giriş gecikmeleri önemli ölçüde uzun olabilir. Bu durum, ana iş parçacığında gerçekleşen etkinlik (ör. komut dosyalarının yüklenmesi, ayrıştırılması ve derlenmesi), getirme işlemleri, zamanlayıcı işlevleri veya hatta birbirini takip eden ve birbiriyle örtüşen diğer etkileşimlerden kaynaklanabilir.

Etkileşimin giriş gecikmesinin kaynağı ne olursa olsun, etkileşimlerin en kısa sürede etkinlik geri çağırma işlemlerini başlatabilmesi için giriş gecikmesini minimuma indirmeniz gerekir.

başlıklı makaleyi inceleyin.

Komut dosyası değerlendirmesi ile başlangıç sırasındaki uzun görevler arasındaki ilişki

Sayfa yaşam döngüsünde etkileşimin kritik bir yönü, başlatma sırasındadır. Sayfa yüklenirken ilk olarak oluşturulur ancak bir sayfanın oluşturulmuş olması, sayfanın yüklenmesi işleminin tamamlandığı anlamına gelmez. Bir sayfanın tam olarak işlevsel hale gelmesi için ihtiyaç duyduğu kaynaklara bağlı olarak, kullanıcıların sayfa henüz yüklenirken sayfayla etkileşim kurmaya çalışması mümkündür.

Sayfa yüklenirken etkileşimin giriş gecikmesini uzatabilecek bir faktör komut dosyası değerlendirmesidir. Bir JavaScript dosyası ağdan getirildikten sonra, bu JavaScript'in çalışabilmesi için tarayıcıda yapılması gereken işlemler vardır. Bu işlemler arasında, söz dizimi geçerli olduğundan emin olmak için komut dosyasını ayrıştırma, onu bayt koduna derleme ve ardından yürütme yer alır.

Bir komut dosyasının boyutuna bağlı olarak bu işlem, ana iş parçacığında uzun görevler oluşturabilir. 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 duyarlı kalması için sayfa yükleme sırasında uzun görevlerin olasılığını azaltmak amacıyla neler yapabileceğinizi anlamak önemlidir. Böylece sayfanız hızlı kalır.

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

Giriş gecikmesi, INP'nin ölçtüğü verilerin yalnızca ilk kısmıdır. Ayrıca, kullanıcı etkileşimine yanıt olarak çalıştırılan etkinlik geri çağırmalarının mümkün olduğunca hızlı bir şekilde tamamlandığından emin olmanız gerekir.

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

Etkinlik geri çağırmalarını optimize etmeyle ilgili en iyi genel tavsiye, bu geri çağırmalarda mümkün olduğunca az işlem yapmaktır. Ancak etkileşim mantığınız karmaşık olabilir ve yaptıkları işi yalnızca biraz azaltabilirsiniz.

Web sitenizde de bu durumun geçerli olduğunu düşünüyorsanız bir sonraki denemenizde, etkinlik geri çağırmalarında yapılan işi ayrı görevlere ayırmayı deneyebilirsiniz. Bu sayede, ortak çalışma ana iş parçacığını engelleyen uzun bir görev haline gelmez. Böylece, ana iş parçacığında bekleyen diğer etkileşimlerin daha erken çalışması sağlanır.

setTimeout, kendisine iletilen geri çağırma işlevi yeni bir görevde çalıştığından görevleri bölmenin bir yoludur. setTimeout'yi tek başına kullanabilir veya daha ergonomik bir sonuç elde etmek için kullanımını ayrı bir işleve soyutlayabilirsiniz.

başlıklı makaleyi inceleyin.

Ayrıntılara girmeden veriyi aktarmak, hiç aktarmamaktan daha iyidir. Ancak ana iş parçacığına veriyi aktarmanın daha ayrıntılı bir yolu vardır. Bu yöntemde, kullanıcı arayüzünü güncelleyen bir etkinlik geri çağırma işlevi hemen sonrasında veriyi aktararak oluşturma mantığının daha erken çalışmasını sağlarsınız.

Oluşturma işleminin daha erken yapılmasına izin vermek için verim

Daha gelişmiş bir verim verme tekniği, çalıştırılacakları bir sonraki kare için görsel güncellemeleri uygulamak için gereken mantıkla sınırlamak üzere etkinlik geri çağırmalarınızdaki kodu yapılandırmayı içerir. Diğer tüm işlemler sonraki bir göreve ertelenebilir. Bu, geri çağırmaların hafif ve çevik kalmasını sağlar. Ayrıca, görsel güncellemelerin etkinlik geri çağırma kodunda engellenmesine izin vermeyerek etkileşimlerin oluşturma süresini de iyileştirir.

Örneğin, siz yazarken metni biçimlendiren ancak yazdıklarınıza göre 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) zengin bir metin düzenleyiciyi düşünün. Ayrıca, uygulamanın yazdığınız metni kaydetmesi de gerekebilir. Böylece, ayrılıp geri döndüğünüzde hiçbir çalışmanızı kaybetmezsiniz.

Bu örnekte, kullanıcı tarafından yazılan karakterlere yanıt olarak aşağıdaki dört işlemin yapılması gerekir. Ancak bir sonraki karenin gösterilmesi için yalnızca ilk öğenin yapılması gerekir.

  1. Metin kutusunu kullanıcının yazdığıyla güncelleyin ve gerekli biçimlendirmeyi 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 kullanacağınız 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 ertelenmesi işlemin süresini ve dolayısıyla genel etkileşim gecikmesini nasıl azaltabileceği gösterilmektedir.

İki senaryoda klavye etkileşimini ve sonraki görevleri gösteren bir resim. Üstteki resimde, oluşturma işlemi için kritik olan görev ve sonraki tüm arka plan görevleri, bir kare sunma fırsatı gelene kadar senkronize olarak çalışır. Alttaki resimde, oluşturma işlemi için kritik olan iş önce çalıştırılır, ardından yeni bir kareyi daha hızlı sunmak için ana iş parçacığına devredilir. Arka plan görevleri daha sonra çalışır.
Yüksek çözünürlüklü sürümü görmek için yukarıdaki resmi tıklayın.

Önceki kod örneğinde bir requestAnimationFrame() çağrısı içinde setTimeout() kullanılmasının biraz gizemli olduğu kabul edilse de kritik olmayan kodun sonraki kareyi engellemesini önlemek için tüm tarayıcılarda çalışan etkili bir yöntemdir.

Düzenin çok hızlı değişmesini önleyin

Bazen zorunlu eşzamanlı düzen olarak da 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üzenin bozulması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 düzen karmaşası örneği. Düzenin sık sık yeniden oluşturulmasını içeren oluşturma görevleri, çağrı yığınının sağ üst köşesinde genellikle Stili Yeniden Hesapla veya Düzen olarak etiketlenmiş kırmızı bir üçgenle belirtilir.

Stillerin güncellenmesi ve ardından bu stillerin değerlerinin JavaScript'te hemen istenmesi nedeniyle tarayıcı, senkronize bir şekilde sayfa düzeni çalışması yapmak zorunda kalır. Bu çalışmayı, aksi takdirde etkinlik geri çağırma işlevleri tamamlandıktan sonra asenkron olarak gerçekleştirebilirdi. Bu nedenle sayfa düzeni karmaşası, performans darboğazıdır.

Sunum gecikmesini en aza indirme

Bir etkileşimin sunma gecikmesi, etkileşimin etkinlik geri çağırmalarının çalışmasını tamamlamasından tarayıcıda ortaya çıkan görsel değişiklikleri gösteren bir sonraki kareyi boyayabildiği noktaya kadar olan süreyi kapsar.

DOM boyutunu en aza indirin

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şlemi, DOM boyutu arttıkça ölçeklenir. 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 DOM'lar iki durumda soruna yol açar:

  1. Büyük bir DOM'un sayfanın ilk durumunu oluşturmak için çok fazla çalışma gerektirdiği ilk sayfa oluşturma işlemi sırasında.
  2. Büyük bir DOM'un, oluşturma güncellemelerinin çok pahalı olmasına ve dolayısıyla tarayıcının bir sonraki kareyi sunmasının zaman almasına neden olabileceği kullanıcı etkileşimlerine yanıt olarak.

Büyük DOM'ların önemli ölçüde küçültülemediği 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 kullanabilirsiniz. Ancak bu teknikler yalnızca belirli bir noktaya kadar etkili olabilir.

Ekran dışındaki öğeleri yavaşça oluşturmak için content-visibility öğesini kullanma

Sayfa yükleme sırasındaki ve kullanıcı etkileşimlerine yanıt olarak yapılan oluşturma çalışmalarının miktarını sınırlamanın bir yolu, CSS content-visibility mülkünden yararlanmaktır. Bu, öğeleri görüntü alanına yaklaştıkça tembelce oluşturmaya eşdeğerdir. content-visibility'ü etkili bir şekilde kullanmak için biraz alıştırma yapmanız gerekebilir ancak bunun sonucunda sayfanızı INP'sini artırabilecek daha düşük bir oluşturma süresi elde edip edemeyeceğinizi incelemeye değer.

JavaScript kullanarak HTML'yi oluştururken performans maliyetlerini göz önünde bulundurun

HTML'nin olduğu yerde HTML ayrıştırma işlemi de vardır. Tarayıcı, HTML'yi DOM'a ayrıştırmayı bitirdikten sonra bu DOM'a stiller 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şturacağınız önemlidir.

Sunucu HTML gönderdiğinde bu içerik tarayıcıya akış olarak gelir. Akış, sunucudan gelen HTML yanıtının parçalar halinde geldiği anlamına gelir. Tarayıcı, bir akışı nasıl işleyeceğini optimize etmek için akıştaki parçaları 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 periyodik olarak ve otomatik olarak dolaylı olarak verim sağlaması nedeniyle bir performans optimizasyonudur ve bunu ücretsiz olarak elde edersiniz.

Herhangi bir web sitesine yapılan ilk ziyaret her zaman bir miktar HTML içerir. Yaygın bir yaklaşım, minimum düzeyde bir HTML ile başlar ve ardından içerik alanını doldurmak için JavaScript kullanılır. Bu içerik alanındaki sonraki güncellemeler de kullanıcı etkileşimleri sonucunda gerçekleşir. Buna genellikle tek sayfalık uygulama (SPA) modeli denir. Bu kalıbın bir dezavantajı, istemcide HTML'yi JavaScript ile oluşturarak yalnızca bu HTML'yi oluşturmak için JavaScript işlemenin maliyetini almanız değil, aynı zamanda tarayıcının bu HTML'yi ayrıştırıp oluşturmayı tamamlayana kadar verimi vermemesidir.

Ancak SPA olmayan web sitelerinin bile etkileşimler sonucunda JavaScript aracılığıyla bir miktar HTML oluşturma işlemi içereceğini unutmayın. Müşteride büyük miktarlarda HTML oluşturmadığınız sürece bu genellikle sorun oluşturmaz. Aksi takdirde bir sonraki karenin sunumu gecikebilir. Ancak tarayıcıda HTML oluşturmaya yönelik bu yaklaşımın performans üzerindeki etkilerini ve JavaScript aracılığıyla çok fazla HTML oluşturmanız durumunda web sitenizin kullanıcı girişine olan duyarlılığını nasıl etkileyebileceğini anlamanız önemlidir.

Sonuç

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

INP'yi iyileştirmenin anahtarı, kararlılıktır. Zaman içinde sayfanızı, kullanıcıların sunduğunuz deneyimden memnun olduğu bir düzeye getirebilirsiniz. Kullanıcılarınız için yeni özellikler geliştirirken onlara özel etkileşimleri optimize etmek için aynı süreci uygulamanız gerekebilir. Bu işlem zaman ve çaba gerektirir ancak harcadığınız zaman ve çabaya değecektir.

David Pisnoy tarafından Unsplash'tan alınan ve Unsplash lisansına uygun şekilde değiştirilen hero resim.