Chrome DevTools Performance Paneli

TL;DR — Performance paneli, Chrome’a yerleşik bir araçtır (DevTools’u açın, Performance’a tıklayın) ve bir sayfa yüklenirken tarayıcınızın yaptığı her şeyi — her betiği, her ağ isteğini, her boyamayı — kaydeder. PageSpeed Insights’tan farklı olarak size bir puan vermez; bir sayfanın neden yavaş olduğunu bulabilmeniz için ham tabloyu sunar. Önemli: Google’ın tarayıcısının değil, sizin tarayıcınızın ne yaptığını gösterir; ücretsizdir ve hesap gerektirmez.

Nedir?

Chrome DevTools’da birçok sekme bulunur. Performance paneli, bir sayfanın nasıl yüklendiğini ve çalıştığını kaydedip ayrıntıları incelemek için kullanılan sekmedir. Tarayıcınızın zaman içindeki çalışmalarını — dosyaları indirme, JavaScript çalıştırma, sayfayı düzenleme ve boyama — yakalar ve yakınlaştırabileceğiniz bir zaman çizelgesinde gösterir.

Aradaki farkı şöyle düşünün: PageSpeed Insights ve Lighthouse, bir karne gibidir; bir test çalıştırıp size puan ve yapılacaklar listesi verir. Performance paneli ise tüm sayfa yüklemesinin güvenlik kamerası kaydı gibidir — puan vermez, ancak geri sarıp bir şeyin ters gittiği anı tam olarak görebilirsiniz.

Nasıl açılır ve önce ne görürsünüz?

1. DevTools’u açın (sayfaya sağ tıklayıp → Inspect’i seçin veya Mac’te Cmd+Option+I / Windows’ta Ctrl+Shift+I tuşlarına basın).
2. Üstteki Performance sekmesine tıklayın.

Paneli açtığınız anda, kendi tarayıcınızda canlı olarak ölçülen üç Core Web Vitals ölçümünden ikisini — Largest Contentful Paint (LCP) ve Cumulative Layout Shift (CLS) — zaten gösterir. Sayfayla etkileşime geçtiğinizde Interaction to Next Paint (INP) ölçümünü de yakalar. Hiçbir şey kaydetmeden yerel Core Web Vitals ölçümlerinizin anlık görüntüsünü elde edersiniz.

Bir sayfa yüklemesini kaydetme

Bir yüklemenin bütün hikâyesini görmek için Start profiling and reload page’e tıklayın (sayfanın her anda nasıl göründüğünü gösteren bir film şeridi de elde etmek için önce Screenshots onay kutusunu işaretleyin). Panel sayfayı yeniden yükler ve her şeyi kaydeder. Kayıt durduğunda yoğun bir zaman çizelgesi görürsünüz: betik çalıştırma, oluşturma ve boyama işlemlerini gösteren renkli çubuklar; üst kısım boyunca uzanan bir ekran görüntüsü şeridi ve neyin ne zaman yüklendiğini gösteren bir ağ bölümü.

İlk bakışta göz korkutucu görünür. Çoğu SEO uzmanının buraya gelme amacı aslında basittir ve bunu Advanced sekmesinde adım adım anlatacağım: LCP’niz olan öğeyi tam olarak bulmak — yani sayfanın boyadığı en büyük şeyi — böylece neyi optimize etmeniz gerektiğini bilirsiniz.

İnsanların yanlış anladığı nokta

Performance paneli, Googlebot’ın değil, sizin Chrome tarayıcınızın ne yaptığını gösterir. Googlebot, sayfaları kendi sistemiyle (Web Rendering Service) oluşturur; bu sistem, tam özellikli masaüstü tarayıcınızla aynı değildir. Dolayısıyla panel, hızı teşhis etmek ve oluşturma sürecini anlamak için harikadır; ancak Google’ın gerçekte neyi tarayıp dizine ekleyebildiğini doğrulamanın bir yolu değildir. Bunun için Google Search Console’un URL Inspection aracını kullanın.

Alev grafiğini ve Insights kenar çubuğunu okumayı, LCP öğenizi bulmayı, yavaş bir telefonu simüle etmek için kısıtlama uygulamayı ve bunun Lighthouse ile WebPageTest’le nasıl karşılaştırıldığını içeren eksiksiz anlatımı ister misiniz? Advanced sekmesine geçin.

TL;DR — Performance paneli, Chrome DevTools’un yerleşik, yerel profil oluşturucusudur. Paneli açtığınızda canlı yerel LCP/CLS’yi (etkileşim kurduğunuzda da INP’yi) gösterir; tam bir yüklemeyi kaydetmek için Screenshots açıkken Start profiling and reload page’e basın. Ana iş parçacığındaki çalışmaları gösteren bir alev grafiğini, FPS/CPU zaman çizelgesini, ağ şelalesini ve analiz sekmelerini (Bottom-up, Call Tree, Event Log) okuyabilirsiniz. Ayrıca LCP’yi dört alt parçaya ayıran ve oluşturmayı engelleyen istekleri, zorunlu yeniden akışı ve üçüncü taraf maliyetini işaretleyen bir Insights kenar çubuğu vardır. LCP öğenizi tam olarak belirlemenin en hızlı yerleşik yoludur. Üç noktayı birbirinden ayırın: Googlebot’ın Web Rendering Service’ini değil, sizin tarayıcınızı profiller; kaydedilen iz laboratuvar kanıtıdır ve panel isteğe bağlı olarak gerçek kullanıcılara ait CrUX alan verilerini yanında gösterebilse de bu alan katmanı, yerel izinizle aynı ölçüm değildir; ayrıca bağımsız eski Performance Insights paneli Chrome 132’de kaldırılmıştır — bu özellikler artık bu panelin Insights sekmesindedir. Kısıtlama çarpanları mutlak bir karşılaştırma ölçütü değil, makinenize göreli değerlerdir.

