cerenyilmaz

Responsiveness: Sayfa İçi Tüm Etkileşimleri Ölçme Metriği

Google Core Web Vitals, Google tarafında web ziyaretçileri gibi internet kullanıcılarının sayfa deneyimlerini ve site hız değerlerini ölçümlemek için tasarlanmıştır. Kullanıcı deneyimini optimize etmek, web üzerinde başarı yakalamak isteyen web siteleri için kilit noktadır. Tabi site sahipleri kullanıcılara sundukları deneyimin kalitesini anlayabilmek için performans gurusu olmak zorunda değiller. Bu noktada Core Web Vitals girişimi, site performansının daha net bir şekilde anlaşılabilmesi için basitleştirilmiş metrikler ile sunulmuştur.

 

Bu metrikler arasında CLS, LCP, TTFB ve FID gibi metrikler site hızını iyileştirmek ve en iyi kullanıcı deneyimi sunmak için büyük önem taşımaktadır.

 

Peki sayfa deneyimi (page experience) nedir?

Page experinence, yani sayfa deneyimi kullanıcıların web siteleri ile etkileşim deneyimlerini hem mobil hem de masaüstü cihazlarda nasıl algıladıklarını belirtmektedir.

 

Sayfa deneyimi için kullanmış olduğunuz arama motoru değişmemektedir. Çünkü tüm arama motorları kullanıcılarına en iyi sayfa deneyiminin sunulmasını istemektedir. Sayfa deneyimi konusunda ziyaretçilerine en iyi deneyimi yaşatan web sitelerin SERP sıralamaları da değişmektedir. Peki sayfa deneyime neler girer?

  • Sitenin yüklenme hızı (core web vitals)
  • Etkileşim
  • Kullanılan görseller
  • Mobil uyumluluk
  • HTTPs
  • Geçiş reklamları vs. gibi.

 

 

Özellikle SEO açısından sitelerin daha kullanıcı deneyimine hitap eden bir fonksiyonda tasarlanması, mevcut sorunların giderilmesi gibi işlemlerde (sayfa kaymaları, açılış gecikmeleri vs. gibi) ele alınmaktadır.

 

Peki Google tarafından sunulan CWV metriklerinin SEO açısından bu denli önemli olmasının sebebi nedir?

 

Core Web Vitals Neden Önemli?

Google gibi diğer tüm arama motorlarının siteleri arama sonuçlarında sıralarken dikkate aldığı bazı önemli hususlar vardır. Bu noktada CWV metrikleri sitelerin daha kullanıcı deneyimine uygun bir şekilde tasarlanmasına yardımcı olabilmek için hazırlanmıştır. Arama motoru botlarının site etkileşim verilerini toplarken, kullanıcıların sayfa gezinmesi gibi tüm site içi hareketlerinde ne gibi sorunlar yaşadığına dikkat etmektedir.

 

Bu noktada yüksek sayfa deneyimi kullanıcıların, arama niyetlerine göre ziyaret ettiği web sitelerinde aradıklarını daha kolay bulmaları ve iyi bir deneyim ile siteden ayrılmalarını sağlamaktır.

 

Kullanıcı deneyimi için büyük önem taşıyan CWV metrikleri içerisinde 2021 yılından 2022 yılına geçerken Google’ın tüm etkileşim sürelerini ölçebilmek için yeni bir metrik tasarlandığına dair bir genelge yayınlandı. Yayınlanan yeni genelge ile kullanıcıların sayfa içerisinde sadece ilk giriş gecikmelerini esas alan FID metriğine nazaran, sayfa içi tüm tıklama, fare gezinmesi ve kaydırma gibi hareketlerinin de hesaplanacağı duyuruldu.

 

Google tarafından tasarlanan yeni metrik ‘Responsiveness’ metriğine geçmeden önce diğer CWV meriklerine değinmek isteriz.

 

Core Web Vitals Metrikleri

Core Web Vitals metrikleri içerisinde temel alınan 3 adet metrik vardır. Bu metrikler:

  • LCP
  • CLS
  • FID

Bu metriklerin ne anlama geldiği, neden önemli olduğu ve nasıl optimize edebileceğimize değinelim.

Largest Contentful Paint (LCP) Nedir?

LCP metriği, bir web sayfasının yükleme zamanı ile ilgilidir. Kullanıcının sayfa ziyaret isteğinde bulunması ile birlikte ana içeriğin yüklenme süresine hesaplayarak, deneyimi ölçmektedir.

