Chrome DevTools Performans Paneli Kullanımı

Lighthouse size "ana iş parçacığı çalışmasını azaltın" der ve orada bırakır; hangi fonksiyonun 380 milisaniye harcadığını söylemez. Chrome DevTools performans paneli tam olarak bu boşluğu doldurur: sayfanın yüklenişini veya bir tıklamanın işlenişini mikrosaniye çözünürlüğünde kaydeder ve zamanın hangi fonksiyonda geçtiğini fonksiyon fonksiyon önünüze serer.

Bu rehberde paneli verimli kullanmanın yolunu anlatacağım: kaydı hangi koşullarda almak gerekir, zaman çizelgesindeki katmanlar neyi gösterir, alev grafiği nasıl okunur, uzun görevler nasıl bulunur ve bir tıklamanın neden geç cevap verdiğini nasıl tespit edersiniz. Panel ilk açılışta korkutucu görünür ama aslında yalnızca dört beş görünümden oluşur; hangisine ne zaman bakacağınızı öğrendiğinizde teşhis süreniz dakikalara iner.

Paneli Doğru Koşullarda Açmak#

Ölçüme başlamadan önce üç şeyi ayarlamazsanız aldığınız kayıt gerçeği yansıtmaz. Birincisi tarayıcı eklentileri: her eklenti sayfaya kod enjekte eder ve alev grafiğinde sizin kodunuz gibi görünür. Bu yüzden ölçümü daima gizli pencerede ya da eklentisiz ayrı bir Chrome profilinde yapın.

İkincisi işlemci kısıtlaması. Panelin dişli simgesindeki CPU menüsünden 4x slowdown seçin. Masaüstü işlemciniz JavaScript'i orta sınıf bir telefondan dört beş kat hızlı çalıştırır; kısıtlama uygulamazsanız kullanıcılarınızın yaşadığı takılmayı hiç göremezsiniz.

Üçüncüsü ağ kısıtlaması ve önbellek. Network menüsünden Slow 4G veya Fast 4G seçin, Disable cache kutusunu işaretleyin. Kendi bilgisayarınızın önbelleğinde duran dosyalarla yapılan ölçüm, yeni ziyaretçinin deneyimini anlatmaz.

Bu üç ayar yapıldıktan sonra iki farklı kayıt biçimi kullanabilirsiniz:

Yükleme analizi için birinciyi, etkileşim analizi için ikincisini kullanın. İkisini karıştırmak en yaygın hatalardan biridir: bir düğmenin neden geç cevap verdiğini araştırırken sayfa yükleme kaydı almak, size tamamen alakasız bir zaman aralığı gösterir.

Zaman Çizelgesinin Katmanları#

Kayıt bittiğinde ekranda üst üste birkaç şerit görürsünüz. Her biri farklı bir katmanı temsil eder ve hangisine bakacağınızı bilmek, panelin yarısını öğrenmek demektir.

En üstteki genel bakış şeridi, kaydın tamamını küçültülmüş olarak gösterir; buradan bir aralık seçerek yakınlaştırırsınız. Altındaki Network şeridi, o kayıt sırasındaki istekleri waterfall biçiminde çizer; ayrıntılı okuma yöntemi için waterfall grafiği nasıl okunur yazısına bakabilirsiniz.

Frames şeridi, her çizilen kareyi kutu olarak gösterir. Yeşil kutular akıcı kareleri, sarı ve kırmızı kutular ise geciken kareleri işaret eder. Kaydırma sırasında takılma yaşıyorsanız ilk bakacağınız şerit budur.

Timings şeridi, tarayıcının işaretlediği anahtar anları gösterir: FCP, LCP, DCL (DOMContentLoaded) ve L (load). Bu işaretler alev grafiğinde nereye bakmanız gerektiğini söyler; örneğin LCP işaretinden önceki bölgede duran uzun bir görev, LCP'yi doğrudan geciktiriyor demektir.

Main şeridi ise işin kalbidir: ana iş parçacığında çalışan her şey burada, iç içe geçmiş bloklar hâlinde çizilir. Alev grafiği dediğimiz görünüm budur ve bir sonraki bölümde ayrıntılı ele alacağım.

Alev Grafiğini Okumak#

Alev grafiğinde her blok bir fonksiyon çağrısıdır. Yatay genişlik süreyi, dikey konum ise çağrı derinliğini gösterir: üstteki blok alttakini çağırmıştır. Yani grafiği yukarıdan aşağıya okuduğunuzda çağrı zincirini takip edersiniz.

