Mobil site hızı nasıl ölçülür? LCP, INP ve CLS rehberi

Site hızına bakarken önce hangi sayfayı seçmeli?

Ana sayfanın sonucunu bütün siteye genellemem. Bir hizmet sayfasının büyük görseli, blog yazısının gömülü videosu ve bir aracın hesaplama işlemi farklı sorunlar çıkarabilir. İlk inceleme için ziyaretçinin önemli bir işi tamamladığı sayfayı seçmeyi öneriyorum: hizmeti anlamak, bir rehberi okumak veya bir araçtan sonuç almak.

Elimde trafik verisi varsa mobil ziyaret alan ve iş açısından önemli URL’leri öne alırım. Veri henüz azsa her ana şablondan bir örnekle başlarım. Böylece yalnızca kolay puan yükseltebildiğim bir sayfaya çalışıp asıl kullanılan ekranı gözden kaçırmam.

Testten önce tek cümlelik bir hedef yazın: ‘Ziyaretçi mobilde hizmetin ilk paragrafını beklemeden görebilsin ve iletişim düğmesini kullanabilsin.’ Bu cümle, raporda çok sayıda öneri çıktığında hangi işe döneceğinizi hatırlatır.

LCP, INP ve CLS nedir? Üç ölçütü birlikte okuyun

Core Web Vitals, sayfanın yüklenmesini, etkileşime yanıtını ve görsel kararlılığını ele alan üç temel ölçütten oluşur. LCP büyük içerik öğesinin görünmesini, INP etkileşim sonrası bir sonraki görsel güncellemeye kadar geçen süreyi, CLS ise beklenmedik yerleşim kaymalarını değerlendirir. [1]

Aşağıdaki ‘iyi’ eşikleri gerçek kullanıcı verisinin 75. yüzdelik değeri için kullanılır. Bu, ölçülen ziyaretlerin en az yüzde 75’inin ilgili eşikte veya daha iyi olması demektir. Mobil ve masaüstü ayrı değerlendirilir. CLS’nin birimi saniye değildir. [1]

PageSpeed Insights ile mobil site hız testi nasıl yapılır?

PageSpeed Insights’a inceleyeceğiniz sayfanın tam adresini girin ve analizi başlatın. Sonuçta mobil görünümü seçin. Araç, gerçek kullanıcı deneyimini CrUX verisiyle; kontrollü test sonucunu ise Lighthouse ile sunar. İkisini aynı ölçüm gibi okumayın. [2]

Ben ilk okumada aşağıdaki sırayı kullanmayı öneriyorum. Her satır için kısa bir not yeterli; raporun bütün ekranlarını kopyalamak zorunda değilsiniz.

• Adres: Sonucun gerçekten seçtiğiniz sayfaya ait olduğunu kontrol edin.
• Kapsam: Gerçek kullanıcı alanında ‘bu URL’ mi, ‘kaynak / origin’ mı gösteriliyor?
• Gözlem: Hangi ölçüt sorunlu, hangisi için veri yok? Aynı notta cihazı ve tarihi belirtin.
• Teşhis: Laboratuvar bölümünde ilgili öğeyi, isteği veya işlemi bulun.
• İş: İlk değişiklik önerisini ve değişiklikten sonra neyi yeniden ölçeceğinizi yazın.

Gerçek kullanıcı verisi yoksa veya puanlar uyuşmuyorsa

CrUX alanı son 28 günlük gerçek kullanıcı verisini gösterir ve günlük güncellenir. Sayfa için yeterli veri yoksa PageSpeed Insights aynı kaynağın, yani origin’in verisini gösterebilir. O da yoksa gerçek kullanıcı verisi görüntülenmez. Bu durum sıfır performans veya başarısız test anlamına gelmez. Kaynak düzeyindeki sonucu da tek URL’nin kesin sonucu olarak sunmayın. [2]

Laboratuvar testi kontrollü bir koşulu, saha verisi ise farklı cihaz ve bağlantılarla gerçekleşen ziyaretleri yansıtır. Bu yüzden aynı sayfa için farklı sonuçlar görmek mümkündür. Laboratuvarı sorunu tekrar üretmek ve değişikliği sınamak için kullanın; gerçek kullanıcı deneyiminin tamamı saymayın. [3]

Yeni veya az ziyaret alan bir sitede ‘veri oluşana kadar hiçbir şey yapamayız’ demem. Mobil sayfayı kullanır, laboratuvar bulgularını inceler ve test koşullarını kaydederim. Yalnız raporun başlığını doğru koyarım: Bu aşamada elimde laboratuvar gözlemi vardır.

