Performans Analizleri
React Performans Analizleri -2 (Initial Loading)
Chrome DevTool kullanarak Web Sayfasının ilk yüklenme sürecini analiz etmeye, buradaki metrikleri nasıl okumamız gerektiğini anlatmaya çalışacağım.
Performans Analizleri Serimize kaldığımız yerden devam ediyorum. Burada amacım Web Vitals metriklerini daha iyi anlamak ve Chrome DevTools aracılığı ile etkilerini analiz etmek.
Öncelikle Web Vitals kavramını bir hatırlayalım. Bunun için daha önceden yazmış olduğum aşağıdaki blog yazısını okuyabilirsiniz.
Bu metrikler web sayfasının ilk yüklenmesi, ilk etkileşime geçilmesi sırasında geçen sürelerdir. Bu konuları aşağıda özetliyor olacağım fakat daha detaylı ve derinlemesine konuyu öğrenmek için, aşağıdaki E-Kitap da tarayıcıların bu durumları nasıl ele aldığını detaylı olarak anlatılmaktadır.
Kullanıcı URL alanına girip enter düğmesine basması veya bir linke tıklayıp redirect edilmesi sonrasında Navigation ve Rendering nasıl çalıştığı detaylı bir şekilde anlatılıyor.
Web Vitals
Bir URL gitmek için domain adını yazıp, enter bastığınızda veya bir linke tıklayıp ilgili sayfaya gittiğinizde sunucudan ilk byte gelmesi için geçen süre gerçekleşir.
Time to First Byte (TTFB): tarayıcının bir isteği sunucuya göndermesi ile, sunucudan ilk bayt verinin geri gelmesi arasında geçen süredir. İstek → Sunucu → İlk cevap bu sürenin ölçümüdür.
Kullanıcılar bir siteyi açmaya çalıştıklarında, sunucudan hızlı bir yanıt gelmezse sayfanın diğer CSS, HTML , JS ve sonrasındaki Data Fetching işlemlerinin gecilebileceği konusunda ilk sinyal kontrolü diyebiliriz.
Bunun birçok nedeni olmuş olabilir. Web Performance API’de ilk Byte neden geç geldiğini ile ilgili detaylı bilgiye erişebilirsiniz.
Örneğin bir css resource erişme sırasında yolda geçen zaman, benzerini index.html, js ve diğer resource içinde düşünebilirsiniz.
Şimdi örneğimizde bu durumu simüle edip sonuçlarını DevTools üzerinden analiz edelim .
// Bad TTFB (delay before sending first byte)
app.get("/ttfb-bad", async (c) => {
await sleep(3000); // Simulate 3 second backend delay
return c.text("Slow TTFB response after delay");
});Burada sunucuyu bekletiyoruz ki ilk byte geç ulaşsın. Performans tabına geldiğimizde 3 sn den sonra cevabın geldigini görebilirsiniz.
Bu durum Lighthouse bütün FCP (İlk İçerik Boyama), LCP(Geniş İçerik Boyama) skorları kötü verdi.
Bunun nedeni aslında LCP → FCP bağımlı olması, FCP’nin de TTBF bağımlı olmasından kaynaklıdır.
Özetle sunucu hızlı cevap verecek TTBF (index.html), kullanının anlamlı olarak görebileceği basit de template FCP(index.html uyumlu css olabilir) sonrasında da ilk basit JS ler spinner ve sonrasında da gerçek gösterilmesi gereken resim ve görseller yani tüm ekran LCP aşaması geliyor.
Bu son oluşacak içeriğin geç gelmesini sağlayalım. Önce resim yerinde Loading… gözükecek
app.get("/lcp-bad", async (c) => {
return c.html(`
<html>
<body>
<h1>Bad LCP</h1>
<img id="hero" src="https://placehold.co/800x400?text=Loading..." alt="Hero Placeholder" />
<script>
setTimeout(() => {
const img = document.getElementById('hero');
img.src = 'https://placehold.co/800x400?text=Loaded+Image';
}, 6000);
</script>
</body>
</html>
`);
});Sonrasında JS işletilerek gerçek resim gösterilecek. Burada bir 6 saniyelik bekletme yapıyoruz.
Bunun haricinde CLS (Cumulative Layout Shift) şeklinde bir kavram var. Bu da sayfa yüklenirken gerçekleşen kayma ve hareketleri ölçümler, bunun fazla olması kullanıcıyı rahatsız edecektir.
Aşağıdaki kod örneğinde 0.5s aralıklar ile sayfanın en başında alt alta dikdörtgenler eklenmektedir.
// CLS: Simulated layout shift
app.get("/cls-bad", (c) => {
return c.html(`
<html>
<head>
<style>
body {
font-family: sans-serif;
margin: 0;
padding: 0;
}
.content {
padding: 16px;
}
.shift-box {
width: 100%;
height: 100px;
background: lightcoral;
margin-bottom: 16px;
}
</style>
</head>
<body>
<div class="content">
<h1>Watch this page jump!</h1>
<p>This is a test for the worst CLS ever.</p>
<div id="container"></div>
</div>
<script>
const container = document.getElementById('container');
let count = 0;
const createShiftingBlock = () => {
const box = document.createElement('div');
box.className = 'shift-box';
container.prepend(box); // Insert at top: causes layout shift
};
// Add shifting blocks multiple times
const interval = setInterval(() => {
createShiftingBlock();
count++;
if (count > 10) clearInterval(interval);
}, 500); // Shift every 500ms
</script>
</body>
</html>
`);
});Bu durum CLS değerini arttırmaktadır. Aşağıdaki resimden görebileceğiniz gibi CLS değeri 0.39 değerine gelmiştir.
Birde UI kullanıcının etkileşimine ilk verdiği tepki süresi var. Buna INP(Interaction Next Paint) adı veriliyor. Özellikle SSR gibi Server Side Rendering ile gerçekleşen HTML oluşumları UI kısmında hydrate edilirken gecikmeden kaynaklı bu durumlar yaşanabilir.
Aşağıdaki örnekte bir düğme oluşturulup, click event geç ekleniyor.
app.get('/inp-bad', (c) => {
return c.html(`
<html>
<head>
<style>
body {
font-family: sans-serif;
padding: 2rem;
}
button {
font-size: 1.2rem;
padding: 1rem 2rem;
}
</style>
</head>
<body>
<h1>Bad INP Example</h1>
<p>Click the button and notice how long it takes to respond.</p>
<button id="freeze">Click Me</button>
<div id="result"></div>
<script>
function blockMainThread(ms) {
const start = performance.now();
while (performance.now() - start < ms) {
// Blocking loop
}
}
document.getElementById('freeze').addEventListener('click', () => {
blockMainThread(3000); // Simulate 3s delay
document.getElementById('result').textContent = 'You clicked!';
});
</script>
</body>
</html>
`);
});Bu kodun Performansını analiz ettiğimiz zaman INP süresinin çok uzadığını click etkileşimine çok geç tepki verdiğini görebiliyoruz.
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
