Lansman sonrası Core Web Vitals: 30 günlük izleme planı

Lansmandan sonra Search Console CWV sekmesinin sarıya dönmesini izliyorsanız ama nereden başlayacağınızı bilmiyorsanız bu yazı 30 günlük bir plan veriyor. Lansman gününde Lighthouse’da 95+ aldınız, performans kategorisi yeşil, LCP 1,8 saniyede sabit. Üç hafta sonra Search Console “Core Web Vitals” sekmesi sarıya, ardından kırmızıya dönüyor. Gerçek kullanıcılarda LCP 3,4 saniye, INP 280 ms, CLS 0,18. Tanıdık bir tablo. Bunun nedeni Lighthouse’un yalan söylemesi değil; lab koşulu (sabit CPU throttling, sabit ağ, soğuk önbellek, tek bir konum) ile alandaki kullanıcının (orta seviye Android, mobil 4G, ısınmış DOM, üçüncü taraf script’leri yüklenirken sayfa açan) deneyimi arasındaki açıktır.

Bu yazı, bu açığı kapatmak için ilk 30 günü nasıl geçirdiğimizi anlatıyor. Plan dört aşamadan oluşuyor: 0–3 gün baseline ve alarm kurulumu, 4–14 gün örüntü tespiti, 15–21 gün hedefli düzeltmeler, 22–30 gün stabilizasyon ve raporlama. Sonunda haftalık yönetim raporunu çıkartıp ürün ekibine devrediyoruz. Yazı boyunca somut eşikler (LCP <2,5 sn, INP <200 ms, CLS <0,1) ve gerçek araçlar (Plausible web-vitals, Lighthouse CI, web-vitals npm, PostHog session replay, Cloudflare Web Analytics) ile çalışıyoruz çünkü “RUM kurun” tavsiyesi kâğıtta iyi durur, salı sabahı incelenecek bir dashboard’a dönüşmediği sürece işe yaramaz.

0–3. gün: baseline ve alarm kurulumu

İlk 72 saatin tek hedefi vardır: gerçek kullanıcı verisi (RUM) akmaya başlasın ve eşik aşıldığında doğru kişi haber alsın. Lansman gününden önce hiçbir şey ölçmediyseniz, lansman sonrası “kötüleşti mi” sorusunu cevaplayamazsınız. Bu yüzden gün sıfırı baseline günü kabul ediyoruz.

RUM kaynağını seç ve kur. İki ana yol var. İlki, Plausible web-vitals plugin’i — script.manual.outbound-links.tagged-events.web-vitals.js script’i pageview’ların yanında LCP, INP ve CLS’yi de gönderiyor; çerezsiz, KVKK uyumlu, dashboard’da p75 görünür. İkincisi, Google’ın resmi web-vitals npm paketi (onLCP, onINP, onCLS callback’leri) ile metrikleri kendi telemetri uç noktanıza yazmak. Çoğu projede Plausible ile başlıyoruz; PUBLIC_PLAUSIBLE_DOMAIN env var’ı set olduğu anda ölçüm devrede.

Eşikleri yaz. Google’ın “Good” sınırlarını sabit kabul ediyoruz: p75 LCP <2,5 sn, p75 INP <200 ms, p75 CLS <0,1. Lighthouse CI yapılandırmamızda da aynı sayılar var (largest-contentful-paint 2500, cumulative-layout-shift 0.1, total-blocking-time 200) — lab ile alan arasındaki tutarlılık burada başlıyor.

Alarm hattını kur. Plausible Stats API ya da PostHog event’lerinden günde bir kez p75 hesaplayan bir script çalıştırıyoruz; eşik aşılırsa Slack #perf-alerts kanalına ve nöbetçi mühendisin e-postasına bildirim. İlk hafta yanlış pozitiflerle dolu — örnek hacmi düşükken p75 oynar. 200’den az sample’da alarm bastırıyoruz; tek günlük dalgalanma yerine üç gün üst üste eşik aşımı ararız.

Search Console bağlantısı. Lansman sonrası 48 saat içinde site verify ve sitemap submit. Search Console’un “Core Web Vitals” raporu CrUX (Chrome User Experience Report) verisinden besleniyor; ilk anlamlı veri 21–28 gün sonra geliyor. Bu yüzden Search Console’u erken takip etmiyoruz; ay sonu raporunda kullanacağız.

3. günün sonunda elinizde şunlar olmalı: Plausible’da CWV kartı görünüyor, alarm yapılandırması test ediliyor, Lighthouse CI günlük cron olarak .lighthouserc.json üzerinden çalışıyor, Search Console doğrulanmış.

4–14. gün: örüntü tespiti

İkinci aşama on bir günlük gözlem dönemi. Her sabah 15 dakika ayırın: Plausible CWV kartı + PostHog session replay (sample %10) + Lighthouse CI son 24 saat çıktısı. Hedef hızlı düzeltme yapmak değil; örüntü görmek.

