Lighthouse 90+ Puan Ama Kullanıcı Yavaş Hissediyor: Neden Olur?

Lab verisi ile alan verisi neden farklı konuşur

Lighthouse skoru; performans, erişilebilirlik, en iyi uygulamalar ve SEO kategorilerinin ağırlıklı ortalamasından oluşur. Performans kategorisi de kendi içinde FCP, LCP, TBT, CLS ve Speed Index gibi metriklerin ağırlıklı toplamıdır. Yüksek skor, bu belirli metrik setinin belirli bir test koşulunda iyi çıktığını garanti eder; kullanıcının gerçekte hissettiği her anı garanti etmez.

Özellikle şu ayrım kritiktir: skor sayfa yüklenme sürecini ölçer, sayfa yüklendikten sonraki etkileşim akışını sınırlı ölçüde yansıtır. Bir kullanıcı sayfayı hızlı açıp menüde takılabilir, formda gecikme yaşayabilir veya kaydırırken donma hissedebilir. Bu deneyimlerin hiçbiri klasik Lighthouse skoruna tam yansımaz.

Chrome User Experience Report (CrUX), gerçek Chrome kullanıcılarından toplanan alan verisidir ve iki ana yerden erişilebilir: Search Console'daki Core Web Vitals raporu ve PageSpeed Insights'ın gerçek kullanıcı verisi bölümü. Her iki kaynak da aynı ham veriye dayanır, ama sunum farklıdır.

Search Console'daki rapor site genelinde URL grupları bazında iyi, orta ve zayıf deneyim yaşayan kullanıcı oranını gösterir. PageSpeed Insights ise tek bir URL için origin düzeyinde ve sayfa düzeyinde ayrı ayrı CrUX verisi sunar; bu ayrım önemlidir çünkü bazen tek bir sayfa origin ortalamasını aşağı çeker, bazen de origin ortalaması tek bir sayfanın gerçek durumunu gizler.

Search Console raporu 28 günlük kayan pencere üzerinden hesaplanır ve p75 (75. yüzdelik dilim) kullanır. Bu, kullanıcıların dörtte üçünün o değerden daha iyi bir deneyim yaşadığı anlamına gelir; ama geri kalan dörtte birinin deneyimi raporda görünmez şekilde daha kötü olabilir. Lighthouse ise tek bir çalıştırmanın anlık sonucudur, dağılım göstermez.

Search Console'da "Zayıf" olarak işaretlenen bir URL grubu ile Lighthouse'ta 96 puan alan aynı sayfa çelişkili görünebilir. Aslında ikisi çelişmiyor, farklı soruları yanıtlıyor: Lighthouse "bu koşulda nasıl performans gösteriyor" sorusuna, Search Console "gerçek kullanıcıların çoğu ne yaşıyor" sorusuna cevap verir.

Şikayetin hangi bağlamdan geldiğini netleştirmek

Tanılamaya başlamadan önce şikayetin kaynağını somutlaştırmak gerekir. "Yavaş" kelimesi çok geniştir; hangi sayfada, hangi cihazda, hangi işlemde yaşandığı bilinmeden yapılan her araştırma rastgele bir arama olur. Kullanıcıdan veya destek kaydından şu bilgileri almak tanılamayı doğrudan hızlandırır: cihaz tipi (marka, model varsa), tarayıcı, bağlantı türü (mobil veri mi Wi-Fi mi), şikayetin sayfa açılışında mı yoksa bir etkileşimde mi ortaya çıktığı.

Bu bilgi eksikse bile en azından Google Analytics veya sunucu loglarından hangi sayfa tipinin, hangi ülke ve cihaz segmentinin şikayetle örtüştüğünü kabaca çıkarmak mümkündür. Şikayetin bağlamı netleşmeden lab testine geri dönmek, aynı olumlu sonucu tekrar üretmekten öteye geçmez.

Test ortamının gerçek cihaz ve ağı temsil ettiği nokta

Lighthouse mobil testi, orta seviye bir Android cihazı simüle eden bir CPU yavaşlatma (throttling) katsayısı uygular. Ancak bu katsayı, pazardaki en düşük donanımlı cihazları temsil etmez. Türkiye'deki mobil trafiğin önemli bir kısmı, test ortamının simüle ettiğinden çok daha zayıf işlemcili cihazlardan gelir.

Bu fark özellikle JavaScript yürütme süresinde kendini gösterir. Aynı script bloğu güçlü bir cihazda 40 milisaniyede işlenirken düşük donanımlı bir cihazda 150 milisaniyeye çıkabilir. Lighthouse'un simülasyonu bu uç noktayı yakalamaz; ortalamaya yakın bir senaryoyu temsil eder. Şikayetlerin büyük kısmı bu ortalamanın altında kalan cihazlardan gelir.

Lighthouse'un mobil profili, sabit bir gecikme ve bant genişliği katsayısıyla ağı simüle eder. Bu, laboratuvar tutarlılığı için gereklidir ama gerçek mobil ağların değişkenliğini yansıtmaz. Gerçek kullanıcılar bazen 4G'nin zayıf çektiği bir bölgede, bazen kalabalık bir Wi-Fi ağında, bazen de hücresel veri sıkışıklığında sayfayı açar.

Bu değişkenlik, aynı sayfanın aynı gün içinde farklı kullanıcılarda oldukça farklı TTFB ve LCP değerleri üretmesine yol açar. Lab testi tek bir noktayı ölçtüğü için bu dalgalanmayı hiçbir zaman göstermez; sadece "kontrollü koşulda ne oluyor" sorusuna cevap verir.

Sayfa yüklendikten sonraki etkileşimler ve INP

