Yükleniyor...
Interaction to Next Paint (INP), Core Web Vitals metriklerinin yeni bir üyesi olarak Mart 2024 tarihinde aramıza katılıyor. Özellikle SEO uzmanları için INP metriğini anlamak ve gerekli optimizasyonları web siteleri üzerinde gerçekleştirmek kritik öneme sahip. Aksi halde CWV denetimlerinden başarısız olabilir, sıralama kayıplarıyla karşılaşabilirsiniz. INP skorunuzu ölçmek ve geliştirmek için izlemeniz gereken adımları tüm detaylarıyla bu yazımızda ele aldık. Keyifli okumalar.
Interaction to Next Paint (INP), kısaca bir web sayfasının kullanıcı etkileşimlerine maksimum kaç milisaniye gecikmeyle görsel geri bildirim sunabildiğini ölçümleyen yeni Core Web Vitals metriğidir. Yani INP, bir kullanıcı etkileşimi ile tarayıcının yanıt olarak sonraki çerçeveyi boyaması arasındaki geçen süreyi temsil eder. Türkçe anlamı ise Sonraki Boyayla Etkileşimdir.
Örneğin;
INP skoru hesaplanırken bir oturumda gerçekleşen tüm kullanıcı etkileşimleri analiz edilir. Bu etkileşimler arasından gecikme süresinin en uzun olduğu etkinlik INP skoru olarak baz alınır. Örneğin, yukarıdaki tüm Case’lerin aynı sayfada ve aynı oturumda gerçekleştiğini varsayalım. 1.Case: 400 ms, 2.Case: 600 ms ve 3.Case:50 ms gecikme süresine sahiptir. Bu durumda INP skoru en yüksek değer olan 600 milisaniye baz alınarak hesaplanacaktır. Dolayısıyla kullanıcıların etkileşime girebileceği tüm alanların tespiti ve analizi oldukça kritik öneme sahiptir.
Google, 2022 yılında duyurduğu bu metrik ile web sayfalarının “yanıt verebilirlik” seviyesini daha gerçekçi bir şekilde ölçümlemeyi hedeflemektedir. INP metriğinin öne çıkan özelliği, sayfada gezinme süresi boyunca tüm etkileşimlerin mevcut skoru değiştirebilme ihtimalidir. Bu özellik kullanıcılara daha optimize ve daha hızlı tepki sürelerine sahip web sitelerini deneyimleme imkanı sunacaktır.
INP’nin temel çalışma prensibi bir sayfadaki tüm etkileşimler içerisinden en uzun yanıt süresine sahip olanın tespit edilmesi ve INP skoru olarak rapor edilmesidir. Eğer bir sayfada 50’nin altında etkileşim varsa bu temel prensip geçerli olacaktır. Kullanıcı fareyle bir butona tıkladığında, mobil cihazından bir ürün görseline dokunduğunda veya klavyeden herhangi bir tuşa bastığında ilgili etkileşimler tetiklenir.
Bir etkileşim tetiklendikten sonra kullanıcı girdisi olay işleyicileri tarafından işleme alınır ve tetiklenen kodlar çalışır. Bu kodlar CPU birimi tarafından işlendikten sonra geriye bir sonuç döner. Ardından dönen sonucun render edilmesi ve sonraki çerçevenin boyanması, yani sonucun ön yüze yansıtılması işlemi gerçekleşir. Böylece kullanıcı etkileşimi başarıyla tamamlanmış olur.
INP metriğinin çalışma sistemi, bir etkileşimin gecikmesini ölçmek için etkileşim sürecinin toplamda kaç milisaniyede tamamlandığını hesaplamak ve en uzun etkileşim olup olmadığını kontrol etmek üzerine kuruludur.
Etkileşime geçilebilecek çok fazla alanın olduğu sayfalarda farklı dinamikler devreye girmektedir. 50 ve üzerinde etkileşimin aynı oturumda tetiklendiği sayfalarda, sunucu kesintileri veya anlık bağlantı hataları nedeniyle etkileşim sürelerinin olumsuz anlamda manipüle olma ihtimali yüksektir.
Örneğin; normal şartlarda 150 ms gecikme süresine sahip olan bir etkileşim, anlık bağlantı hatası nedeniyle 1300 ms gecikmeyle gerçekleşiyorsa INP skorunun 1300 ms olarak raporlanması gerçekçi bir sonuç olmayacaktır.
Bu tarz yanlış raporlanan skorların önüne geçebilmek için INP algoritması, her 50 etkileşimde 1 kez en yüksek gecikmeye sahip etkileşimi yok saymaktadır. Yani 50 etkileşim tetiklendiyse 49 etkileşim, 100 etkileşim tetiklendiyse 98 etkileşim üzerinden INP skoru belirlenmektedir.
Çok sayıda etkileşimin tetiklendiği sitelere örnek olarak; oyun siteleri, online metin & html editör araçları, borsa & kripto para sitelerinin fiyat grafiği içeren sayfaları verilebilir.
INP skoru ölçülürken yalnızca belirli kullanıcı etkileşimleri hesaplamaya dahil edilir. Google tarafından paylaşılan dokümanlara göre aşağıdaki etkileşimler INP skoruna dahildir.
Aşağıdaki etkileşimler ise INP skoruna dahil edilmez;
Yukarıda INP skoruna dahil edilmeyen maddelere ek olarak; klavyedeki “boşluk”, “pageup”, “pagedown” tuşları ile yapılan kaydırma hareketleri INP metriğine dahil olan farklı olayları tetikleyebilir. Ancak bu tetiklemelerin haricinde klavye tuşları aracılığıyla yapılan kaydırma hareketleri INP skoruna dahil değildir.
Kullanıcı deneyimi, günümüzde arama motorları tarafından giderek ön plana çıkarılan ve algoritma güncellemelerinde daha geniş rol oynayan önemli bir faktördür. Özellikle Google’ın 2020 yılında Core Web Vitals’ı kullanıma sunmasıyla birlikte web sitelerinde kullanıcı deneyimi metrikleri daha etkin şekilde ele alınmaktadır.
Core Web Vitals, ilk duyurulduğu tarihten itibaren 2024 yılına kadar LCP, CLS ve FID olarak sıralanan üç temel metrik setiyle işlevini sürdürmekteydi. Bu metrikler kullanıcı deneyiminin “Yükleme Hızı”, “Görsel Kararlılık” ve “Etkileşim” olarak üç kritik yönüne odaklanıyordu. Ancak kullanıcı deneyimini bir üst seviyeye taşıyabilmek için FID metriğinin sorumlu olduğu “Etkileşim” yönünün daha detaylı ve kapsamlı şekilde analiz edilmesi gerekmekteydi.
Tam olarak bu noktada kullanıcı etkileşimlerinin daha detaylı ve kapsamlı analiz edilebilmesi için INP (Interaction to Next Paint) geliştirildi. Bu metriğin en önemli özelliği; FID’nin aksine bir etkileşimin yalnızca giriş gecikmesini ölçmek yerine, başlangıç aşamasından tarayıcının bir sonraki kareyi boyamasına kadar geçen sürenin tamamını ölçmek olduğu için FID metriğinden daha kapsamlı ve daha verimli analizler sunmaktadır.
INP ile birlikte CWV’ın temel odaklarından biri olan "Etkileşim" kavramı yeni bir boyut kazanmıştır. Artık bir etkileşimin “iyi” olarak nitelendirilebilmesi için kullanıcıya gönderilecek görsel geri bildirim baz alınmaktadır. Bu nedenle CWV kapsamında site hızı çalışmaları yürüten SEO uzmanları ve geliştiriciler için, daha hızlı görsel yanıt döndüren web siteleri oluşturmak bir “zorunluluk” haline gelmiştir. Duruma kullanıcıların perspektifinden bakarsak; daha hızlı ve stabil, işlevselliğin ön planda tutulduğu, bekleme sürelerinin kısa olduğu, kullanılabilirliğe odaklanan web sitelerine daha sık rastlanacağını söyleyebiliriz.
FID ve INP arasındaki temel fark; FID metriği kullanıcının tetiklediği ilk etkileşimi dikkate alırken, INP metriği tüm sayfa etkileşimlerini analiz eder. Bu fark INP’nin daha gerçekçi çıktılar üretmesini sağlar.
FID ve INP arasındaki bir diğer önemli fark ise; FID metriği etkileşimin yalnızca Input Delay sürecini temsil ederken INP metriği etkileşimin Input Delay, Processing Time, Presentation Delay süreçlerinin tümünü temsil eder. Bu fark INP’nin daha kapsamlı çıktılar üretmesini sağlar.
INP metriği, FID’nin yetersiz kaldığı bütünsellik noktasında daha iyi bir alternatif olarak karşımıza çıkmaktadır. Oturum boyunca tüm kullanıcı etkileşimlerinin analiz edilmesi ve herhangi bir anda gerçekleşen yavaş etkileşimin yakalanması INP’nin en büyük avantajları arasındadır.
Google tarafından paylaşılan dokümanlara göre INP metriği Mart 2024 tarihinden itibaren FID metriğinin yerini alacaktır. Bu tarihten itibaren Search Console aracında bulunan Önemli Web Verileri raporundan FID metriği kaldırılacak ve yerine INP metriği konumlandırılacaktır. Şu anda Search Console üzerinden her iki metriğin de verilerine ulaşılabilmektedir.
Core Web Vitals denetimlerini başarıyla geçmek için, SEO uzmanları ve site sahiplerinin INP skorlarını Mart 2024’e kadar iyileştirmeleri gerekmektedir.
Web sayfalarının INP denetiminden geçebilmesi için toplam kullanıcı etkileşimlerinin %75’i 200 milisaniyenin altında tamamlanmalıdır.
INP skorunun hesaplanması için öncelikle, kullanıcı tarafından INP kapsamında olan bir etkileşimin tetiklenmesi gerekmektedir. İlgili etkileşim tetiklendiğinde, bir sonraki karenin boyanması ve kullanıcıya gösterilmesi için arka planda bazı süreçler yürütülür. Bu süreçler yürütülürken yaşanan gecikmelerin tümü toplanarak milisaniye cinsinden INP skoru elde edilir.
Bir etkileşimin tetiklenmesi ve sonraki karenin boyanması arasında tarayıcı tarafından arka planda yürütülen süreçler şu şekilde sıralanabilir;
Yukarıdaki tüm süreçlerde milisaniye cinsinden gecikmeler meydana gelir. INP skoru ise bu gecikmelerin toplamından oluşur.
INP skorunun hesaplanması için aşağıdaki formül baz alınabilir;
Interaction to Next Paint (INP) = Giriş Gecikmesi + İşleme Süresi + Sunum Gecikmesi
Örneğin;
Kullanıcı bir ürünün yorumlarını görüntülemek için “review” bölümüne tıkladığında etkileşim aşağıdaki şekilde gerçekleşiyorsa;
Bu etkileşimin INP skoru 230 ms olarak hesaplanacaktır.
Evet, sayfanızda gömülü olan iframe’ler INP skoruna dahildir. Önemli Web Verileri raporundaki CrUX çıktıları, iframe’lerin INP performansını da içermektedir. Dolayısıyla INP optimizasyonu aşamasında sayfalarınıza embed edilen içerikleri de göz önünde bulundurmanızı tavsiye ederiz.
INP skorunu etkileyebilecek iframe’ler şu şekilde örneklendirilebilir;
Ancak saha verilerini toplamak için bir RUM sağlayıcısı kullanıyorsanız, iframe’lerin performansını ölçümleyemeyeceğinizi de hatırlatalım. Güvenlik nedeniyle RUM sağlayıcılarının iframe içeriklerine erişmesine izin verilmez. Eğer INP skorunuzu olumsuz etkileyen bir iframe’e sahipseniz bu durumu RUM kütüphaneleriyle tespit etmeniz mümkün değildir. Bu noktada tüm veri kaynaklarını bütünsel olarak ele almanız önemlidir.
INP metriği, saha verisi ve laboratuvar verisi olarak iki farklı veri türüyle ölçülebilir. Sahadan gelen RUM (Real User Monitoring) ve CrUX verileri direkt olarak web sitesini ziyaret eden kullanıcıların davranışları ölçümlenerek elde edilir. Laboratuvar verileri ise Lighthouse, Web Vitals Extension gibi araçlar ile kullanıcı davranışlar simüle edilerek elde edilir.
INP’yi optimize etmek için ilk olarak saha verileriyle web sitenizin hangi bölümlerine odaklanacağınıza dair içgörüler elde edebilirsiniz. Odak alanlarınızı tespit ettikten sonra laboratuvarda INP skorunuzu olumsuz etkileyen etkileşimleri daha detaylı ele alabilirsiniz.
Sahadan toplanan veriler, gerçek kullanıcıların web sitenizde nasıl bir deneyim yaşadığını analiz edebilmek kritik öneme sahiptir. Saha verileriyle kullanıcıların hangi alanlarda daha fazla gecikme yaşadığını tespit edebilir ve çalışmalarınızı doğru alanlara yönlendirebilirsiniz.
Saha verilerini, CWV için özel üretilmiş RUM kütüphanelerini kullanarak toplayabilir veya CrUX olarak da bilinen Chrome Kullanıcı Deneyimi Raporundan inceleyebilirsiniz. Ancak CrUX raporundan elde edeceğiniz veriler, tek başına INP sorunlarını çözmenize yardımcı olmayabilir. Dolayısıyla hem CrUX hem de RUM (Real User Monitoring) verilerini birlikte değerlendirip analizlerinizi şekillendirmeniz en sağlıklısı olacaktır.
Chrome aracılığıyla toplanan saha verilerine, Google’ın Looker Studio üzerinden sunduğu Chrome Kullanıcı Deneyimi Raporundan erişebilirsiniz. CrUX Raporunu, INP dahil olmak üzere tüm CWV metriklerindeki genel performansınızı incelemek ve aylık gelişiminizi takip etmek için kullanabilirsiniz. Ancak bu raporda URL bazlı çıktılara erişimin mümkün olmadığını da hatırlatalım.
Bir web sitesi için Chrome Kullanıcı Deneyimi Raporunu aşağıdaki adımları izleyerek oluşturabilirsiniz;
Yukarıdaki adımları takip ederek rakiplerin veya sahibi olduğunuz web sitelerinin CrUX veri kümesine erişebilirsiniz. Raporda INP performansınızı incelemek için “Interaction to Next Paint (INP)” sayfasına tıklayın. Çıktıları cihaz bazlı filtreleyerek daha spesifik sonuçlar elde edebilirsiniz.
INP denetiminden başarıyla geçebilmek için kullanıcıların en az %75’i web sitenizde iyi bir deneyim yaşamış olmalıdır. Eğer CrUX raporunda “Good” olarak belirtilen kullanıcı deneyimlerinin oranı %75’in üzerindeyse, bu INP denetiminden başarılı bir şekilde geçtiğiniz anlamına gelir.
Rapordaki Interaction to Next Paint tablosunu incelediğinizde “Good” olarak belirtilen kullanıcı deneyimlerinin oranı %75’in altındaysa, INP skorunuzu geliştirmek için optimizasyon çalışmaları yürütmeniz gerekmektedir. Odak alanınızı belirlemek için raporu cihaz bazlı da incelemenizi tavsiye ederiz.
Google Chrome tarafından toplanan saha verilerine ulaşabileceğiniz bir diğer yer ise PageSpeed Insights (PSI) aracıdır. Bu araç INP ve diğer CWV metrikleriyle ilgili çıktıları URL bazlı sunmaktaktadır. Verimli kullanım önerisi olarak; belirli sayfa türlerinizin performansını analiz etmek için bir örneklem belirleyip PageSpeed Insights aracıyla test edebilirsiniz. Bu sayede kategori, ürün detay, blog içeriği gibi sayfa türlerinizin genel performansını tahminleyebilirsiniz.
Örneğin;
X bir site üzerindeki “Blog Detay” sayfa türünün genel INP performansını PageSpeed Insights aracılığıyla tahminlemek için 3 adet blog içeriği sayfasını örneklem olarak belirleyelim. Kullanıcıların en çok ziyaret ettiği içerikler olan “LOL’de En Çok Oynanan Jungle Karakterler”, “Uncharted Serisi” ve “Windows 10 Nasıl Kurulur?” sayfalarını https://pagespeed.web.dev adresi üzerinden test ettiğimizde aşağıdaki çıktıları elde ediyoruz.
Yukarıdaki görselde örneklem olarak belirlediğimiz tüm içerik sayfalarının benzer INP skorlarına sahip olduğunu görebiliriz. Bu bağlamda, X sitesinin tüm “Blog Detay” sayfalarında INP skorunun geliştirilmesi gerektiği çıkarımını yapabiliriz.
Chrome saha verilerine ulaşabileceğimiz bir diğer yer ise Google Search Console aracı üzerinden erişebileceğiniz Önemli Web Verileri Raporudur. Bu rapor, sahibi olduğunuz web sitesindeki URL’lerin CWV skorlarını tekil veya gruplandırılmış şekilde sunmaktadır. Web sitesinizin URL bazlı CWV performansını incelemek ve gelişimini takip etmek için Önemli Web Verileri Raporunu birincil kaynak olarak kullanabilirsiniz. Öncelikli amacımız bu raporda listelenen tüm URL’lerin “Good (İyi)” olarak nitelendirilmesini sağlamaktır.
Önemli Web Verileri Raporundaki INP performans çıktılarına erişmek için aşağıdaki adımları izleyebilirsiniz;
INP optimizasyonuna “Poor (Yetersiz)” olarak gösterilen sayfa türlerinden başlayabilirsiniz. Eğer web siteniz birden fazla sayfa türünde zayıf performans sergiliyorsa en çok trafik aldığınız sayfa türüne öncelik verebilirsiniz. Örneğin; bir e ticaret sitesinde en çok trafik alan sayfalar genellikle kategori sayfalarıdır. Dolayısıyla bir e ticaret sitesiyle çalışıyorsanız önceliği kategori sayfalarına verebilirsiniz.
Önemli Web Verileri raporunu site hızınızı geliştirirken her zaman takip etmenizi ve çalışmalarınıza bu rapordaki çıktılara göre yön vermenizi tavsiye ederiz. Listelenen tüm URL’ler “Good (İyi)” olarak nitelendirildiğinde, web siteniz CWV denetiminden başarıyla geçmiş demektir.
RUM (Real User Monitoring), entegre olduğu platformu ziyaret eden kullanıcıların etkileşimlerini takip eden ve çıktıları kaydeden bir performans takip uygulamasıdır. RUM ile Core Web Vitals dahil olmak üzere pek çok kullanıcı deneyimi metriği ölçümlenebilmektedir.
INP için en detaylı saha verilerine erişebileceğiniz yöntem RUM kütüphaneleriyle kendi saha verilerinizi toplamaktır. Daha kolay bir kurulum isterseniz RUM (Real User Monitoring) hizmeti veren sağlayıcıları değerlendirebilirsiniz.
INP ölçümü ve analizi için sahada toplamanız gereken önemli veriler şunlardır;
INP skorunu tespit ve optimize edebilmek için yukarıdaki değerleri toplanız gerekmektedir. Ancak kendi RUM Script’inizi yazmak yerine tüm bu kurulumların hazır olarak sunulduğu web-vitals kütüphanesi de kullanabilirsiniz.
Web-vitals Javascript kütüphanesiyle yukarıda belirttiğimiz değerleri hızlı bir şekilde toplayabilirsiniz. Ancak INP’nin yalnızca Event Timing API ve interactionId özelliğini destekleyen tarayıcılarda toplanabildiğini de hatırlatalım. Google’ın web-vitals kütüphanesiyle oluşturduğu aşağıdaki örnek Script’i kullanarak INP verilerini Analytics'e gönderebilirsiniz;
//Kütüphaneyi içeri aktarın:
import {onINP} from 'web-vitals/attribution';
function sendToGoogleAnalytics ({name, value, id, attribution}) {
// attribution nesnesini parçalayın:
const {eventEntry, eventTarget, eventType, loadState} = attribution;
// eventEntry nesnesinden gerekli timing girdilerini alın:
const {startTime, processingStart, processingEnd, duration, interactionId} = eventEntry;
const eventParams = {
// Sayfanın INP değeri:
metric_inp_value: value,
// Sayfa oturumu için benzersiz bir kimlik:
metric_id: id,
// Etkileşimden sorumlu olan ögenin selector dizesi:
metric_inp_event_target: eventTarget,
// Etkileşim türü:
metric_inp_event_type: eventType,
// INP skorunun kaydedildiği andaki sayfanın yüklenme durumu:
metric_inp_load_state: loadState,
// Sayfa yüklendikten sonra etkileşimin gerçekleştiği zaman:
metric_inp_start_time: startTime,
// Event callbacks fonksiyonlarının çalışmaya başladığı an:
metric_inp_processing_start: processingStart,
// Event callbacks fonksiyonlarının çalışmayı bitirdiği an:
metric_inp_processing_end: processingEnd,
// Etkileşimin toplam süresi:
metric_inp_duration: duration,
// Etkileşime atanan ID:
metric_inp_interaction_id: interactionId
};
// Verilerin Google Analytics’e gönderilmesi:
gtag('event', name, eventParams);
}
onINP(sendToGoogleAnalytics);
INP’yi analiz edebileceğiniz diğer bir veri kaynağı ise laboratuvar verileridir. Laboratuvar verileri; gerçek kullanıcı davranışları, bağlantı hızı, cihaz özellikleri gibi etkenler simüle edilerek toplanır. Ancak laboratuvar testlerine, sahada hangi etkileşimlerin yavaş çalıştığını öğrendikten sonra geçmenizi öneririz. Bu sayede doğru etkileşimler üzerinden testler gerçekleştirebilir ve ilgili etkileşimlerin neden yüksek gecikmeye sahip olduğunu tespit edebilirsiniz.
Yavaş etkileşimleri tespit ettikten sonra laboratuvar testlerini Web Vitals Extension, Lighthouse, Chrome DevTools araçlarıyla gerçekleştirebilirsiniz.
Chrome tarayıcılarında desteklenen Web Vitals eklentisiyle en basit şekilde simüle etmek istediğiniz etkileşimlerin INP skorunu tespit edebilirsiniz. Sayfadaki herhangi bir işlevi kullandığınızda INP değeri otomatik olarak eklenti tarafından kaydedilecektir.
Bir kullanıcının yaşayabileceği deneyimi simüle etmek veya en yüksek gecikmeye sahip etkileşimi tespit etmek için sayfanın tüm işlevlerini kullanmaya dikkat edin. Eğer INP skorundan sorumlu olan etkileşimi zaten biliyorsanız direk olarak ilgili etkileşim üzerinde farklı koşulları simüle ederek testler gerçekleştirebilirsiniz.
Eklentiyi yükledikten sonra daha verimli kullanabilmek için şu ayarları yapabilirsiniz;
Bu özelliği aktif ettiğinizde artık etkileşimlerinizle ilgili detaylar console üzerine yansıtılacaktır.
Örneğin;
https://www.amazon.com.tr sitesindeki header menünün INP değerini inceleyelim. Buradaki amaç header menüyü test etmek olduğu için tüm sayfalarda benzer sonuçlar elde edeceğiz. Eklentiyi teste hazırlamak için aşağıdaki aşamaları tamamlamamız gerekiyor;
Mobil cihaz üzerinden header menünün kullanıcıya kaç milisaniye gecikmeyle görsel geri bildirim sunabildiğini tespit etmek için öncelikle kullanıcı etkileşimlerini simüle etmemiz gerekiyor. Bunun için header menüye tıklayarak açılmasını bekliyoruz. Etkileşim tamamlandıktan sonra sağdaki console ekranında INP skorunu görüntüleyebiliriz.
Etkileşim tamamlandıktan sonra INP skorunun 216 ms olarak yansıdığını görüyoruz. İyi bir kullanıcı deneyimi için görsel geri bildirim süresi maksimum 200 ms olmalıdır. Dolayısıyla bu testin bir sonucu olarak; amazon.com.tr üzerinde daha iyi bir INP skoru elde etmek için header menü etkileşim süresinin optimize edilmesi gerektiği çıkarımını yapabiliriz.
Console ekranında INP skorunun üstüne tıklayarak gerçekleşen etkinlikle ilgili detaylı bilgilere erişebilirsiniz.
Chrome DevTools altında bir modül olarak bulunan Lighthouse aracıyla sayfalarınızın INP performansını test edebilirsiniz. INP skorunu ölçümleyebilmek için default kullanımın biraz dışına çıkmanız gerekecek. Lighthouse aracının sunduğu “Timespan” özelliğiyle INP analizlerinizi gerçekleştirebilirsiniz. Eğer odaklanacağınız etkileşimi daha önceden saha verileriyle belirlediyseniz direkt olarak ilgili etkileşimi tetikleyebilirsiniz. Ancak saha verisine sahip değilseniz, kullanıcıların etkileşime geçebileceği tüm alanların INP skorlarını manuel olarak tespit etmeniz gerekecektir. Bu sayede optimizasyona hangi etkileşimden başlamanız gerektiği hakkında bir içgörüye sahip olacaksınız.
Örneğin;
Daha önceden test ettiğimiz amazon.com.tr’nin header menüsünü bu sefer Lighthouse aracıyla analiz edelim. Amazon.com.tr’nin ana sayfasına girdikten sonra Lighthouse aracını açıyoruz. Mod olarak Timespan’ı seçip Categories kısmından yalnızca “Performance” seçeneğini aktif ediyoruz. Ardından “Start timespan” butonuna tıklayıp testi başlattıktan sonra header menü etkileşimini tetikliyoruz. Son olarak “End timespan” butonuyla testi durduruyoruz.
Sayfanın alt kısmında tetiklediğimiz etkileşimin INP skoru yer almaktadır. Bu skor simüle edilen koşullara bağlı olarak diğer analiz araçlayla birebir uyuşmayabilir. Lighthouse aracı, header menüyle etkileşimin INP skorunu 300 ms olarak belirlemiştir. Ancak “İyi” olarak nitelendirilen INP skoru maksimum 200 ms olmalıdır. Sonuç olarak; amazon.com.tr sitesinde header menü etkileşim süresinin optimize edilmesi gerektiği çıkarımını yapabiliriz.
Etkileşimle ilgili daha detaylı bilgi edinmek için INP skorunun hemen altındaki “View Trace” butonuna tıklayabilirsiniz. Bu sayede testin çıktıları “Performance” sekmesine yansıtılacaktır. Etkileşiminizin hangi JS kodlarını tetiklediği ve Task’in tamamlanmasının ne kadar sürdüğü gibi detaylara bu sekmeden erişebilirsiniz.
INP metriğini optimize etmek için öncelikle saha verileriyle en yavaş etkileşimleri tespit edip laboratuvarda bu etkileşimler hakkında detaylı bilgi edinme aşamalarını tamamlamış olmalısınız. Ek olarak yavaş etkileşimlerin hangi sayfa türlerinde tetiklendiği de önemli bir detaydır.
INP optimizasyonuna “Poor (Yetersiz)” olarak gösterilen sayfa türlerinden başlayabilirsiniz. Eğer web siteniz birden fazla sayfa türünde zayıf performans sergiliyorsa en çok trafik aldığınız sayfa türüne öncelik verebilirsiniz. Örneğin; bir e ticaret sitesinde öncelik verilmesi gereken sayfalar “kategori” ve “ürün detay” sayfalarıdır, blog sitelerinde “içerik detay” sayfalarının önemi yüksektir, kurumsal sitelerde ise “hizmetler” sayfalarının performansına öncelik verilmesi gerekir.
Her web sitesi özelinde zayıf INP’ye neden olan pek çok farklı etken olabilir. Ancak genel olarak site hızı gözetilmeden oluşturulmuş JavaScript’e bağımlı çalışan işlevler asıl odak noktamız olacaktır. Şimdi iyi bir INP skoru için optimize edilmesi gereken alanları inceleyelim.
Input Delay bir etkileşimin başlangıcının ilk adımıdır. Kullanıcı bir etkileşim başlattığında olay işleyicilerinin çalışması milisaniye düzeyinde gecikir. Bu gecikmenin optimize edilmesi etkileşimin tamamlanma süresini, yani INP skorunu da doğrudan etkileyecektir.
İdeal giriş gecikmesi FID metriği için 100 milisaniye olarak belirlenmiştir. Ancak ideal INP skorunun maksimum 200 milisaniye olduğunu düşünürsek bu süresinin yarısının Input Delay için ayrılması INP için verimli olmayacaktır. Dolayısıyla her zaman mümkün olan en kısa giriş gecikmesini hedeflemek INP için en doğru yaklaşımdır. Giriş gecikmesini en aza indirgemek için aşağıdaki başlıkları inceleyebilirsiniz.
JavaScript'te kullanılan setTimeout ve setInterval fonksiyonları, giriş gecikmesini etkileyebilecek iki timer işlevdir. İkisi arasındaki temel fark; setTimeout işlevi geri çağrının belirli sürelerde çalıştırılmasını planlarken, setInterval işlevi geri çağrının sonsuza kadar her N milisaniyede bir çağrılması yöntemiyle çalışır. setTimeout genellikle çok sık çalıştırılmadığında sorun oluşturmaz ancak zaman aşımının kullanıcı etkileşimiyle çakışması gecikmelere neden olma ihtimali vardır. setInterval ise tekrarlayan yapısıyla genellikle etkileşimleri engelleme eğilimindedir ve bu da giriş gecikmesini olumsuz etkiler. Sonuç olarak setTimeout işlevini çok sık çalıştırmamak şartıyla kullanmak INP için daha verimli olabilir.
Giriş gecikmesini azaltmanın yollarından bir tanesi de uzun görevleri (long tasks) optimize etmektir. Uzun görevlerin varlığı ana iş parçacığını uzun süre meşgul edeceğinden kullanıcı girdilerinin işlenmesini engelleyerek Input Delay değerini olumsuz etkileyecektir. Daha iyi bir INP skoru için uzun görevleri parçalara bölmenizi ve görevdeki iş miktarını minimuma indirmenizi öneririz.
Bir kullanıcının kısa sürede birçok etkileşimi tetiklediği senaryolarda bu etkileşimler çakışarak giriş gecikmesini artırabilir. Bu çakışmayı optimize etmek için şu yöntemleri deneyebilirsiniz;
Event callbacks, bir etkileşimin tetiklenmesi sonrasında çalışacak kod parçacıklarının doğru zamanda ve doğru sıralamada yürütülmesini sağlayan fonksiyonlardır. Etkileşimlerin “Processing Time” bölümünün daha hızlı bir şekilde tamamlanması için olay geri çağrılarını optimize etmelisiniz.
Callback fonksiyonlarını optimize etmenin en verimli yollarından biri, gereksiz olanları kodları tamamen kaldırmak veya iş yükünü azaltacak şekilde yeniden oluşturmaktır. Eğer bunlar mümkün değilse, ana iş parçacağını uzun süre meşgul etmemek için görevleri “setTimeout” ile bölmeyi deneyebilirsiniz.
INP skoruna en çok fayda sağlayacak callback optimizasyonlarından biri de görsel geri bildirim sağlayan kodların önceliklendirilmesi, geriye kalanların ise bir sonraki göreve ertelenmesidir. Callback fonksiyonlarınızı, öncelikle bir sonraki çerçeveyi boyamak için gereken kodları çalıştıracak şekilde düzenleyebilirsiniz. Render için gerekli olmayan kodları da bir sonraki göreve erteleyebilirsiniz. Aşağıdaki görselden bu optimizasyonun “Presentation Delay” aşamasına olumlu etkisini inceleyebilirsiniz.
Örneğin;
Whatsapp benzeri bir sohbet uygulamasının çalışma mantığı INP odaklı olarak aşağıdaki şekilde kurgulanabilir. Kullanıcının karşıdaki kişiye mesaj gönderdiğini varsayalım.
Yukarıdaki örnekten yola çıkarak kendi fonksiyonlarınızı da benzer mantıkla kurgulayabilirsiniz. Ek olarak; requestAnimationFrame() çağrısı içinde setTimeout() fonksiyonunu kullanmak istediğiniz yapıyı kurmanıza yardımcı olabilir.
Layout Thrashing, web sayfası oluşturulurken Javascript kodlarının DOM üzerinde sürekli düzen değişikliği yapması ve tarayıcının öge konumlarını/boyutlarını verimli şekilde hesaplayamaması sonucunda ortaya çıkan bir performans sorunudur. Bu sorun web sayfasının yavaş yüklenmesine ve kullanıcı etkileşimlerinin gecikmesine neden olmaktadır. Dolayısıyla INP performansını doğrudan etkileyen sorunlardan biridir.
Layout Thrashing sorunundan mümkün olduğunca kaçınmak için DOM üzerinde okuma yazma işlerini azaltmak ve bu işlemleri toplu olarak gerçekleştirmek gerekir. Örneğin; DOM elemanlarının stillerini bir döngü yardımıyla okuyorsanız, stil güncellemelerini döngü tamamlandıktan sonra tek seferde uygulayabilirsiniz. Ancak bu güncellemeleri okuma işlemiyle birlikte döngü içerisine yapmaya çalışırsanız bu durum Layout Thrashing sorununa yol açabilir.
Tarayıcı, DOM elemanlarının stillerini değiştirmek için JavaScript’ten bir komut aldığında stil kuyruğu oluşturur ve değişiklikleri toplu olarak yapar. Ancak DOM elemanlarının stillerini okumak için bir komut aldığında bunu hemen yapmak zorundadır. Eğer stil değiştirme isteğinin arasına bir stil okuma isteği girerse, tarayıcı tek tek layout hesaplaması yapmak durumda kalabilir. Bu durum da performansı olumsuz etkiler.
Eğer bir JavaScript kodu ile Layout Thrashing sorununu simüle etmek gerekirse;
Aşağıdaki kod bir döngü içerisinde DOM elemanlarının stillerini tekrarlı olarak okumaya değiştirmeye çalışmaktadır. Bu durumda tarayıcı sürekli olarak layout hesaplaması yaparak performansı düşürmektedir.
// Layout Thrashing örneği
var elements = document.querySelectorAll(".box");
for (var i = 0; i < elements.length; i++) {
// Aşağıdaki Kod Ögenin Genişliği Okunuyor
var width = elements[i].offsetWidth;
// Burada İse Genişlik Sürekli Güncelleniyor.
elements[i].style.width = (width + 10) + "px";
}
Aşağıda tarayıcının stil kuyruğu oluşturup güncellemeleri tek seferde yapmasına olanak sağlayacak bir kod yapısını görebilirsiniz.
// Layout Thrashing çözümü
var elements = document.querySelectorAll(".box");
var widths = [];
// Stil okuma işlemlerini toplu olarak yapılmalı.
for (var i = 0; i < elements.length; i++) {
widths.push(elements[i].offsetWidth);
}
// Stil değiştirme işlemlerini de toplu olarak yapılmalı.
for (var i = 0; i < elements.length; i++) {
elements[i].style.width = (widths[i] + 10) + "px";
}
Bir etkileşimin gerçekleşmesi için son süreç olan Sunum Gecikmesi, event callbacks fonksiyonlarının tamamlanmasından tarayıcının bir sonraki çerçeveyi boyadığı noktaya kadar uzanır. Bu sürecin INP odaklı olarak nasıl optimize edileceğini inceleyelim.
DOM, bir web sayfası elemanlarının ağaç yapısı şeklinde temsil edilmesini ve bu elemanlara sonradan erişilebilmesini sağlayan bir doküman nesne modeldir. Etkileşimli ve dinamik web sayfaları oluşturmak için DOM yapısı kritik öneme sahiptir. Sayfanın HTML içeriği ne kadar büyük olursa DOM boyutu da o kadar artacaktır.
Ancak DOM boyutu ne kadar artarsa, sayfanın yüklenmesi ve daha sonra güncellenmesi de o kadar zor olacaktır. Güncelleme aşamasında yaşanan gecikmeler de doğrudan INP skorunu etkileyecektir. Dolayısıyla iyi bir INP skoru için DOM boyutunun küçük ve sade tutulması gereklidir. Ek bir kazanım olarak bu geliştirme diğer tüm Core Web Vitals metriklerini de olumlu etkileyecektir.
Lighthouse verilerine göre ideal sınır 800 düğümdür. Eğer web sayfanızda 800 düğümden fazla varsa bu durum Lighthouse aracına uyarı olarak yansır. 1400 düğümden sonrası ise hata olarak görüntülenir. Eğer SEO açısından rekabetin yüksek olduğu bir sektördeyseniz her zaman en iyisini yani 800 node altını hedeflemenizi öneririz.
DOM boyutunu küçültmenin en temel yolu, gereksiz olarak oluşturulan iç içe ögeleri sadeleştirerek DOM derinliğini azaltmaktır. Aşağıda çok fazla gereksiz div etiketinin iç içe kullanıldığı bir örneği inceleyebilirsiniz.
<table>
<tr>
<td>
<div>
<div>
<p>Veri 1</p>
</div>
</div>
</td>
<td>
<div>
<div>
<p>Veri 2</p>
</div>
</div>
</td>
</tr>
</table>
Tablo yapısını kullanırken gereksiz iç içe etiketleri eklemek, hem kod okunurluğunu düşürebilir hem de gereksiz DOM derinliği oluşturabilir.
<table>
<tr>
<td>Veri 1</td>
<td>Veri 2</td>
</tr>
</table>
Mümkün olduğunca en sade yapıyı kurgulamak, INP ve diğer Core Web Vitals metriklerinin optimizasyonu için önemlidir. Yukarıda bu tablo yapısının basit bir şekilde nasıl kurgulanabileceğini inceleyebilirsiniz.
Bir CSS özelliği olan content-visibility, sayfa yükleme sırasında görünür olmayan elemanların render sürecini erteleyebilmenizi sağlar. Bu da tarayıcının render yükünü azaltarak sayfaların daha hızlı yüklenmesini ve INP skorunun iyileşmesini sağlar.
content-visibility’nin alabileceği değerler şunlardır;
content-visibility şu şekilde kullanılabilir;
.class {
content-visibility: visible;
content-visibility: hidden;
content-visibility: auto;
}
Aşağıdaki görselde content-visibility uygulaması yapılan bir web sayfasının Rendering ve Painting performansındaki artışı görebilirsiniz. Sayfanın ilk yüklenmesinde render süresinden 7 kat tasarruf edilmiştir.
content-visibility şu anda aşağıdaki tarayıcılarda desteklenmektedir;
ResizeObserver bir elemanın genişliği veya yüksekliğindeki değişiklikleri izlemenize ve buna uygun olarak kodunuzu tetiklemenize olanak tanır. Eğer ResizeObserver ile çok fazla elemanı izlemeye çalışırsanız veya callback fonksiyonunda çok fazla işlem yaparsanız web sayfanızın performansı olumsuz etkilenebilir. ResizeObserver kullanımını optimize etmek için şu noktalar dikkat edebilirsiniz;
INP metriğinin yeni sürümlerinde yapılan güncellemeler, hem analiz hem de optimizasyon tarafında değişikliğe gitmenizi gerektirebilir. Dolayısıyla bu güncellemeleri düzenli olarak takip etmenizi ve potansiyel olarak sizi olumsuz etkileyebilecek yeni gelişmeler için önlem almanızı öneririz.
Tüm Core Web Vitals metriklerinde olduğu gibi INP değişiklik günlüğüne de https://chromium.googlesource.com adresi üzerinden erişebilirsiniz.
Google Analytics 4'ü daha yakından tanıyın! GA4'ün işletmenize nasıl avantajlar sağlayabileceğini öğrenin ve web sitenizi bir üst seviyeye t...
Google Mayıs 2022 geniş çekirdekli algoritma güncellemesi yayına alındı. Peki bu algoritma güncellemeleri hangi kapsamları içeriyor ve web s...
Beta sürümdeki Lighthouse 6 ile gelen yeni metrikler ve hayatımızda var olan metriklerin puanlarını nasıl arttırabiliriz?
POPÜLER YAZILAR