Performans Regresyonunu Önlemek İçin Kalıcı Süreç Nasıl Kurulur?

Haftalık ölçüm rutini: neyi, ne zaman, nasıl takip edersiniz

Ölçüm olmadan regresyon görünmez. Çoğu ekip bir sorun ortaya çıktığında ölçmeye başlar; oysa bir sorunun ortaya çıkmadığını anlamak için de düzenli ölçüm gerekir. Haftalık bir kontrol listesi bu boşluğu kapatır.

Takip edilmesi gereken temel metrikler şunlardır: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint), TTFB (Time to First Byte) ve FCP (First Contentful Paint). Bu beş metrik, kullanıcı deneyiminin teknik izdüşümüdür. LCP için 2,5 saniyenin altı, CLS için 0,1'in altı, INP için 200 milisaniyenin altı hedef eşikler olarak kabul edilir.

Haftalık rutini ikiye ayırabilirsiniz. İlki, gerçek kullanıcı verisine dayanan alan ölçümü (field data); ikincisi, lab ortamında tekrarlanabilir sentetik ölçüm. Alanı Google Search Console'un Core Web Vitals raporundan ya da CrUX (Chrome User Experience Report) verisinden alabilirsiniz. Sentetik ölçümü ise Lighthouse CLI ile her hafta aynı sayfalar üzerinde, aynı bağlantı koşullarını simüle ederek çalıştırabilirsiniz.

Hangi sayfaları ölçmeli? Tüm siteyi haftalık taramak küçük bir ekip için sürdürülemez. Bunun yerine kritik yol sayfaları belirleyin: ana sayfa, en yüksek trafik alan iki veya üç içerik sayfası, alışveriş varsa ödeme ve ürün listesi. Bu sayfalar düzenli olarak izlenirse sinyaller erken gelir. Uzun kuyruk sayfalar için aylık ya da çeyreklik döngü yeterlidir.

Ölçüm sonuçlarını tabloya alın. Tarih, sayfa, metrik, değer - dört sütun yeter. Haftalık delta, yani geçen haftaya göre fark, artı veya eksi olarak not edilsin. Değer tek başına pek bir şey söylemez; değişim söyler. 2,1 saniye LCP iyi görünebilir, ama bir önceki haftadan 0,4 saniye kötüleşmişse bu bir sinyal.

Deploy pipeline'a performans kapısı eklemek

Regresyonların büyük bir kısmı deploy sırasında girer. Yeni bir JS bundle'ı büyür, bir görselin optimize edilmemiş sürümü production'a geçer, bir üçüncü taraf script eklenir ve kimse fark etmez. Pipeline'a otomatik kontroller eklemek bu geçişleri yakalar.

Lighthouse CI, her deploy tetiklendiğinde belirlenmiş eşiklere karşı sayfa puanlarını karşılaştırır. Eşik aşılırsa merge veya deploy bloklanır. Temel yapılandırma şöyle kurulabilir:

// lighthouserc.js
module.exports = {
  ci: {
    collect: {
      url: ['https://staging.example.com/', 'https://staging.example.com/urunler/'],
      numberOfRuns: 3
    },
    assert: {
      assertions: {
        'categories:performance': ['error', { minScore: 0.85 }],
        'first-contentful-paint': ['error', { maxNumericValue: 2000 }],
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
        'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }]
      }
    },
    upload: {
      target: 'temporary-public-storage'
    }
  }
}

numberOfRuns: 3 önemli; tek çalıştırmada ağ varyansı sonucu bozar. Üç çalıştırmanın ortalaması daha kararlı bir sinyal verir. Staging ortamı production ortamıyla aynı kaynak profilini taşımalıdır, aksi halde eşikler gerçekçi olmayan koşullarda belirlenir.

Bundle boyutu kontrolü ayrı bir katman. Webpack veya Rollup kullanan projelerde bundlesize ya da benzer bir araç, her paketin boyutunu bir bütçeyle karşılaştırır. Örneğin ana JS bundle'ı 150 KB'yi geçerse CI hata döndürür. Bu sınır ekibinizin sayfasına ve mevcut baseline'ına göre ayarlanmalıdır; her site için geçerli tek bir sayı yoktur.

Üçüncü taraf script değişikliklerini de pipeline'a ekleyebilirsiniz. Üretim manifest dosyasını iki deploy arasında karşılaştıran basit bir script, yeni eklenen external domain'leri raporlar. Bir pazarlama etiketi sessizce eklendiyse bu rapor onu yakalar.

Eklenti ve bağımlılık güncelleme protokolü

Bağımlılık güncellemeleri hem zorunlu hem tehlikeli. Güvenlik yamaları uygulanmadan bırakılamaz; ama kör güncelleme regresyon kapısını açar. İkisi arasındaki denge bir protokolle kurulur.

