Sonraki boyamayla etkileşimi optimize edin

Web sitenizin Next Paint ile etkileşimini nasıl optimize edeceğinizi öğrenin.

Sonraki Boyamayla Etkileşim (INP), bir 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 duyarlılığını değerlendiren kararlı bir Core Web Vital 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 sitelerinin sonraki boyamayla etkileşim süresinin 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 75. yüzdelik dilimi iyi bir ölçüm eşiğidir.

İyi INP değerleri en fazla 200 milisaniye, düşük değerler 500 milisaniyeden fazladır ve aradaki tüm değerlerin iyileştirilmesi gerekir.

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

INP'yi iyileştirmek zaman ve çaba gerektirse de bunun karşılığında daha iyi bir kullanıcı deneyimi sunulur. Bu kılavuzda, INP'yi iyileştirme yolları ele alınmaktadır.

INP'nin düşük olmasına neyin sebep olduğunu bulun

Yavaş etkileşim sorununu düzeltmeden önce, web sitenizin INP'sinin zayıf olup olmadığını veya iyileştirilmesi gerekip gerekmediğini anlamanızı sağlayacak verilere ihtiyacınız vardır. Bu bilgileri edindikten sonra laboratuvara geçerek yavaş etkileşimleri teşhis etmeye başlayabilir ve çözüm için çalışmaya başlayabilirsiniz.

Sahadaki yavaş etkileşimleri bulma

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

Alan verilerini almak için bir RUM sağlayıcısından yararlanmıyorsanız INP alan verileri rehberinde, boşlukların doldurulmasına yardımcı olmak üzere PageSpeed Insights aracılığıyla Chrome Kullanıcı Deneyimi Raporu'nun (CrUX) kullanılması tavsiye edilir. CrUX, Core Web Vitals programının resmi veri kümesidir ve INP dahil milyonlarca web sitesi için yüksek düzeyde metrik özeti sunar. Ancak CrUX, sorunları analiz etmenize yardımcı olması için bir RUM sağlayıcısından alacağınız bağlamsal verileri genellikle sağlamaz. Bu nedenle, mümkün olduğunda sitelerin bir RUM sağlayıcısı kullanmasını veya CrUX'te mevcut olanları desteklemek için kendi RUM çözümlerini uygulamasını öneririz.

Laboratuvardaki yavaş etkileşimleri teşhis etme

İdeal olarak, etkileşimlerinizin yavaş olduğunu gösteren alan verileriniz olduğunda laboratuvarda testlere başlamanız önerilir. Alan verisi olmadığında laboratuvardaki yavaş etkileşimleri tanımlamak için bazı stratejiler kullanılabilir. 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 yükleme sırasında (ana iş parçacığının genellikle en yoğun olduğu sırada) sayfayla etkileşimde bulunma yer alır. Böylece, kullanıcı deneyiminin önemli bir parçası olan yavaş etkileşimleri ortaya çıkarabilirsiniz.

Etkileşimleri optimize edin

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

  1. Giriş gecikmesi, kullanıcı sayfayla bir etkileşim başlattığında başlar ve etkileşim için geri arama yapıldığında sona erer.
  2. Etkinlik geri çağırmalarının tamamlanması için gereken süreyi içeren işleme süresi.
  3. Sunum gecikmesi, tarayıcının etkileşimin görsel sonucunu içeren bir sonraki kareyi sunması için gereken süredir.

Bu üç aşamanın toplamı, toplam etkileşim gecikmesidir. Bir etkileşimin her bir aşaması, 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üre devam edecek şekilde nasıl optimize edebileceğinizi bilmek önemlidir.

Giriş gecikmesini tanımlayın ve azaltın

Bir kullanıcı bir sayfayla etkileşime geçtiğinde bu etkileşimin ilk bölümü giriş gecikmesidir. Sayfadaki diğer etkinliklere bağlı olarak, giriş gecikmelerinin uzunluğu önemli ölçüde uzayabilir. Bunun nedeni ana iş parçacığında gerçekleşen etkinlik (komut dosyalarının yüklenmesi, ayrıştırılması ve derlemesi), getirmenin işlenmesi, zamanlayıcı işlevleri ve hatta hızlı bir şekilde art arda gerçekleşen ve birbiriyle çakışan diğer etkileşimlerden kaynaklanabilir.

