Web Sitesi Hızı ve Core Web Vitals: Yavaş Site Neden Müşteri Kaybettirir?

Kısaca: Core Web Vitals, Google'ın sayfa deneyimini ölçtüğü üç göstergedir: yükleme için LCP (2,5 saniye veya altı), tepki için INP (200 milisaniye veya altı) ve görsel kararlılık için CLS (0,1 veya altı). Bir sayfanın "iyi" sayılması için bu eşiklerin, gerçek ziyaretçilerin %75'inin deneyiminde, mobil ve masaüstünde ayrı ayrı tutturulması gerekir. Hız tek başına sizi üst sıraya taşımaz; ama yavaş bir sayfa, ziyaretçi içeriğinizi görmeden onu kaybettirir.

Site hızıyla ilgili gelen soruların çoğu birkaç başlıkta toplanıyor. Bu yazıyı bir anlatı yerine doğrudan o soruların cevabı olarak kurduk. Teknik terimleri açıklıyoruz ama gereğinden fazla derine inmiyoruz — amaç, konuyu yönetici olarak takip edebilecek ve ekibinize ya da ajansınıza doğru soruyu sorabilecek kadar anlamanız.

Core Web Vitals tam olarak neyi ölçüyor?

Sunucunuzun ne kadar hızlı olduğunu değil, sayfanın kullanıcıya nasıl hissettirdiğini ölçüyor. Bu ayrım önemli: sunucu çok hızlı olabilir ama sayfa yine de kötü bir deneyim sunabilir. Üç gösterge var ve eşikler web.dev'deki Core Web Vitals sayfasında ve Search Console belgelerinde aynı şekilde tanımlanıyor:

Değerlendirme ortalamaya göre değil, 75. yüzdelik dilime göre yapılır: ziyaretlerinizin en az %75'i "iyi" eşiğin içindeyse o gösterge geçer. Bu, en hızlı cihazdaki deneyimin değil, yavaş telefonu ve zayıf bağlantısı olan ziyaretçinin de hesaba katıldığı anlamına gelir.

LCP nedir, kaç saniye olmalı?

LCP, sayfadaki en büyük içeriğin — genellikle bir kapak görseli veya ana başlık — ekranda belirmesine kadar geçen süredir. Pratikte "ziyaretçi ne zaman anlamlı bir şey gördü?" sorusunun cevabıdır. Hedef 2,5 saniye veya altıdır.

Google'ın LCP optimizasyon rehberi bu süreyi dört parçaya ayırır: sunucunun ilk baytı göndermesi (TTFB), tarayıcının görseli istemeye başlamasına kadar geçen gecikme, görselin inme süresi ve inen görselin ekrana çizilmesi. Hangi parçanın uzun olduğunu bilmeden yapılan "hızlandırma" çoğu zaman yanlış yere vurur.

INP nedir? FID'in yerine mi geçti?

Evet. INP, Mart 2024'te FID'in yerini alarak kalıcı bir Core Web Vitals göstergesi oldu. Fark şu: FID yalnızca ilk etkileşimdeki gecikmeyi ölçüyordu; INP ise sayfadaki etkileşimlere bakar ve tıklamadan, tepkinin ekrana yansımasına kadar geçen tüm süreyi değerlendirir. Hedef 200 milisaniye veya altıdır.

Bir menüye dokunduğunuzda açılmasının "takılması" tipik bir INP sorunudur. Sebep çoğunlukla tarayıcının ana iş parçacığını uzun süre meşgul eden JavaScript'tir: sayfa o an başka bir işi bitirmeden sizin dokunuşunuza cevap veremez.

CLS nedir, neden bu kadar sinir bozucu?

CLS, sayfa yüklenirken içeriğin ne kadar kaydığını ölçer. Tam butona basacakken üstte bir görselin yüklenip her şeyi aşağı itmesi ve sizin yanlış yere tıklamanız — ölçtüğü şey tam olarak budur. Hedef 0,1 veya altıdır.

En sık sebep, görsellere, reklam alanlarına ve sonradan yüklenen bileşenlere önceden yer ayrılmamış olmasıdır. Geç yüklenen web yazı tiplerinin metni bir anda yeniden dizmesi de sık rastlanan ikinci sebeptir.

Bu skorlar sıralamamı gerçekten etkiliyor mu?

Etkisi var ama sınırlı ve iyi anlaşılması gerekiyor. Google'ın sayfa deneyimi belgesi iki şeyi açıkça söylüyor: iyi Core Web Vitals sonuçları üst sırayı garanti etmez ve Google, sayfa deneyimi zayıf olsa bile en alakalı içeriği göstermeyi seçer. Aynı belgeye göre sayfa deneyimi asıl, benzer derecede faydalı birçok sayfanın yarıştığı durumlarda fark yaratır.

Doğru okuma şu: kötü bir içerik hızlı olduğu için üste çıkmaz, fakat benzer kalitede iki içerik arasında daha iyi deneyim sunan öne geçebilir. Asıl etki zaten sıralamadan önce başlar: sayfa açılmadan giden ziyaretçi, siz kaçıncı sırada olursanız olun kaybedilmiştir.

