Bir sitenin açılması birkaç saniye sürüyorsa ziyaretçinin ne kadarını bekleyeceğini kimse tam olarak bilmez. Ama çoğu kişi, bir sayfa yavaş açıldığında ya da bir düğmeye bastıktan sonra tepki vermediğinde geri döner. Bu davranış, arama motorlarının da ilgilendiği bir kullanıcı deneyimi sorununu işaret eder. Google, bu deneyimi ölçmek için Core Web Vitals adını verdiği bir metrik grubu tanımlamıştır.
Bu yazı, Core Web Vitals kavramını teknik terimlerden arındırarak anlatıyor. Üç ana metriğin ne ölçtüğünü, bunların nasıl okunacağını ve bir site sahibinin ilk olarak nereye bakması gerektiğini gösteriyor. Kurumsal sitelerde hız ve yapı konusunda genel çerçeve için web tasarım hizmetimize da bakabilirsiniz.
Core Web Vitals neyi ölçer?
Core Web Vitals, bir sayfanın kullanıcı açısından üç ayrı soruya verdiği cevabı ölçer. Sayfa ne kadar çabuk görünür oluyor? Ziyaretçi bir şeye dokunduğunda ne kadar çabuk tepki alıyor? Ve sayfa yüklenirken içerik ne kadar kayıyor? Bu üç soru, kullanıcının sitede yaşadığı günlük sorunların büyük kısmını kapsar.
Önemli olan, bu metriklerin tek bir teknik ayar değil, bir deneyim özeti olduğunu anlamaktır. Sunucu yanıtı hızlı olsa bile sayfa ağır bir betikle kilitlenebilir. Görseller hızlı yüklense bile metin yer değiştirebilir. Bu yüzden üç metriği birlikte okumak gerekir.
LCP: sayfa ne kadar çabuk görünüyor?
LCP, Largest Contentful Paint kısaltmasıdır. Sayfadaki en büyük görünür öğenin ekranda ne kadar sürede belirdiğini ölçer. Bu öğe çoğu zaman ana sayfanın üst kısmındaki büyük bir görsel ya da başlığın altındaki ilk metin bloğudur.
Ziyaretçi sayfanın açıldığını ilk bu öğeden anlar. O görünmeden sayfa boş ya da yarım gibi durur. Bu nedenle LCP, algılanan hızın en güçlü göstergesidir. Yavaş bir LCP çoğu zaman büyük ve optimize edilmemiş bir görselden, yavaş bir sunucu yanıtından ya da tarayıcının önce indirmek zorunda kaldığı gereksiz stil dosyalarından kaynaklanır.
Sunucu tarafı da bu metriği doğrudan etkiler. Sayfa ilk bayt gelene kadar bekliyorsa, en iyi optimize edilmiş görsel bile geç görünür. Barındırma seçimi, önbellekleme ayarları ve sayfanın ne kadar ağır veriyle açıldığı, LCP’nin gerçek sınırını belirler. Bu yüzden görsel küçültmek tek başına yetmeyebilir; sunucu yanıtının da birlikte ele alınması gerekir.
INP: tıklamaya ne kadar çabuk tepki veriliyor?
INP, Interaction to Next Paint kısaltmasıdır. Kullanıcının bir tıklama, dokunma ya da tuş vuruşu yaptığı andan, ekranın bu etkileşime görsel olarak yanıt verdiği ana kadar geçen süreyi ölçer. Sayfanın tüm etkileşimleri üzerinden tipik bir değer hesaplanır.
Bu metrik özellikle menülerde, açılır listelerde ve formlarda önemlidir. Bir düğmeye basıldığında hiçbir şey olmazsa ziyaretçi bir kez daha denemeye ya da siteyi terk etmeye karar verir. Yavaş INP genellikle sayfayı meşgul eden ağır JavaScript kodundan kaynaklanır. Bu kodun ne zaman çalıştığına ve kimin ihtiyaç duyduğuna bakmak, çözümün ilk adımıdır.
CLS: içerik ne kadar kayıyor?
CLS, Cumulative Layout Shift kısaltmasıdır. Sayfa yüklenirken görünen öğelerin beklenmedik biçimde yer değiştirmesini ölçer. Herkesin yaşadığı tanıdık bir durumdur: metni okurken altındaki bir reklam ya da görsel yüklenir ve satır aşağı kayar.
Bu kayma, ziyaretçinin yanlış bir bağlantıya ya da düğmeye basmasına neden olabilir. Özellikle form alanlarında ya da satın alma adımlarında bu, ciddi bir güven kaybına dönüşür. Kaymanın en yaygın nedeni, boyutları önceden tanımlanmamış görsellerdir. Tarayıcı görselin ne kadar yer kaplayacağını bilmediğinde, yüklendiği anda içeriği iter. Görsel ve reklam alanlarına önceden yer ayırmak bu sorunu büyük ölçüde çözer.
Yazı tipleri de kaymanın sessiz bir kaynağıdır. Özel bir yazı tipi yüklendiğinde metnin boyutu ya da satır aralığı değişiyorsa, sayfadaki yazılar yeniden düzenlenir. Yazı tipi yüklemesini kontrol etmek ve geri dönüş yazı tipinin ölçülerini ana yazı tipine yakın tutmak, bu tür kaymaları azaltır. Bu ayrıntılar tek tek küçük görünse de birlikte değerlendirildiğinde ziyaretçinin okuma akışını belirgin biçimde etkiler. Ölçüm sonuçlarını her değişiklikten sonra yeniden okumak da bu nedenle önemlidir.
Üç metrik nasıl okunur?
Üç metriğin iyi, geliştirilmesi gereken ve zayıf olarak sınıflandırıldığı eşik değerleri Google tarafından belgelenmiştir. Bu eşikleri yazının içinde sayı olarak vermiyoruz; güncel değerler için Google’ın Core Web Vitals dokümanına bakmanızı öneririz. Okurken akılda tutulacak nokta şudur: bir metrik iyi, diğeri zayıf olabilir ve her birinin çözümü farklıdır.
| Metrik | Ölçtüğü şey | Tipik neden | İlk bakılacak yer |
|---|---|---|---|
| LCP | Ana içeriğin görünme süresi | Büyük görseller, yavaş sunucu | Üst alandaki görsel ve sunucu yanıtı |
| INP | Etkileşime tepki süresi | Ağır JavaScript | Menü, form ve üçüncü taraf betikler |
| CLS | Öğelerin kayma miktarı | Boyutu belirsiz görsel ve reklam | Görsel ölçüleri ve sonradan eklenen alanlar |
Bu tabloyu bir teşhis listesi gibi kullanabilirsiniz. Sorun hangi satıra denk geliyorsa, düzeltme de o satırdaki konularda aranmalıdır.
Ölçüm yaparken nelere dikkat edilmeli?
Core Web Vitals iki farklı kaynaktan okunabilir. Laboratuvar testleri, sayfayı belirli bir cihaz ve ağ koşulunda çalıştırır. Sonuçlar tekrarlanabilirdir ve bir değişikliğin etkisini hemen görmek için uygundur. Saha verisi ise gerçek ziyaretçilerden toplanır ve siteniz günlük hayatta nasıl çalışıyor, onu gösterir.
Bu iki kaynak aynı sonucu vermeyebilir ve bu normaldir. Laboratuvar testi güçlü bir bilgisayar ve hızlı bir bağlantı ile çalışabilir; ziyaretçilerinizin çoğu ise orta sınıf bir telefonda ve zayıf bir mobil ağda siteye girer. Bu yüzden saha verisi, kararlarda daha belirleyici bir yere sahiptir.
Ölçümü tek bir sayfada değil, ana şablonlarda yapmak da işe yarar. Ana sayfa, bir hizmet sayfası, bir blog yazısı ve iletişim sayfası farklı bileşenler kullanır. Birini düzeltip diğerini unutmak sık görülen bir hatadır.
Hızlı kazanımlar için ilk adımlar
Her site için geçerli bir sıralama yoktur, ama çoğu kurumsal sitede aynı sorunlar tekrarlanır. Önce en büyük görseli kontrol edin. Ana sayfanın üst kısmındaki görselin gereğinden büyük bir dosya olup olmadığına bakın ve ekran boyutuna uygun, sıkıştırılmış bir sürümünü kullanın.
Ardından üçüncü taraf betiklere bakın. Analitik, sohbet, harita ve reklam kodları her biri sayfanın işini biraz daha uzatır. Gerçekten kullanılmayanları kaldırmak ve gerekli olanları sayfanın sonunda yüklemek, INP üzerinde doğrudan etki yapar.
Son olarak görsellerin ve reklam alanlarının boyutlarını önceden tanımlayın. Bu basit adım CLS sorununun büyük kısmını çözer ve tasarımın stabil kalmasını sağlar. Üç adım da küçük değişikliklerdir; ama birlikte uygulandığında sitenin hissedilen kalitesini belirgin biçimde artırır.
Hız ve yapı birlikte düşünülmeli
Hız, tek başına bir teknik ayar değildir. Sitenin nasıl kurulduğu, hangi altyapının kullanıldığı ve içeriklerin nasıl yönetildiği, performansı doğrudan etkiler. Bu yüzden yeni bir site planlanırken ya da mevcut bir site yenilenirken hız hedefini baştan koymak, sonradan yama yapmaktan çok daha verimlidir.
Site yapısı ve altyapı seçimi için WordPress mi, statik site mi yazısına bakabilirsiniz. Yeni bir site yapılırken arama görünürlüğünü korumanın yolları için site yenilerken sıralama kaybetmemek yazımız da yardımcı olur.
Kontrol listesi
- Sayfanın en büyük görseli gereğinden büyük değil mi?
- Görsel ve reklam alanlarının boyutları önceden tanımlı mı?
- Kullanılmayan üçüncü taraf betikler kaldırıldı mı?
- Menü ve formlar tıklamaya hızlı tepki veriyor mu?
- Laboratuvar ve saha verisi birlikte okundu mu?
- Ana şablonların her biri ayrı ayrı ölçüldü mü?
- Değişikliklerden sonra metrikler yeniden kontrol edildi mi?