Performance paneli gerçekte nedir?

Google bunu açıkça şöyle tanımlar: “Use the Performance panel to analyze your website’s performance” ve “The Performance panel lets you record CPU performance profiles of your web applications” (Chrome DevTools docs). Bu bir profil oluşturucudur — tarayıcının belirli bir zaman aralığında yaptığı her şeyin izini kaydeder, ardından bu izi incelersiniz.

İnsanlar bu araçları sürekli birbirine karıştırdığı için en başta benzerleriyle karşılaştırmak yararlı olur:

• Lighthouse / PageSpeed Insights, otomatik bir denetim çalıştırır ve size puan ile önceliklendirilmiş öneriler verir (PSI ayrıca gerçek CrUX alan verilerini ekler). Puanlı, otomatik ve belirli görüşlere dayalıdır.
• WebPageTest, sayfanızı uzaktaki gerçek bir cihazda çalıştırır; geçmişe dönük, paylaşılabilir sonuçlar kaydeder ve çok adımlı betikleri destekler. Uzak, paylaşılabilir ve kapsamlıdır.
• Performance paneli, kendi yerel tarayıcınızdan alınan ham, etkileşimli bir iz sunar — puan, hesap veya uzak makine yoktur. Daha derin ve esnektir, ancak yorumu siz yaparsınız.

Kaydedilen izin kendisi yerel laboratuvar kanıtıdır — o andaki tek bir tarayıcınızın, cihazınızın ve ağınızın anlık görüntüsüdür. Ancak çevresindeki panel yalnızca bir laboratuvar aracı değildir: yeniden tasarımdan bu yana yerel sonuçlarınızın yanında isteğe bağlı gerçek kullanıcı CrUX alan metriklerini de gösterebilir. Yerel laboratuvar, uzak laboratuvar ve gerçek kullanıcı alan verilerini birbirinden ayırın; çünkü bu ayrım, web performansı araçları kümesinin omurgasıdır ve aşağıdaki efsaneler de bu ayrıma dayanır.

Kısa bir tarihçe (hangi panele baktığınızı bilmeniz için)

Panel uzun zamandır var. Chrome DevTools ekibinden Elizabeth Sweeny ve Paul Irish bunu şöyle ifade ediyor: “The Performance panel in Chrome DevTools has been helping developers measure and optimize their runtime performance in one form or another for the better part of 15 years,” ve “Starting with a panel called ‘Timeline’, it evolved to the Performance panel you know today” (Performance tooling in 2024 and beyond). Belirttikleri üzere bu süreçte “Lighthouse was launched in 2016 to help spot optimization opportunities more easily,” ve “The experimental Performance Insights panel was released in 2022 to test new ways of surfacing performance insights.”

Sonuncusu, bilgilerin güncelliği açısından önemlidir. Bağımsız Performance Insights paneli bir deneydi ve artık yok: Google’ın kendi bildiriminde “The Performance insights panel is deprecated and removed from DevTools starting with Chrome version 132. We recommend you use the Performance > Insights tab instead” deniyor (deprecation notice). İzlediğiniz bir eğitim veya ekran görüntüsü ayrı bir “Performance Insights” paneli gösteriyorsa Chrome 132’den öncedir ve artık güncel değildir — içgörüler artık normal Performance panelinin içindeki bir kenar çubuğunda yer alır.

Paneli açma ve canlı metrikler ekranı

DevTools’u açın ve üstteki sekmelerden Performance’ı seçin. Google’ın ifadesiyle, “When you open the Performance panel, it immediately captures and shows you your local Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) metrics,” ve “If you interact with your page, the Performance panel also captures your local Interaction to Next Paint (INP)” (overview docs). Bu açılış ekranı, Rick Viscomi’nin “a completely redesigned Performance panel landing page featuring a live view of your local Core Web Vitals performance” diye tanımladığı yeniden tasarımın bir parçasıdır (Monitor your local and real-user Core Web Vitals in DevTools). Dolayısıyla herhangi bir kayıt almadan önce bile yerel Core Web Vitals ölçümlerinizin tamamına sahip olursunuz.

İz kaydetme: çalışma zamanı ve yükleme

Kaydedebileceğiniz iki şey vardır ve aralarındaki ayrım önemlidir:

• Çalışma zamanı performansı — sayfa zaten yüklenmiştir ve onu çalışırken profillemek istersiniz (animasyon, yavaş etkileşim veya takılan kaydırma). Google: “Runtime performance is how your page performs when it is running, as opposed to loading” (Analyze runtime performance).
• Yükleme performansı — yeni bir gezinmeden itibaren tüm hikâyeyi görmek istersiniz. Start profiling and reload page’e tıklayın. İzle birlikte görsel karelerden oluşan bir film şeridi almak için önce Screenshots’ı açın.

SEO çalışmaları — LCP, düzen kayması, oluşturmayı engelleyen betikler — için neredeyse her zaman ekran görüntülerinin açık olduğu yükleme kaydını kullanmak istersiniz.

Bir iz yalnızca kayıt penceresinde gerçekleşenleri içerir — yakalamadığınız herhangi bir şey (pencere dışındaki bir etkileşim veya daha sonra tetiklenen geç yükleme işi) yok değil, yalnızca gözlemlenmemiştir. Sizin ya da başka birinin daha sonra yeniden üretebileceği veya karşılaştırabileceği bir iz istiyorsanız şunları not edin: Chrome sürümü ve tarih (etiketler, kısayollar ve arayüzün tam biçimi sürümden sürüme değişir), ekran görüntülerinin açık olup olmadığı, CPU/ağ kısıtlama ayarlarınız ve gelişmiş boyama/CSS araçlarıyla JavaScript örnekleme seçeneklerini varsayılan değerlerinde bırakıp bırakmadığınız. Bunların her biri ayrıntı ve ek yük getirdiğinden, farklı ayarlarla kaydedilen bir iz bunlar olmadan kaydedilen bir izle doğrudan karşılaştırılamaz.

