Performans İzleme ve Raporlama
Core Web Vitals Takibi İçin Dashboard Nasıl Kurulur?
Çoğu ekip Core Web Vitals'ı bir kez kontrol eder ve dosyayı kapatır. Search Console'a girip "İyi" kategorisinde kaç sayfa olduğuna bakar, bir not düşer ve bir sonraki sprint'e geçer. Aylarca sonra yeni bir dağıtım ya da bir üçüncü taraf script değişikliği metrikleri bozmuş olur; ama bu kimsenin dikkatini çekmez. Ta ki Search Console bildirimi gelene kadar — ve bu bildirimin gelmesi bazen haftalar alır.
Sürekli izleme bu boşluğu kapatır. Doğru kurulmuş bir dashboard, metriklerin hangi sayfa tipinde hangi yönde hareket ettiğini düzenli olarak gösterir; eşik ihlallerini erken haber verir ve ekibin aynı veri üzerinde konuşmasını sağlar. Bunun için karmaşık bir altyapıya ihtiyaç yoktur. Mevcut API'ler ve ücretsiz araçlar, ciddi bir izleme altyapısını herkes için erişilebilir kılmıştır.
Bu yazı, hangi veri kaynaklarının ne sağladığını, bu kaynakları nasıl bir araya getireceğinizi ve ekibinize anlamlı gelen bir raporlama yapısını nasıl kuracağınızı ele alıyor. Teknik detay gerektiren adımlar için alternatif yollar da gösterilecek.
Sürekli takibin önünde duran zihinsel engel
Core Web Vitals takibinin ihmal edilmesinin en yaygın nedeni "manuel kontrol yeterli" yanılgısıdır. Search Console'a haftada bir girilir, büyük bir kırmızı alan yoksa sorun da yoktur diye düşünülür. Oysa Search Console 28 günlük kayan pencereyle çalışır; bir gerileme, pencereye yeterli ölçüm verisi girene kadar raporlara yansımayabilir. Bu gecikme, sorunun kaynağını tespit etmeyi de zorlaştırır.
İkinci engel "dashboard kurmak karmaşıktır" kabulüdür. Looker Studio, Google Sheets ve ücretsiz API'ler bir araya geldiğinde, teknik bilgisi orta düzeyde biri birkaç saatte işlevsel bir izleme sistemi kurabilir. Karmaşıklık algısı çoğu zaman gerçek karmaşıklığın çok önüne geçer. Küçük ama sürekli çalışan bir sistem, ayda bir açılan eksiksiz bir rapordan çok daha değerlidir.
Veri kaynakları: Search Console, CrUX API ve PSI API arasındaki fark
Bu üç kaynak aynı temel veriyi farklı erişim yollarıyla sunar, ama aralarında önemli farklar vardır. Search Console en erişilebilir olanıdır: arayüzden doğrudan okunur, site doğrulaması gerektirir ve sitenizin URL gruplarına göre aggrege edilmiş CWV verisini gösterir. Bireysel URL detayı sınırlıdır; büyük ölçekte otomasyon için yeterli değildir.
CrUX API (Chrome UX Report API) sayfa ve origin düzeyinde ham metrik dağılımlarına programatik erişim sağlar. LCP, CLS ve INP için yüzdelik dilim verilerini alabilir, belirli URL'leri sorgulayabilir ve bu veriyi zaman serisi olarak depolayabilirsiniz. Ücretsizdir; API anahtarı gerektirir. PageSpeed Insights API ise CrUX verisini Lighthouse lab verisiyle birleştirerek tek bir endpoint'ten döndürür. Her iki kaynağı tek istekte almak için kullanışlıdır; ama rate limiting nedeniyle büyük site analizi için uygun değildir. Bu üç kaynağın hangi kombinasyonunu kullanacağınız, sitenizin büyüklüğüne ve otomasyon ihtiyacınıza göre belirlenir.
Search Console Core Web Vitals raporu nasıl verimli okunur
Search Console'daki Core Web Vitals raporu sayfaları benzer URL gruplarına göre kümeleyerek sorunlu grupları listeler. "İyi", "İyileştirme gerekiyor" ve "Zayıf" kategorilerindeki URL sayısını gösterir; hangi metric'in soruna yol açtığını belirtir. Buradaki kritik nokta şudur: rapor sorunun hangi metrikten kaynaklandığını gösterir, hangi sayfanın etkilendiğini tam olarak söylemez. Aynı URL şablonundaki sayfalar gruplanır.
Bu kısıtlamayı aşmak için URL inceleme aracı ile birlikte kullanmak gerekir. Bir URL grubunda sorun tespit edildiğinde, o gruba dahil birkaç temsil edici URL ayrı ayrı incelenir. Hangi metrik eşiği aşıyor, bu hangi sayfa tipinde daha yaygın — bu soruların yanıtı Search Console'dan çıkarılabilir ama biraz emek gerektirir. Düzenli izleme için ayda en az bir kez bu raporu kontrol etmek ve önceki ay ile karşılaştırma yapmak makul bir başlangıç noktasıdır.
CrUX API ile sayfa düzeyinde veri çekme
CrUX API, belirli bir URL ya da origin için 75. yüzdelik dilim metrik değerlerini ve dağılım verilerini döndürür. Bir URL için POST isteği gönderilir; yanıtta LCP, CLS ve INP değerleri hem sayısal olarak hem de "good", "needs improvement" veya "poor" kategorisiyle birlikte gelir. Bu veri, izlemek istediğiniz her URL için periyodik olarak çekilebilir ve bir Google Sheets ya da basit bir veritabanına yazılabilir.
Pratik bir yaklaşım şudur: öncelikli sayfaların listesi belirlenir — ana sayfa, kategori sayfaları, en fazla trafik alan içerik sayfaları. Bu URL'ler için haftalık CrUX API sorgusu çalıştıran bir Google Apps Script yazılır ve sonuçlar bir Sheets belgesine eklenir. Bu belge hem zaman serisi izleme hem de Looker Studio kaynağı olarak kullanılabilir. API anahtarı ücretsiz alınabilir; rate limit günlük 25.000 istektir, bu çoğu site için yeterlidir.
PageSpeed Insights API ile periyodik veri toplama
PageSpeed Insights API hem CrUX alan verisi hem de Lighthouse lab verisi döndürür. Tek bir istekte bir URL için tüm CWV metriklerini, Lighthouse puanını ve teşhis verilerini almak mümkündür. Bunu bir zamanlama sistemiyle birleştirmek — örneğin Google Apps Script'in tetikleyicileri ya da GitHub Actions — düzenli veri toplamanın pratik bir yolunu sunar.
Büyük siteler için PSI API tek başına yeterli değildir; her URL için ayrı istek gerekmesi ve rate limit kısıtlamaları bunu zorlaştırır. Küçük ve orta ölçekli siteler için ise oldukça işlevseldir. Kritik sayfalar (ana sayfa, ürün detay, kategori listesi, ödeme akışı) için günlük PSI API sorgusu çalıştırmak ve sonuçları depolamak, olası gerilemeleri o gün içinde tespit etmeyi mümkün kılar. Bu yaklaşım hiçbir özel altyapı gerektirmez.
Looker Studio ile görsel dashboard oluşturma
Looker Studio (eski adıyla Google Data Studio) ücretsizdir ve Google Sheets dahil birçok veri kaynağına bağlanabilir. CrUX API ya da PSI API'den Sheets'e yazılan veriler Looker Studio'da görselleştirilebilir. Zaman serisi grafikleri, renk kodlu eşik göstergeleri ve sayfa tipi bazında karşılaştırma tabloları — bunların tümü birkaç saat içinde kurulabilir.
Dashboard'un temel yapısı şöyle düzenlenebilir: üstte özet kart satırı — LCP, CLS, INP için güncel 75. yüzdelik dilim değerleri ve "İyi/İyileştirme gerekiyor/Zayıf" durumu. Altında zaman serisi grafikleri — son 12 hafta için her metriğin seyri. Eşik çizgileri grafiğe eklenerek hangi dönemde eşiğin üstüne çıkıldığı görsel olarak işaretlenebilir. En alta sayfa tipi dökümü — ana sayfa, kategori, içerik sayfaları ayrı satırlarda karşılaştırmalı olarak gösterilir. Bu yapı hem düzenli izleme hem de yönetim raporlaması için kullanışlıdır.
Dashboard'da hangi metrikler öncelikli izlenmeli
Her üç Core Web Vitals metriği dashboard'da yer almalıdır, ama izleme yoğunluğu farklılaştırılabilir. LCP doğrudan kullanıcının sayfayı hızlı algılayıp algılamadığını etkiler ve ağ koşullarıyla bağlantılıdır; görsel yükleme sorunlarını, CDN değişikliklerini veya büyük kaynak değişikliklerini en hızlı yansıtan metriktir. INP kullanıcı etkileşim kalitesini ölçer; JavaScript ağırlıklı sayfalarda kritiktir ve bir script değişikliğiyle aniden bozulabilir.
CLS görece kararlı bir metrik olma eğilimindedir; büyük layout değişiklikleri olmadıkça kendiliğinden bozulmaz. Ancak yeni bir reklam birimi, embed veya content block eklendiğinde ani artışlar yaşanabilir. Bu üç metriği ayrı ayrı izlemek yerine bütünleşik bir görünümde sunmak, hangisinin sorunlu olduğunu tek bakışta anlamayı kolaylaştırır. Performans bütçesi anlayışıyla entegre edildiğinde, metrik değerleri sayısal eşiklerle doğrudan ilişkilendirilebilir.
Eşik değerler ve uyarı mekanizmaları
Dashboard'un pasif bir görünüm olmaktan çıkıp aktif bir izleme aracına dönüşmesi için uyarı mekanizması gerekir. Google'ın tanımladığı eşikler iyi başlangıç noktalarıdır: LCP için 2,5 saniye, CLS için 0,1 ve INP için 200 milisaniye "İyi" kategorisinin üst sınırıdır. Bu değerleri aşan durumda otomatik bildirim gönderilmesi, sorunun fark edilmesini dağıtım değişikliğiyle zamana yakın tutar.
Uyarı mekanizması için birkaç pratik yol vardır. Google Sheets'te Apps Script ile belirli bir hücre değeri eşiği aşınca e-posta gönderen bir tetikleyici yazılabilir. Looker Studio'nun yerleşik uyarı özelliği, belirli koşullar karşılandığında e-posta bildirimi gönderebilir. Daha gelişmiş bir seçenek olarak Slack ya da Teams'e webhook entegrasyonu kurulabilir. Uyarı eşiğini çok hassas ayarlamak — her küçük dalgalanmada bildirim göndermek — uyarı yorgunluğuna neden olur; eşiği biraz daha yukarıda tutmak, gerçek sorunların dikkat çekmesini sağlar.
Segmentasyon: sayfa tiplerine göre izleme
Tüm siteyi tek bir ortalama üzerinden izlemek, sorunları gizleyebilir. Ana sayfa "İyi" sınıfında olabilir ama kategori sayfaları "Zayıf" sınıfında kalıyor olabilir. Bu ayrım, origin düzeyi CrUX verisinde görünmez; sayfa tipi bazında segmentasyon gerekir.
Segmentasyon için izlenecek URL listesi sayfa tiplerine göre organize edilir: ana sayfa, kategori listeleri, ürün/içerik detay sayfaları, arama sonuçları, ödeme akışı. Her grup için ayrı CrUX sorguları çalıştırılır ve sonuçlar ayrı satırlarda dashboard'a aktarılır. Bu yapı hem sorunun nerede yoğunlaştığını gösterir hem de iyileştirme çalışmalarının hangi segmenti en çok etkilediğini takip etmeyi sağlar. Büyük e-ticaret sitelerinde ürün sayfaları ile kategori sayfaları çoğu zaman farklı CWV profiline sahiptir; bu farkı görmezden gelmek optimizasyon önceliklerini yanlış belirlemek demektir.
Ekip içi raporlama ve paylaşım formatı
Dashboard'un değeri onu kimin, ne sıklıkla kullandığına bağlıdır. Teknik ekip için ham metrik değerleri ve zaman serileri anlamlıdır; yönetim için kategorik durum özeti — kaç sayfa "İyi", kaç tanesi "Zayıf" — daha işlevseldir. İki farklı görünüm içeren bir Looker Studio raporu bu ihtiyacı karşılayabilir.
Haftalık özet e-postası, dashboard'u düzenli açmayan ekip üyelerini döngüde tutar. Bu e-posta, önceki haftaya göre her metriğin durumunu, dikkat gerektiren sayfa tiplerini ve herhangi bir eşik ihlali varsa bunun muhtemel nedenini içerebilir. Dashboard bağlantısı e-postaya eklenir; detay merak edenler doğrudan görünüme ulaşır. Bu düzeni kurmak otomasyonla kolaylaştırılabilir: her Pazartesi çalışan bir Apps Script özet e-postayı otomatik gönderir.
Otomasyona giden yol: CI entegrasyonu ve sürekli izleme
Dashboard bir raporlama aracıdır; gerilemeyi önlemenin diğer kolu CI/CD sürecine performans kontrolleri eklemektir. Her dağıtımda kritik sayfalar için PSI API sorgusu çalıştırmak ve alan verisi metriklerini geçmiş ortalamalarla karşılaştırmak mümkündür. Eşik aşılırsa dağıtım uyarısı verilebilir ya da gerekirse durdurulabilir.
Bu entegrasyon başlangıçta karmaşık görünse de GitHub Actions gibi araçlarla adım adım kurulabilir. Hafif bir başlangıç için CI pipeline'ına yalnızca bir uyarı adımı eklemek — dağıtım sonrası PSI API'yi çağırıp sonuçları kaydet, eşik aşıldıysa bildirim gönder ama durma — gereksiz karmaşıklıktan kaçınırken değerli veri sağlar. Alan verisi ile lab verisi arasındaki farkı göz önünde bulundurduğunuzda, bu kontrolde alan verisi kullanmak daha güvenilir sonuç verir.
Dashboard'un ne zaman yanıltabileceği
Bir izleme sisteminin sınırlarını bilmek, onu doğru yorumlamak için gereklidir. CrUX verisi 28 günlük kayan pencereyle çalışır; bugün yapılan bir değişiklik dashboard'a hemen yansımaz. Bu gecikme, gerilemeleri geç fark ettirebileceği gibi iyileştirmelerin etkisini de geciktirerek gösterir. Ani bir düşüş ya da artış gördüğünüzde, bunun ne zaman başladığını tahmin etmek için dağıtım geçmişiyle karşılaştırma yapmak gerekir.
Öte yandan düşük trafikli sayfalar CrUX'ta temsil edilmeyebilir; bu sayfalar dashboard'da görünmez ve sorunlar gözden kaçar. Yalnızca yeterli trafik alan sayfalar için veri döner; yeni yayınlanan içerikler veya az ziyaret gören sayfalar için alan verisi olmayabilir. Bu durumda söz konusu sayfalar için PSI API'nin Lighthouse lab verisi tek referans noktası olur. Dashboard güçlü bir araçtır ama eksiklerini bilmek, yanlış güven duymaktan daha değerlidir.
Bir Core Web Vitals dashboard'u kurmak, tek seferlik bir proje değil; süregelen bir izleme alışkanlığının teknik altyapısıdır. Başlangıç basit tutulabilir: birkaç kritik URL için haftalık CrUX sorgusu, bir Sheets belgesi ve temel bir Looker Studio görünümü. Buradan itibaren segmentasyon, uyarı mekanizmaları ve CI entegrasyonu sistemi ihtiyaca göre genişletebilir.
Asıl risk mükemmel bir sistem kurmayı beklerken hiçbir şey kurmamaktır. Eksik ama çalışan bir izleme sistemi, var olmayan mükemmel bir sistemden her zaman daha değerlidir. Metriklerdeki bir gerilemeyi bir ay sonra değil o hafta fark etmek, sorunun kaynağını bulmayı ve çözmeyi önemli ölçüde kolaylaştırır.
Veri toplamak ve görselleştirmek bu sürecin teknik kısmıdır. Asıl değer, dashboard'un ekibin ortak referans noktasına dönüşmesinden gelir. Herkes aynı metrikleri, aynı sayfa tiplerini ve aynı eşikleri takip ettiğinde, performans konuşmaları spesifik verilere dayanır; sezgilere değil. Dashboard kurulumuna başlamadan önce sitenin genel performans durumuna hızlı bir giriş yapmak için bir site analiz aracı temel referans noktası olarak kullanılabilir.