Performans Sorunlarını Tanılama
Performans Sorununu Düzeltirken Önce Neye Bakılmalı?
Bir sayfanın yavaş yüklendiğini fark ettiğinizde ilk tepki genellikle bir şeyleri sıkıştırmak, görselleri küçültmek veya bir plugin kurmaktır. Bu adımlar bazen işe yarar; ama çoğunlukla asıl sorunun yanından geçer. Performans sorunlarının büyük kısmı, görünen semptomun işaret ettiği yerden değil, görünmez bir katmandan kaynaklanır.
Yüksek LCP değeri bir görselin büyük olduğunu söylemez. Görselin geç yüklendiğini söyler; ancak bu gecikmenin kaynağı görsel boyutu olabileceği gibi render-blocking bir CSS dosyası, yüksek TTFB veya keşfedilemeyen bir kaynak da olabilir. Bu ayrımı yapmadan başlanan optimizasyon, efor harcasa da metriği neredeyse hiç hareket ettirmez.
Doğru tanılama, neyi düzelteceğinizi değil, neden düzeltmeniz gerektiğini söyler. Bu yazıda performans sorununa yaklaşımın sırasını ve her adımda hangi soruyu sormak gerektiğini ele alıyoruz.
Semptom ile neden arasındaki kritik ayrım
Lighthouse raporu veya PageSpeed Insights, semptomları gösterir. "LCP 4,2 saniye" bir semptomdur. "Render-blocking kaynak LCP'yi geciktiriyor" neden için bir ipucudur; ama henüz neden değildir. Neden, hangi kaynağın neden o noktada olduğunu, neden önceden yüklenemediğini ve hangi değişikliğin bunu çözeceğini bilmektir.
Bu ayrım pratik bir sonuç doğurur: araç önerisini doğrudan uygulamak, nedeni anlamak yerine semptomu örtbas etme riskini taşır. "Görseli sıkıştır" önerisi LCP görsel boyutundan kaynaklanıyorsa işe yarar; kaynak TTFB'den kaynaklanıyorsa hiçbir şey değişmez. Önce neyin neden olduğunu anlamak, her müdahaleyi olması gereken yere konumlandırır.
TTFB mi, render sorunu mu: ilk ayrım noktası
Performans tanılamasının ilk dallanma noktası basittir: sorun sunucudan mı geliyor, tarayıcı katmanından mı? TTFB yüksekse — yani sunucu yanıtı uzun sürüyorsa — tarayıcı henüz HTML'yi almadan önce zaman geçer. Bu durumda görselleri küçültmek, CSS'i minify etmek veya lazy loading eklemek etkisiz kalır; sunucu katmanı çözülmeden tarayıcı katmanı iyileştirilemez.
TTFB kabul edilebilir bir değerdeyken — genellikle 800 ms'nin altı, tercihen 200 ms civarı — sayfa yine de yavaşsa sorun tarayıcı katmanındadır: kaynak yükleme sırası, render-blocking içerik, JavaScript yürütme süresi veya görsel önceliği. Bu iki katmanı ayırt etmek, tanılama süresini yarıya indirir.
Waterfall'u doğru okumak
Network Waterfall, performans tanılamasının en değerli aracıdır. Her kaynağın ne zaman istendiğini, ne kadar sürede geldiğini ve diğer kaynaklarla nasıl ilişkilendiğini gösterir. Doğru okunduğunda sorunun nerede olduğunu çoğunlukla açıkça işaret eder.
Waterfall'da dikkat edilmesi gereken birkaç örüntü vardır. Uzun bir boş alan — yani istek başlamadan önce geçen bekleme süresi — çoğunlukla render-blocking bir kaynağın önce tamamlanmasını beklediğini gösterir. Zincirleme istekler, bir kaynağın yüklenmesinin başka kaynakları tetiklediği ve gecikmenin katlandığı durumları işaret eder. LCP öğesinin waterfall'da nerede başladığını bulmak, hangi kaynakların onu geciktirdiğini görünür kılar.
Chrome DevTools'da Network sekmesi bu waterfall'u sunar. "Initiator" sütunu hangi kaynağın hangi isteği başlattığını gösterir; bu zinciri geriye doğru izlemek, beklenmedik gecikmelerin kaynağına ulaştırır.
LCP öğesini ve gecikmesinin kaynağını tespit etmek
LCP gecikmesinin dört farklı kaynağı olabilir: kaynak keşif gecikmesi, kaynak yükleme gecikmesi, render-blocking süresi ve kaynak boyutu. Her birinin çözümü farklıdır; dolayısıyla hangisinin ağırlıklı katkı yaptığını bilmeden başlanan optimizasyon rastgele bir deney olur.
Kaynak keşif gecikmesi, tarayıcının LCP öğesini — görsel veya font — HTML işlenene kadar fark edememesinden kaynaklanır. Çözüm, bu kaynağı <link rel="preload"> ile öne çekmek veya fetchpriority="high" ile önceliklendirmektir. Render-blocking gecikme ise LCP başlamadan önce CSS veya JS dosyalarının tamamlanmasını beklemekten gelir; kritik olmayan kaynakları ertelemek önceliklidir. Kaynak boyutu büyükse sıkıştırma, format değişimi ve responsive boyutlandırma devreye girer.
INP sorununu tanılamak: etkileşim zincirini izlemek
INP yüksekse sorunun kaynağı üç yerden biri olabilir: input delay (etkileşim algılanmadan önce geçen süre), processing time (etkileşimi işleyen JavaScript kodu) veya presentation delay (tarayıcının ekranı güncellemesi). Bu üçünü birbirinden ayırt etmek, çözümü doğrudan belirler.
Chrome DevTools'da bir buton tıklaması ya da form girişi sırasında Performance paneli kaydı başlatmak, etkileşim zincirini milisaniye düzeyinde gösterir. Input delay yüksekse ana iş parçacığını meşgul eden başka bir görev var demektir; long task analizi bu görevi bulur. Processing time yüksekse etkileşim handler'ının kodu optimize edilmeli ya da ağır işler Web Worker'a taşınmalıdır.
Render-blocking kaynakları izole etmek
Render-blocking kaynaklar, tarayıcının sayfayı boyamaya başlamasını geciktirir. Lighthouse raporu bunları açıkça listeler; ancak listedeki her kaynak eşit öneme sahip değildir. Bazıları yüzlerce milisaniye, bazıları yalnızca birkaç milisaniye bloke eder.
Önceliği belirlemek için her kaynağın katkıladığı gecikmeyi ayrı ayrı değerlendirmek gerekir. Kritik CSS'i satır içi olarak eklemek ve kritik olmayan CSS'i ertelemek, render-blocking etkisini azaltmanın en doğrudan yoludur. JavaScript için defer ve async kullanmak, HTML parse'ını durdurmadan script yüklenmesini sağlar. Ancak bu değişiklikleri rastgele uygulamak sipariş bozukluğuna yol açabilir; değişiklik öncesi test vazgeçilmezdir.
JavaScript yürütme süresini ve ana iş parçacığı yükünü ölçmek
Sayfa görsel olarak hızlı yükleniyor ama etkileşime geç açılıyorsa sorun JavaScript yürütme süresindedir. Büyük veya uzun süre çalışan scriptler ana iş parçacığını bloke eder; bu süre boyunca kullanıcı etkileşimleri sıraya girer.
Chrome DevTools'da Performance panelinin "Bottom-Up" veya "Call Tree" görünümü, en fazla CPU süresi tüketen fonksiyonları listeler. Bu liste, hangi kütüphanenin veya uygulama kodunun yük oluşturduğunu gösterir. Üçüncü taraf scriptlerin bu listedeki payını görmek — reklam kütüphanesi, chat widget, analytics — hangi kaynağın ana iş parçacığına ne kadar baskı uyguladığını netleştirir.
Hangi araç hangi soruyu yanıtlar?
Tanılama araçları birbirini tamamlar; ama her biri farklı sorulara cevap verir. Lighthouse, semptomları ve önerileri gösterir; hangi alanlarda sorun olduğunu hızlıca özetler. Network Waterfall, kaynak yükleme sırasını ve zamanlamasını gösterir; gecikmenin nerede başladığını işaret eder. Performance paneli, CPU kullanımını ve ana iş parçacığı aktivitesini gösterir; JavaScript maliyetini izole eder. Coverage paneli, kullanılmayan JavaScript ve CSS yüzdesini gösterir; gereksiz yük tespiti için kullanılır.
Bu araçların doğru sırayla kullanılması önemlidir. Lighthouse ile başlamak, hangi metriğin sorunlu olduğunu belirler. Ardından o metriğe göre hangi araçla devam edeceğiniz şekillenir: LCP sorunu için Network ve Waterfall, INP sorunu için Performance paneli, kaynak boyutu sorunu için Coverage ve bundle analizi.
Hatalı önceliklendirmenin tipik görüntüleri
Tanılama yapılmadan başlanan optimizasyonun birkaç tipik örüntüsü vardır. Görseller sıkıştırılır, ama asıl sorun render-blocking CSS'tir; LCP değişmez. JavaScript minify edilir, ama asıl sorun üçüncü taraf script'in yükleme zamanıdır; değişiklik etkisizdir. Lazy loading her görsele eklenir, ama hero görseli de lazy olur; LCP değeri düşmek yerine artar.
Bu hataların ortak paydası, semptomdan doğrudan çözüme atlamaktır. Her seferinde araya bir tanılama adımı koymak — bu semptomun hangi katmandan geldiğini doğrulamak — bu örüntüleri kırar. Ölçüm, önce ne yapılacağını değil, neden yapılacağını söylemelidir.
Tanılama sırasını pratikte oluşturmak
Pratik bir tanılama sırası şu adımlarla kurulabilir: önce hangi metriğin sorunlu olduğunu belirle (Lighthouse veya Search Console); ardından o metriğin hangi aşamasının ağır olduğunu izole et (TTFB mu, kaynak yükleme mi, render mi); sonra o aşamayı açıklayan kaynağı veya kodu bul (Waterfall, Coverage, Performance paneli); son olarak tek bir değişiklik yap ve ölçüm al.
Son adım — tek değişiklik — kritik öneme sahiptir. Aynı anda birden fazla değişiklik uygulandığında hangisinin etkili olduğu bilinemez. Bu belirsizlik, ilerleyen aylarda aynı türden soruna tekrar yaklaşıldığında neyi tekrarlayacağınızı bilinmez kılar. Her değişikliği izole etmek, bilginin birikmesini sağlar.
Alan verisi ve lab verisi tanılamada birlikte nasıl kullanılır?
Lab verisi (Lighthouse, PageSpeed Insights) kontrollü bir ortamda tutarlı ölçüm sağlar. Alan verisi (CrUX, Search Console) gerçek kullanıcıların karşılaştığı koşulları yansıtır. Tanılama bu iki kaynağı birlikte kullanmayı gerektirir çünkü bazen lab verisi sorunu gösterirken alan verisi göstermez — ya da tersi olur.
Gerçek kullanıcıların yaşadığı ama lab'de görülmeyen sorunlar çoğunlukla düşük güçlü cihazlar, yavaş ağlar veya coğrafi farklılıklardan kaynaklanır. Bu durumda lab ve alan verisinin neden farklı çıktığını anlamak, tanılamayı doğru yöne taşır. Lab'de iyi görünen ama Search Console'da kötü olan bir sayfa, gerçek kullanıcı koşullarını simüle eden bir test gerektiriyor demektir.
Performans sorununa el atmadan önce harcanan tanılama süresi, optimizasyon sırasında harcanan eforu azaltır. Nedenini bilmeden yapılan her değişiklik bir tahmindir; nedeni bilerek yapılan her değişiklik bir karardan ibarettir. İkisi arasındaki fark, hem sonuç kalitesini hem de tekrarlanabilirliğini belirler.
Tanılama alışkanlığı zamanla hızlanır. Her sorunun aynı sorularla başlaması — TTFB mı, render mı, JS mi? — giderek daha az çaba gerektiren bir refleks haline gelir. Bu refleks, performans çalışmasını rastgele bir deneme sürecinden çıkarıp sistematik bir mühendislik pratiğine dönüştüren şeydir.