Core Web Vitals 28 günlük gecikme neden bir efsanedir
Google'ın Core Web Vitals verisinin 28 gün geciktiğini söylediğinde gerçekten ne demek istediğini anlayın
Core Web Vitals 28 Günlük Gecikme Efsanesini Çürütmek
Core Web Vitals verisinin 28 günlük bir gecikme yaşadığı fikri, web geliştirme topluluğunda yaygın bir yanlış anlamadır. Bu inanç, "28 gün daha değişiklikleri göremeyiz" veya "Umalım ki işe yarar; 28 gün sonra öğreneceğiz" gibi ifadelere yol açmıştır. Ancak bu algı yanlıştır ve Chrome User Experience Report (CrUX) verisinin nasıl işlendiği ve sunulduğuna dair bir yanlış anlamaya dayanmaktadır.
CrUX Verisinin Gerçeği!
Popüler inancın aksine, CrUX verisi 28 günlük bir gecikmeye tabi değildir. Aslında, veri son derece günceldir, genellikle sadece iki gün eskidir. Bu, Google CrUX API'sini sorgulayarak doğrulanabilir ve bu API verinin ne kadar güncel olduğunu açıkça gösterir!

28 Günlük Pencereyi Anlamak
Kafa karışıklığı, Google'ın Core Web Vitals verisini sunma şeklinden kaynaklanır. Kullanıcıların gerçekte gördüğü şey, son 28 gün boyunca hesaplanan 75. yüzdelik değerdir. Bu istatistiksel yaklaşım, kısa vadeli dalgalanmaları yansıtmak yerine, zaman içinde bir web sitesinin performansının daha istikrarlı ve temsili bir ölçüsünü sağlamak için tasarlanmıştır.
Neden Gecikme Varmış Gibi Görünüyor
75. yüzdeliği hesaplamak için 28 günlük kayan bir pencerenin kullanılması, iyileştirmeleri görmede bir gecikme yanılsaması yaratabilir. İşte nedeni:
- Kademeli Veri Değiştirme: Başlangıçta, bu yeni veri daha eski, potansiyel olarak daha düşük performans verisiyle karıştırılır. Her gün yeni veri 28 günlük performans penceresine eklenir ve en eski verinin bir günü çıkarılır. Tüm verinin değiştirilmesi tam 28 gün sürecektir.
- Yüzdelik Hesaplama: 75. yüzdelik kullanıldığından, bu metriği önemli ölçüde değiştirmek için yeterli iyileştirilmiş veri noktasının toplanması zaman alır. Bu sezgisel olmayabilir, ancak yüzdelik skorları ortalamalar gibi düşünemezsiniz. Sonuç olarak, 75. yüzdelik ani dalgalanmalar söz konusu olduğunda 'değişime dirençli' olabilir.
Şöyle düşünün: 28 kırmızı bilyeniz olan bir kutunuz var. Her gün bir eski, kırmızı bilye çıkarıp yerine yeni bir yeşil bilye koyuyorsunuz. Tüm kutuyu tamamen yenilemek tam 28 gün sürecektir ama hiçbir zaman bir gecikme olmamıştır!
Kavanozun ne kadar hızlı çoğunlukla yeşil olacağı (75. yüzdelik) içinde zaten kaç kırmızı bilye olduğuna bağlıdır. Çok fazla kırmızı bilye varsa, yeşil olması daha uzun sürer. Ama daha az kırmızı bilye varsa, kavanoz daha hızlı yeşil olur.
Web Geliştiricileri için Sonuçlar
Bu mekanizmayı anlamak, web geliştiricileri ve site sahipleri için önemli sonuçlar doğurur:
- Sürekli İzleme: Sonuçları görmek için 28 gün beklemek yerine, Core Web Vitals'inizi düzenli olarak izleyin, tercihen günlük aralıklarla 75. yüzdeliği hesaplayabilen RUM izleme ile.
- Aşamalı İyileştirmeler: Küçük iyileştirmeler bile zaman içinde 75. yüzdeliği kademeli olarak kaydırmaya katkıda bulunabilir.
- Sabır ve Azim: Bildirilen metriklerde hemen dramatik değişiklikler görmeyebilirsiniz, ancak tutarlı iyileştirmeler sonunda yansıtılacaktır.
Stop debating in Jira.
Get a definitive answer on your performance issues. I deliver a granular breakdown of your critical rendering path.
- Definitive Answers
- Granular Breakdown
- Critical Path Analysis