Skorumu nasıl ölçerim? Test aracı neden farklı sonuç veriyor?

Buradaki karışıklık çok sık yaşanır, çünkü iki farklı tür veri vardır:

• Saha verisi (field data) — sitenizi gerçekten ziyaret eden Chrome kullanıcılarından toplanan ölçüm (Chrome User Experience Report, kısaca CrUX). PageSpeed Insights bu veriyi son 28 günlük dönem için gösterir. Core Web Vitals değerlendirmesi bu veriye dayanır.
• Laboratuvar verisi (lab data) — Lighthouse'un tek bir simüle cihaz ve sabit bağlantı koşullarıyla yaptığı ölçüm. Sorunu bulmak için çok değerlidir ama gerçek kullanıcıların darboğazlarını yakalamayabilir; aynı sayfayı iki kez ölçtüğünüzde farklı sonuç almanız normaldir.

Önemli bir ayrıntı: laboratuvar testinde kullanıcı etkileşimi olmadığı için Lighthouse INP'yi ölçemez; onun yerine Total Blocking Time (TBT) değerini bir işaret olarak kullanır. Yani PageSpeed Insights'taki "performans puanı" ile sayfanın Core Web Vitals'ı geçip geçmediği aynı şey değildir.

Search Console'daki Core Web Vitals raporu benzer deneyim sunan URL'leri gruplar ve her grubu mobil ile masaüstü için ayrı ayrı "İyi", "İyileştirilmesi gerekiyor" veya "Kötü" olarak işaretler. Düşük trafikli sitelerde yeterli saha verisi oluşmayabilir; bu durumda rapor boş kalabilir veya tüm siteye ait (origin düzeyinde) veriye döner.

Bu yüzden bir düzeltme yaptıktan sonra iyileşme hemen görünmez. Search Console'da bir sorun için doğrulamayı başlattığınızda 28 günlük bir izleme dönemi başlar; saha verisi de kayan 28 günlük pencereye dayandığından birkaç hafta beklemeniz gerekir.

Skorum 100 olmalı mı?

Hayır. 100 peşinde koşmak, gerçek kullanıcı için hiçbir şey değiştirmeyen mikro optimizasyonlara saatler harcatır. Anlamlı hedef, saha verisinde üç göstergede de "iyi" bandında olmaktır. Laboratuvar puanında 92 ile 100 arasındaki fark ziyaretçinizin fark edeceği bir şey değildir; 2,4 saniye ile 6 saniye arasındaki fark ise kesinlikle öyledir.

Yavaşlığın en yaygın sebepleri ve somut çözümleri neler?

Bizim denetlediğimiz sitelerde sorunlar büyük ölçüde aynı başlıklarda toplanıyor. Çözümler Google'ın CLS, LCP ve INP rehberleriyle örtüşüyor:

Sık yapılan hatalar

• Yalnızca masaüstünde test etmek. Değerlendirme mobil ve masaüstü için ayrı yapılır; sorunlar çoğunlukla mobilde çıkar.
• Laboratuvar puanını hedef sanmak. Lighthouse puanı yükselirken saha verisi yerinde sayabilir; karar saha verisine göre verilmeli.
• Her görsele lazy-load uygulamak. Ekranın ilk görünen kısmındaki görseli ertelemek LCP'yi doğrudan kötüleştirir.
• "Bir eklenti daha" ile hızlandırmaya çalışmak. Sorunu üçüncü taraf betik yarattıysa, çözüm genellikle yeni bir araç değil, mevcut olanın kaldırılmasıdır.
• Düzeltmeden ertesi gün sonuç beklemek. Saha verisi 28 günlük pencereyle hareket eder.

Sonradan düzeltilebilir mi?

Bir kısmı evet — görsel optimizasyonu ve gereksiz betiklerin temizliği her zaman yapılabilir. Ancak sayfanın nasıl önbelleklendiği, sunucu tarafında mı yoksa tarayıcıda mı oluşturulduğu ve içeriğin hangi sırayla yüklendiği mimari kararlardır; bunları sonradan değiştirmek yeniden yapmaya yaklaşır. Bu yüzden hız, projenin sonunda ele alınacak bir madde değil, başında verilecek bir karardır. Kurumsal web sitesi ve e-ticaret projelerimizde bu kararları ilk günden veriyoruz; mevcut sitelerde ise hız denetimini SEO ve GEO hizmetimizin bir parçası olarak yürütüyoruz.

Konuyla ilgili diğer yazılarımız: kendi sitemizde bulduğumuz sorunları anlattığımız teknik SEO kontrol listesi, hızın satışa nasıl dokunduğunu tartıştığımız e-ticarette dönüşüm oranı yazısı ve yavaşlığın bir yenileme sinyali olabileceğini anlattığımız kurumsal web sitenizi ne zaman yenilemelisiniz yazısı.

Mevcut sitenizin nerede takıldığını merak ediyorsanız ölçüp size somut bir liste çıkarabiliriz — hangi düzeltmenin hangi göstergeyi etkileyeceğini de yanına yazarız.