Metriğin kendi içerisinde en ideal süresi 2,5 saniye veya daha kısasıdır.

Ana içeriğin yüklenme hızı web sitesi veya web sayfasının ziyaretçi gözünde ilk izlenimi olması sebebi ile en kısa sürede yüklemeyi gerektirmektedir.

 

LCP Nasıl Optimize Edilir?

Genel anlamı ile ana içeriğin yüklenme süresini hesaplayarak deneyimi ölçümleyen LCP metriğinin zayıf olmasının bazı nedenleri vardır. Bunlar:

 

1.Yavaş sunucu yanıt süreleri:

Bir tarayıcının sunucu tarafından kaynağı alması ne kadar uzun sürerse, ilgili kaynağın ekrana getirilme süresi de uzayacaktır. Bunun için her şeyden önce sunucunuzun ilgili içeriğinizi nerede ve nasıl işlediğini inceleyerek iyileştirmeler yapmalısınız. Sunucu yanıt sürecinizi ölçümlemek için TTFB (ilk bayt) kullanın. İlk bayt sürenizi iyileştirmek için kullanabilecekleriniz arasında:

  • Sunucu optimizasyonu
  • Kullanıcıları yakınlarındaki CDN’ e bağlamak
  • Önbellek varlıkları
  • HTML sayfalarını önce önbelleğe sunmak
  • Thirty-party (üçüncü taraf kodlar) kod bağlantılarını erken kurun.

 

2. JS ve CSS dosyalarının optimizasyonu (LCP ve FCP geciktirmesini engellemek için)

 

3.Yavaş kaynak yükleme süreleri:

JS ve CSS dosyalarının yüklemeye etkileri olduğu gibi; <img>, <svg> ve <video> gibi kaynaklarında yüklemeye etkileri vardır. Bu dosyaların LCP etkilerini azaltmak için,

  • Görüntüleri optimize edin ve sıkıştırın,
  • Önemli kaynakları önceden yükleyin (preload.),
  • Metin dosyalarını sıkıştırın.

 

4.İstemci tarafı oluşturma:

İstemci üzerinde bir site oluşturuyorsanız, muhtemelen büyük JavaScript paketiniz vardır. Web sitenizi kullanıcıya sunmadan önce büyük dosyaların LCP üzerindeki etkileri hesaba katmalısınız. Çünkü kullanıcıların bütün JS dosyalarının indirilmesini ve yürütülmesini beklemesi, kullanıcıları herhangi bir içerik görememesine sebep olabilir. Bunun için yapabilecekleriniz:

  • Kritik JS kodlarını en aza indirin,
  • Sunucu tarafı oluşturmayı unutmayın,
  • Ön işleme (pre-rendering) kullanın.

 

Cumulative Layout Shift (CLS)

CLS metriği, sayfa yüklemesinde gerçekleşen düzen kaymalarını hesaplamaktadır. Görünür bir öğenin veya bir çerçevenin yükleme esnasında değişimler yaşaması düzen kaymasına girmektedir. Diğer tüm metrikler gibi, kullanıcı deneyimini en üst seviyelere çıkarmayı hedefleyen CLS metriğinde en ideal süre 0.1 saniye veya daha kısa bir puan olmalıdır.

CLS Nasıl Optimize Edilir?

Site içi düzen kaymalarını ölçümleyen CLS metriğini optimize edebilmenin yolları elbette vardır. Bunlar arasında:

 

1.Boyutsuz görselleri boyutlandırın:

Site içinde yer alan görsellerin mobil ve masaüstü cihazlarda doğru şekilde kullanıcıya verilebilmesi için görsellere ‘width- height’ değerleri verin.

 

2.Boyutsuz reklam yerleştirmeleri ve iframeler:

Reklamlar markaların tıklama ile gelir getirebildiği gibi, doğru yerleştirilmediği zamanlarda sayfa içeriklerinin kaymasına sebep olabilmektedir. Bunların önüne geçebilmek için reklamlar için site içinde yer ayırabilir ya da geçmiş verilerinize dayanarak reklamlar için en olası boyutları kullanabilirsiniz.

Diğer bir konu iframeler için; site içine gömülen videolar (youtube videoları gibi) en başta çok doğal bir boyutta gelebilir fakat farklı cihazlarda kayma gibi sorunlar yaratabilir. Bunun için yerleştirilecek alanın yükseklik ve genişliğini tarayıcı geliştiricileri (browser developer tools) ile hesaplayın, sonrasında eklenen iframe alana göre boyutlanabilecektir.

 