Güncellemeleri üçe ayırın. Güvenlik yamaları (patch seviyesi, yani x.y.z'de son rakam) mümkün olan en kısa sürede uygulanır ve sonrasında sadece TTFB ve LCP ölçülür. Minor güncellemeler (x.y.z'de orta rakam) haftalık döngüye girer; staging ortamında tam Lighthouse çalıştırmasından geçer, ardından production'a alınır. Major güncellemeler (x.y.z'de baş rakam) kendi sürümüne alınır, tam regresyon testiyle doğrulanır ve tercihen tek başına deploy edilir - başka değişikliklerle birleştirilmez.

WordPress veya benzeri CMS kullanan sitelerde eklenti güncellemeleri benzer bir yapıda ele alınabilir. Her güncellemenin ardından, etkilendiği tahmin edilen sayfalarda LCP ve CLS kontrol edilir. Bir sayfa düzenleyicisi eklentisi güncellemesi neredeyse her zaman görselleri, blok yapılarını ya da CSS yükleme sırasını etkiler.

Bağımlılık dondurma (dependency pinning) bazı durumlarda doğru seçimdir, bazılarında değil. Kritik üretim altyapısında sürümleri sabitlemek riski azaltır, ama güvenlik açıklarını geç kapatır. Aktif geliştirme yapılan bir projede floating sürümler küçük regresyonları otomatik testlere gizler. Her iki yaklaşımın da maliyeti vardır; hangisini seçerseniz seçin, neden seçtiğinizi dokümante edin.

Yavaş. Bağımlılık değişikliğinden kaynaklanan bir regresyonu hızlıca bulmak için en iyi yöntem şudur: her güncelleme ayrı bir commit'te. Tek commit, tek değişken. Böylece git bisect ile veya manuel olarak hangisinin sorunu getirdiği hızla bulunur.

Performans bütçesi tanımlamak ve korumak

Performans bütçesi (performance budget), belirli metrikler için konulan üst sınırlardır. "LCP 2,5 saniyenin altında kalacak", "ana JS bundle'ı 200 KB'yi geçmeyecek", "toplam üçüncü taraf istek sayısı 10'u aşmayacak" gibi somut taahhütler. Bu sınırların değeri, herkesin aynı ölçeği kullanmasından gelir.

Bütçeyi belirlerken mevcut baseline'dan başlanır. Sitenizin şu anki performansını ölçün, ardından hedeflerinizi ve mevcut değerlerinizi göz önünde bulundurarak sınırlar koyun. Hedef, "en iyi durumu sürdür" değil, "regresyonu erkenden fark et" olmalıdır. Bu nedenle bütçe değerlerini mevcut iyinin biraz üstünde değil, kritik eşiğin biraz altında tutmak daha iyi sinyal üretir.

Farklı sayfa türleri farklı bütçe gerektirir. Blog yazısı ile e-ticaret ürün sayfası aynı JS bütçesini taşıyamaz. Her sayfa kategorisi için ayrı bütçe tanımlayın ve bu bütçeleri versiyon kontrol sisteminde tutun. performance-budget.json ya da benzeri bir dosya, hem CI entegrasyonuna kaynak olur hem de ekibin referans belgesi olarak kalır.

Bütçe ihlali her zaman engelleme değil. Bazen bir ihlal kasıtlıdır: yeni bir özellik için JS eklendi, bütçe güncellenmeli. Burada önemli olan ihlali görünür kılmak ve bilinçli bir karar vermektir. Sessizce geçen bir ihlal ile gözden geçirilmiş bir istisna arasındaki fark, zaman içinde birikimli etkide ortaya çıkar.

Ekip içi sorumluluk dağılımı ve gözden geçirme döngüsü

Herkesin sorumlu olduğu şey kimsenin sorumluluğunda değildir. Performans regresyon takibi, "geliştirici bakar" ya da "ekip bilir" şeklinde belirsiz bırakılırsa düzenli gözden geçirme yapılmaz. Net atamalar bu belirsizliği giderir.

Küçük bir ekip için bile üç rol tanımlamak yeterlidir. Birinci rol: haftalık ölçümü çalıştıran ve sonuçları kaydeden kişi. Bu kişi yorumlamaz, sadece ölçer ve tabloya girer. İkinci rol: sonuçları inceleyen ve regresyon olup olmadığına karar veren kişi. Üçüncü rol: regresyon bulunduğunda kök neden analizini yürüten ve düzeltmeyi takip eden kişi. Küçük ekiplerde aynı kişi birden fazla rolü üstlenebilir, ama rollerin ayrı tanımlanmış olması süreci net tutar.