LCP yüksekse: Önce geç görünen öğeyi bulun

LCP öğesi bir görsel de olabilir, metin bloğu da. Görsel söz konusuysa süreyi yalnız dosya boyutuyla açıklamayın. Sunucunun ilk yanıtı, görsel isteğinin ne zaman başladığı, indirme süresi ve indirildikten sonra ekrana gelene kadar beklemesi ayrı gecikmeler oluşturabilir. [4]

Rapordaki öğeyi sayfada bulun, ardından ağ isteklerini inceleyin. Örneğin ilk ekrandaki ana görsel geç keşfediliyorsa yalnız sıkıştırma yapmak sorunun tamamını çözmeyebilir. LCP görselini ‘lazy loading’ ile geciktirmeyin. Öncelik ipuçlarını da bütün görsellere dağıtmayın; gerçekten kritik kaynağı seçip değişikliği tekrar ölçün. [4]

Ben bu bulguyu ‘görseller optimize edilecek’ diye bırakmam. Daha açık bir iş yazarım: ‘Mobil hizmet sayfasında LCP olan kapak görselinin isteği geç başlıyor; yükleme davranışını düzelt, aynı koşulda yeniden ölç.’ İşi yapan kişi hangi sayfaya, hangi öğeye ve hangi kabul ölçütüne bakacağını görebilsin.

INP yüksekse: Menüye, filtreye ve forma dokunun

Sayfanın açılması, etkileşimin de hızlı olacağı anlamına gelmez. INP; tıklama, dokunma ve klavye etkileşimlerinde yanıtın ekrana gelmesine kadar geçen süreyi değerlendirir. Gecikme, işleyicinin başlamasını beklerken, işlemi yürütürken veya görsel sonucu üretirken oluşabilir. Uzun JavaScript işleri bu akışı tıkayabilir. [5]

Kontrol için bir kullanıcı akışı seçin: menüyü açın, filtre değiştirin, araçta hesaplama yapın veya formdaki doğrulamayı tetikleyin. Gecikmeyi tekrar üretebildiğinizde Chrome DevTools Performance kaydında ilgili etkileşimi inceleyin. Ağır işi bölmek veya gerekli olmayan işi görsel yanıttan sonraya taşımak, bulguya göre değerlendirilebilecek seçeneklerdir. [5]

Lighthouse’daki TBT, yani toplam engelleme süresi, uzun görevlerin ana iş parçacığını ne kadar engellediğini inceleyen bir laboratuvar ölçütüdür. INP ile aynı sayı değildir; iyi bir TBT sonucundan doğrudan ‘INP geçti’ sonucu çıkarmayın. [6]

Önerdiğim görev tanımı şu: ‘Mobil menüyü açınca oluşan gecikmeyi kaydet; açılış sırasında çalışan gereksiz işi ayır; menünün hem ilk hem sonraki kullanımını yeniden dene.’ Böyle bir kayıt, bütün JavaScript dosyalarını rastgele küçültmekten daha somut bir başlangıç sağlar.

CLS yüksekse: Kayan öğe her zaman sorunun kaynağı değildir

Okuduğunuz paragraf aşağı kayıyorsa sorun paragrafın kendisi olmayabilir. Üstüne sonradan yüklenen bir görsel, reklam veya gömülü içerik onu itiyor olabilir. DevTools’taki yerleşim kayması kayıtlarını bu gözle inceleyin. Yalnız ilk açılışı izleyen bir test, sayfayı kullanırken oluşan sonraki kaymaları kaçırabilir. [7]

Görsel ve videolarda doğru genişlik / yükseklik bilgisi ya da uygun en-boy oranı ile alan ayırmak, içerik gelmeden yerinin hesaplanmasına yardım eder. Geç yüklenen gömülü içerikler için de ayrılmış alan gerekebilir. Ayırdığınız alanı mobil görünümde ayrıca kontrol edin. [7]

Bu kontrolde sayfayı gerçekten okuyarak aşağı inerim. Bir başlığı takip etmek veya bir düğmeye dokunmak zorlaşıyorsa, yalnız ilk ekranın iyi görünmesini yeterli bulmam. Düzeltmeden sonra aynı okuma ve tıklama sırasını tekrarlarım.

Örnek: Üç testten hangi sonucu çıkarabiliriz?

