Chrome DevTools Performance panelinde flame chart okuma, long task tespiti, LCP ve INP olaylarını izleme ile main thread bloğunun kaynağını bulma: adım adım profil analizi rehberi.

Chrome DevTools Performance Panel Nasıl Kullanılır?

Chrome DevTools'un Performance paneli, tarayıcının bir sayfayı işlerken tam olarak ne yaptığını milisaniye düzeyinde gösterir. JavaScript yürütme süresi, layout hesaplamaları, boyama işlemleri ve ağ gecikmesi, hepsi tek bir zaman çizelgesinde üst üste katmanlanır. Üçüncü taraf bir script'in sayfayı neden yavaşlattığını ya da scroll sırasında neden takılma yaşandığını anlamak istiyorsanız bu panel, tahmin yerine somut veri koyar.

Pek çok geliştirici paneli açar, kayıt yapar, renkli bir bloklar yığınıyla karşılaşır ve kapatır. Flame chart okumak öğrenilmesi gereken bir beceri; bir kez öğrendikten sonra aynı veriyi farklı görürsünüz. Main thread bloğu, uzun görevler, LCP zamanlaması, INP gecikmesi... bunların hepsinin izini sürmek mümkün, yeter ki hangi katmanın neyi temsil ettiğini bilin.

Performance kaydını doğru başlatmak

DevTools'u açın ve üst sekmelerden "Performance"a geçin. İki kayıt yöntemi var: el ile kayıt, yani siz başlatıp durduruyorsunuz, ve sayfa yükleme kaydı. LCP, FCP veya TTFB gibi yükleme metriklerini inceleyecekseniz ikinci yöntemi tercih edin: araç çubuğundaki kayıt düğmesinin yanındaki yenile simgesine tıklayarak "Start profiling and reload page" seçeneğini kullanın. Panel sayfayı sıfırdan yükler ve kaydı otomatik olarak başlatır; sayfanın temiz bir başlangıçtan itibaren izini sürmüş olursunuz.

Kayıt öncesinde iki ayar büyük fark yaratır. CPU Throttling'i 4x olarak ayarlayın; bu, orta segment bir Android cihazı simüle eder ve masaüstü donanımında fark edilmez olan performans sorunlarını görünür hale getirir. Network Throttling için "Fast 3G" konumu, özellikle LCP elemanı büyük bir görsel ise ağ darboğazını daha net ortaya çıkarır. Her iki throttling'i de açık bırakmak, geliştirme bilgisayarının güçlü donanımından kaynaklanan yanıltıcı "her şey hızlı" sonuçlarını engeller.

Kayıt süresini kısa tutun. Beş ila on saniye çoğu senaryo için yeterli; uzun kayıtlar dosyayı şişirir ve analiz ağırlaşır. Bir scroll veya tıklama etkileşimini inceliyorsanız kaydı başlatın, hareketi gerçekleştirin, hemen durdurun. Kayıt bittikten sonra panel kısa bir işlem süresi gerektirip tam zaman çizelgesini gösterir. Throttling aktifken bu işlem birkaç saniye alabilir.

Flame chart'ı okumak: renk, derinlik ve zaman ekseni

Flame chart, yatay eksende zamanı, dikey eksende çağrı zincirini gösterir. En üstteki blok çağrılan işlevi temsil eder; altındaki bloklar onu çağıran işlevleri. Bir blok ne kadar genişse o işlev o kadar uzun süre çalışmış demektir. Derinlik tek başına sorun değildir; geniş ve yassı bloklar önce dikkat çekmelidir, çünkü CPU'yu uzun süre meşgul eden onlardır.

Renkler katmana göre ayrışır. Sarı JavaScript yürütmesini temsil eder, mor layout ve stil yeniden hesaplamalarını, yeşil boyama (paint) işlemlerini, mavi ise HTML parse ve ağ görevlerini. Bu kodları ezberlemenize gerek yok; herhangi bir bloğun üzerine geldiğinizde tooltip o işlevin ne olduğunu, kaç milisaniye sürdüğünü ve hangi kaynak dosyadan geldiğini gösterir. Bununla birlikte sarı bloklara bakmak genellikle en verimli başlangıç noktasıdır: JavaScript, main thread'i en uzun süre bloke eden katmandır ve profil üzerinde en sık sorun orada çıkar.

Flame chart üzerinde gezinmek için fare tekerleğini veya W/A/S/D klavye kısayollarını kullanın. W yakınlaştırır, S uzaklaştırır, A sola, D sağa kaydırır. Belirli bir alanı seçmek için Shift basılı tutarak tıklayıp sürükleyin. Bu navigasyon birkaç kez kullandıktan sonra refleks haline gelir ve istediğiniz zaman dilimine odaklanmak artık hızlanır.