İzi okuma

Bir kayıt, üst üste yerleştirilmiş birkaç iz sunar. Başlıcaları şunlardır:

• Alev grafiği / Main izi. Panelin merkezidir. Google: “DevTools shows you a flame chart of activity on the main thread, over time. The x-axis represents the recording, over time,” ve “Use the Main track to view activity that occurred on the page’s main thread” (features reference). Zaman soldan sağa ilerler; her anın altındaki çubuk yığını çağrı yığınıdır. Daha geniş çubuk = daha uzun süren görev — zamanınızın nereye gittiğini böyle görürsünüz. Bu iç içe yapı, iz yapısını — neyin neyi, ne zaman çağırdığını — gösterir; ancak bir üst görevin daha geniş bir kullanıcı deneyimi sorununa neden olduğunun tek başına kanıtı değildir. Bunu bir hipotezin başlangıç noktası olarak ele alıp ardından doğrulayın.
• FPS grafiği. Takılmayı hızlıca görmenizi sağlar. Google: “Whenever you see a red bar above FPS, it means that the framerate dropped so low that it’s probably harming the user experience” (runtime docs). Hedefiniz akıcı bir 60 FPS’dir; kırmızı çubuklar sorunlu noktaları işaretler.
• CPU grafiği, kayıt boyunca ana iş parçacığının ne kadar meşgul olduğunu gösterir.
• Network izi, her isteğin şelale görünümüdür — neyin, ne zaman ve hangi sırayla yüklendiğini gösterir (oluşturmayı engelleyen kaynaklar burada görünür).
• Timings izi, uygulamanız yayımlıyorsa özel performance.mark() ölçümlerinizi gösterir.

Alev grafiğinin altında, aynı verileri farklı biçimlerde inceleyen üç analiz sekmesi bulunur:

• Bottom-up — “Use the Bottom-up tab to view which activities directly took up the most time in aggregate.” “Tek başına hangi işlev zamanımın çoğunu tüketiyor?” sorusu için en iyisidir.
• Call tree — “Use the Call tree tab to view which root activities cause the most work.” “Tüm bu işleri hangi üst düzey görev başlattı?” sorusu için en iyisidir.
• Event log — aynı olayları kronolojik sırayla gösterir.

Insights kenar çubuğu

Yeniden tasarımın teşhis açısından en yararlı yeniliği, kaldırılan bağımsız Performance Insights panelinin halefi olan Insights kenar çubuğudur. Sizi alev grafiğinde arama yapmaya bırakmak yerine belirli ve adlandırılmış sorunları öne çıkarır. SEO açısından en önemli olanlar şunlardır:

• LCP dökümü. Google, LCP’yi dört alt parçaya ayırır — ilk bayta kadar geçen süre, kaynak yükleme gecikmesi, kaynak yükleme süresi ve öğe oluşturma gecikmesi (LCP breakdown insight). Bu, LCP’nizin yalnızca yavaş olduğunu değil, neden yavaş olduğunu (sunucu mu, geç yüklenen bir görsel mi, oluşturma engellemesi mi?) gösterir.
• Oluşturmayı engelleyen istekler — ilk boyamayı geciktiren CSS/JS (render-blocking insight).
• Zorunlu yeniden akış — tarayıcının düzeni yeniden hesaplamak için betiği duraklatmak zorunda kaldığı yerler.
• Üçüncü taraf maliyeti — yerleştirmelerin, etiketlerin ve widget’ların size maliyeti.

Bu sorunlar otomatik olarak öne çıkarıldığından Insights kenar çubuğu, Performance panelinin Lighthouse’taki “işte düzeltmeniz gerekenler” deneyimine en çok yaklaştığı yerdir — yine de her içgörünün arkasındaki ham ize inebilirsiniz.

Her içgörüyü kanıt olarak değil, yönlendirilmiş bir hipotez olarak ele alın. Olası bir sorunu belirleyip sizi arkasındaki iz bağlamına bağlar; ancak bir öğenin işaretlenmesi, o öğenin peşinde olduğunuz sonuca neden olduğunu veya onu düzeltmenin sonucu iyileştireceğini kanıtlamakla aynı şey değildir. Bir müşteriye veya ekip arkadaşınıza içgörünün asıl neden olduğunu söylemeden önce izin kendisiyle ve değişiklik öncesi/sonrası yeniden kayıtla doğrulayın.

CPU ve ağ kısıtlaması (ve insanları yanıltan önemli nokta)

Geliştirme makineniz tipik bir telefondan çok daha hızlıdır; bu nedenle size anında açılıyormuş gibi gelen bir sayfa, gerçek kullanıcılar için eziyet verici olabilir. Kısıtlama, daha zayıf koşulları simüle eder: bir CPU yavaşlatma çarpanı ve ağ profili (Slow 4G vb.).

Önemli nokta doğrudan Google’dan geliyor: “Throttling is relative to your computer’s capabilities. For example, the 2x slowdown option makes your CPU operate 2 times slower than its usual ability” (features reference). Bu, “4x slowdown” değerinin mutlak bir karşılaştırma ölçütü olmadığı anlamına gelir — hızlı bir dizüstündeki 4x ile zayıf bir makinedeki 4x aynı sonucu vermez. Makineler arasında karşılaştırabileceğiniz bir standart değil, göreli bir ayardır. DebugBear’ın deep DevTools walkthrough yazısında belirttiği ikinci pratik kullanım da şudur: kısıtlama, yoğun olay kümelerinin okunabilmesi için kaydı yavaşlatmaya da yarayabilir.

