INP Nasıl İyileştirilir? Etkileşim Gecikmesini Düşürmenin Yolları

Bu rehberde Talha Aslan ve ekibi olarak INP iyileştirme sürecini sahada uyguladığımız sırayla anlatıyoruz. Önce metriğin neyi ölçtüğünü netleştiriyoruz. Ardından uzun görevler, ağır JavaScript, üçüncü taraf betikler ve olay işleyicileri gibi asıl suçluları tek tek ele alıyoruz. Core Web Vitals kavramının genel tanımını merak ediyorsanız Core Web Vitals nedir yazımıza göz atabilirsiniz; burada yalnız etkileşim gecikmesine odaklanıyoruz.

INP tam olarak neyi ölçer?

INP, ziyaretçinin sayfadaki tüm ziyareti boyunca yaptığı etkileşimlerin gecikmesini izler. web.dev INP belgesine göre raporlanan değer, aykırı değerler dışarıda bırakıldığında gözlenen en uzun etkileşimdir. Yani tek bir hızlı tıklama sonucu kurtarmaz; en kötü deneyim belirleyici olur.

Ölçüme giren etkileşimler üç türdür:

• Fareyle yapılan tıklamalar.
• Dokunmatik ekrandaki dokunmalar.
• Fiziksel ya da ekran klavyesindeki tuş basışları.

Öte yandan fareyle üzerine gelme, yakınlaştırma ve kaydırma INP hesabına girmez. Belge ayrıca aykırı değerler için bir kural tanımlar: her 50 etkileşimde en yüksek bir tanesi yok sayılır. Çoğu sayfada 50'den az etkileşim olduğu için pratikte en kötü etkileşim doğrudan sonucu belirler. Bu nedenle tek bir ağır menü düğmesi bile tüm sayfanın puanını aşağı çekebilir.

INP, daha önce kullanılan First Input Delay (ilk giriş gecikmesi, FID) metriğinin yerini aldı. FID yalnız ilk etkileşimin giriş gecikmesine bakıyordu. INP ise tüm etkileşimleri ve gecikmenin tamamını hesaba katar; dolayısıyla daha zorlu ama daha dürüst bir ölçüdür.

INP için iyi, orta ve kötü eşikler nelerdir?

Google, eşikleri saha verisinin 75. yüzdelik dilimine göre değerlendirir ve mobil ile masaüstünü ayrı tutar. Yani ziyaretlerin dörtte üçü hedefin altında kalmalıdır. Aşağıdaki tablo web.dev belgesindeki sınırları özetler.

Bu sınırlar değişebilir; güncel değeri her zaman web.dev ve Google Search Central sayfalarından kontrol edin. Ayrıca mobil ve masaüstü sonuçlarını karıştırmayın. Masaüstünde iyi görünen bir sayfa, orta seviye bir telefonda rahatlıkla kötü bölgeye düşebilir. Bu yüzden biz denetimlerde her zaman önce mobil satırına bakarız.

Bir etkileşim hangi üç aşamadan oluşur?

Her etkileşimin gecikmesi üç parçanın toplamıdır. web.dev INP optimizasyon rehberi bu ayrımı temel alır; çünkü her parçanın çözümü farklıdır.

1. Giriş gecikmesi (input delay): Kullanıcı tıkladıktan sonra olay işleyicileri çalışmaya başlayana kadar geçen bekleme. Genellikle ana iş parçacığındaki uzun görevlerden kaynaklanır.
2. İşleme süresi (processing duration): Olay işleyici fonksiyonlarının çalışması için geçen süre.
3. Sunum gecikmesi (presentation delay): Fonksiyonlar bittikten sonra bir sonraki karenin ekrana gelmesine kadar geçen süre.

Örneğin bir sepete ekle düğmesi yavaşsa, önce hangi aşamanın uzun olduğunu bulmanız gerekir. Giriş gecikmesi uzunsa sorun başka bir kodun ana iş parçacığını tutmasıdır. İşleme süresi uzunsa düğmenin kendi kodu ağırdır. Sunum gecikmesi uzunsa tarayıcı büyük bir DOM ağacını yeniden çizmekte zorlanıyordur. Kısacası doğru teşhis, yanlış yere emek harcamanızı önler.