Profil yüklenir yüklenmez iki ayrı katmana bakın. "Main" satırı ana iş parçacığıdır ve JavaScript, layout, paint işlemlerinin tamamı burada görünür. "Network" satırı ise kaynak indirmelerini gösterir. İki katmanı örtüştürerek bir JavaScript bloğunun tam olarak hangi network isteğiyle eş zamanlı çalıştığını görmek mümkün olur; bu, LCP gecikmesinin kaynağını izlerken özellikle değerli olur.

Long task tespiti: 50 ms eşiği ve kırmızı üçgen

Long task, ana iş parçacığının 50 milisaniyenin üzerinde kesintisiz çalıştığı her görevdir. Tarayıcı bu süre boyunca kullanıcı girdisine yanıt veremez; scroll, tıklama veya klavye girişi işlenmez, bekler. 50 ms eşiği keyfi değil: insan algısı yaklaşık 100 ms'ye kadar gecikmeleri fark etmez, ama bu eşiğe güvenli biçimde ulaşmak için tampon olarak 50 ms kullanılır. INP (Interaction to Next Paint) için iyi eşik 200 ms, kötü eşik 500 ms; her ikisinin matematiksel temelinde de bu mantık yatar.

Flame chart'ta uzun görevler kırmızı üçgenle işaretlenir. O görevi tıkladığınızda alt bölümdeki "Summary" sekmesi toplam süreyi gösterir. "Bottom-Up" sekmesine geçin: burada hangi işlevin toplam sürenin ne kadarını harcadığı azalan sırada sıralanır. "Self Time" (öz süre), o işlevin yalnızca kendi kodunu çalıştırdığı süredir; "Total Time" ise çağırdığı tüm alt işlevlerin süresini de kapsar. Öz süre yüksekse sorun o işlevin doğrudan kendisindedir; toplam süre yüksek ama öz süre düşükse sorun alt çağrılardan kaynaklanıyordur ve Call Tree ile daha aşağı inmek gerekir.

"Call Tree" sekmesi tersine çalışır: tepeden aşağıya iner ve hangi çağrı zincirinden geldiğini gösterir. "Event Log" sekmesi ise tüm olayların zaman sıralı listesidir; belirli bir aralığı taramak istediğinizde kullanışlıdır. Bu üç sekmeyi sırayla kullanmak long task analizinin standart akışını oluşturur: Bottom-Up ile sorunu bulmak, Call Tree ile iz sürmek, Event Log ile doğrulamak.

LCP ve INP olaylarını zaman çizelgesinde bulmak

Kayıt bittikten sonra üst şeridin "Timings" satırına bakın. FCP (First Contentful Paint), LCP (Largest Contentful Paint) ve diğer sayfa yaşam döngüsü olayları burada dikey çizgiler ve etiketlerle gösterilir. LCP marker'ına tıkladığınızda alt bölümde hangi elemanın LCP'yi tetiklediği, varsa kaynak URL'si ve tam zamanlama verisi görünür. Bu bilgi, LCP elemanının fotoğraf mı yoksa metin mi olduğunu doğrulamak için de kullanışlıdır.

LCP gecikmesi dört alt parçaya ayrışır: Time to First Byte (TTFB), kaynak yükleme gecikmesi, kaynak yükleme süresi ve eleman render gecikmesi. Flame chart üzerinde bu dört dilimi birleştirdiğinizde gecikmenin hangi aşamada biriktiğini görmek kolaylaşır. LCP elemanı bir görsel ise kaynak yükleme süresi uzunsa ağ veya dosya boyutu sorunu vardır; TTFB uzunsa sunucu tarafında bir gecikme söz konusudur; eleman render gecikmesi uzunsa büyük olasılıkla bir JavaScript bloğu boyamayı geciktiriyordur. Üç olasılık farklı çözümlere işaret ettiğinden doğru parçayı tespit etmek gereksiz çabayı önler.

INP için kayıt sırasında etkileşim gerçekleştirmeniz şart: bir düğmeye tıklayın, bir form alanına yazın, bir menü açın. Kayıt bittiğinde "Interactions" satırında bu etkileşim görünür. Tıkladığınızda etkileşimin başından bir sonraki boyama anına kadar geçen toplam süre gösterilir. 200 ms üzerindeki INP değerleri "needs improvement" bandına, 500 ms üzerindeki değerler "poor" eşiğine girer. Flame chart'ta o zaman dilimine yakınlaştırıp hangi JavaScript bloğunun boyamayı geciktirdiğini bulabilirsiniz; etkileşim sırasında tetiklenen layout thrashing, ağır event handler veya senkron ağ isteği bu yöntemle tespit edilir.

Timings satırı boş görünüyorsa iki olasılık var. Kayıt yeterince uzun tutulmamıştır ya da sayfa yükleme yerine el ile kayıt yöntemi kullanılmıştır. Sayfa yükleme kaydında FCP ve LCP neredeyse her zaman görünür; el ile kayıtta ise sayfa zaten yüklenmiş olduğundan bu olaylar yakalanmaz.