Segmentlere bölün. p75 toplam sayı yanıltıcıdır. Aynı sayıyı dört eksende ayrıştırın: route bazında (anasayfa, hizmet sayfaları, blog, iletişim), cihaz bazında (mobile/desktop), ülke bazında (TR, EU, US), bağlantı türü bazında (4G/3G/wifi). Çoğu zaman regresyon tek bir kesişimde: “mobile + 4G + blog detay” hızlandırma listesinin ilk maddesi olur, oysa toplam p75 normal görünür.

Yaygın erken-aşama problemleri. İlk 30 gün analizlerinde sürekli karşılaştığımız beş örüntü var:

• Üçüncü taraf script regresyonu. Pazarlama ekibi GTM üzerinden bir piksel ekliyor, INP 60 ms’den 240 ms’ye çıkıyor. Yeni script’leri Plausible “outbound link” tag’iyle ya da PostHog’ta event olarak işaretleyip kuruluş tarihiyle eşleştirin.
• Görsel format uyumsuzluğu. Hero görselleri AVIF/WebP olarak ship ettik ama CMS’ten yeni eklenen blog görselleri PNG geliyor. LCP element CMS resmi olduğunda 2,5 sn’i aşıyor. Astro <Image /> zorunluluğu kuralı tam burada işe yarıyor.
• Hidrasyon zirvesi. React island’ları (özellikle ağır form bileşenleri) hydrate olurken main thread bloke oluyor; INP fırlıyor. Bunu PostHog session replay’de “input lag” olarak yakalıyoruz.
• Font swap CLS. Self-hosted Inter ve Inter Tight font-display: swap ile yüklendiğinde, fallback fontla custom font arasındaki x-height farkı CLS 0,12’ye çıkarıyor. size-adjust ile düzeltilmediği sürece her sayfada görünüyor.
• Lazy-load atlamaları. Above-the-fold görseline loading="lazy" koymak LCP’yi 800 ms geciktiriyor. Standart hata; her sprint’te bir yerde ortaya çıkıyor.

Günlük not tutun. Markdown bir log dosyası — tarih, gözlem, hipotez, henüz değişiklik yapılmadı. Bu log 15. günde başlayacak düzeltme dalgasının önceliklendirme kaynağı olacak. Dağınık Slack mesajları yerine tek dosya: hangi sayfa, hangi metrik, hangi cihaz, hangi tarih.

INP konusunda özel uyarı. INP, FID’in halefi olarak Mart 2024’te resmî CWV’ye girdi; lab Lighthouse’da TBT (Total Blocking Time) ile yaklaşılıyor ama bire bir aynı şey değil. Field INP, kullanıcının sayfayla etkileşim süresince hissettiği p98 gecikmenin proxy’si — ilk on saniyeden sonra DOM ısındığında çıkan değer farklı. Bu yüzden ilk 14 gün lab’a değil, RUM’a güveniyoruz.

Türkçe ve uluslararası kullanıcı ayrımı. Çoğu engagement’ta TR kullanıcılar yerel CDN noktasından beslenirken EU/US kullanıcılar uzak edge’den geliyor. Aynı route üzerinde p75 LCP, TR’de 1,9 sn, EU’da 3,2 sn olabiliyor. Bu fark CDN cache hit oranı ve görsel boyutlarıyla ilgili — Cloudflare Web Analytics’in coğrafi kırılımı bu farkı 30 saniyede gösteriyor. Tek bir global p75 ile sınırlı kalmayın.

15–21. gün: hedefli düzeltmeler

Üçüncü aşamada iki hafta toplanmış veriyle düzeltme dalgasına geçiyoruz. Düzeltme önceliği iki eksenden geliyor: kullanıcı etkisi (etkilenen oturum yüzdesi) × sıklık (günlük tetiklenme).

Önce kolay kazanımlar. Tek sprint içinde kapanan, ölçülebilir etki yaratan, regresyon riski düşük düzeltmeler:

• Above-the-fold görsellerden loading="lazy" çıkar, bunun yerine fetchpriority="high". Kritik fontları <link rel="preload"> ile preload et. Critical CSS’i inline çıkar. Bu üçü tipik olarak LCP’yi 400–700 ms iyileştiriyor.
• Üçüncü taraf script’leri defer ya da <script async> ile geciktirin; gerekmeyenleri (eski analytics, kullanılmayan A/B test SDK’leri) tamamen kaldırın.

Sonra orta zorlukta düzeltmeler. Bir sprint’i aşan, mimari etki yaratan değişiklikler:

• Hidrasyon partial’ları: Astro’da client:visible ya da client:idle direktifi kullanarak ağır island’ları viewport’a girene kadar hydrate etmeyin. INP düşüşü 80–150 ms aralığında oluyor.
• CMS görsel pipeline’ı: yeni eklenen her görsel için otomatik AVIF/WebP fallback üretimi. CDN tarafında Cloudflare Image Resizing ya da kendi build adımı.
• Font metric override (size-adjust, ascent-override): font swap CLS’ini 0,12’den 0,02’ye indiriyor; tek seferlik iş.