Saha verisi ile laboratuvar verisi neden farklı çıkar?

Saha verisi gerçek kullanıcılardan gelir; laboratuvar verisi ise tek bir cihazda, tek bir ağda yapılan testtir. web.dev üzerindeki saha ve laboratuvar farkı belgesi bu ayrımı ayrıntılı anlatır. INP açısından en kritik nokta şudur: laboratuvar testi kullanıcının ne zaman tıklayacağını bilemez.

Belgeye göre Total Blocking Time (toplam engelleme süresi, TBT) bir vekil göstergedir, INP'nin yerine geçmez. Üstelik sayfa çok iyi bir TBT değerine sahipken bile INP kötü çıkabilir. Bu nedenle önceliği saha verisine verin, laboratuvarı yalnız teşhis için kullanın.

Search Console'da INP sorununu nasıl görürsünüz?

Önemli Web Verileri raporu (Core Web Vitals report), Search Console içinde gerçek kullanıcı verisini mobil ve masaüstü olarak ayrı gösterir. Search Console Yardım belgesine göre rapor benzer sayfaları gruplar ve her gruba tek durum verir: Poor (kötü), Need improvement (iyileştirme gerekli) ve Good (iyi).

Grubun durumu LCP, INP ve CLS arasındaki en kötü metriğe göre belirlenir. Veriler CrUX raporundan gelir ve son 28 günü yansıtır. Dolayısıyla bugün yaptığınız düzeltme raporda hemen görünmez. Rapor ayrıca dizindeki sayfaların bir örneklemidir, eksiksiz liste değildir.

Raporu ilk kez açıyorsanız temel kullanım için Google Search Console rehberimizden başlayabilirsiniz. Mülkünüz yeniyse ya da trafik düşükse veri ekranı boş kalabilir; bu durumu yeterli kullanım verisi yok yazımızda ayrıca ele aldık. Rapordan bir URL grubu seçtiğinizde örnek adresleri görürsünüz. Bu örnekler, laboratuvarda hangi sayfayı test edeceğinizi gösteren en değerli ipucudur.

Mobil cihazlarda INP neden daha kötü çıkar?

Mobil cihazlarda işlemci gücü masaüstüne göre genellikle daha sınırlıdır. Aynı JavaScript kodu telefonda daha uzun sürer, dolayısıyla uzun görev sayısı artar. Bu yüzden Search Console'da mobil satırı çoğu zaman masaüstünden daha kötü görünür.

web.dev üzerindeki saha ve laboratuvar farkı belgesi ilginç bir ayrıntıya da dikkat çeker. Mobil için hazırlanmamış sayfalarda tarayıcı, dokunma ile olay işleyicisi arasına ek bir bekleme ekleyebilir. Bu bekleme uzun görev sayılmadığı için TBT değerinde görünmez, ama INP'yi artırır. Belgeye göre mobil görünüm alanı (viewport) etiketini doğru tanımlamak bu gecikmeyi önler.

Pratikte şunu öneririz: testlerinizi ekibin güçlü bilgisayarında değil, kitlenizin kullandığı türden orta seviye bir telefonda yapın. Ayrıca sitenizin mobil uyumunu genel olarak gözden geçirin. Örneğin küçük ekranda açılan menülerin, kayan panellerin ve sabit alt çubukların etkileşim anında ne kadar iş yaptığını tek tek ölçün. Böylece sorunun cihazdan mı yoksa koddan mı kaynaklandığını daha net ayırırsınız.

Yavaş etkileşimi laboratuvarda nasıl yeniden üretirsiniz?

Saha verisi size hangi sayfa grubunun sorunlu olduğunu söyler, ama hangi düğmenin yavaş olduğunu çoğu zaman söylemez. Bu yüzden ikinci adım, sorunu kendi tarayıcınızda yeniden üretmektir. web.dev rehberi, sık kullanılan kullanıcı akışlarını elle denemenizi önerir.