Main thread bloğunun kaynağına inmek

Flame chart'ta geniş bir sarı blok gördünüz. Tıkladınız, işlev adı çıktı. Nereden geldiğini bulmak için alt bölümdeki kaynak bağlantısına tıklayın; Sources paneli doğrudan o dosya ve satır numarasına atlar. Kaynağı bulmak tek adım. Sonrası o satırda ne olduğunu anlamaktır.

Sorun üçüncü taraf bir script'ten geliyorsa kodu doğrudan değiştiremezsiniz. Ama yükleme biçimini kontrol edebilirsiniz: async veya defer öznitelikleri olmadan yüklenen bir script, HTML parse'ı durdurur ve her şeyi bloke eder. Profil üzerinde hangi görevde ne kadar süre harcadığını görerek bu etkinin kabul edilebilir olup olmadığına karar verebilirsiniz. Kararınız olumsuzsa o üçüncü tarafı ertelemeyi, koşullu yüklemeye almayı veya kaldırmayı değerlendirebilirsiniz; her üç seçenek de flame chart'taki uzun görevin nasıl tepki verdiğini kayıt alarak doğrulanabilir.

Kendi kodunuzdan gelen bir blok söz konusuysa Bottom-Up ve Call Tree'yi birlikte kullanarak hangi döngünün ya da işlevin maliyetli olduğunu daraltın. Ana iş parçacığı bloğunu incelerken şu soruyu sorun: bu iş gerçekten burada yapılmak zorunda mı? Ağır hesaplamalar Web Worker'a taşınabilir, uzun listeler virtualization ile küçültülebilir, yükleme anında gerekli olmayan script'ler code splitting ile ertelenebilir. Profil size sorunun ne olduğunu gösterir, çözümü seçmek size kalır.

Mor bloklarda da benzer bir yoğunluk varsa layout thrashing olabilir. JavaScript'in DOM'u okuyup yazarak zorla yeniden hesaplama tetiklemesi, "Recalculate Style" veya "Layout" kaleminin Bottom-Up'ta öne çıkmasına neden olur. Bu kalemi gördüğünüzde ilgili JavaScript kodunu bulun ve okuma-yazma sıralamasını düzeltmeyi, ya da değerleri önbelleğe almayı deneyin.

Profil dosyasını kaydetmek ve paylaşmak

Performance panelinin sağ üst köşesindeki aşağı ok simgesi "Save profile..." seçeneğini sunar. Kayıt .json uzantılı bir dosyaya aktarılır. Aynı menüdeki "Load profile..." ile bu dosyayı başka bir makinede açabilirsiniz. Bir geliştirici sorunu tespit edip kaydı paylaşır; başka biri o dosyayı açar ve tam aynı flame chart'ı görür. Ek araç gerekmez, hesap gerektirmez.

Profil dosyaları büyük olabilir; 5-20 MB arası yaygındır. Kısa kayıtlar boyutu azaltır. Uzun bir kaydın belirli bir kesimine odaklanmak istiyorsanız önce Shift ile sürükleyerek o kesimi seçin, ardından "Save selection..." ile yalnızca seçili aralığı dışa aktarın. Alakasız veri kesilir, paylaşılan dosya küçülür, analizi devralan kişi gereksiz bölümlere zaman harcamaz.

Kayıt sırasında "Screenshots" onay kutusunu işaretliyseniz zaman çizelgesinde her kareye karşılık gelen sayfa görüntüsü de kaydedilir. Zaman çizelgesi üzerinde fareyi sürüklediğinizde sayfanın o andaki görsel durumu küçük önizlemede gösterilir. CLS (Cumulative Layout Shift) sorunlarını takip ederken, elemanların tam olarak ne zaman yerinden oynadığını görmek için bu özellik değerlidir; saf sayısal veri bazen anlatamadığı bağlamı görsel onaylama tamamlar.

Performance paneli, neyin nerede yavaşladığını görmek için sağlam bir başlangıç noktasıdır. Flame chart'ı okumak, long task'leri tespit etmek, LCP zincirini izlemek, main thread bloğunun kaynağına inmek: bunların her biri ayrı bir alışkanlık, ama birlikte kullanıldığında bir sayfanın neden yavaş olduğunu somut verilerle açıklayabilirsiniz. Tahmin yerini ölçüme bırakır; tartışma yerini profile.

Profil almak, her deploy öncesinde değil, ciddi bir değişiklikten sonra işe yarar. Yeni bir JavaScript kütüphanesi eklendiğinde ya da ağır bir bileşen yeniden yazıldığında alınan bir kayıt, ileride saatlerce sürebilecek bir tanılama sürecini baştan kısaltır. Veriye dayalı hata ayıklama, çoğu performans sorununu kaynağında görünür kılar.