Buradaki laboratuvar verileri ile Google’ın sıralamada kullandığı alan verileri

SEO uzmanlarının yanıldığı yer burasıdır. Performance panelindeki sayılar — canlı metrikler ve her kayıt — sizin makinenizden, sizin ağınızda ve o anda alınan laboratuvar verileridir. Google’ın gerçek Core Web Vitals sıralama sinyali, Search Console ve PageSpeed Insights’ta gördüğünüz gerçek kullanıcılara ait CrUX alan verilerinden (gerçek Chrome kullanıcılarının 28 günlük toplamı) gelir. Kusursuz bir yerel kayıt, alan puanının geçeceğini garanti etmez — gerçek kullanıcıların cihazları daha yavaş, ağları daha kötü ve koşulları tek testinizden çok daha çeşitlidir.

Yeniden tasarlanan panel aslında bu iki taraf arasında köprü kurar: güncellemeden beri gerçek kullanıcılara ait CrUX alan verilerinizi yerel sonuçlarınızın hemen yanında gösterebilir; böylece “az önce ölçtüğüm şey” ile “gerçek kullanıcıların deneyimi”ni karşılaştırabilirsiniz. Alan katmanı mevcut olduğunda URL ve kaynak düzeyi ile mobil ve masaüstü arasında geçiş yapabilir; arayüz ayrıca verilerin ait olduğu dönemi gösterir. Bunları karşılaştırdığınız izle eşleştirin. Bu şekilde eşleştirildiğinde bile alan verilerinden türetilen ortam ayarları (panelin CrUX’a göre önerdiği kısıtlama hazır ayarları), seçilen bir gerçek kullanıcı kesimini yalnızca yaklaşık olarak temsil eder; tek bir yerel kayıt, alttaki nüfus dağılımını yeniden oluşturmaz veya bir sıralama sonucunu öngörmez. Bu katman, yerel iziniz ile Google’ın sıralama sinyalinin iki farklı sayı olduğunu hatırlatan en açık yerleşik göstergedir. Laboratuvar ve alan verileri konusunun tamamı için web performansı araçları merkezine ve ilgili Core Web Vitals ile CrUX açıklamalarına bakın.

Teknik SEO için nasıl kullanıyorum?

Performance panelinden yıllardır yararlanıyorum — tek başına teslim edilecek bir çıktı olarak değil, bir puan yeterli olmadığında ve gerçek işleyişi görmem gerektiğinde başvurduğum araç olarak. Birkaç somut kullanım alanı:

LCP öğesini tam olarak bulma. Bu, paneldeki en değerli SEO tekniğidir ve sahnede öğrettiğim bir yöntemdir. Page Experience Update (TMC, June 2021) sunumumdaki adımlar şunlardır: Performance > “Screenshots” seçeneğini işaretleyin, “Start profiling and reload page“‘e tıklayın, zamanlama grafiğinde LCP’yi bulun, sonra düğüme tıklayın — LCP öğesi budur. DevTools, Google’ın Largest Contentful Paint olarak sayacağı öğeyi tam olarak gösterir; böylece neyi optimize edeceğinizi bilirsiniz. Seer Interactive’ten Richie Lauridsen, Search Engine Journal’da aynı tekniği şöyle anlatıyor: “In hovering over the flag for LCP, we can actually see the piece of content flagged to be the largest contentful paint during the page load” (3 Ways to Use Chrome DevTools for SEO Troubleshooting). Birbirinden bağımsız iki yazının aynı yönteme ulaşması, bunun tek seferlik değil, standart bir iş akışı olduğunu gösterir.

Oluşturma sürecini insanlara açıklama. JavaScript SEO guide yazımda oluşturma işlem hattını görünür kılmak için paneli kullanıyorum: “In Chrome Dev Tools, if you run a test on the ‘Performance’ tab, you get a loading chart.” Bu grafikte indirme, HTML ayrıştırma, JS yürütme, düzen ve boyama adımlarını göstermek; Googlebot’ın oluşturma işleminin tam bir tarayıcı boyamasının yaptığı her şeyi yapmadığını müşterilere ve iş arkadaşlarına açıklama biçimimdir. Bu ayrım, JS SEO sorunlarının teşhisinde merkezi önemdedir.

Oluşturmayı engelleyen üçüncü tarafları saptama ve düzen kaymasını teşhis etme diğer önemli kullanımlardır: ağ şelalesi ilk boyamayı neyin geciktirdiğini, iz ise (CLS metriğiyle birlikte) neyin ne zaman kaydığını gösterir.

Googlebot efsanesi (gerçekten içselleştirmeniz gereken nokta)

Tuzak şudur: “if it looks fine in my Performance panel, Googlebot sees it fine too.” Böyle bir sonuç çıkarılamaz. Panel, yerel ve tam özellikli Chrome’unuzu profiller. Googlebot, tam bir tarayıcının desteklediği her şeyi desteklemeyen ve farklı davranan (durumsuzdur, izin istemlerini reddeder vb. — bkz. tarama ve oluşturma) yakın tarihli ancak aynı olmayan bir Chromium derlemesi olan Web Rendering Service ile sayfaları oluşturur. Performance paneli, oluşturma davranışını anlamak ve teşhis etmek için mükemmeldir; gerçekte neyin taranıp dizine eklenebildiğini doğrulamanın yerini tutmaz. Bunun için Search Console’un URL Inspection aracını veya ham bir getirme işlemini kullanın.

Kısa bir ayrım notu

