Web sitesinde INP skoru nasıl düşürülür?

Web sitesinde INP skoru, kullanıcı etkileşimlerini geciktiren JavaScript ve görsel güncellemeler azaltılarak düşürülür. Önce gerçek kullanıcı verisi incelenmeli, ardından uzun görevler ve yavaş olay işleyicileri ölçülmelidir.

Özellikle e-ticaret sitelerinde filtreler, varyant seçiciler, sepet işlemleri ve üçüncü taraf etiketler gecikme oluşturur. Sorunun kaynağı belirlenmeden dosya küçültmek veya eklenti silmek kalıcı çözüm sağlamaz.

İyi bir INP skoru kaç milisaniye olmalıdır?

İyi bir INP skoru 200 milisaniye veya daha düşük olmalıdır. 200 ile 500 milisaniye arası geliştirilmesi gereken, 500 milisaniyenin üzeri ise zayıf sonuç kabul edilir.

Değerlendirme, sayfadaki tek bir hızlı tıklamaya göre yapılmaz. Chrome kullanıcılarından toplanan alan verileri kullanılır ve ziyaretlerin yüzde 75’lik dilimi dikkate alınır.

INP; giriş gecikmesi, olay işleyicisinin çalışma süresi ve sonraki karenin ekrana çizilme süresinden oluşur. Bu nedenle sorun yalnızca JavaScript dosyasının boyutu değildir.

Örneğin kullanıcı sepete ekle düğmesine bastığında tarayıcı önce başka bir görevin bitmesini bekleyebilir. Ardından sepet kodunu çalıştırır ve yeni fiyatı ekrana çizer. Üç aşamanın toplamı etkileşim gecikmesini oluşturur.

INP; tıklama, dokunma ve klavye etkileşimlerini kapsar. Kaydırma veya fareyi yalnızca bir öğenin üzerinde gezdirme, aynı şekilde değerlendirilmez. Bu ayrım, test senaryosunun doğru kurulması için önemlidir.

Mobil sonuçların masaüstünden kötü olması olağandır. Daha yavaş işlemciler aynı JavaScript görevini daha uzun sürede tamamlar. Bu yüzden yalnız güçlü bir geliştirici bilgisayarında yapılan ölçüm yeterli değildir.

Hedef, her sayfayı laboratuvarda 200 milisaniyenin altına zorlamak değildir. Öncelik, gerçek kullanıcı verisinde zayıf görünen sayfa türlerini ve tekrarlanan etkileşimleri düzeltmektir.

INP sorununun kaynağı nasıl bulunur?

INP sorununun kaynağı, PageSpeed Insights alan verisi ile Chrome DevTools performans kaydı birlikte incelenerek bulunur. Bu iki araç farklı soruları cevaplar.

PageSpeed Insights, yeterli veri varsa son 28 günlük Chrome kullanıcı deneyimini gösterir. Sonuç belirli URL’ye veya benzer sayfaları kapsayan kaynak düzeyine ait olabilir.

Raporun alan verisi bölümü gerçek kullanıcı koşullarını temsil eder. Laboratuvar bölümündeki Lighthouse testi ise kontrollü bir yükleme çalıştırır ve doğrudan gerçek kullanıcı INP değerini üretmez.

Total Blocking Time, laboratuvar testinde yararlı bir göstergedir. Ancak TBT’nin düşmesi, INP’nin kesin olarak iyileşeceği anlamına gelmez. Çünkü test sırasında kritik kullanıcı etkileşimi gerçekleşmemiş olabilir.

Rapor bölümlerinin farklarını görmek için Web sitesinde INP raporu PageSpeed’de nasıl okunur? rehberindeki URL, kaynak ve laboratuvar verisi ayrımını uygulayın.

1. PageSpeed Insights içinde mobil alan verisini kontrol edin.
2. Zayıf sonuç görülen sayfa şablonunu gerçek cihazda açın.
3. Chrome DevTools Performance panelinde kayıt başlatın.
4. Filtreleme, menü açma veya sepete ekleme işlemini tekrarlayın.
5. Uzun görevleri, olay süresini ve görsel güncellemeyi inceleyin.

Alan verisi yoksa sonuç çıkarılamaz demek değildir. Temsili cihazlarda senaryo testi yapın ve mümkünse kendi gerçek kullanıcı ölçümünüzü kurun. Yeni sayfalarda veri oluşması zaman alabilir.

Uzun JavaScript görevleri nasıl parçalanır?

Uzun JavaScript görevleri, yapılan işi küçük parçalara ayırıp tarayıcıya aralarda kontrol vermekle kısaltılır. Özellikle 50 milisaniyeyi aşan görevler ana iş parçacığını engelleyebilir.