• Menüyü açın, filtreleri seçin, formu doldurun, sepete ürün ekleyin.
• Bu etkileşimleri sayfa yüklenirken de deneyin; ana iş parçacığı en çok o sırada meşguldür.
• Testi orta seviye bir telefonda ya da tarayıcının işlemci yavaşlatma seçeneğiyle yapın.
• Geliştirici araçlarının performans kaydında uzun görevleri ve etkileşim satırını inceleyin.

Örnek senaryo: example.com adresindeki bir mağazada mobil INP kötü çıksın. Ekip kategori sayfasında filtre kutusuna dokunduğunda kaydı başlatır. Kayıtta filtrenin tüm ürün listesini baştan çizdiği görülür. Böylece sorun "site yavaş" gibi belirsiz bir ifadeden çıkar ve tek bir fonksiyona iner. Laboratuvar araçlarının genel kullanımı için Lighthouse ile performans testi yazımıza bakabilirsiniz.

INP'yi kendi ziyaretçilerinizden nasıl ölçersiniz?

CrUX verisi değerlidir, ama size hangi düğmenin yavaş olduğunu söylemez. web.dev rehberi bu nedenle gerçek kullanıcı ölçümü (RUM, real user monitoring) yapan bir çözümü en iyi başlangıç noktası olarak görür. Kendi ölçümünüz olduğunda her yavaş etkileşimin hangi öğede yaşandığını kaydedebilirsiniz.

Pratikte üç bilgiyi toplamanızı öneririz:

• Etkileşimin gerçekleştiği öğe, örneğin filtre kutusu ya da menü düğmesi.
• Etkileşimin türü: tıklama, dokunma ya da tuş basışı.
• Gecikmenin üç aşamaya dağılımı: giriş gecikmesi, işleme süresi ve sunum gecikmesi.

Örnek senaryo: example.com sitesinde ölçüm verisi en kötü etkileşimlerin çoğunun mobil menüde toplandığını gösteriyor. Ekip böylece tüm siteyi taramak yerine tek bir bileşene odaklanıyor. Ayrıca ölçümü kurarken kişisel veri toplamamaya dikkat edin; amaç kullanıcıyı değil, etkileşimi tanımaktır. Kendi ölçümünüz yoksa PageSpeed Insights içindeki CrUX verisi boşluğu kısmen doldurur.

INP iyileştirme sırasında en sık hangi hatalar yapılır?

Sahada INP iyileştirme çalışmalarında aynı hataları tekrar tekrar görüyoruz. Birincisi yalnız laboratuvar puanına bakmaktır. Lighthouse puanı yükselir, ekip işi bitti sanar, ama saha verisi yerinden kıpırdamaz. Çünkü gerçek kullanıcının tıkladığı an testte hiç yaşanmamıştır.

İkincisi tüm siteyi aynı anda düzeltmeye çalışmaktır. Bu yaklaşım hem geliştirici zamanını tüketir hem de hangi değişikliğin işe yaradığını görmenizi engeller. Bunun yerine en çok trafik alan şablonu seçin, orada sonucu kanıtlayın, ardından diğer şablonlara geçin.

Üçüncüsü masaüstü sonucuyla yetinmektir. Ekibin kullandığı güçlü bilgisayarlar sorunu gizler. Dördüncüsü ise ölçüm etiketlerini körü körüne kapatmaktır; bu, pazarlama ekibinin verisini bozar. Son olarak değişikliği yayına alıp doğrulamayı başlatmayı unutmak da sık görülen bir eksiktir. Kısacası plan, ölçüm ve takip birlikte yürümezse emek boşa gider.

Giriş gecikmesini düşürmek için ne yapmalısınız?

Giriş gecikmesi, tıklamanın sırada beklediği süredir. Tarayıcı o anda başka bir işi bitirmeye çalışıyorsa sizin tıklamanız bekler. Bu yüzden çözüm, ana iş parçacığını boş tutmaktır. web.dev rehberi açılışta değerlendirilen betik miktarını sınırlamayı ve uzun görevleri azaltmayı önerir.

Pratikte şu soruları sorarız. Sayfa açılırken hemen gerekmeyen kod var mı? Görünmeyen bir bölümün betiği baştan yükleniyor mu? Zamanlayıcıyla sürekli çalışan bir kod parçası ana iş parçacığını meşgul ediyor mu? Ayrıca analiz ve reklam etiketleri tıklama anında ek iş yapıyor mu?