Performance paneli ile Performance monitor’ı karıştırmayın. Performance monitor, kaydedilmiş bir iz yerine gerçek zamanlı metriklerin (CPU kullanımı, JS heap, DOM düğümleri) canlı şeridini gösteren ayrı ve daha küçük bir DevTools özelliğidir. Aynı sözcük, farklı araç.

Yapay zekâ özeti

Advanced sürümünün kısa özeti:

• Nedir: Chrome DevTools Performance paneli, yerleşik ve yerel bir profil oluşturucudur. DevTools → Performance yolunu izleyin. Sayfanın nasıl yüklendiğini ve çalıştığını kaydeder; puan üretmez. Kaydedilen iz yerel laboratuvar kanıtıdır, ancak panel isteğe bağlı olarak CrUX alan verilerini yanında gösterebilir.
• Konumu: Lighthouse/PageSpeed Insights = puanlı otomatik denetim (+ CrUX alan verileri); WebPageTest = uzaktaki gerçek cihaz laboratuvarı; Performance paneli = kendi tarayıcınızdan alınan ham, etkileşimli iz.
• Canlı metrikler: açıldığında yerel LCP ve CLS’yi gösterir; etkileşim kurduğunuzda yerel INP de eklenir — kayıt almadan eksiksiz yerel Core Web Vitals.
• Kayıt: çalışma zamanı (sayfa zaten çalışıyor) ve yükleme (Start profiling and reload page; film şeridi için Screenshots açık).
• İzi okuma: ana iş parçacığı çalışmasının alev grafiği (daha geniş çubuk = daha uzun görev), FPS grafiği (kırmızı = takılma, hedef 60 FPS), CPU grafiği, Network şelalesi, Timings ve Bottom-up / Call Tree / Event Log analiz sekmeleri.
• Insights kenar çubuğu (bağımsız Performance Insights panelinin yerini aldı; panel Chrome 132’de kaldırıldı): LCP’nin 4 alt parçaya ayrılması, oluşturmayı engelleyen istekler, zorunlu yeniden akış ve üçüncü taraf maliyeti. Her içgörüyü nedenin kanıtı değil, yönlendirilmiş bir hipotez olarak ele alın; iz ve değişiklik öncesi/sonrası yeniden kayıtla doğrulayın.
• Kısıtlama, mutlak bir karşılaştırma ölçütü değil, makinenize göreli bir değerdir — hızlı bir dizüstündeki “4x” ≠ zayıf bir makinedeki “4x”.
• Laboratuvar ≠ alan: kaydedilen iz laboratuvar verisidir; Google, gerçek kullanıcı CrUX alan verilerine göre sıralama yapar. Yeniden tasarlanan panel, CrUX’u yerel sonuçlarınızın yanında gösterebilir (URL/kaynak, form faktörü ve dönem bakımından eşleştirilmiş olarak) — bu, gerçek kullanıcı kesiminin yaklaşık temsilidir; onu yeniden oluşturmaz.
• SEO kullanımları: tam LCP öğesini belirleme (Patrick’in slayt yöntemi, SEJ’den Richie Lauridsen tarafından da doğrulanmıştır), oluşturmayı engelleyen üçüncü tarafları saptama, düzen kaymasını teşhis etme ve oluşturmayı açıklama.
• Çürütülecek efsane: Googlebot’ın Web Rendering Service’ini değil, sizin tarayıcınızı gösterir — taranabilirliği DevTools ile değil, URL Inspection ile doğrulayın.

Resmî belgeler

Chrome DevTools ekibinin birincil kaynak belgeleri.

Chrome / Google

• Performance panel overview — nedir, nasıl açılır ve canlı yerel LCP/CLS/INP metrikleri.
• Analyze runtime performance — kayıt, alev grafiği, FPS/CPU ve çalışma zamanı-yükleme ayrımı.
• Performance features reference — Main izi, Bottom-up, Call Tree, Event Log ve kısıtlama tanımları.
• Performance insights (deprecation notice) — bağımsız panel Chrome 132’de kaldırıldı; yerine Performance > Insights’ı kullanın.
• LCP breakdown insight — LCP’nin TTFB, kaynak yükleme gecikmesi, kaynak yükleme süresi ve öğe oluşturma gecikmesine ayrılması.
• Render-blocking requests insight — ilk boyamayı geciktiren CSS/JS’yi belirleme.
• Monitor your local and real-user Core Web Vitals in DevTools — Rick Viscomi’nin yeniden tasarlanan açılış sayfası ve CrUX alan verisi katmanı hakkındaki yazısı.
• Performance tooling in 2024 and beyond — Elizabeth Sweeny ve Paul Irish’in Timeline → Performance tarihçesi ile Lighthouse/Insights’ın konumu hakkındaki yazısı.
• A 400% faster Performance panel — mühendislik derinlemesine incelemesi; panele etkin biçimde yatırım yapıldığının ve panelin sürümden sürüme değiştiğinin kanıtı.
• Performance monitor — ana Performance paneli değil, ayrı gerçek zamanlı metrik şeridi (ayrım notu).

Bing / Microsoft

• Chrome/Edge DevTools Performance paneline özgü Bing belgesi yoktur — bu bir arama motoru ürünü değil, tarayıcı aracıdır. Chromium tabanlı Edge, aynı Performance paneline sahip neredeyse özdeş bir DevTools sunduğundan buradaki her şey Edge için de geçerlidir.

Kaynaktan alıntılar

Chrome DevTools ekibinin ve sektör uygulayıcılarının kayda geçmiş açıklamaları. Her Chrome bağlantısı, alıntılanan bölüme götüren bir derin bağlantıdır.

Chrome DevTools — panelin ne olduğu ve nasıl okunacağı