Okuma yönteminde iki kavramı ayırmak gerekir. Total time (toplam süre), bir fonksiyonun kendisi ve çağırdığı tüm alt fonksiyonlar için geçen süredir. Self time (kendi süresi) ise yalnızca o fonksiyonun kendi gövdesinde harcanan süredir. Optimizasyon yaparken self time yüksek olan fonksiyonu ararsınız; total time yüksek ama self time düşük bir fonksiyon sadece "kapı"dır, asıl iş altındakilerdedir.

Alev grafiğinde renkler de bilgi taşır. Sarı bloklar JavaScript çalıştırmayı, mor bloklar stil hesaplama ve düzen (layout) işlemlerini, yeşil bloklar boyama ve birleştirmeyi, gri bloklar ise sistem işlerini gösterir. Grafiğiniz baştan sona sarıysa sorun JavaScript'tedir; mor bloklar baskınsa DOM'a çok fazla dokunuyorsunuz ve tarayıcıyı sürekli yeniden düzen hesaplamaya zorluyorsunuz demektir.

Bir bloğa tıkladığınızda panelin altında dört sekme belirir. Hangisini ne için kullanacağınız şöyle özetlenebilir:

Pratikte en çok kullandığım sekme Bottom-Up'tır. Bir aralığı seçip bu sekmeyi açtığınızda, o aralıkta en çok kendi süresini harcayan fonksiyonlar en üstte listelenir. Genellikle ilk üç satır size sorunun kaynağını doğrudan söyler.

Uzun Görevleri Bulmak ve Yorumlamak#

Ana iş parçacığındaki bloklardan bazılarının sağ üst köşesinde küçük kırmızı bir üçgen vardır. Bu işaret, o görevin 50 milisaniyeyi aştığını yani "uzun görev" olduğunu bildirir. Uzun görev, o süre boyunca tarayıcının kullanıcı girdisine cevap veremediği anlamına gelir ve TBT metriğinin hammaddesidir.

Uzun görevleri incelerken şu sırayı izleyin: önce en uzun olanı seçin, sonra Bottom-Up sekmesinde self time'ı en yüksek fonksiyona bakın, ardından Summary sekmesindeki dosya bağlantısına tıklayarak kaynağa gidin. Üç tıklamada, hangi satırın sayfanızı kilitlediğini görürsünüz.

Aynı bilgiyi kod ile de toplayabilirsiniz; özellikle üretim ortamında gerçek kullanıcılardan veri almak isterseniz:

// Uzun gorevleri konsola dok, DevTools kaydi olmadan
new PerformanceObserver((list) => {
  list.getEntries().forEach((g) => {
    console.log("Uzun gorev:", Math.round(g.duration) + " ms", "| baslangic:", Math.round(g.startTime));
  });
}).observe({ type: "longtask", buffered: true });

Kendi kodunuzun hangi bölümünün ne kadar sürdüğünü alev grafiğinde etiketli görmek isterseniz performance.measure kullanın; bu ölçümler Timings şeridinde adlarıyla birlikte görünür:

// Kendi kod blogunu zaman cizelgesinde etiketle
performance.mark("liste-basla");
listeyiIsle(kayitlar);
performance.mark("liste-bitti");
performance.measure("Liste isleme", "liste-basla", "liste-bitti");

Bu teknik, büyük bir uygulamada "zaman nereye gidiyor" sorusunu cevaplamanın en pratik yoludur; çünkü alev grafiğinde küçük harflerle görünen minify edilmiş fonksiyon adları yerine kendi verdiğiniz Türkçe etiketleri görürsünüz.

Etkileşim Gecikmesini Ölçmek#

Sayfa yüklendikten sonra bir düğmeye tıkladığınızda hiçbir şey olmuyorsa, serbest kayıt (Ctrl+E) alıp tıklamayı gerçekleştirin ve kaydı durdurun. Zaman çizelgesinde Interactions şeridi belirir ve o tıklamanın süresi kutu olarak gösterilir.

Bir etkileşim üç parçadan oluşur: girdi gecikmesi (tarayıcı meşgul olduğu için olayın kuyrukta beklediği süre), işleme süresi (olay dinleyicinizin çalıştığı süre) ve sunum gecikmesi (ekranın yeniden çizilmesi). Hangi parçanın uzun olduğunu görmek, çözümü de belirler:

1. Girdi gecikmesi uzunsa başka bir görev ana iş parçacığını meşgul ediyordur; suçlu genellikle bir üçüncü taraf betiğidir.
2. İşleme süresi uzunsa kendi olay dinleyicinizde ağır bir hesaplama vardır; işi parçalara bölmeniz ya da worker'a taşımanız gerekir.
3. Sunum gecikmesi uzunsa DOM çok büyüktür veya dinleyici içinde düzen değişikliğine yol açan pahalı işlemler yapılmaktadır.