Bir etkileşimin giriş gecikmesinin kaynağı ne olursa olsun, etkileşimlerin mümkün olan en kısa sürede geri çağırmaları çalıştırmaya başlayabilmesi için giriş gecikmesini en aza indirmeniz önerilir.

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

Sayfa yaşam döngüsünde etkileşimin kritik bir yönü, başlangıç aşamasıdır. Sayfa yüklendiğinde başlangıçta oluşturulur, ancak yalnızca bir sayfanın oluşturulmuş olmasının, sayfanın yüklenmenin tamamlandığı anlamına gelmediğini unutmayın. Bir sayfanın tam olarak işlevsel hale gelmesi için kaç kaynak gerektiğine bağlı olarak, kullanıcıların sayfa yüklenirken hâlâ etkileşimde bulunmaya çalışması mümkündür.

Bir sayfa yüklenirken etkileşimin giriş gecikmesini uzatabilecek bir özellik de komut dosyası değerlendirmesidir. Ağdan bir JavaScript dosyası getirildikten sonra, JavaScript'in çalışabilmesi için tarayıcının yapması gereken işlemler vardır. Bu işlem, söz diziminin geçerli olduğundan emin olmak için komut dosyasının ayrıştırılmasını, bayt koduna derlenmesini ve son olarak çalıştırılmasını içerir.

Komut dosyasının boyutuna bağlı olarak bu çalışma, ana iş parçacığında uzun görevler ekleyerek tarayıcının diğer kullanıcı etkileşimlerine yanıt vermesini geciktirebilir. Sayfanızın yükleme sırasında kullanıcı girişine duyarlı olmasını sağlamak için, sayfanın hızlı kalması için sayfa yüklenirken uzun görevlerin ortaya çıkma olasılığını azaltmak üzere neler yapabileceğinizi anlamanız önemlidir.

Optimize etkinlik geri çağırmaları

Giriş gecikmesi, INP'nin ölçtüğünün yalnızca ilk kısmıdır. Ayrıca kullanıcı etkileşimine yanıt olarak çalışan etkinlik geri çağırma işlemlerinin mümkün olduğunca hızlı bir şekilde tamamlanabileceğinden de emin olmanız gerekir.

Sık sık ana ileti dizisine dönün

Etkinlik geri çağırmalarını optimize etmek için yapılacak en iyi genel tavsiye, bu geri çağırmalarda mümkün olduğunca az iş yapmaktır. Ancak etkileşim mantığınız karmaşık olabilir. Bu durumda, iş yükünü azaltmanız mümkün olabilir.

Bu durumun web siteniz için geçerli olduğunu fark ederseniz, atabileceğiniz bir sonraki adım, etkinlik geri çağırmalarındaki işi ayrı görevlere bölmektir. Bu, ortak çalışmanın ana iş parçacığını engelleyen uzun bir görev haline gelmesini önler ve ana iş parçacığının daha erken çalışmasına olanak tanıyan diğer etkileşimlerin yapılmasına olanak tanır.

setTimeout, görevlere iletilen geri çağırma yeni bir görevde çalıştığından görevleri bölmenin bir yoludur. setTimeout öğesini tek başına kullanabilir veya daha ergonomik verim için kullanımını ayrı bir işlevde soyutlayabilirsiniz.

Dikkatsiz bir şekilde sonuç vermek hiç sonuç vermemekten daha iyidir. Bununla birlikte, ana iş parçacığının elde edilmesi için daha incelikli bir yol vardır ve bu yöntem yalnızca kullanıcı arayüzünü güncelleyen bir etkinlik geri çağırmasından hemen sonra veri oluşturmayı içerir. Böylece oluşturma mantığı daha kısa sürede çalışır.

Oluşturma işleminin daha erken gerçekleşmesini sağlama