• “Use the Performance panel to analyze your website’s performance.” / “The Performance panel lets you record CPU performance profiles of your web applications.” — Chrome DevTools belgeleri. Alıntıya git
• “When you open the Performance panel, it immediately captures and shows you your local Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) metrics.” / “If you interact with your page, the Performance panel also captures your local Interaction to Next Paint (INP).” Alıntıya git
• “Runtime performance is how your page performs when it is running, as opposed to loading.” / “DevTools shows you a flame chart of activity on the main thread, over time. The x-axis represents the recording, over time.” Alıntıya git
• “Whenever you see a red bar above FPS, it means that the framerate dropped so low that it’s probably harming the user experience.” Alıntıya git
• “Use the Main track to view activity that occurred on the page’s main thread.” / “Use the Bottom-up tab to view which activities directly took up the most time in aggregate.” / “Use the Call tree tab to view which root activities cause the most work.” Alıntıya git
• “Throttling is relative to your computer’s capabilities. For example, the 2x slowdown option makes your CPU operate 2 times slower than its usual ability.” Alıntıya git

Chrome DevTools — tarihçe ve güncellik notu

• “The Performance panel in Chrome DevTools has been helping developers measure and optimize their runtime performance in one form or another for the better part of 15 years.” / “Starting with a panel called ‘Timeline’, it evolved to the Performance panel you know today.” — Elizabeth Sweeny ve Paul Irish, Chrome DevTools ekibi. Alıntıya git
• “The Performance insights panel is deprecated and removed from DevTools starting with Chrome version 132. We recommend you use the Performance > Insights tab instead.” Alıntıya git
• “a completely redesigned Performance panel landing page featuring a live view of your local Core Web Vitals performance.” — Rick Viscomi, Chrome ekibi. Yazıyı okuyun

Sektör — SEO iş akışı

• “In hovering over the flag for LCP, we can actually see the piece of content flagged to be the largest contentful paint during the page load.” — Richie Lauridsen (Seer Interactive), Search Engine Journal. Makaleyi okuyun

Patrick Stox — panelin kullanımı

• “In Chrome Dev Tools, if you run a test on the ‘Performance’ tab, you get a loading chart.” — Googlebot’ın oluşturma işleminin tam bir tarayıcı boyamasından nasıl ayrıldığını açıklamak için Ahrefs’teki JavaScript SEO guide yazımda kullandım.

Hangi performans aracını kullanmalıyım?

Panel, çeşitli seçeneklerden biridir ve yanlış aracı seçmek zaman kaybettirir. Hızlı karar vermenin bir yolu:

Bir puana mı, teşhise mi ihtiyacınız var?

• Sıralama için bir puan / geçti-kaldı kararı → alan verileri gerekir: PageSpeed Insights veya Search Console’un Core Web Vitals raporu (CrUX). Performance paneli bunu sağlamaz.
• Bir sayfanın neden yavaş olduğunun teşhisi → devam edin.

Sayfaya herkese açık biçimde erişilebiliyor mu?

• Hayır (giriş arkasında, hazırlık ortamında veya localhost’ta) → aracınız Performance panelidir (veya DevTools içindeki Lighthouse); tarayıcınızda ne varsa onun üzerinde çalışır. PSI ve WebPageTest herkese açık bir URL gerektirir.
• Evet → Performance paneli de uzak bir araç da kullanılabilir; devam edin.

Paylaşılabilir, gerçek cihazdan alınmış ve tekrarlanabilir bir sonuca ihtiyacınız var mı?

• Evet (müşteri raporu, gerçek donanım, geçmiş eğilimi) → WebPageTest.
• Hayır — yalnızca işleyişi hemen görmeniz gerekiyor → Performance paneli.

Tam olarak neyi bulmaya çalışıyorsunuz?

• “LCP’m hangi öğe?” → Performance paneli: Screenshots’ı açın → Start profiling and reload page → zamanlama grafiğindeki LCP düğmesine tıklayın.
• “İlk boyamamı ne engelliyor / üçüncü taraf süresinin maliyeti nedir?” → Performance paneli → Insights kenar çubuğu (oluşturmayı engelleyen istekler, üçüncü taraf maliyeti).
• “Önceliklendirilmiş bir düzeltme listesi” → Lighthouse / PageSpeed Insights.
• “Googlebot gerçekte neyi tarayıp oluşturabilir?” → bu paneli kullanmayın — Search Console’un URL Inspection aracını kullanın.

Temel kural: Alan araçları bir sorununuz olup olmadığını ve sıralamayı etkileyip etkilemediğini söyler; Performance paneli ise tam işlev, istek ve öğeye kadar inerek nedeni açıklar.

Performance paneli kısa başvuru kılavuzu

Başlangıç

İzi okuma

LCP öğenizi bulun (SEO yöntemi)

1. Screenshots’ı açın.
2. Start profiling and reload page’e tıklayın.
3. Zamanlama grafiğinde işaretlenmiş LCP’yi bulun.
4. Düğüme tıklayın — DevTools tam LCP öğesini gösterir.

Hızlı bilgiler / yanılmamanız gerekenler

• Kaydedilen iz yerel laboratuvar verisidir — panel isteğe bağlı olarak alan verilerini yanında gösterebilse de Google’ın sıralamada kullandığı CrUX alan verisi değildir.
• Googlebot’ın Web Rendering Service’ini değil, sizin tarayıcınızı profiller.
• Bağımsız Performance Insights paneli Chrome 132’de kaldırıldı; içgörüler artık bu panelin Insights sekmesindedir.
• Kısıtlama çarpanları mutlak bir karşılaştırma ölçütü değil, makinenize görelidir.
• Ücretsizdir, yerleşiktir, hesap gerektirmez — aynı panel Chromium tabanlı Edge’de de bulunur.
• Performance monitor, bu panel değil, farklı bir özelliktir (canlı metrik şeridi).