Hepsini bir kerede yapma. En pahalı hata, beş düzeltmeyi aynı PR’da göndermek. Bir tanesi regresyon getirirse hangisi olduğunu bulmak günler alır. Her düzeltmeyi ayrı PR, ayrı deploy, en az 24 saat ara. Belirsizlik varsa A/B test: Cloudflare Workers ile %10 trafiği yeni versiyona, Plausible’da varyant property’si ile p75 farkını izleyin.

Düzeltme log’una yazın. Hangi PR, hangi metrik öncesi-sonrası, hangi sayfa. Bu kayıt 22–30. gün raporunun omurgasını oluşturuyor.

22–30. gün: stabilizasyon ve raporlama

Son aşamada düzeltme dalgalarının kalıcı olduğunu doğruluyoruz ve süreci ürün ekibine devrediyoruz.

İki hafta gözlem. 15–21. günde ship edilen düzeltmelerin RUM’da göründüğünden emin olun. Plausible CWV kartında p75 LCP/INP/CLS ile öncesi-sonrası karşılaştırma; en az yedi gün üst üste eşiklerin altında kalması bekleniyor. Tek günlük iyi rakam yanıltıcı; trend lazım.

Search Console kontrol. 22. günden itibaren CrUX verisi anlamlı oluyor. “Core Web Vitals” raporunda yeşil URL sayısı artmış, kırmızı düşmüş olmalı. Hâlâ kırmızı kalan URL’ler genelde çok düşük trafikli sayfalar — ürün ekibiyle “bu sayfa kapanacak mı, optimize edilecek mi” kararı veriyoruz.

Haftalık yönetim raporu. Beş bölümden oluşan tek sayfa: 1) p75 LCP/INP/CLS trend grafiği (son 4 hafta), 2) route hotlist (en kötü 5 sayfa, p75 değerleri ve etkilenen oturum sayısı), 3) düzeltme log’u (bu hafta ship edilen PR’lar, ölçülen etki), 4) bekleyen riskler (üçüncü taraf script ekleme talepleri, planlanan büyük ürün değişiklikleri), 5) önümüzdeki hafta planı. CTO ya da ürün direktörü 5 dakikada okuyabilmeli.

Devir teslim. 30. günde rapor ürün ekibine geçiyor: alarm kanalı sahibi atanıyor, haftalık 30 dakikalık “perf review” toplantısı takvime giriyor, Lighthouse CI PR pipeline’da blocker olarak kalıyor (her PR LCP <2,5 sn, CLS <0,1 testini geçmeden merge edilemiyor). Bizim aktif izleme rolümüz 30. günden sonra reactive consultancy’ye dönüyor — eşik aşılırsa çağırılıyoruz.

beynart’ta kullandığımız araçlar

• Plausible web-vitals plugin — birincil RUM kaynağı; çerezsiz, KVKK uyumlu, p75 dashboard kutudan çıkıyor. Self-hosted ya da SaaS, her iki seçenek de bizim setup’ımızda destekli.
• PostHog session replay — sample %10, INP zirvelerinin sebebini görmek için. “Input lag” event’i ile filtre.
• Cloudflare Web Analytics — yedek RUM kaynağı; Plausible kapanırsa boşluk kalmasın diye paralel akıyor.
• Lighthouse CI — PR pipeline’da blocker; .lighthouserc.json üzerinden 18 URL koşturuyor (TR + EN, kritik sayfalar). LCP/CLS/TBT eşik aşılırsa PR fail.
• web-vitals npm paketi — Plausible plugin’in karşılamadığı özel metrikler (Time to First Byte detay, custom event timing) için kendi telemetri yazıyoruz.

Bu araç setini her engagement’a göre ayarlıyoruz; tam yapılandırmayı martech ve AI operasyonu angajmanlarımızın bir parçası olarak kuruyoruz.

Kapanış

30 günlük plan amacına ulaştığında elinizde üç şey kalıyor: alarm bağlanmış sürdürülebilir bir RUM hattı, beş kritik düzeltme uygulanmış stabil bir CWV profili ve ürün ekibinin sahip olduğu haftalık raporlama disiplini. Kötü senaryoyu — üç hafta sonra Search Console kırmızıya dönerken kimsenin haberinin olmaması — bir daha yaşamamak için yeterli.

Bu disiplini stack kararlarınızın bir parçası haline getirmek istiyorsanız martech yığını mimarisi yazımız önceki adımı anlatıyor; performans hattını kurumsal sistemlerinizle bütünleştirmek için kurumsal sistemler sayfamıza bakın. Lansman öncesi ya da sonrası bir performans audit’i istiyorsanız bize ulaşın — [email protected].