Daha gelişmiş bir getiri tekniği, etkinlik geri çağırmalarınızda kodu yapılandırarak çalıştırılacakları yalnızca bir sonraki kareye görsel güncellemeleri uygulamak için gereken mantıkla sınırlamaktır. Diğer her şey sonraki göreve ertelenebilir. Bu, geri çağırmaların hafif ve hızlı olmasını sağlamanın yanı sıra, görsel güncellemelerin etkinlik geri çağırma kodunu engellemesine izin vermeyerek etkileşimler için 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 özelliklerini de (ör. kelime sayısı, yazım hatalarını vurgulama ve diğer önemli görsel geri bildirimler) güncelleyen zengin bir metin düzenleyici düşünün. Ayrıca, ayrılır ve geri dönerseniz hiçbir çalışmayı kaybetmemeniz için uygulamanın, yazdıklarınızı da kaydetmesi gerekebilir.

Bu örnekte, kullanıcı tarafından yazılan karakterlere karşılık aşağıdaki dört şeyin gerçekleşmesi gerekir. Bununla birlikte, 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çimlendirmeyi uygulayın.
  2. Kullanıcı arayüzünün, mevcut kelime sayısını görüntüleyen bölümünü günceller.
  3. Yazım hatalarını denetlemek için mantığı çalıştırın.
  4. En son değişiklikleri kaydedin (yerel olarak veya uzak bir veritabanına).

Bu işlemin yapılması için gereken 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ştirme, kritik olmayan güncellemeleri bir sonraki kareden sonrasına ertelemenin işleme süresini ve dolayısıyla genel etkileşim gecikmesini nasıl azaltabileceğini göstermektedir.

İki senaryoda klavye etkileşiminin ve ardından gelen görevlerin tasviri. Yukarıdaki şekilde, oluşturma açısından kritik görev ve sonraki tüm arka plan görevleri, bir kare sunma fırsatı elde edilene kadar eşzamanlı olarak çalışır. Alttaki şekilde, oluşturma açısından kritik olan çalışma önce çalışır, ardından yeni bir karenin daha erken sunulması için ana iş parçacığına verilir. Arka plan görevleri daha sonra çalışır.
Yüksek çözünürlüklü sürümünü görmek için yukarıdaki resme tıklayın.

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

Yoğun düzen uygulanmasından kaçının

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. JavaScript'te stilleri güncellediğinizde ve daha sonra bunları aynı görevde okuduğunuzda meydana gelir. 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 bozmanın görselleştirmesi.
Chrome Geliştirici Araçları'nın performans panelinde gösterildiği gibi, düzen bozma örneği. Düzen bozma içeren oluşturma görevleri, çağrı yığınının kısmının sağ üst köşesinde genellikle Stili Yeniden Hesapla veya Düzen şeklinde etiketli kırmızı bir üçgenle belirtilir.

Düzen bozma bir performans sorunudur, çünkü stilleri güncelleyip bu stillerin değerlerini JavaScript'te hemen isteyerek, tarayıcı eşzamanlı düzen çalışması yapmak zorunda kalır. Aksi takdirde, etkinlik geri çağırma işlevleri tamamlandıktan sonra eşzamansız olarak gerçekleştirmeyi bekleyebilir.

Sunum gecikmesini en aza indirme

Bir etkileşim işaretlerinin sunum gecikmesi, bir etkileşimin etkinlik geri çağırmalarının çalışmasının bitmesinden tarayıcının ortaya çıkan görsel değişiklikleri gösteren bir sonraki kareyi boyayabildiği noktaya kadar sürer.

DOM boyutunu en aza indir

Bir sayfanın DOM'si küçük olduğunda oluşturma işlemi genellikle hızlı bir şekilde tamamlanır. Ancak DOM'ler çok büyük hale geldiğinde, oluşturma işi artan DOM boyutuyla birlikte ölçeklenme eğilimindedir. Oluşturma işi ile DOM boyutu arasındaki ilişki doğrusal bir ilişki değildir. Ancak büyük DOM'larda, oluşturma işlemi için küçük DOM'lere kıyasla daha fazla çalışma yapılması gerekir. Büyük bir DOM iki durumda sorunludur:

  1. İlk sayfa 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 yapılması gerekir.
  2. Büyük bir DOM'un, güncelleme oluşturma işleminin çok pahalı olmasına ve dolayısıyla tarayıcının bir sonraki kareyi göstermesi için gereken süreyi uzattığı kullanıcı etkileşimine tepki olarak.