Ürün listesini sıralama, yüzlerce öğeyi dönüştürme veya büyük JSON verisini işleme tek görevde yapılmamalıdır. Kullanıcı bu sırada tıklarsa olay, mevcut görev tamamlanana kadar bekler.

İlk adım, kullanılmayan kodu kaldırmaktır. Sayfada çalışmayan kampanya modülleri, eski takip araçları ve bütün siteye yüklenen sayfa özelindeki paketler ayrı ayrı incelenmelidir.

İkinci adım, zorunlu işi parçalara ayırmaktır. Uygun durumlarda görevler arasında tarayıcıya kontrol verilebilir. Kullanılan yöntemin hedef tarayıcılardaki desteği dağıtımdan önce doğrulanmalıdır.

Yoğun hesaplamalar kullanıcı arayüzüne doğrudan bağlı değilse Web Worker değerlendirilebilir. Worker, hesaplamayı ana iş parçacığından taşır. Ancak DOM öğelerine doğrudan erişemediği için her işlem uygun değildir.

Kod bölme de başlangıç yükünü azaltabilir. Ödeme, ürün karşılaştırma veya gelişmiş filtre kodu yalnız gerektiği sayfada yüklenmelidir. Bütün paketi ana sayfaya eklemek işlem ve derleme maliyeti yaratır.

Yanlış: Büyük JavaScript dosyasını yalnızca küçültmek INP sorununu çözer. Doğru: Dosyanın çalışma süresini, çağrılma anını ve ana iş parçacığını ne kadar engellediğini birlikte ölçmek gerekir.

Dosya boyutu küçük olsa bile yoğun döngüler kötü INP oluşturabilir. Buna karşılık büyük fakat kullanıcı etkileşiminden sonra çalışmayan bir paket, ilgili gecikmenin temel nedeni olmayabilir.

Sunucu yanıt süresini iyileştirmek sayfanın açılışını hızlandırır. Fakat sayfa açıldıktan sonraki yavaş filtre tıklaması JavaScript kaynaklıysa, yalnız sunucu optimizasyonu INP değerini düşürmez.

Olay işleyicileri INP için nasıl optimize edilir?

Olay işleyicileri, etkileşim anında yalnız zorunlu işlemler çalıştırılarak optimize edilir. Analitik, depolama ve ikincil hesaplamalar ilk görsel yanıtın önüne geçirilmemelidir.

Sepete ekleme örneğinde düğmenin durumunu hemen değiştirmek kullanıcıya geri bildirim sağlar. İlgili olmayan öneri hesapları veya ayrıntılı analitik olayları daha sonra yürütülebilir.

Bir olay işleyicisi içinde art arda DOM sorguları, fiyat hesapları ve depolama işlemleri bulunabilir. DevTools içindeki Bottom-up görünümü, toplam sürenin hangi fonksiyonlarda biriktiğini gösterir.

async anahtar kelimesi, fonksiyonun tüm işlemlerini otomatik olarak arka plana taşımaz. İlk await satırından önceki senkron kod yine ana iş parçacığında çalışır ve etkileşimi geciktirebilir.

Arama kutularında her tuş vuruşunda ağır filtre çalıştırmak yerine uygun bir gecikme uygulanabilir. Ancak düğme tıklamasındaki görsel yanıtı gereksiz yere erteleyen genel bir debounce kullanımı ters etki yaratır.

Scroll olaylarında pasif dinleyiciler kaydırma performansına yardımcı olabilir. Fakat passive: true eklemek, yavaş çalışan sepete ekleme veya menü tıklama kodunu kendiliğinden hızlandırmaz.

Çok sayıda benzer öğe için ayrı dinleyici eklemek yerine olay delegasyonu kullanılabilir. Yine de üst kapsayıcıdaki işleyici her olayda pahalı DOM araması yapıyorsa kazanç sınırlı kalır.

React, Vue veya benzer yapılarda gereksiz yeniden çizimler kontrol edilmelidir. Değişmeyen ürün kartlarının tekrar oluşturulması, küçük bir filtre tıklamasını büyük bir render işlemine çevirebilir.

Optimizasyon sonrasında işlevsel test yapılmalıdır. Çift tıklama, klavye kullanımı, hızlı varyant değişimi ve ağ hatası senaryoları denenmelidir. Hız kazanırken işlem güvenilirliği bozulmamalıdır.

DOM ve görsel güncellemeler nasıl hızlandırılır?

DOM ve görsel güncellemeler, değiştirilen öğe sayısı azaltılarak ve stil okumaları yazmalardan ayrılarak hızlandırılır. Amaç, etkileşim sonrasındaki layout ve paint maliyetini düşürmektir.

JavaScript önce bir öğenin stilini değiştirip sonra ölçüsünü okursa tarayıcı güncel yerleşimi hesaplamak zorunda kalabilir. Bu işlem döngü içinde tekrarlanırsa zorunlu senkron yerleşim oluşur.

