Sonraki boyamayla etkileşimi optimize edin

Web sitenizin Sonraki Boyamayla Etkileşimini nasıl optimize edeceğinizi öğrenin.

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

İyi bir kullanıcı deneyimi sağlamak için web sitelerinin Sonraki Boyama ile Etkileşimin 200 milisaniye veya daha kısa olmasını sağlamaları gerekir. Kullanıcılarınızın çoğunda bu hedefe ulaştığınızdan emin olmak için iyi bir ölçüm eşiği, mobil ve masaüstü cihazlarda segmentlere ayrılmış sayfa yüklemelerinin yüzde 75'lik dilimidir.

İyi INP değerleri 200 milisaniye veya daha kısa, zayıf değerler 500 milisaniyeden büyük ve iyileştirilmesi gerekenlerin arasındaki tüm değerlerdir.

Web sitesine bağlı olarak, çok az etkileşim bulunabilir veya hiç etkileşim kurulmayabilir. Örneğin, çok az veya hiç etkileşim öğesi içermeyen, çoğunlukla metin ve resim içeren sayfalar gösterilebilir. Metin editörleri veya oyunlar gibi web sitelerinde ise yüzlerce, hatta binlerce etkileşim olabilir. Her iki durumda da yüksek INP olduğunda kullanıcı deneyimi risk altındadır.

INP'yi iyileştirmek zaman ve çaba ister ancak karşılığında daha iyi bir kullanıcı deneyimi sunulur. Bu kılavuzda, INP'yi iyileştirmenin yolları incelenmektedir.

Düşük INP'nin nedenini öğrenin

Yavaş etkileşimleri gidermeden önce, web sitenizin INP'sinin zayıf olup olmadığını veya iyileştirilmesi gerektiğini belirten verilere ihtiyacınız vardır. Bu bilgileri edindikten sonra, yavaş etkileşimlerin teşhisine başlamak için laboratuvara gidebilir ve sorunu çözüme ulaştırmak için ilerleyebilirsiniz.

Alanda yavaş etkileşimleri bulun

İdeal olarak, INP'yi optimize etme yolculuğunuz alan verileri ile başlar. 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 etkileşimin sorumlu 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şa basma veya dokunma) ve diğer değerli bilgileri vurgulayan içerik verileri sağlar.

Alan verilerini almak için bir RUM sağlayıcısından yararlanmıyorsanız boşlukları doldurmaya yardımcı olması için INP alan verileri kılavuzunda PageSpeed Insights üzerinden 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 olmak üzere 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ısından alacağınız bağlamsal verileri sağlamaz. Bu nedenle, mümkün olduğunda sitelerin bir RUM sağlayıcısı kullanmasını veya CrUX'te bulunanları 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 test yapmaya başlamanız gerekir. Alan verileri yoksa laboratuvarda yavaş etkileşimleri tanımlamaya yönelik bazı stratejiler vardır. Bu tür stratejiler, kullanıcı deneyiminin bu önemli bölümünde yavaş etkileşimleri ortaya çıkarmak için, genel kullanıcı akışlarını takip etmeyi ve süreç boyunca etkileşimleri test etmeyi, ayrıca ana iş parçacığının en yoğun olduğu zamanlarda sayfayla etkileşimde bulunmayı içerir.

Etkileşimleri optimize edin

Yavaş bir etkileşim tanımladıktan ve lab'da manuel olarak yeniden oluşturabiliyorsanız sonraki adım, etkileşimi optimize etmektir. Etkileşimler üç aşamaya ayrılabilir:

  1. Kullanıcı sayfayla bir 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üreyi içeren işleme süresi.
  3. Sunu 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 aşaması, toplam etkileşim gecikmesine bir miktar süre katkıda bulunur. Bu nedenle, etkileşimin her bir parçasını mümkün olduğunca kısa bir süre için nasıl optimize edebileceğinizi bilmek önemlidir.

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

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 uzun sürebilir. Bunun nedeni, ana iş parçacığında gerçekleşen etkinlik (komut dosyası yükleme, ayrıştırma ve derleme), getirme işlemi, zamanlayıcı işlevleri, hatta hızlı bir şekilde arka arkaya gerçekleşen ve birbiriyle çakışan diğer etkileşimlerden kaynaklanabilir.

Bir etkileşimin giriş gecikmesinin kaynağı ne olursa olsun, etkileşimlerin en kısa sürede etkinlik geri çağırmaya başlayabilmesi için giriş gecikmesini en aza indirmelisiniz.

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

Sayfa yaşam döngüsündeki etkileşimin kritik bir özelliği başlatma sırasındadır. Sayfa yüklendiğinde ilk olarak oluşturulur, ancak bir sayfanın oluşturulmuş olmasının sayfanın yüklenmesinin tamamlandığı anlamına gelmediğini unutmayın. Bir sayfanın tam olarak çalışması için kaç kaynak gerektiğine bağlı olarak, kullanıcıların sayfa yüklenirken sayfayla etkileşimde bulunmaya çalışması mümkündür.

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