Örneğin sayfanın alt kısmındaki yorum widget'ı ilk anda yüklenmek zorunda değildir. Onu kullanıcı o bölüme yaklaşınca yüklerseniz açılıştaki yük hafifler. Böylece ilk tıklamalar sırada beklemez. Kod ayırma ve erteleme tekniklerinin genel çerçevesini JavaScript optimizasyonu yazımızda anlattık; burada amaç yalnız etkileşim anını rahatlatmaktır.

Uzun görevler INP'yi neden bozar?

web.dev uzun görevler belgesine göre 50 milisaniyeden uzun süren her görev uzun görevdir. Ana iş parçacığı aynı anda yalnız bir görevi işleyebilir. Dolayısıyla 300 milisaniyelik bir görev çalışırken gelen tıklama, görev bitene kadar bekler.

Uzun görevler genellikle şu kaynaklardan doğar:

• Büyük JavaScript paketlerinin ayrıştırılması ve çalıştırılması.
• Tek seferde yüzlerce öğeyi oluşturan liste ve tablo kodları.
• Sayfa açılışında bir arada çalışan analiz, reklam ve sohbet betikleri.
• Her tıklamada tüm durumu yeniden hesaplayan arayüz çerçeveleri.

Ancak uzun görev kendi başına hata değildir; sorun, kullanıcının etkileşimiyle çakıştığında ortaya çıkar. Bu nedenle hedef, büyük işleri küçük parçalara bölmek ve aralarda tarayıcıya nefes aldırmaktır. Bir sonraki bölüm tam olarak bunu anlatıyor.

Ana iş parçacığına nasıl yol verirsiniz?

Yol vermek (yielding), işinize kısa bir ara verip tarayıcının daha önemli işleri yapmasına izin vermektir. Böylece bekleyen tıklama işlenir, ekran güncellenir, sonra kodunuz kaldığı yerden devam eder. web.dev rehberi bunu INP iyileştirmenin ana tekniklerinden biri sayar.

Belgeler iki yaklaşım anlatır. Birincisi setTimeout ile işin geri kalanını yeni bir göreve atmaktır. Ancak bu yolla ertelenen iş kuyruğun sonuna gider ve başka görevler önce çalışır. İkincisi scheduler.yield() fonksiyonudur. Belgeye göre bu fonksiyonun devamı önceliklidir; böylece üçüncü taraf betikler gibi başka kaynaklar kodunuzun sırasını bozamaz.

Desteklemeyen tarayıcılar için belge setTimeout tabanlı bir yedek ya da hazır bir polyfill paketi önerir. Ayrıca bir zamanlar önerilen isInputPending() yaklaşımını artık önermediğini açıkça yazar. Rehberdeki şu cümle de pratikte işinize yarar: ayrım yapmadan yol vermek, hiç yol vermemekten iyidir. Kısacası mükemmel zamanlamayı beklemeyin; uzun bir döngüyü parçalara bölmek bile fark yaratır.

Olay işleyicilerini nasıl hafifletirsiniz?

İşleme süresi uzunsa sorun doğrudan tıklanan öğenin kodundadır. web.dev rehberinin önerisi nettir: önce görsel güncellemeyi yapın, geri kalanı sonraya bırakın. Kullanıcı tıklamanın işe yaradığını hemen görmelidir.

Örneğin bir "favorilere ekle" düğmesini düşünün. Kalbin dolması anında olmalıdır. Sunucuya kayıt isteği, analiz olayı ve öneri listesinin yenilenmesi ise birkaç yüz milisaniye sonra çalışabilir. Rehber bu iş için requestAnimationFrame içinde bir setTimeout kurmayı anlatır; böylece görsel değişiklik bir sonraki karede çizilir, ağır iş ondan sonra gelir.

• Aynı olaya bağlı gereksiz işleyicileri temizleyin.
• Her tuş basışında arama yapan kutularda isteği kısa bir bekleme süresine bağlayın.
• Tıklamada tüm sayfanın durumunu değil, yalnız değişen bölümü güncelleyin.
• Ağır hesaplamaları mümkünse arka plan işçisine (web worker) taşıyın.