Bu üçlü ayrım, gerçek kullanıcı verisindeki INP metriğinin de temelidir; ayrıntılı müdahale yöntemleri için INP nedir ve nasıl iyileştirilir yazısına bakabilirsiniz.

Düzen Kaymalarını ve Zorlanmış Yeniden Düzeni Yakalamak#

Panel iki sinsi sorunu daha yakalar. Birincisi düzen kaymalarıdır: Experience ya da Layout Shifts şeridinde beliren mavi bloklara tıkladığınızda hangi elemanın kaydığını ve kayma puanını görürsünüz. Bu, CLS düzen kayması sorunlarını avlamanın en doğrudan yoludur.

İkincisi zorlanmış senkron düzen (forced synchronous layout) sorunudur. Alev grafiğinde mor bir blok üzerinde kırmızı bir uyarı görürseniz, kodunuz DOM'a yazdıktan hemen sonra bir ölçüm değeri okumuş ve tarayıcıyı düzen hesaplamasını erkenden yapmaya zorlamış demektir. Klasik örnek şudur:

// KOTU: her donguda yaz-oku sirasi tarayiciyi zorlar
kutular.forEach((kutu) => {
  kutu.style.width = "300px";
  console.log(kutu.offsetHeight); // yazmadan hemen sonra okuma
});

// IYI: once tum okumalar, sonra tum yazmalar
const yukseklikler = kutular.map((k) => k.offsetHeight);
kutular.forEach((kutu, i) => {
  kutu.style.width = "300px";
  kutu.dataset.eskiYukseklik = yukseklikler[i];
});

Bu tek değişiklik, uzun listelerde yüzlerce milisaniye kazandırabilir ve tipik olarak alev grafiğindeki mor blok yığınını tamamen ortadan kaldırır.

Bir Kaydı Beş Dakikada Okuma Rutini#

Panel karşısında nereden başlayacağını bilememek en çok zaman kaybettiren durumdur. Yıllar içinde oturttuğum ve neredeyse her kayıtta işe yarayan sıra şudur:

1. Timings şeridine bak. FCP ve LCP işaretleri nerede duruyor? İkisi arasındaki mesafe büyükse sorun görsel/kaynak yüklemesinde, ikisi de geç ise sorun sunucu cevabında ya da render engelleyen kaynaklardadır.
2. Main şeridinde kırmızı üçgenleri say. LCP işaretinin solunda kaç uzun görev var? Bu sayı, ilk çizimi geciktiren JavaScript yükünün doğrudan göstergesidir.
3. En uzun görevi seç ve Bottom-Up'a geç. İlk üç satırdaki fonksiyonlardan hangisi sizin kodunuz, hangisi üçüncü taraf? Kendi kodunuz değilse çözüm optimizasyon değil, o betiği ertelemektir.
4. Renk dağılımına bak. Sarı baskınsa JavaScript, mor baskınsa düzen hesaplaması, yeşil baskınsa boyama sorunudur. Üçü üç ayrı çözüm ailesine götürür.
5. Network şeridiyle çapraz kontrol yap. Uzun görev, büyük bir dosyanın indirilmesinin hemen ardından mı başlıyor? O zaman suçlu o dosyanın ayrıştırılmasıdır ve kod bölme doğrudan işe yarar.

Bu beş adımı bir kez alışkanlık hâline getirdiğinizde, tanımadığınız bir sitenin kaydını bile birkaç dakikada teşhis edebilirsiniz. Bulduğunuz sonucu not edip düzeltmeyi uyguladıktan sonra aynı senaryoyu tekrar kaydedin; iki kaydı yan yana koymak, kazancın gerçek olup olmadığını gösteren tek güvenilir yöntemdir.

Sık Yapılan Hatalar#

En yaygın hata, kısıtlama uygulamadan ölçmektir. Masaüstünüzde 40 ms süren bir görev, orta sınıf bir telefonda 200 ms sürer. Kısıtlamasız kayıt size "sorun yok" der ve kullanıcılarınız aksini yaşamaya devam eder.

İkinci hata, eklentili profilde ölçmektir. Alev grafiğinde tanımadığınız uzantı adları görüyorsanız kaydınız kirlenmiş demektir; gizli pencerede tekrarlayın.