Aşağıdaki sayılar yöntemi anlatmak için oluşturulmuş temsili verilerdir; Kürklü Digital’e veya bir müşteri projesine ait ölçüm değildir. Varsayımımız şu: Bir hizmet sayfasında ilk ekrandaki görselin geç yüklenmesine yönelik tek bir değişiklik deniyoruz.

Aynı URL’yi, mobil test ayarını ve ortamı koruyup önce ve sonra üçer laboratuvar çalıştırması kaydediyoruz. Üç tekrar, burada önerdiğim pratik bir başlangıçtır; Google’ın zorunlu test sayısı değildir. Önbellek durumunu ve test aracının sürümünü de kayda eklemek karşılaştırmayı anlaşılır kılar.

• Çıkarılabilecek sonuç: Bu test grubunda ortanca LCP 1 saniye daha düşük.
• Henüz çıkarılamayacak sonuç: Bütün ziyaretçiler aynı iyileşmeyi yaşadı veya Core Web Vitals değerlendirmesi geçti.
• Ayrıca kanıt gerektiren iddia: Sıralama, organik trafik ya da başvuru sayısı bu değişiklik nedeniyle arttı.
• Sonraki kontrol: Görsel kalitesi, diğer sayfa davranışları ve aynı değişikliğin yeni testlerdeki sonucu.

İlk hangi hız sorununu düzeltmeli?

Öncelik verirken üç şeye bakıyorum: Kullanıcının hangi işi aksıyor, bulgu ne kadar açık ve aynı bileşen kaç önemli sayfada kullanılıyor? Tek sayfaya özgü küçük bir ayrıntıdan önce, birçok hizmet sayfasında aynı sorunu üreten şablonu incelemek daha anlamlı olabilir.

Aşağıdaki tablo bir karar başlangıcıdır. Her satırı kendi sayfanızdaki kanıtla doldurun; listede yazıyor diye ölçmeden değişiklik yapmayın.

Hız iyileştirmesinden sonra SEO sonucunu nasıl izlemeli?

Google, Core Web Vitals ölçütlerini sıralama sistemlerinde kullandığını belirtiyor. Ancak iyi sonuç almak üst sıraları garanti etmiyor. Sayfanın aramaya uygunluğu ve içeriğin faydası da önemli. Sırf kusursuz puana ulaşmak için çalışmanın her zaman en iyi zaman kullanımı olmadığını da açıkça söylüyor. [8]

Bu yüzden iki kayıt tutmayı öneriyorum. Teknik kayıtta hangi sayfanın hangi davranışının değiştiği yer alır. Arama kaydında ise aynı sayfanın tamamlanmış dönemlerdeki gösterim ve tıklamalarını, sorgu ve cihaz kapsamıyla izlerim. İkisinin aynı anda değişmesi tek başına neden-sonuç ilişkisi kurmaz.

Yayımdan hemen sonra yeni laboratuvar testini yapabilirsiniz. Gerçek kullanıcı verisinin önceki 28 günlük dönemi de içerdiğini hatırlayın; yeni bir ölçümü görür görmez bütün deneyimin değiştiğini söylemeyin. [2]

Bugün uygulanabilecek kısa bir çalışma planı

İlk tur için tek önemli sayfa seçin. Bir sorunu kanıtıyla tanımlayıp düzeltmek, on sayfanın puanını toplayıp ne yapılacağına karar verememekten daha yararlı bir başlangıçtır. Benim hedefim, çalışmanın sonunda geliştiricinin veya site sahibinin elinde açık bir sonraki adım olması.

Aşağıdaki maddeleri teknik SEO kontrol listemizde notlara dönüştürebilirsiniz. Liste otomatik hız testi yapmaz; ölçtüğünüz bulguyu ve yeniden kontrol tarihini takip etmenize yardımcı olur.

• Tam URL, mobil / masaüstü seçimi, test tarihi ve rapor bağlantısını kaydedin.
• Saha verisinin URL mi kaynak mı olduğunu ve kapsadığı dönemi yazın; yoksa ‘veri yok’ deyin.
• İlk değişikliği tek cümleyle tarif edin; hangi gözleme dayandığını ekleyin.
• Değişiklikten önceki ölçümü ve sayfanın çalışan hâlini saklayın.
• Sonrasında aynı koşullarda ölçün; menü, bağlantı, form ve görselleri de kullanarak kontrol edin.
• Teknik iyileşmeyi, arama görünürlüğünü ve gerçek başvuruları ayrı değerlendirin.