Komut dosyasının boyutuna bağlı olarak bu çalışma, ana iş parçacığında uzun 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şlerine duyarlı olmasını sağlamak amacıyla, sayfa yüklenirken sayfanın hızlı hareket etmesi için uzun görevlerin ortaya çıkma olasılığını azaltmak üzere neler yapabileceğinizi anlamanız önemlidir.

Etkinlik geri çağırmalarını optimize edin

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ğırmalarının mümkün olduğunca hızlı bir şekilde tamamlanabileceğinden emin olmanız gerekir.

Ana ileti dizisine sık sık geri dönün

Etkinlik geri çağırmalarının optimize edilmesinde en iyi genel tavsiye, bu geri çağırmalarda mümkün olduğunca az işlem yapmaktır. Bununla birlikte, etkileşim mantığınız karmaşık olabilir ve bu kişilerin yaptığı işi yalnızca marjinal şekilde azaltabilirsiniz.

Bu durumun web siteniz için de geçerli olduğunu düşünüyorsanız deneyebileceğiniz bir sonraki şey, etkinlik geri çağırma yöntemindeki işi ayrı görevlere ayırmaktır. Böylece, toplu çalışmanın ana iş parçacığını engelleyen uzun bir görev haline gelmesi önlenir. Böylece, aksi halde ana iş parçacığında bekleyecek diğer etkileşimlerin daha erken çalıştırılması sağlanır.

setTimeout, görevleri ayırmanın bir yoludur. Çünkü kendisine iletilen geri çağırma yeni bir görevde çalışır. setTimeout öğesini tek başına kullanabilir veya daha ergonomik verim için kullanımını soyut olarak ayrı bir işlevde kullanabilirsiniz.

Ayrımsız verim, hiç veri vermemekten daha iyidir. Ancak ana iş parçacığına getiri sağlamanın daha ince bir yolu vardır ve bu, yalnızca kullanıcı arayüzünü güncelleyen bir etkinlik geri çağırmasından hemen sonra veri getirmeyi içerir. Böylece, oluşturma mantığı daha erken çalışabilir.

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

Daha gelişmiş bir getiri tekniğinde, etkinlik geri çağırma kurallarınızda kodun yapılandırılması, çalıştırılacak işlemi yalnızca bir sonraki kareye görsel güncellemeleri uygulamak için gereken mantığa göre sınırlandırmayı içerir. Diğer her şey bir sonraki göreve ertelenebilir. Bu yöntem, 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 yazdıkça metni biçimlendiren ancak yazdıklarınıza yanıt olarak kullanıcı arayüzünün diğer yönlerini de güncelleyen (kelime sayısı, yazım hatalarını vurgulama ve diğer önemli görsel geri bildirimler gibi) zengin bir metin düzenleyici düşünün. Ayrıca, uygulamadan çıkıp geri dönerseniz herhangi bir çalışmayı kaybetmemiş olmanız için uygulamanın yazdıklarınızı kaydetmesi de gerekebilir.

Bu örnekte, kullanıcının yazdığı karakterlere karşılık olarak aşağıdaki dört şeyin gerçekleşmesi gerekir. Bununla birlikte, 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 geçerli kelime sayısını gösteren bölümünü güncelleyin.
  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şlemi yapan 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 sonraki kareden sonrakine kadar ertelenmesi, işleme süresini ve dolayısıyla genel etkileşim gecikmesini nasıl azaltabileceğini gösterir.

İki senaryoda klavye etkileşiminin ve onu izleyen görevlerin tasviri. Üstteki şekilde oluşturma açısından kritik görev ve izleyen tüm arka plan görevleri, kare sunma fırsatı gelene kadar eşzamanlı olarak çalışıyor. Alttaki şekilde, oluşturma açısından kritik iş önce çalışır, ardından daha kısa sürede yeni bir kare sunmak için ana iş parçacığına veri verir. Arka plan görevleri daha sonra çalışır.
Yüksek çözünürlüklü sürümünü görmek için yukarıdaki resmi tıklayın.

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

Düzen rahatsızlığından kaçının

Bazen zorunlu eşzamanlı düzen olarak da adlandırılan düzen taşması, düzenin eşzamanlı olarak gerçekleştiği bir oluşturma performansı sorunudur. Bu hata, JavaScript'teki stilleri güncellediğinizde ve daha sonra, bunları aynı görevde okuduğunuzda ortaya çıkar ve JavaScript'te, düzenin bozulmasına neden olabilecek birçok özellik vardır.

Chrome Geliştirici Araçları'nın performans panelinde gösterildiği gibi düzenin bozulmasının görselleştirmesi.
Chrome Geliştirici Araçları'nın performans panelinde gösterildiği gibi düzen bozma örneği. Düzen karmaşası içeren oluşturma görevleri, çağrı yığınının sağ üst köşesindeki kırmızı bir üçgenle belirtilir ve genellikle Stili Yeniden Hesapla veya Düzen olarak etiketlenir.

Düzen karmaşası bir performans sorunudur. Çünkü stilleri güncelleyip bu stillerin değerlerini hemen JavaScript'te istediğinizde tarayıcı, eşzamanlı düzen çalışması yapmaya zorlanır. Aksi takdirde, etkinlik geri çağırmalarının çalışması bittikten sonra, eşzamansız bir şekilde çalışmak için bekleyebilirler.