Ölçü okumalarını bir arada, DOM yazmalarını başka bir aşamada yapmak daha güvenlidir. DevTools performans kaydında tekrarlanan Layout blokları bu soruna işaret edebilir.

Yüzlerce ürünün bulunduğu listede her filtre işleminde bütün kartları yeniden oluşturmak pahalıdır. Yalnız değişen kartları güncellemek veya görünür alanı sanallaştırmak işlem miktarını azaltabilir.

DOM öğesi sayısı için her siteye uyan tek bir sihirli sınır yoktur. Kart yapısının derinliği, CSS seçicileri, cihaz gücü ve güncellenen öğe sayısı birlikte değerlendirilmelidir.

Açılır menüde gizli bütün alt kategorileri başlangıçta oluşturmak gerekmeyebilir. İçerik yalnız açıldığında üretilebilir. Ancak ilk açılışta gecikme oluşuyorsa gerekli veriler önceden hazırlanmalıdır.

Animasyonlarda yerleşimi sürekli değiştiren özellikler yerine çoğunlukla transform ve opacity tercih edilir. Yine de büyük bir katmanın animasyonu bellek ve boyama maliyeti oluşturabilir.

Görsel güncellemeyi azaltmak erişilebilirliği bozmamalıdır. Standart düğmeler, klavye odağı ve durum bildirimleri korunmalıdır. Özellikle e-ticaret sitelerinde erişilebilirlik gereklilikleri performans uğruna kaldırılmamalıdır.

content-visibility gibi CSS özellikleri görünmeyen bölümlerin işlenmesini erteleyebilir. Fakat kullanıcı etkileşimindeki gecikme yalnız JavaScript hesaplamasından kaynaklanıyorsa bu yöntem tek başına çözüm olmaz.

Üçüncü taraf kodlar INP skorunu nasıl etkiler?

Üçüncü taraf kodlar, ana iş parçacığında JavaScript çalıştırarak INP skorunu yükseltebilir. Etiket yöneticileri, sohbet araçları, reklam pikselleri ve kişiselleştirme yazılımları ayrı ayrı ölçülmelidir.

Her araç ağ isteği yapmakla kalmaz. Yanıt geldikten sonra kod ayrıştırılır, derlenir ve çalıştırılır. Bazı araçlar DOM değişikliklerini izleyerek sayfa açık kaldığı sürece ek maliyet oluşturur.

Chrome DevTools içindeki Network ve Performance panellerinde alan adı, başlatıcı ve çalışma süresi kontrol edilmelidir. Etiket kaldırılarak yapılan karşılaştırmalı test, etkisini daha açık gösterir.

Etiket yöneticisi boş bir taşıyıcı değildir. İçine eklenen her tetikleyici ve özel HTML etiketi çalışma maliyeti yaratabilir. Kurulumu gözden geçirmek için Web sitesinde Google etiketi nasıl kurulur? rehberindeki doğrulama adımları kullanılabilir.

Sohbet penceresi, yorum bileşeni veya harita ilk ekranda gerekmiyorsa kullanıcı niyetiyle yüklenebilir. Örneğin sohbet kodu, kullanıcı destek düğmesini açtığında başlatılabilir.

Buna karşılık ödeme doğrulaması veya stok kontrolü gibi temel işlevleri rastgele ertelemek doğru değildir. Bu kodların hızlandırılması gerekir; tamamen geciktirilmesi işlem hatasına veya yanlış bilgiye yol açabilir.

Çerez izni mekanizması da ölçülmelidir. Reddedilen kategorilere ait etiketler gerçekten çalışmamalıdır. Arayüz ve mevzuat tarafı için çerez reddetme butonu zorunluluğu ayrıca değerlendirilmelidir.

Bir etiket kaldırıldığında INP değişmiyorsa sorun başka yerde olabilir. Etiket yalnız sayfa yüklenirken çalışıyor, geciken etkileşim ise çok sonra gerçekleşiyorsa doğrudan ilişki kurulamaz.

Karar verirken yalnız PageSpeed puanına bakmayın. Etiketin işlevini, kullanıcı etkileşimi sırasında çalışıp çalışmadığını ve ana iş parçacığında tükettiği süreyi birlikte karşılaştırın.

E-ticaret sayfalarında hangi etkileşimler önce düzeltilmelidir?

E-ticaret sayfalarında önce satın alma akışını etkileyen filtre, varyant, sepet ve ödeme etkileşimleri düzeltilmelidir. Öncelik, kullanım sıklığı ile gecikme şiddeti birlikte değerlendirilerek belirlenir.

Ürün filtresi yüzlerce kartı aynı anda değiştiriyorsa kullanıcı önce seçimin alındığını görmelidir. Sonuçlar hesaplanırken filtre kontrolünün durumu hemen güncellenebilir ve ilerleme bilgisi gösterilebilir.