Böylece işleme süresi kısalır ve kullanıcı geri bildirim alır. Üstelik bu değişiklikler çoğu zaman tasarımı değiştirmeden yapılabilecek kod düzenlemeleridir.

Ağır JavaScript paketleri INP iyileştirme sürecini nasıl etkiler?

Ağır JavaScript, INP iyileştirme çalışmasının en sık karşılaştığımız engelidir. Paket ne kadar büyükse tarayıcı onu ayrıştırmak, derlemek ve çalıştırmak için o kadar uzun süre ana iş parçacığını kullanır. Bu süre boyunca gelen her tıklama bekler.

Biz denetimde önce kullanılmayan kodu ararız. Geliştirici araçlarının kapsam (coverage) görünümü, açılışta yüklenip hiç çalışmayan kodu gösterir. Ardından sayfaya özel paket ayırma fırsatlarına bakarız. Örneğin ödeme adımının kodu ana sayfada yüklenmek zorunda değildir.

Öte yandan istemci tarafında büyük miktarda HTML üretmek de risklidir. web.dev rehberi, JavaScript ile çok fazla HTML çizmenin sunum gecikmesini artırabileceği konusunda uyarır. Dolayısıyla sunucuda hazırlanabilecek içeriği tarayıcıya bırakmamak, hem yükleme hem etkileşim tarafında fayda sağlar. Sitenin genel hızının sıralamayla ilişkisini merak ediyorsanız site hızı SEO'yu nasıl etkiler yazımız bu bağlamı tamamlar.

Üçüncü taraf betikler etkileşimi nasıl yavaşlatır?

Analiz, reklam, sohbet penceresi, ısı haritası ve çerez bildirimi gibi araçlar sizin yazmadığınız kodu sayfaya ekler. Bu betikler de aynı ana iş parçacığını kullanır. Dolayısıyla kendi kodunuz hafif olsa bile üçüncü taraf bir betik tıklama anında uzun görev başlatabilir.

Bu yazıda konuyu yalnız INP açısından ele alıyoruz. Pratik kontrol listemiz şöyledir:

1. Etiket yöneticisindeki tüm etiketleri listeleyin ve artık kullanılmayanları kaldırın.
2. Her etiketin hangi sayfada gerçekten gerekli olduğuna karar verin.
3. Sohbet penceresi gibi araçları kullanıcı etkileşiminden sonra yükleyin.
4. Tıklama dinleyen etiketlerin her tıklamada ne kadar iş yaptığını performans kaydında ölçün.
5. Kaldıramadığınız betiklerin sağlayıcısında daha hafif yükleme seçenekleri olup olmadığını kontrol edin.

Ancak dönüşüm ölçümünü kapatmak bir çözüm değildir. Amaç ölçümden vazgeçmek değil, ölçümün kullanıcıyı bekletmemesini sağlamaktır. Bu dengeyi kurarken pazarlama ve geliştirme ekiplerinin aynı masada olması gerekir.

Sunum gecikmesini azaltmanın yolları nelerdir?

Sunum gecikmesi, kodunuz bittikten sonra tarayıcının yeni kareyi hazırlaması için geçen süredir. Tarayıcı stilleri hesaplar, yerleşimi çıkarır ve ekranı boyar. Sayfa ne kadar karmaşıksa bu iş o kadar uzar.

web.dev rehberi bu aşama için iki ana öneri verir. Birincisi DOM ağacını küçük tutmaktır. İkincisi content-visibility CSS özelliğiyle ekran dışındaki öğelerin çizimini ertelemektir. Böylece tarayıcı yalnız görünen bölümle uğraşır.

Örneğin uzun bir ürün listesinde yüzlerce kartın hepsini aynı anda çizmek yerine görünen kartlara odaklanabilirsiniz. Ayrıca büyük alanları etkileyen animasyonlar ve ağır gölge, bulanıklık efektleri de boyama maliyetini artırabilir. Yani tasarım kararları da INP sonucunu etkiler. Bu yüzden biz performans bulgularını tasarım ekibiyle de paylaşırız.