Aylık performans gözden geçirmesi, haftalık rutinin tamamlayıcısıdır. Haftalık rutinde veri toplanır; aylık toplantıda eğilimler okunur. Hangi metrik son dört haftada sürekli yükseldi? Hangi sayfa tutarlı biçimde bütçe sınırına yaklaşıyor? Aylık gözden geçirme bu soruları yanıtlar ve önümüzdeki ayın önceliklerini belirler.

Deploy gözden geçirmesi de bu döngüye dahildir. Her büyük deploy öncesinde performansa etkisi olabilecek değişiklikler sorgulanır: yeni script eklendi mi, görsel değişikliği var mı, CSS yükleme sırası bozulabilir mi? Bu soruların deploy checklist'ine eklenmesi, pipeline kontrolünün yakalayamadığı insan kaynaklı kararları da sürece dahil eder.

Sorumluluk dağılımı belgelenmeli. CLAUDE.md, README, ya da ekibin kullandığı herhangi bir dahili belge sistemi - nerede tutulduğu ikincil. Önemli olan, yeni katılan bir ekip üyesinin bağımsız olarak anlayabileceği bir yazılı kaynağın var olmasıdır.

Regresyon tespit etmek ve kök nedene inmek

Ölçüm bir regresyon sinyali verdiğinde sıradaki adım kök neden bulmaktır. Hızlı yanlış tanı, yanlış yerde harcanan çabayla sonuçlanır.

İlk soru: değişiklik ne zaman başladı? Haftalık ölçüm tablosuna bakın; değer hangi haftadan itibaren kötüleşti? O hafta yapılan deployları listeleyin. Birden fazla deploy varsa her biri ayrı ayrı staging ortamında test edilir. Sorunu getiren deploy'u bulduktan sonra, o deploy'daki commit'lere bakılır. Mümkünse git bisect süreci hızlandırır.

LCP regresyonunda genellikle üç kaynak vardır: büyüyen resim boyutu, render-blocking kaynak eklenmesi veya yeni bir sunucu gecikmesi. CLS regresyonunda en sık neden geç yüklenen reklamlar, değişen font yükleme davranışı ya da yeni eklenen dinamik içeriktir. INP regresyonunda ana iş parçacığını (main thread) kilitleyen yeni JS yükü araştırılır. Bu sınıflandırma araştırmayı daraltır; her metrik için başlangıç hipotezleri değişir.

Tarayıcı geliştirici araçlarındaki Performance sekmesi ve Network sekmesi çoğu durumda yeterlidir. Hangi kaynak ne zaman yüklendi, hangi script ana iş parçacığında ne kadar süre çalıştı, LCP elementi ne zaman render edildi - bunlar görsel olarak okunabilir. Kök neden bulunduğunda hem düzeltme hem de neden olduğuna dair kısa not commit mesajına ya da gözden geçirme belgesine eklenir. Bu not bir sonraki benzer durumda araştırma süresini kısaltır.

Sürekliliği sağlamak için otomasyon sınırları

Otomasyon çok şeyi kolaylaştırır; ama her şeyi çözmez. Pipeline kontrolleri, otomatik Lighthouse çalıştırmaları ve bundle boyutu uyarıları insan gözünün fark edemeyeceği hızlı değişimleri yakalar. Alan verisini yorumlamak, uzun vadeli eğilimleri okumak ve kök neden analizi yapmak ise hâlâ insan kararı gerektirir.

Aşırı otomasyon kendi sorunlarını yaratır. Her küçük değişiklikte patlayan CI uyarıları, ekibin zamanla bu uyarıları görmezden gelmesine yol açar. Eşikler çok katı ayarlanırsa yanlış pozitifler artar; çok gevşek ayarlanırsa gerçek regresyonlar geçer. Eşiğin nereye konulacağı ekibin risk toleransına ve sayfanın mevcut baseline'ına göre ayarlanmalıdır; değer bir kez belirlendikten sonra zaman içinde gözden geçirilmeli, sabit bırakılmamalıdır.

Üçüncü taraf scriptler otomasyonun en kör noktasıdır. Pipeline kontrolü sitenizin kodunu değerlendirir; ama bir reklam ağının veya analitik aracının üçüncü taraf yükünü kontrol edemez. Üçüncü taraf script değişikliklerini izlemek için düzenli alan verisi incelemesi zorunludur. Bir ay içinde TTFB sabit kalırken TBT (Total Blocking Time) yükseldiyse bu neredeyse her zaman üçüncü taraf kaynaklıdır.

Otomasyon ve insan gözü birbirini tamamlar. Günlük ve haftalık ölçümleri makinenin yapmasına izin verin; aylık yorumu, önceliklendirmeyi ve kök neden kararını insana bırakın. İkisinin sınırını netleştirmek, sürecin zaman içinde çökmesini önler.