Lighthouse'un klasik çalışma modu, sayfa yüklenene kadarki süreci ölçer. Kullanıcının sayfayı yükledikten sonra menüyü açması, bir filtreyi tıklaması, formu doldurması veya bir modal penceresi açması gibi etkileşimler bu ölçümün dışında kalır. Oysa "yavaş hissetme" şikayetlerinin önemli bir kısmı tam olarak bu noktalarda doğar.

Bir e-ticaret sitesinde ürün listesini filtrelerken yaşanan gecikme, sayfa açılış skorunu hiç etkilemez ama kullanıcı deneyimini doğrudan biçimlendirir. Bu tür sorunları yakalamak için Lighthouse'un tek seferlik ölçümü yeterli değildir; etkileşim bazlı profil çıkarmak gerekir.

INP, sayfa ömrü boyunca yapılan tüm etkileşimlerin en kötü performans gösterenini yakalar. Bu, tek bir tıklamayı değil, kullanıcının o oturumda yaptığı onlarca etkileşimi kapsar. Lighthouse'un standart raporu ise sayfayı otomatik olarak yükler ve genellikle hiçbir etkileşim simüle etmez; bu yüzden INP değeri lab raporunda çoğu zaman raporlanmaz.

Gerçek kullanıcı INP verisi yalnızca alan verisinden (CrUX, Search Console, RUM araçları) gelir. Skor yüksekken kullanıcı şikayeti "tıkladığımda geç açılıyor" şeklindeyse, bakılması gereken metrik LCP değil INP'dir; ve bu metrik lab testinde neredeyse hiç temsil edilmez.

Tekrar eden ziyaretlerde cache durumu skoru nasıl gizler

Lighthouse varsayılan olarak soğuk (cold) bir oturumu test eder: hiçbir kaynak önbellekte değildir, her şey sıfırdan indirilir. Gerçek kullanıcıların büyük kısmı ise siteyi daha önce ziyaret etmiştir ve tarayıcı önbelleği devrededir. Bu durum bazen ters yönde de çalışır: cache başlıkları yanlış yapılandırılmışsa, tekrar eden ziyaretçiler soğuk testte görünmeyen bir yavaşlık yaşayabilir.

Örneğin bir CSS dosyasının cache süresi çok kısa ayarlanmışsa, ilk ziyarette fark edilmeyen bu sorun, sık ziyaret eden kullanıcılarda her seferinde yeniden indirme maliyeti olarak birikir. Lab testi tek seferlik olduğu için bu birikimli maliyeti hiç göstermez.

Segment bazlı kırılım: hangi sayfa, hangi ülke, hangi cihaz sınıfı şikayet ediyor

Şikayetler genellikle tek bir noktadan değil, belirli bir segmentten yoğunlaşarak gelir. Search Console raporunu ve analytics verisini cihaz tipi, ülke ve sayfa şablonu bazında kırmak, sorunun genele mi yoksa dar bir dilime mi ait olduğunu netleştirir. Genele yayılmış bir sorun ile yalnızca eski Android cihazlarda görülen bir sorun, tamamen farklı çözüm gerektirir.

Bu kırılım aynı zamanda önceliklendirmeyi de belirler. Şikayet trafiğin küçük bir yüzdesinden geliyorsa acil bir müdahale gerekmeyebilir; ama şikayet büyüyen bir segmentten (örneğin artan mobil trafik payından) geliyorsa, lab skorunun iyi görünmesi yanıltıcı bir rahatlık yaratır.

Algılanan hız ile ölçülen hız arasındaki fark

Kullanıcının "yavaş" dediği şey her zaman bir metrikle bire bir eşleşmez. Bir sayfa teknik olarak hızlı yüklenebilir ama görsel geri bildirim eksikliği (yükleniyor göstergesi olmadan boş bir alan, ani içerik atlaması, tıklamaya geç tepki veren bir buton) kullanıcıda yavaşlık hissi yaratabilir. Bu, ölçülen performans ile algılanan performans arasındaki klasik ayrımdır.

Bazı durumlarda çözüm hızı artırmak değil, geri bildirimi iyileştirmektir: bir işlem sürüyorsa bunu görünür kılmak, buton tıklamasına anında görsel tepki eklemek, iskelet ekran kullanmak. Bu müdahaleler ölçülen metrikleri değiştirmese bile algılanan yavaşlık hissini azaltabilir.

Tanılama sırasını kurmak: şikayetten veriye, veriden köke

Pratik bir sıra şöyle kurulabilir: önce şikayetin bağlamını netleştirin (cihaz, sayfa, işlem). Ardından Search Console ve PageSpeed Insights üzerinden aynı sayfanın CrUX verisine bakın; lab skoruyla alan verisi arasında gerçekten bir fark var mı, yoksa şikayet münferit mi? Fark varsa, hangi metrikte (LCP mi INP mi) yoğunlaştığını belirleyin. Ardından o metriğin hangi kullanıcı segmentinde (cihaz, ülke, sayfa tipi) kötüleştiğini kırılım verisiyle doğrulayın.

Son adım, o segmenti temsil edecek şekilde testi yeniden kurmaktır: Chrome DevTools'ta CPU throttling'i daha agresif bir değere çekmek, ağ profilini yavaş 4G'ye ayarlamak veya gerçekten düşük donanımlı bir cihazda manuel test yapmak. Mobil test profilinin masaüstünden farklı davrandığını unutmadan, şikayetin geldiği koşulu laboratuvarda yeniden üretmeden çözüm aramak, sorunu tekrar gözden kaçırma riski taşır.

Bu sıralama, semptomdan nedene giden genel tanılama mantığının özel bir uygulamasıdır: burada semptom "skor iyi ama şikayet var" çelişkisidir, neden ise genellikle lab testinin temsil etmediği bir cihaz, ağ veya etkileşim koşuludur.