DOM boyutu ve düzen tekrarı neden önemlidir?

Düzen tekrarı (layout thrashing), kodun bir öğenin stilini değiştirip hemen ardından aynı görev içinde boyut ya da konum okumasıdır. Tarayıcı bu durumda yerleşimi zorunlu olarak hemen yeniden hesaplar. web.dev rehberi buna zorunlu eş zamanlı yerleşim der ve bundan kaçınmanızı önerir.

Sorun genellikle bir döngü içinde ortaya çıkar. Örneğin her kart için önce yükseklik okuyup ardından yeni yükseklik yazan bir kod, her adımda yerleşimi baştan hesaplatır. Okumaları bir arada, yazmaları bir arada yaparsanız tarayıcı tek hesaplamayla işi bitirir.

Büyük DOM ağacı ise her stil değişikliğinin maliyetini artırır. Menüler, gizli sekmeler ve kullanılmayan modal pencereler sayfada gereksiz düğüm biriktirir. Dolayısıyla temizlik yaparken yalnız görünen içeriğe değil, gizli bekleyen yapılara da bakın. Kısacası daha yalın bir sayfa hem daha hızlı çizilir hem de daha az sürprizle yönetilir.

Hazır temalarda INP iyileştirme nasıl ilerler?

Hazır tema ve sayfa oluşturucu kullanan sitelerde INP iyileştirme biraz farklı ilerler. Çünkü sorunlu kodun önemli kısmı size ait değildir; tema, eklenti ya da sayfa oluşturucudan gelir. Bu durumda kodu tek tek yeniden yazmak yerine önce envanter çıkarırsınız.

Biz şu sırayı izleriz. Önce aktif eklentileri listeleriz ve her birinin hangi sayfada betik yüklediğine bakarız. Ardından kaydırıcı, sekme, açılır pencere gibi etkileşimli bileşenleri performans kaydında test ederiz. Sonra gereksiz bileşenleri kaldırır, kalanları yalnız ihtiyaç duyulan sayfalarda yükleriz.

Öte yandan önbellek ve küçültme eklentileri çoğu zaman yükleme metriklerine yardım eder, ama INP'yi tek başına çözmez. Çünkü INP, kodun ne kadar hızlı indiğiyle değil, tıklama anında ne kadar iş yaptığıyla ilgilidir. Yani bir eklenti kurup sorunun bittiğini varsaymayın; mutlaka saha verisiyle doğrulayın.

Adım adım INP iyileştirme planı nasıl kurulur?

Sahada uyguladığımız INP iyileştirme planını tek listede topladık. Sıra önemlidir; çünkü her adım bir sonrakinin hedefini daraltır.

1. Search Console'daki Önemli Web Verileri raporundan INP sorunu olan mobil URL gruplarını çıkarın.
2. Her gruptan örnek adresleri seçin ve trafik değerine göre sıralayın.
3. Bu sayfalarda sık kullanılan etkileşimleri listeleyin: menü, filtre, form, sepet.
4. Etkileşimleri yavaşlatılmış işlemciyle performans kaydında yeniden üretin.
5. Her yavaş etkileşimde giriş gecikmesi, işleme süresi ve sunum gecikmesi paylarını not edin.
6. Uzun görevleri bölün, olay işleyicilerinde görsel güncellemeyi öne alın.
7. Gereksiz üçüncü taraf betikleri kaldırın ya da erteleyin.
8. DOM boyutunu azaltın ve düzen tekrarı yapan kodu düzeltin.
9. Değişiklikleri yayına alın ve raporda doğrulama sürecini başlatın.
10. Sonraki 28 gün boyunca saha verisini izleyin, gerilemeleri kaydedin.

Bu planı kendi sitenizde ekip olarak yürütmek isterseniz SEO danışmanlığı hizmetimizde teknik denetimi, geliştiriciye verilecek iş listesini ve sonrasındaki takibi biz üstleniyoruz. Böylece düzeltme bir kez yapılıp unutulmaz.

Düzeltmeyi Search Console'da nasıl doğrularsınız?