3.Web Fontları (Web yazı tipleri):

Web yazı tiplerinizin düzen kaymasına etkisini azaltabilmek için kullanabileceğiniz bazı yöntemler vardır. Bunlar arasında:

<link rel=preload> kullanarak yazı tipini önceden yükleyebilirsiniz. Daha fazlası için yazı tipi yükleme API’ sını incelemenizi öneririz.

 

First Input Delay (FID)

FID metriği, ilk giriş gecikmesi anlamına gelmektedir.

Farklı arama niyetlerine göre arama yapan kullanıcılar için web sitelerinin ilk izlenimleri oldukça önemlidir. Web gezinmelerinde ziyaretçiler üzerinde iyi bir izlenim bırakmak, sadık bir kullanıcı kitleniz oluşmasını sağlayacaktır.

 

İşte bu noktada FID, kullanıcıların sayfayla ilk etkileşimde bulundukları zamandan (yeni bir bağlantıya tıklama gibi) itibaren tarayıcının bu etkileşime verilecek yanıtı işlemeye başladığı zamana kadar sürmektedir.

Sayfayı veya siteyi ziyaret eden kullanıcının etkileşim süresindeki gecikmeyi hesaplayan FID metriğinin olması gereken değeri 100 milisaniye veya daha altında bir puandır.

 

FID Nasıl Optimize Edilir?

İlk giriş gecikmesini hesaplayan FID metriğinin optimize edilmesi en az diğer metrikler kadar önemlidir. FID optimizasyonu için yapabileceklerimiz:

 

1.JavaScript ve CSS dosyalarını optimize edin:

Uzun görevleri bölerek başlayabilirsiniz. Uzun görevler, ana iş parçacığı 50 ms veya daha fazla sürede bloke ediyorsa uzun görev olarak nitelendirilir ve bu JS şişkinliği anlamına gelmektedir. Kullanıcının ihtiyacından fazlasını yüklemek ve yürütmek FID sorunlarına sebep olabilir.

 

2.Üçüncü taraf (thirty-pard) kaynakları erteleyin:

Site içi yüklemede sorun yaratan üçüncü taraf kodları <async> veya <defer> ile erteleyin. Bu sayede site açılırken bu kodların açılış üzerindeki olumsuz etkisi ortadan kaldırılacaktır.

 

3.Web çalışanlarını kullanın (using web workers):

Ana iş parçacığı üzerindeki etkiyi azaltmak için bazı çalışmaları web çalışanlarına devredebilirsiniz.Web çalışanları, kodlarınızın bir kısmını iş parçacığında çalıştırılmak üzere yetkilendirmenize izin verir; bu, ana iş parçacığı için daha az iş ve daha az giriş gecikmesi anlamına gelir.

 

Core Web Vitals metriklerleri arasında 3 temel olandan bahsettikten sonra, konunun en başında belirttiğimiz gibi Google tarafından tasarlanmaya başlanan yeni metrik Responsiveness’ den söz etmek isteriz.

 

Yeni CWV Metriği: Responsiveness

Google üzerinde niyete göre arama yapan kullanıcıların ziyaret ettikleri web sitelerinde FID ile ilk etkileşime başlama süreleri hesaplanıyordu. FID gibi tüm metriklerde iyileştirme yapılmasının en büyük sebebi kullanıcı deneyimini doğru şekilde ölçümleyebilmektir.

 

Ziyaretçinin site ile etkileşimi sonrası beklediği süreyi baz alan FID metriği, TTB (Total Blocking Time)  ve TTI (Time to Interactive) metriklerine nazaran kullanıcı deneyimini çok daha doğru ölçebiliyor. Fakat devamındakileri ölçebilmemiz için responsiveness metriğinin geliştirilmesine karar verildi.

 

Peki Neden Yeni Bir Metrik?

Google, FID metriğinin üstte söz ettiğimiz diğer metriklerden daha iyi ölçümleme yapmasına rağmen, yalnızca tıklama veya dokunma gibi ilk etkileşimleri baz almasının sayfa içerisindeki diğer etkileşimleri kaçırdığını düşünmesine sebep oldu.

 