Büyük DOM'lerin önemli ölçüde azaltılamadığı durumlar da vardır. DOM boyutunu küçültmek amacıyla, ilk DOM boyutunuzu küçük tutmak için DOM'u düzleştirmek veya kullanıcı etkileşimleri sırasında DOM'ye ekleme yapmak gibi yaklaşımlar vardır. Ancak bu teknikler çoğunlukla işe yarayabilir.

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

Hem sayfa yükleme sırasındaki oluşturma işinin miktarını, hem de kullanıcı etkileşimlerine yanıt olarak oluşturma işinin miktarını sınırlandırmanın bir yolu da CSS content-visibility mülküne odaklanmaktır. Bu, öğelerin görüntü alanına yaklaştığında geç oluşturulmasıyla sonuçlanacaktır. content-visibility ürününün etkili bir şekilde kullanılması için pratik yapmak gerekebilir. Ancak, sonucun sayfanızın INP'sini iyileştirebilecek daha kısa oluşturma süresi sağlayıp sağlamadığını araştırmanızda yarar vardır.

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

HTML olduğunda HTML ayrıştırma işlemi vardır ve tarayıcı HTML'yi bir DOM'a ayrıştırmayı bitirdikten sonra 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şturduğunuz önemlidir.

Sunucu HTML gönderdiğinde bu HTML tarayıcıya bir akış olarak gelir. Akış, sunucudan gelen HTML yanıtının parçalar halinde ulaştığı anlamına gelir. Tarayıcı, o akışın parçalarını geldikçe artımlı olarak ayrıştırarak ve bunları parça parça oluşturarak işleme şeklini optimize eder. Bu, tarayıcının sayfa yükleme sırasında örtülü bir şekilde düzenli ve otomatik olarak veri sağlaması açısından bir performans optimizasyonudur ve bunu ücretsiz olarak alırsınız.

Herhangi bir web sitesine yapılan ilk ziyaret her zaman bir miktar HTML içerse de, yaygın yaklaşımda kullanılan HTML başlangıç bölümü minimum HTML ile başlar ve daha sonra içerik alanını doldurmak için JavaScript kullanılır. Bu içerik alanında daha sonra yapılacak güncellemeler de kullanıcı etkileşimleri sonucunda gerçekleşir. Buna genellikle tek sayfalı uygulama (SPA) modeli denir. Bu kalıbın bir dezavantajı, HTML'yi istemcide JavaScript ile oluşturarak yalnızca o HTML'yi oluşturmak için JavaScript'in işleme maliyetini almakla kalmaz, aynı zamanda bu HTML'yi ayrıştırma ve oluşturma işlemini tamamlayana kadar tarayıcının getiri olmamasıdır.

Ancak SPA olmayan web sitelerinin bile, etkileşimler sonucunda muhtemelen JavaScript üzerinden bir miktar HTML oluşturma işlemi içereceğini unutmayın. İstemcide büyük miktarlarda HTML oluşturmadığınız sürece bu genellikle sorun yaratmaz, bu da bir sonraki karenin sunumunu geciktirebilir. Ancak, tarayıcıda HTML oluşturmayla ilgili bu yaklaşımın performans sonuçlarını ve JavaScript aracılığıyla çok fazla HTML görüntülüyorsanız web sitenizin kullanıcı girişine duyarlılığını nasıl etkileyebileceğini anlamanız önemlidir.

Sonuç

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

INP'yi iyileştirmenin anahtarı sebattır. Zaman içinde, sayfanızın kullanıcıların sunduğunuz deneyimden memnun kaldığı bir yere duyarlılığını gösterebilirsiniz. Ayrıca, kullanıcılarınız için yeni özellikler geliştirirken onlara özel etkileşimleri optimize ederken de aynı süreci tekrarlamanız gerekebileceğini unutmayın. Bunun için zaman ve çaba gerekir, ancak harcanan zaman ve çabadır.

Unsplash'tan David Pisnoy'a ait olan ve Unsplash lisansı uyarınca değiştirilen hero resim.