Üçüncü hata, total time yüksek olan fonksiyonu optimize etmeye çalışmaktır. Kök fonksiyonun total time'ı doğal olarak en yüksektir çünkü her şeyi o kapsar; asıl hedef self time'ı yüksek olandır. Bottom-Up sekmesi bu ayrımı sizin için zaten yapar.

Dördüncü hata, çok uzun kayıt almaktır. Otuz saniyelik bir kayıt hem tarayıcıyı yorar hem de içinde aradığınızı bulmayı zorlaştırır. İlgilendiğiniz eylemi hedefleyen üç beş saniyelik kayıtlar çok daha kullanışlıdır.

Beşinci hata, tek kayıtla karar vermektir. İlk kayıtta derleyici henüz kodu optimize etmemiş olabilir; aynı senaryoyu iki üç kez kaydedip tutarlı olan deseni arayın.

Sıkça Sorulan Sorular#

DevTools performans paneli ile Lighthouse arasındaki fark nedir#

Lighthouse bir denetim aracıdır: sayfayı ölçer, puan verir ve genel öneriler listeler. Performans paneli ise bir profilleyicidir: size puan vermez, zamanın hangi fonksiyonda geçtiğini gösterir. Pratikte Lighthouse ile sorunu tespit eder, performans paneliyle sebebini bulursunuz. İkisi birbirinin yerine geçmez.

CPU throttling kaç kat olmalı#

Genel kullanım için 4x slowdown iyi bir başlangıçtır; orta sınıf bir Android telefonu kabaca temsil eder. Daha düşük segmentte cihaz kullanan bir kitleniz varsa 6x ile de deneyin. Kısıtlamasız ölçüm yalnızca kendi makinenizde bir gerilemeyi karşılaştırmak için anlamlıdır.

Alev grafiğinde minify edilmiş isimler görüyorum, ne yapmalıyım#

Kaynak haritalarını (source map) üretime dâhil edin ya da en azından geliştirme derlemesinde profil alın. Kaynak haritası mevcutsa DevTools fonksiyon adlarını orijinal hâliyle gösterir. Alternatif olarak kendi kritik bloklarınızı performance.mark ve performance.measure ile etiketleyerek okunur adlar üretebilirsiniz.

Kaydı kaydedip başkasıyla paylaşabilir miyim#

Evet. Panelin sol üstündeki indirme simgesiyle kaydı JSON olarak dışa aktarabilir, karşı taraf da aynı panele yükleyerek birebir aynı görünümü açabilir. Bu, ekip içinde performans sorunlarını tartışmanın en verimli yoludur; ekran görüntüsü yerine gerçek veriyi paylaşırsınız.

Mobil cihazda gerçek ölçüm nasıl alınır#

Telefonu USB ile bilgisayara bağlayıp geliştirici seçeneklerinden USB hata ayıklamayı açın, ardından masaüstü Chrome'da chrome://inspect adresine gidin. Cihazdaki sekmeye "inspect" dediğinizde açılan DevTools, gerçek telefon üzerinde kayıt alır. Emülasyonun aksine işlemci farkını da gerçek olarak ölçmüş olursunuz.

Bellek sızıntısını da bu panelden bulabilir miyim#

Performans panelindeki Memory kutusunu işaretlerseniz kayıt sırasında yığın (heap) grafiğini görürsünüz ve sürekli yükselen bir çizgi sızıntıya işaret eder. Ancak sızıntının kaynağını bulmak için ayrı Memory paneline geçip yığın anlık görüntüsü almak gerekir; performans paneli sadece sorunun varlığını gösterir.

Kapanış#

DevTools performans paneli, performans işinde tahminin bittiği yerdir: hangi fonksiyonun kaç milisaniye harcadığını size doğrudan söyler. Aklınızda kalması gereken dört alışkanlık: kaydı daima gizli pencerede ve işlemci kısıtlamasıyla alın, yükleme ile etkileşim kayıtlarını birbirine karıştırmayın, Bottom-Up sekmesinde self time'a bakarak gerçek suçluyu bulun ve kendi kritik bloklarınızı performance.measure ile etiketleyerek grafiği okunur hâle getirin.

Profilleme sonucunda darboğazın sunucu tarafında olduğunu görürseniz, kod optimizasyonunun tavanına çarpmışsınız demektir; bu noktada ayrılmış işlemci gücü gerçek fark yaratır. VDS ve bulut sunucu paketlerimiz derleme ve önbellek süreçleri için rahat bir alan sağlar, web hosting planlarımız ise hazır optimize bir başlangıç sunar. Analizi ve düzeltmeleri bize bırakmak isterseniz sunucu yönetimi hizmetimiz bu döngüyü üstlenir.