Tasarlanan yeni metrik Responsiveness ise, FID’ ın daha geliştirilmiş bir versiyonu olarak, sayfa içerisindeki tüm etkileşimlerin ortalama süresi baz alınarak hesaplanacağı açıklandı. Sunulmaya hazırlanan yeni metriğin sayfa etkileşimi sırasında yapması beklenen görevler ise:

  • Tüm kullanıcı etkileşimlerinin göz önünde bulundurulması,
  • Sayfa içerisinde yapılan her etkileşimin tam süresinin yakalanması,
  • Aynı mantıksal çerçevede kullanıcı etkileşiminin bir parçası olarak meydana gelen tüm olayları gruplayarak, etkileşim gecikmesi gibi tüm değerlerinin maksimum süresinin tanımlanması,
  • Sayfa içerisinde yapılan her etkileşim için toplu bir puan oluşturulması.

 

Google açıklamalarına göre, bir web sitesi sunulmaya hazırlanan yeni metrikten düşük bir puan alırsa, kullanıcı etkileşimlerine hızlı yanıt vermediği kesinleşmiş olacaktır.

 

Responsiveness ile sayfa içi tüm etkileşimlerin ortalama yanıt süresini ölçülebildikten sonra bunun için genel bir puan değerlendirilmesi de yapılmalıdır.

 

Etkileşim Toplama Stratejileri

Düşünülen stratejiler arasında daha net bir anlatım olabilmesi için alt kısımda dört etkileşimden oluşan örnek bir senaryo verilmiştir.

 

Oluşturulan senaryo:

 

Etkileşim Gecikme
Tıklama (click) 120 ms
Tıklama (click) 20 ms
Tuşa Basma (key press) 60 ms
Tuşa Basma (key press) 80 ms

 

 

Bu senaryo dahilinde üst listede yer alan değerler sonucunda ‘en kötü etkileşim gecikmesi’ (worst interaction latency) 120 ms olacaktır.

 

Google tarafından sitelere belirtilen her bir etkinlik için oluşturulan bütçe stratejisi:

 

 

Etkileşim Türü Bütçe Eşiği
Sayfa içi tıklama veya dokunma 100 ms
Sayfa içi sürükleme 100 ms
Sayfa içi kaydırma 50 ms

 

Üst tabloda oluşturulmuş etkileşimlerin her biri, bütçe eşiğini aşan gecikmeyi dikkate alacaktır. Üst tarafta oluşturulan örnek senaryo dahilinde bütçe aşımında tutarlar şu şekilde olacaktır:

 

 

Etkileşim Bütçe Bütçeyi Aşan Gecikme
Tıklama (click) 120 ms 20 ms
Tıklama (click) 20 ms 0 ms
Tuşa Basma (key press) 60 ms 10 ms
Tuşa Basma (key press) 80 ms 30 ms

 

Bütçeyi Aşan En Büyük Gecikme

Bütçeyi aşan en büyük gecikme süresi, üst tablo baz alınarak hesaplanacaktır.

 

Örnek Hesaplama:

max(20, 0, 10, 30) = 30 ms

 

Bütçeyi Aşan Toplam Gecikme

Bütçeyi aşan etkileşimlerin toplamı, üst tablo baz alınarak hesaplanacaktır.

 

Örnek Hesaplama:

(20 + 0 + 10 + 30) = 60 ms

 

Bütçe Üzerinden Ortalama Etkileşim Gecikmesi

Toplam bütçeyi aşan etkileşim gecikmesinin toplam etkileşim sayısına bölümü ile hesaplanacaktır.

 

Örnek Hesaplama:

(20 + 0 + 10 + 30) / 4 = 15 ms

 

Tüm bu örnek hesaplamalar sonrasında, Google tarafından sunulmaya hazırlanan yeni metrik Responsiveness ile sayfa içerisinde yer alan header, footer gibi üst- alt alanlar ve sayfa orta kısımları dışında ‘sepete ekle’ ve ‘favorilere ekle’ butonlarının optimizasyonunun önem kazanacağı düşünülüyor.

 

Core Web Vitals metriklerine eklenmek üzere tasarlanmaya başlanan responsiveness metriğinin detaylarından, nasıl ölçümleme yapacağından örnek hesaplamalar ile söz ettik. Peki hayata geçirilmek üzere tasarlanan yeni metriğimiz responsiveness’ i nasıl optimize edeceğiz?

Responsiveness Metriği Nasıl Optimize Edilir?