Performance paneliyle profil oluşturma turu

Temiz ve yararlı bir kayıt elde etme:

• Uzantılar ana iş parçacığı izini kirlettiği için uzantıların devre dışı olduğu bir Incognito window’da test edin.
• Film şeridi elde etmek için yüklemeyi kaydetmeden önce Screenshots’ı açın.
• Kaydın yeniden üretilebilir ve sonraki kayıtla karşılaştırılabilir olması için Chrome sürümünü, tarihi, kısıtlama ayarlarını ve gelişmiş paint/CSS/sampling araçlarının açık olup olmadığını not edin.
• Yükleme performansını teşhis ederken, zaten yüklenmiş bir sayfada yalnızca “Record” kullanmak yerine tüm yükleme hikâyesi için Start profiling and reload page’i kullanın.
• Orta sınıf bir telefonu yaklaşık olarak temsil etmek için CPU throttling (yaygın olarak 4x) ve network throttling uygulayın; çarpanın makinenize göreli olduğunu unutmayın.
• Birkaç kez kayıt alın; yerel kayıtlar değişkenlik gösterir, bu nedenle tek bir çalıştırmayı kesin gerçek değil, örnek olarak değerlendirin.
• Insights kenar çubuğunu açın ve önce LCP breakdown bölümünü okuyun — sizi sunucu, kaynak yükleme veya oluşturma gecikmesi nedenlerine yönlendirir.
• Yöntemi kullanarak LCP düğmesine tıklayın ve gerçek LCP öğesini doğrulayın.
• Network izinde oluşturmayı engelleyen CSS/JS’yi ve ağır üçüncü taraf isteklerini kontrol edin.
• Bulduklarınızı alan verileriyle (PageSpeed Insights / Search Console CrUX) karşılaştırın — iyi bir yerel iz, alan puanının geçeceğini garanti etmez.
• Taranabilirlik/dizine eklenebilirlik sorularında URL Inspection’a geçin — Performance paneli “Googlebot ne görüyor?” sorusunu yanıtlamaz.

Performance paneli ve çevresindeki araçlar

Panel, yerel laboratuvar teşhis aracıdır. Diğer araçlara göre konumu şöyledir:

• Chrome DevTools Performance paneli — bu araç. Yerel, laboratuvar tabanlı ham iz; bir sayfanın neden yavaş olduğunu anlamak ve LCP öğesini belirlemek için en iyisidir.
• Lighthouse — DevTools içinde de çalışır; önceliklendirilmiş düzeltme listesi sunan puanlı, otomatik denetimdir.
• PageSpeed Insights — üstte CrUX alan verileri, altta Lighthouse laboratuvar çalıştırması; yalnızca herkese açık URL’lerde çalışır ve rakiplerde kullanılabilir.
• Chrome UX Report (CrUX) — Google’ın sıralamada gerçekten kullandığı gerçek kullanıcı alan veri kümesi; panel artık bunu yerel sonuçlarınızın yanında katman olarak gösterebilir.
• WebPageTest — uzaktan gerçek cihaz testi, paylaşılabilir sonuçlar ve çok adımlı betikler.
• Google Search Console — Core Web Vitals raporu — başarısız sayfa gruplarını geniş ölçekte gösterir (alan verileri).
• Search Console — URL Inspection — “Googlebot neyi tarayıp oluşturabilir?” sorusu için doğru araçtır (Performance paneli değil).
• Microsoft Edge DevTools — Edge/Bing odaklı iş akışları için aynı Chromium Performance paneli.

Bunların birlikte nasıl kullanıldığını — laboratuvar ile alan verileri arasındaki farkı ve Google’ın hangisini sıralamada kullandığını — öğrenmek için web performansı araçları merkezinden başlayın.

Bir izi boşa harcayan Performance paneli hataları

Tek bir kaydı alan verilerinin gerçeği saymak

Performance paneli tek bir yerel tarayıcıyı, cihazı, ağ profilini, önbellek durumunu ve yolculuğu kaydeder. Bir darboğazı açıklamak için paneli, bu darboğazın ne kadar yaygın olduğunu değerlendirmek içinse CrUX veya RUM’u kullanın.

Yeniden üretilebilir bir etkileşim olmadan kayıt almak

Ucu açık bir iz, ilgisiz etkinliklerle dolar. Yüklemeyi veya etkileşimi tanımlayın, aynı durumdan başlayın ve yalnızca onu yakalayacak kadar uzun kayıt alın.

Alev grafiğini ağ ve kare izleri olmadan okumak

Uzun bir görev, ilk neden değil bir sonuç olabilir. Sorumluluk atamadan önce ana iş parçacığı çalışmalarını istekler, etkileşimler, ekran görüntüleri ve boyamalarla hizalayın.

Ağır kısıtlama uygulayıp sonucu karşılaştırma ölçütü saymak

Kısıtlama, darboğazları ortaya çıkarmaya yardımcı olur; ancak sonucu bir laboratuvar senaryosudur. Önce/sonra karşılaştırmalarında ayarları aynı tutun ve sonuçları paylaşırken bu ayarları etiketleyin.

Yaygın Performance paneli sorunlarını düzeltme

İz okunamayacak kadar gürültülü

Olası neden: Uzantılar, arka plan sekmeleri veya gereğinden uzun bir kayıt ilgisiz işler ekler. Düzeltme: Temiz bir profil kullanın, arka plan etkinliklerini kapatın ve tanımlanmış tek bir yolculuğu yakalayın. Doğrulama: İlgili etkileşim veya yükleme, izin kısa ve kolayca tanınan bir bölümünü kaplar.

Etkileşim yavaş geliyor ancak belirgin bir olay görünmüyor