Varyant seçiminde fiyat, stok, görsel ve teslimat bilgisi birlikte değişebilir. Bütün ürün sayfasını yeniden çizmek yerine yalnız ilgili alanların güncellenmesi daha az işlem gerektirir.

Sepete ekleme düğmesinde istek tamamlanana kadar hiçbir görsel yanıt vermemek gecikme hissini artırır. Düğme durumu hemen değiştirilebilir. Sunucu hatasında durum geri alınmalı ve anlaşılır hata gösterilmelidir.

Filtre veya sepet işlemi hızlı olsa bile açılan yan panel büyük bir DOM oluşturuyorsa sunum gecikmesi devam eder. Bu nedenle ağ süresi ile görsel güncelleme süresi ayrı ölçülmelidir.

Sunucu tarafında oluşturma, ilk HTML görünümünü hızlandırabilir. Ancak hydration sırasında ağır JavaScript çalışıyorsa kullanıcı ekrandaki düğmeye basar fakat uygulama henüz etkileşime hazır olmayabilir.

Bileşen bazlı kod bölme bu yükü azaltabilir. Fakat çok küçük paketlere ayrılan kod, artan istek ve bağımlılık zinciri nedeniyle başka gecikmeler doğurabilir. Sonuç gerçek cihazda ölçülmelidir.

Kampanya sayfalarında gereksiz slider, sayaç ve kişiselleştirme kodları etkileşim maliyeti yaratabilir. Daha sade yapıların nasıl test edileceği landing page ve dönüşüm optimizasyonu rehberindeki bileşen yaklaşımıyla karşılaştırılabilir.

Önce nadiren kullanılan alt menüyü düzeltmek doğru öncelik olmayabilir. Gerçek kullanıcı ölçümleri, hangi etkileşimin sık gerçekleştiğini göstermelidir. Teknik maliyet ile kullanıcı etkisi aynı tabloda izlenmelidir.

INP iyileştirmesi nasıl test edilir ve doğrulanır?

INP iyileştirmesi, dağıtım öncesi performans kaydı ve dağıtım sonrası gerçek kullanıcı verisiyle doğrulanır. Tek bir PageSpeed çalıştırması kalıcı sonuç göstermek için yeterli değildir.

Önce temel değer kaydedilmelidir. Sayfa türü, cihaz sınıfı, etkileşim adı ve test koşulu yazılmalıdır. Böylece değişiklikten önceki ve sonraki kayıtlar aynı senaryoda karşılaştırılabilir.

Chrome DevTools testi birkaç kez tekrarlanmalıdır. Arka plan sekmeleri, tarayıcı eklentileri ve sıcak önbellek sonucu etkileyebilir. Karşılaştırmada aynı cihaz ve benzer ağ koşulları kullanılmalıdır.

Gerçek kullanıcı ölçümü kurulacaksa Event Timing API üzerinden etkileşim süreleri izlenebilir. Toplanan veride sayfa türü ve etkileşim sınıfı bulunmalı, kullanıcıların yazdığı metinler kaydedilmemelidir.

Yeni sürüm önce sınırlı kullanıcı grubuna açılabilir. Hata oranı, etkileşim süresi ve işlevsel sonuç birlikte izlenmelidir. Performans kazanımı sepet işlemlerini bozuyorsa değişiklik tamamlanmış sayılmaz.

• Mobil ve masaüstü sonuçlarını ayrı kontrol edin.
• Ürün, kategori, sepet ve ödeme şablonlarını ayrı ölçün.
• Uzun görevlerin hangi fonksiyondan geldiğini kaydedin.
• Üçüncü taraf etiketleri devre dışı bırakarak karşılaştırın.
• Klavye, dokunma ve hızlı tekrar tıklama senaryolarını deneyin.
• Dağıtım sonrasında alan verisinin güncellenmesini takip edin.
• INP yanında hata oranı ve dönüşüm adımlarını da izleyin.

Chrome kullanıcı deneyimi verileri hareketli bir dönem üzerinden oluştuğu için değişiklik hemen tam olarak görünmeyebilir. Bu sırada laboratuvar kayıtları ve kendi gerçek kullanıcı ölçümünüz erken sinyal sağlar.

İyileştirme işe yaramadıysa önce varsayımı kontrol edin. Küçültülen dosya geciken etkileşim sırasında çalışmıyor olabilir. Sorun layout, üçüncü taraf kod veya başka bir olay işleyicisinde bulunabilir.

Çalışma, iyi bir alan verisi elde edilince bitmez. Yeni etiketler, kampanya araçları ve ürün bileşenleri INP değerini yeniden yükseltebilir. Performans kontrolü sürüm sürecinin tekrarlanan adımı olmalıdır.