Responsiveness, FID metriğinden farklı olarak sayfa içerisinde ki tüm etkileşimleri baz almaktadır. Tüm etkileşimler olarak söz ettiklerimiz arasında; sayfa içi kaydırma, tıklama, yüklenme, fare hareketleri neticesinde üzerine gelinen bağlantıların önceden yüklenmesi.

 

İşte bu noktada böylesine derinleme etkileşim ölçer bir metrik için daha detaylı hareket etmemiz gerektiğinin farkına varmalıyız. Hayata geçirilmeye hazırlanan yeni metriğimizden en iyi puanlamaları almak için doğru optimizasyon çalışmaları yapmalıyız.

 

Peki neler yapabiliriz?

CSS ve JS Dosyalarına Müdahale

FID metriğini optimize etmek için yapacağımız ilk işlemlerden biri CSS ve JS dosyalarına optimize edilmesidir. Çünkü yükü büyük dosyalar, kullanıcıların site ile ilk etkileşime girmek istedikleri süre içerisinde yavaşlamaya ve kullanıcıda ‘bounce rate’ ya da diğer adıyla ‘zıplama’ dediğimiz olayın gerçekleşmesine sebep olabilir.

(bounce rate, kullanıcıların ziyaret ettikleri sitede herhangi bir etkileşimde bulunmadan sayfayı terk etmelerine denir.)

 

CSS ve JS dosyalarının sayfa yüklemesine verebilecekleri zararı en aza indirmek için; dosyaları minimalize ederek, kullanılmayan kodları kaldırabiliriz. Diğer bir yöntem olarak da kullanılmayan JS ve CSS dosyalarını <async> veya <defer> ile ertelemek olacaktır.

 

Bağlantıları Önceden Yükleme (Fare Hareketleri)

En önemlilerinden biri kesinlikle kullanıcının fare ile tıklayacağı alanı önceden biliyormuş gibi hareket edin. Peki bu ne demek?

 

Kullanıcıların sayfa gezinmesi esnasında fare ile üzerinde gezindiği farklı alanlar vardır. Sayfa içi etkileşim esnasında fare hareketleri veya dokunma hareketleri ile üzerine gelinen bağlantıları önceden yükleyebilirsiniz.

 

Bunun için kullanılabilecek yöntemlerden biri instant.page 0.2 olabilir. Peki instant.page 0.2 nedir?

 

Kullanıcının üzerine geldiği alanı ms cinsinden hesaplayarak (bu rakam 65 ms) tıklayacağı ön görülen bağlantıyı tıklama öncesi yüklemeyi sağlar. Yapılan bu işlem sayesinde kullanıcı site içinde sayfalar arası gezinti yaparken aradığı veya merak ettiği alanlara çok daha hızlı bir şekilde ulaşabileceği gibi sayfaların ortalama 80 ms daha hızla yüklenmesini sağlayacaktır.

 

Tabi burada sizlere yöneltmiş olduğumuz çözümler ön görülen çözümler olsa da, FID optimizasyonu için yapılan geliştirmeler Repsonsiveness içinde geçerlidir. Responsiveness tasarımının bitmesi ile geliştirilmiş çözümlerimizi sizlerle paylaşmak için tekrardan güncelleyeceğiz.

 

Son olarak, metriğin hayata geçmesi ile daha rekabetçi bir ortam olacağı kesin. Burada dikkat edilmesi gereken nokta, rekabet çemberi genişlemeden önce harekete geçmek olacaktır.

 

Responsiveness metriği ile kullanıcıların site veya sayfa içerisinde tüm etkileşimlerinin ölçümlemesi alınabilecek, bu sayede web siteleri daha yüksek kullanıcı deneyimine uygun şekilde tasarlanabilecektir.

 

Kaynaklar:

https://www.youtube.com/watch?v=iNfz9tg-wyg&t=383s

https://web.dev/better-responsiveness-metric/ 

https://web.dev/responsiveness/

https://web.dev/fid/

https://web.dev/lcp/

https://web.dev/cls/

https://www.onely.com/blog/what-is-first-input-delay/ 

https://wpdevshed.com/7-ways-to-improve-your-long-scrolling-website/ 

https://css-tricks.com/preloading-pages-just-before-they-are-needed/

https://developers.google.com/search/docs/advanced/experience/page-experience 

https://web.dev/optimize-lcp/ 

https://web.dev/optimize-cls/ 

https://web.dev/optimize-fid/ 

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.