Düzeltmeyi yayına aldıktan sonra rapordaki ilgili sorun satırından doğrulama başlatırsınız. Search Console Yardım belgesine göre doğrulamayı başlatmak 28 günlük bir izleme dönemi açar (Start Tracking). Bu süre içinde sorun hiçbir URL'de görünmezse düzeltilmiş sayılır.

Doğrulama durumları şunlardır: Started (başladı), Passed (geçti) ve Failed (başarısız). Başarısız sonuç, sorunun hâlâ bazı adreslerde sürdüğünü gösterir. Bu durumda örnek adreslere geri dönüp hangi etkileşimin hâlâ yavaş olduğunu yeniden test edersiniz.

Ayrıca beklentiyi doğru kurun. Veri son 28 günü yansıttığı için iyileşme kademeli görünür. İlk günlerde eski ziyaretlerin ağırlığı devam eder. Dolayısıyla bir hafta sonra sonuç değişmedi diye düzeltmeyi geri almayın. Laboratuvarda doğruladığınız iyileşmeyi sahada da görmek için sabırla izleyin.

INP iyi olursa sıralama garanti olur mu?

Hayır, garanti olmaz. Google Search Central Core Web Vitals sayfası site sahiplerine iyi Core Web Vitals değerleri hedeflemelerini önerir ve bunun sıralama sistemlerinin ödüllendirmeyi amaçladığı sayfa deneyimiyle uyumlu olduğunu söyler. Ancak sayfa deneyimi, birçok sinyalden yalnız biridir.

Yani içerik kalitesi, arama niyetine uyum ve güven sinyalleri zayıfsa hızlı bir sayfa tek başına üst sıraya çıkmaz. Öte yandan aynı kalitedeki iki sayfadan kullanıcıyı bekletmeyen sayfa ziyaretçi açısından açıkça daha iyidir. Bu yüzden biz INP çalışmasını sıralama vaadiyle değil, kullanıcı deneyimi ve dönüşüm sağlığı gerekçesiyle öneririz.

Teknik SEO'nun bütününde hızın yerini görmek isterseniz teknik SEO ipuçları yazımız genel çerçeveyi verir. Yükleme tarafındaki karşılığı için LCP rehberimize bakabilirsiniz; bu yazıda o konuyu tekrar etmiyoruz.

Bu işi ne zaman bir ekiple yürütmelisiniz?

INP sorunu tek bir eklentiyle kapanmıyorsa, birden fazla şablonda tekrar ediyorsa ya da geliştirici ekibiniz neyi düzelteceğini bilmiyorsa dışarıdan destek mantıklı hale gelir. Özellikle e-ticaret sitelerinde filtre, sepet ve ödeme adımlarındaki gecikme doğrudan kullanıcı kaybı anlamına gelebilir.

Biz bu işte üç şey yaparız. Önce saha verisinden öncelik listesi çıkarırız. Ardından her yavaş etkileşim için geliştiricinin anlayacağı somut bir iş tanımı yazarız. Son olarak değişiklikleri doğrulama dönemi boyunca izler, gerilemeleri raporlarız. Yeni bir eklenti, kampanya etiketi ya da tema güncellemesi INP değerini yeniden bozabilir. Bu nedenle tek seferlik düzeltme yerine aylık kontrolü öneririz; böylece sorunu kullanıcılar fark etmeden yakalarsınız ve ekibiniz neyin değiştiğini her zaman bilir. Sıralama garantisi vermeyiz; ancak sorunu ölçülebilir biçimde takip ederiz.

Sitenizde INP sorununu birlikte çözmek ve düzenli takibe almak isterseniz SEO danışmanlığı sayfamızdan teklif isteyebilirsiniz. Sitenizin yapısına göre kapsamı netleştirir ve size uygun bir çalışma planı sunarız. Teklifte hangi şablonları inceleyeceğimizi, geliştiricinize hangi listeyi vereceğimizi ve takibi nasıl raporlayacağımızı açıkça yazarız.

Temel rehber: Dijital Pazarlama Nedir? Türleri, örnekleri ve nasıl yapıldığı, beynin içinden geçen etkileşimli bir filmle tek sayfada.