Sunu gecikmesini en aza indir

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

DOM boyutunu en aza indirin

Bir sayfanın DOM'si küçükse, oluşturma işlemi genellikle hızlı bir şekilde biter. Ancak DOM'ler çok büyük olduğunda, oluşturma işlemi artan DOM boyutuyla ölçeklenme eğilimindedir. Oluşturma işi ile DOM boyutu arasındaki ilişki doğrusal değildir. Ancak büyük DOM'lerin oluşturulması, küçük DOM'lere kıyasla daha fazla çalışma gerektirir. Büyük bir DOM, iki durumda soruna neden olur:

  1. Büyük bir DOM'nin, 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'nin, oluşturma güncellemelerinin çok pahalı olmasına, dolayısıyla da tarayıcının bir sonraki kareyi sunması için gereken sürenin artmasına neden olabileceği durumlarda, kullanıcı etkileşimi.

Büyük DOM'lerin önemli ölçüde azaltılamayacağı durumlar olduğunu unutmayın. DOM boyutunu küçültmek için uygulayabileceğiniz yaklaşımlar (ör. DOM'nizi düzeltme veya kullanıcı etkileşimleri sırasında DOM'ye ekleme) başlangıçtaki DOM boyutunuzu küçük tutmanız gerekebilir.

Ekran dışındaki öğeleri geç oluşturmak 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 sırasında yapılacak oluşturma işi miktarını sınırlamanın bir yolu, CSS content-visibility özelliğine odaklanmaktır. Bu da öğelerin görüntü alanına yaklaştıkça geç oluşturulmasını etkili bir şekilde sağlar. content-visibility öğesinin etkili bir şekilde kullanılması için biraz alıştırma yapmanız gerekebilir. Ancak, sonucun sayfanızın INP'sini iyileştirebilecek daha düşük oluşturma süresi olup olmadığını araştırmanızı öneririz.

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

HTML olduğunda, HTML ayrıştırması da vardır ve tarayıcı HTML'yi DOM olarak ayrıştırmayı bitirdikten sonra, ona stiller uygulamalı, düzen hesaplamaları yapmalı ve daha sonra 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 tarayıcıya bir akış olarak gelir. Akış, sunucudan gelen HTML yanıtının parçalar halinde geldiği anlamına gelir. Tarayıcı, akışın parçalarının yerini aldıkça artımlı olarak ayrıştırıp bunları parça parça oluşturarak akışı işleme şeklini optimize eder. Bu, sayfa yükleme sırasında tarayıcının dolaylı olarak düzenli ve otomatik olarak verim sağlaması açısından bir performans optimizasyonudur ve size bunu ücretsiz olarak sağlarsınız.

Herhangi bir web sitesine yapılan ilk ziyaret her zaman bir miktar HTML içerse de, yaygın bir yaklaşım minimum HTML bitimiyle başlar ve daha sonra, 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 sonucu olarak gerçekleşir. Buna genellikle tek sayfalık uygulama (SPA) modeli denir. Bu kalıbın dezavantajlarından biri, istemcide JavaScript ile HTML görüntülediğinizde hem bu HTML'yi oluşturmak için gereken JavaScript işleme maliyetini alırsınız hem de tarayıcının bu HTML'yi ayrıştırıp oluşturmayı bitirene kadar vermemesidir.

Bununla birlikte, SPA olmayan web sitelerinin bile etkileşimler sonucunda JavaScript aracılığıyla bir miktar HTML oluşturabileceğini unutmamak gerekir. Bu, istemcide büyük miktarda HTML oluşturmadığınız sürece genellikle bir sorun teşkil etmez ve sonraki karenin görüntülenmesini geciktirebilir. Ancak, tarayıcıda HTML oluşturmaya ilişkin bu yaklaşımın performans üzerindeki etkilerini ve JavaScript aracılığıyla çok fazla HTML oluşturuyorsanız web sitenizin kullanıcı girişine duyarlılığını nasıl etkileyebileceğini anlamak önemlidir.

Sonuç

Sitenizin INP'sini iyileştirme, yinelemeli bir süreçtir. Sahadaki yavaş bir etkileşimi düzelttiğinizde, özellikle de web siteniz çok fazla etkileşim sunuyorsa başka yavaş etkileşimler bulmanız ve bunları da optimize etmeniz gerekir.

INP'yi iyileştirmenin anahtarı sebattan geçer. Zamanla, sayfanızın, kullanıcıların sunduğunuz deneyimden memnun kaldıkları bir yere duyarlılığını alabilirsiniz. Kullanıcılarınız için yeni özellikler geliştirirken, onlara özel etkileşimleri optimize etmek üzere aynı süreci tamamlamanız gerekme olasılığı da yüksektir. Bu süreç zaman ve emek gerektirse de tüm zamanın ve emeklerin karşılığını alır.

David Pisnoy tarafından hazırlanan ve Unsplash lisansı'na uygun olarak değiştirilmiş hero resim Unsplash'ten alınmıştır.