Olası neden: Kayıt, girdiden boyamaya kadar olan pencerenin tamamını içermiyordur veya yanlış iz genişletilmiştir. Düzeltme: Tam tıklama, dokunma veya tuş etkileşimini yeniden kaydedin; Interactions ile ana iş parçacığı çalışmalarını inceleyin. Doğrulama: Seçilen olay girdi gecikmesini, işlemeyi ve sunum çalışmasını ortaya çıkarır.

Sonuç çalıştırmalar arasında büyük ölçüde değişiyor

Olası neden: Önbellek durumu, ağ değişkenliği, arka plan çalışmaları veya test kurulumu farklıdır. Düzeltme: Yeniden yükleme modunu, kısıtlamayı, görüntü alanını ve yolculuğu standartlaştırın; ardından testi birkaç kez çalıştırın. Doğrulama: Toplam süre değişse bile aynı darboğaz görünür.

Panel iyi laboratuvar vitalleri gösteriyor ancak Search Console sonucu kötü

Olası neden: Yerel iz, gerçek kullanıcıları veya daha uzun yolculukları temsil etmiyordur. Düzeltme: CrUX veya RUM’u bölümlere ayırın, etkilenen cihazı ve etkileşimi yeniden üretin, teşhis için paneli kullanın. Doğrulama: İz, alan toplamıyla çelişmek yerine yavaş kesimi açıklar.

İz odaklı bir düzeltmenin işe yaradığını kanıtlama

Tekrarlanan yolculuk testi

Çalıştırılacak test: Değişiklikten önce ve sonra aynı yüklemeyi veya etkileşimi aynı önbellek, görüntü alanı ve kısıtlama ayarlarıyla kaydedin. Beklenen sonuç: Hedeflenen istek, görev veya oluşturma aşaması tutarlı biçimde küçülür. Başarısızlığın yorumu: Sonucu, çalıştırmalar arası değişkenlik veya farklı bir darboğaz açıklıyordur. İzleme süresi: Birkaç kayıt boyunca hemen. Geri alma tetikleyicisi: Hatalar, eksik işler veya daha kötü görsel davranış ortaya çıkar.

Ana iş parçacığı testi

Çalıştırılacak test: Seçilen ana iş parçacığı görevini ve alt görevlerini iki izde karşılaştırın. Beklenen sonuç: Kaldırılan veya ertelenen çalışma yalnızca yeniden adlandırılmış ya da daha erkene taşınmış olmamalı; kritik aralıkta bulunmamalıdır. Başarısızlığın yorumu: Uygulama aynı maliyeti başka bir yere taşımıştır. İzleme süresi: Hemen. Geri alma tetikleyicisi: Kullanıcı eylemi çevresindeki toplam engelleme artar.

Alan verilerine devir testi

Çalıştırılacak test: Laboratuvar başarısından sonra değiştirilen şablonu veya etkileşimi RUM’da izleyin. Beklenen sonuç: Etkilenen alan metriği ve ilişkilendirme, hedeflenen kesimde iyileşir. Başarısızlığın yorumu: Yerel senaryo temsil edici değildir. İzleme süresi: Trafik geldikçe RUM; hareketli alan penceresi boyunca CrUX. Geri alma tetikleyicisi: Alan performansı veya görev tamamlama oranı tutarlı biçimde kötüleşir.

Kendinizi sınayın: Chrome DevTools Performance Paneli

Performance panelinin ne olduğu, nasıl okunduğu ve ne olmadığı hakkında beş kısa soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Zaman ayırmaya değer kaynaklar

Yazılarım

• JavaScript SEO: What You Need to Know — Googlebot’ın oluşturma işleminin tam bir tarayıcı boyamasından nasıl ayrıldığını açıklamak için Performance sekmesindeki yükleme grafiğini kullandığım yazı.
• Google PageSpeed Insights for SEOs & Developers — DevTools’dan aldığınız ham izi tamamlayan, alan ve laboratuvar verilerini birleştiren puanlı araç.
• The Beginner’s Guide to Technical SEO — performans ve oluşturmanın büyük resimdeki yerini anlatan yazı.

Konuşmalarım

• Page Experience Update (TMC, June 2021) (SlideShare) — “How to see the LCP element in DevTools” yöntemini adım adım içerir.
• What’s Next for Page Experience (SMX Next 2021) (SlideShare) — aynı dönemde yaptığım sayfa deneyimi konuşması.

Sektörden kaynaklar

• Performance panel overview (Chrome for Developers) — temel başlangıç noktası: nedir, nasıl açılır ve canlı metrikler.
• Analyze runtime performance (Chrome for Developers) — alev grafiği, FPS/CPU ve kayıt anlatımı.
• Monitor your local and real-user Core Web Vitals in DevTools (Rick Viscomi, Chrome) — yeniden tasarlanan açılış sayfası ve CrUX alan verisi katmanı.
• Performance tooling in 2024 and beyond (Sweeny & Irish, Chrome) — Timeline → Performance tarihçesi ve Lighthouse/Insights ilişkisi.
• 3 Ways to Use Chrome DevTools for SEO Troubleshooting (Richie Lauridsen, Search Engine Journal) — LCP bulma tekniğini de içeren, SEO açısından çerçevelenmiş en yakın mevcut anlatım.
• Profile Site Speed With The DevTools Performance Tab (DebugBear) — SEO dışındaki en derin teknik anlatım: zorunlu yeniden akışta hata ayıklama, katman analizi ve daha net görmek için kısıtlama.
• Chrome DevTools for Debugging Web Performance (Web Performance Calendar, 2025) — panelin iş akışına ilişkin güncel, yeniden tasarım sonrası topluluk perspektifi.

Değişiklik günlüğü