Saatin Ötesinde: Web Performansı API'lerini Gerçek Kullanıcı Deneyimine Bağlamak

Dijital ekonomide hız sadece bir özellik değil, kullanıcı deneyiminin temelidir. Yavaş bir web sitesi, hayal kırıklığına uğramış kullanıcılara, daha yüksek hemen çıkma oranlarına ve gelir üzerinde doğrudan bir etkiye yol açabilir. Yıllardır geliştiriciler, performansı ölçmek için window.onload gibi zamanlama metriklerine güveniyorlar. Peki hızlı bir yükleme süresi gerçekten mutlu bir kullanıcıya mı eşit? Cevap genellikle hayır.

Bir sayfa tüm teknik kaynaklarını bir saniyeden kısa sürede yüklemeyi bitirebilir, ancak etkileşim kurmaya çalışan gerçek bir kişi için yavaş ve kullanılamaz hissedilir. Bu kopukluk, web geliştirmede kritik bir evrimi vurgulamaktadır: teknik zamanlamaları ölçmekten insan deneyimini ölçmeye geçiş. Modern web performansı iki perspektifin hikayesidir: Web Performansı API'leri tarafından sağlanan ayrıntılı, düşük seviyeli veriler ve Google'ın Temel Web Verileri gibi üst düzey, kullanıcı merkezli metrikler.

Bu kapsamlı kılavuz bu boşluğu dolduracaktır. Tanı araçlarımız olarak işlev gören güçlü Web Performansı API'leri paketini keşfedeceğiz. Ardından, performansın nasıl *hissedildiğini* bize söyleyen modern kullanıcı deneyimi metriklerini inceleyeceğiz. En önemlisi, düşük seviyeli zamanlama verilerini kullanarak küresel hedef kitleniz için kötü bir kullanıcı deneyiminin temel nedenlerini nasıl teşhis edip düzeltebileceğinizi göstererek noktaları birleştireceğiz.

Temel: Web Performansı API'lerini Anlamak

Web Performansı API'leri, geliştiricilere bir web sayfasının navigasyonu ve işlenmesiyle ilgili son derece ayrıntılı ve doğru zamanlama verilerine erişim sağlayan bir dizi standartlaştırılmış tarayıcı arabirimidir. Basit kronometrelerin ötesine geçmemizi ve ağ isteklerinin, ayrıştırmanın ve işlemenin karmaşık dansını anlamamızı sağlayan performans ölçümünün temelidirler.

Navigasyon Zamanlaması API'si: Sayfanın Yolculuğu

Navigasyon Zamanlaması API'si, ana belgenin yüklenmesinin ne kadar sürdüğünün ayrıntılı bir dökümünü sağlar. Bir kullanıcının navigasyonu başlattığı andan (bir bağlantıyı tıklamak gibi) sayfanın tamamen yüklendiği ana kadar olan kilometre taşlarını yakalar. Bu, sayfa yükleme işlemine ilk ve en temel bakışımızdır.

Bu verilere basit bir JavaScript çağrısıyla erişebilirsiniz:

const navigationEntry = performance.getEntriesByType('navigation')[0]; console.log(navigationEntry.toJSON());

Bu, zaman damgalarıyla dolu bir nesne döndürür. Bazı önemli özellikler şunlardır:

• fetchStart: Tarayıcı belgenin getirilmesini ne zaman başlatır.
• responseStart: Tarayıcı sunucudan yanıtın ilk baytını ne zaman alır. fetchStart ve responseStart arasındaki süre genellikle İlk Bayta Kadar Geçen Süre (TTFB) olarak adlandırılır.
• domContentLoadedEventEnd: Stil sayfaları, resimler ve alt çerçevelerin yüklenmesini beklemeden, ilk HTML belgesi tamamen yüklendiğinde ve ayrıştırıldığında.
• loadEventEnd: Sayfadaki tüm kaynaklar (resimler, CSS vb. dahil) tamamen yüklendiğinde.

Uzun bir süre boyunca, loadEventEnd altın standarttı. Ancak, sınırlaması çok ciddi: kullanıcının ne zaman anlamlı içeriği *gördüğü* veya sayfayla ne zaman *etkileşimde bulunabileceği* hakkında hiçbir şey söylemiyor. Teknik bir kilometre taşıdır, insani bir kilometre taşı değildir.

Kaynak Zamanlaması API'si: Bileşenlerin Yapısını Çözmek

Bir web sayfası nadiren tek bir dosyadır. HTML, CSS, JavaScript, resimler, yazı tipleri ve API çağrılarının bir araya getirilmesidir. Kaynak Zamanlaması API'si, bu bireysel kaynakların her biri için ağ zamanlamasını incelemenizi sağlar.

Bu, darboğazları belirlemek için inanılmaz derecede güçlüdür. Başka bir kıtadaki bir İçerik Dağıtım Ağından (CDN) gelen büyük, optimize edilmemiş bir kahraman resmi ilk işlemeyi yavaşlatıyor mu? Üçüncü taraf bir analiz komut dosyası ana iş parçacığını engelliyor mu? Kaynak Zamanlaması bu soruları yanıtlamanıza yardımcı olur.

Şuna benzer şekilde tüm kaynakların bir listesini alabilirsiniz:

const resourceEntries = performance.getEntriesByType('resource'); resourceEntries.forEach(resource => { if (resource.duration > 200) { // 200 ms'den uzun süren kaynakları bulun console.log(`Yavaş kaynak: ${resource.name}, Süre: ${resource.duration}ms`); } });

Önemli özellikler arasında name (kaynağın URL'si), initiatorType (kaynağın yüklenmesine neyin neden olduğu, örneğin 'img', 'script') ve duration (getirilmesinin toplam süresi) bulunur.

Kullanıcı Zamanlaması API'si: Uygulamanızın Mantığını Ölçmek

Bazen, performans darboğazı varlıkları yüklemede değil, istemci tarafı kodun kendisindedir. Tek sayfalık uygulamanızın (SPA), bir API'den veri alındıktan sonra karmaşık bir bileşeni işlemesi ne kadar sürer? Kullanıcı Zamanlaması API'si, özel, uygulamaya özel ölçümler oluşturmanıza olanak tanır.

İki ana yöntemle çalışır:

• performance.mark(name): Performans arabelleğinde adlandırılmış bir zaman damgası oluşturur.
• performance.measure(name, startMark, endMark): İki işaret arasındaki süreyi hesaplar ve adlandırılmış bir ölçüm oluşturur.

Örnek: Bir ürün listesi bileşeninin işleme süresini ölçmek.

// Veri getirmeye başladığınızda performance.mark('product-list-fetch-start'); fetch('/api/products') .then(response => response.json()) .then(data => { // Getirdikten sonra, işlemeden önce performance.mark('product-list-render-start'); renderProductList(data); // İşleme tamamlandıktan hemen sonra performance.mark('product-list-render-end'); // Bir ölçü oluşturun performance.measure( 'Ürün Listesi İşleme Süresi', 'product-list-render-start', 'product-list-render-end' ); });

Bu, uygulamanızın kullanıcının iş akışı için en kritik olan parçalarını ölçmek için size kesin kontrol sağlar.

PerformanceObserver: Modern, Verimli Yaklaşım

`performance.getEntriesByType()` öğesini sürekli olarak yoklamak verimsizdir. `PerformanceObserver` API'si, performans girişlerini dinlemenin çok daha iyi bir yolunu sunar. Belirli giriş türlerine abone olursunuz ve tarayıcı kaydedildikçe geri arama işlevinizi eşzamansız olarak bilgilendirir. Bu, uygulamanıza yük eklemeden performans verilerini toplamanın önerilen yoludur.

const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { console.log(`Giriş Türü: ${entry.entryType}, Ad: ${entry.name}`); } }); observer.observe({ entryTypes: ['resource', 'navigation', 'mark', 'measure'] });

Bu gözlemci, yalnızca yukarıdaki geleneksel metrikleri değil, aynı zamanda bir sonraki tartışacağımız modern, kullanıcı merkezli metrikleri toplamanın anahtarıdır.

Kullanıcı Merkezliliğe Geçiş: Temel Web Verileri

Bir sayfanın 2 saniyede yüklendiğini bilmek yararlıdır, ancak şu önemli soruları yanıtlamaz: Kullanıcı o 2 saniye boyunca boş bir ekrana mı bakıyordu? Sayfayla etkileşim kurabiliyorlar mıydı, yoksa donmuş muydu? Okumaya çalışırken içerik beklenmedik bir şekilde etrafta mı zıpladı?

Bunu ele almak için Google, bir sayfanın gerçek dünyadaki kullanıcı deneyimini üç temel boyutta ölçmek için tasarlanmış bir metrik seti olan Temel Web Verilerini (CWV) tanıttı: yükleme, etkileşim ve görsel kararlılık.

En Büyük İçerikli Boya (LCP): Algılanan Yüklemeyi Ölçmek

LCP, görüntü alanında görünen en büyük resmin veya metin bloğunun işleme süresini ölçer. Kullanıcının sayfanın ana içeriğinin yüklendiğini hissettiği zaman için mükemmel bir vekildir. Kullanıcının "Bu sayfa henüz yararlı mı?" sorusunu doğrudan yanıtlar.

• İyi: 2,5 saniyenin altında
• İyileştirme Gerekiyor: 2,5 sn ile 4,0 sn arasında
• Kötü: 4,0 saniyenin üzerinde

`loadEventEnd`'in aksine, LCP kullanıcının ilk gördüğüne odaklanır ve bu da onu algılanan yükleme hızının çok daha doğru bir yansıması yapar.

Sonraki Boyaya Etkileşim (INP): Yanıt Verilebilirliği Ölçmek

INP, İlk Giriş Gecikmesinin (FID) halefidir ve Mart 2024'te resmi bir Temel Web Verisi haline geldi. FID yalnızca *ilk* etkileşimin gecikmesini ölçerken, INP sayfanın yaşam döngüsü boyunca *tüm* kullanıcı etkileşimlerinin (tıklamalar, dokunmalar, tuş vuruşları) gecikmesini ölçer. Bir kullanıcının yaşadığı en kötü durumdaki yanıt verebilirliği etkili bir şekilde tanımlayarak en uzun etkileşimi rapor eder.

INP, kullanıcının girişinden bir sonraki karenin boyanmasına kadar geçen tüm süreyi ölçer ve görsel geri bildirimi yansıtır. Kullanıcının "Bu düğmeyi tıkladığımda, sayfa hızlı yanıt veriyor mu?" sorusunu yanıtlar.

• İyi: 200 milisaniyenin altında
• İyileştirme Gerekiyor: 200 ms ile 500 ms arasında
• Kötü: 500 ms'nin üzerinde

Yüksek INP genellikle meşgul bir ana iş parçacığından kaynaklanır ve uzun süren JavaScript görevleri tarayıcının kullanıcı girişine yanıt vermesini engeller.

Kümülatif Düzen Kayması (CLS): Görsel Kararlılığı Ölçmek

CLS, bir sayfanın görsel kararlılığını ölçer. Yükleme işlemi sırasında içeriğin ekranda ne kadar beklenmedik bir şekilde hareket ettiğini ölçer. Yüksek bir CLS puanı, bir düğmeyi tıklamaya çalıştığınızda, ancak yukarıda bir reklam yüklendiğinde, düğmeyi aşağı ittiğinde ve bunun yerine reklamı tıklamanıza neden olduğunda olduğu gibi, yaygın bir kullanıcı hayal kırıklığı kaynağıdır.

CLS, kullanıcının "Bu sayfayı öğelerin her yere atlamadan kullanabilir miyim?" sorusunu yanıtlar.

• İyi: 0,1'in altında
• İyileştirme Gerekiyor: 0,1 ile 0,25 arasında
• Kötü: 0,25'in üzerinde

Yüksek CLS'nin yaygın nedenleri arasında boyutları olmayan resimler veya iframe'ler, geç yüklenen web yazı tipleri veya sayfa için yer ayırmadan sayfaya dinamik olarak içerik enjekte edilmesi bulunur.

Boşluğu Doldurmak: Kötü Kullanıcı Deneyimini Teşhis Etmek için API'leri Kullanmak

İşte her şeyin bir araya geldiği yer. Temel Web Verileri bize kullanıcının *neyi* deneyimlediğini söyler (örneğin, yavaş bir LCP). Web Performansı API'leri bize *neden* olduğunu söyler. Bunları birleştirerek, performansı basitçe gözlemlemekten aktif olarak teşhis etmeye ve düzeltmeye dönüşüyoruz.

Yavaş Bir LCP'yi Teşhis Etmek

Gerçek Kullanıcı İzleme (RUM) aracınız, belirli bir bölgedeki kullanıcılar için 4,5 saniyelik kötü bir LCP bildirdiğini varsayalım. Bunu nasıl düzeltirsiniz? LCP süresini kurucu parçalarına ayırmanız gerekir.

1. İlk Bayta Kadar Geçen Süre (TTFB): Sunucunun yanıt vermesi yavaş mı? Navigasyon Zamanlaması API'sini kullanın. `responseStart - requestStart` süresi size kesin bir TTFB verir. Bu yüksekse, sorun ön uçta değil, arka ucunuzda, sunucu yapılandırmanızda veya veritabanınızdadır.
2. Kaynak Yükleme Gecikmesi ve Süresi: LCP öğesinin kendisi yavaş mı yükleniyor? İlk olarak, LCP öğesini (örneğin, bir kahraman resmi) tanımlayın. Öğenin kendisini almak için `'en-büyük-içerikli-boya'` için bir `PerformanceObserver` kullanabilirsiniz. Ardından, bu öğenin URL'si için girişi bulmak için Kaynak Zamanlaması API'sini kullanın. Zaman çizelgesini analiz edin: `connectStart`'tan `connectEnd`'e uzun bir süre var mıydı (yavaş ağ)? `responseStart`'tan `responseEnd`'e uzun bir süre var mıydı (büyük bir dosya boyutu)? CSS veya JavaScript gibi diğer işlemeyi engelleyen kaynaklar tarafından engellendiği için `fetchStart`'ı gecikti mi?
3. Öğe İşleme Gecikmesi: Bu, kaynağın yüklenmeyi bitirdikten sonra ekranda gerçekten boyanana kadar geçen süredir. Bunun nedeni, ana iş parçacığının büyük bir JavaScript paketi yürütmek gibi diğer görevlerle meşgul olması olabilir.

Navigasyon ve Kaynak Zamanlamasını kullanarak, yavaş bir LCP'nin yavaş bir sunucudan, işlemeyi engelleyen bir komut dosyasından veya büyük, optimize edilmemiş bir resimden kaynaklanıp kaynaklanmadığını belirleyebilirsiniz.

Kötü INP'yi Araştırmak

Kullanıcılarınız "Sepete Ekle" düğmesini tıklamanın gecikmeli hissettirdiğinden şikayet ediyor. INP metriğiniz "Kötü" aralığında. Bu neredeyse her zaman bir ana iş parçacığı sorunudur.

1. Uzun Görevleri Tanımlayın: Uzun Görevler API'si buradaki birincil aracınızdır. Ana iş parçacığında 50 ms'den uzun süren herhangi bir görevi bildirir, çünkü daha uzun herhangi bir şey kullanıcının fark edilebilir gecikmesi riskini taşır. `'longtask'` girişlerini dinlemek için bir `PerformanceObserver` ayarlayın.
2. Kullanıcı Eylemleriyle İlişkilendirin: Kullanıcı etkileşimde bulunmaya çalışırken meydana gelirse, uzun bir görev yalnızca bir sorundur. `'event'` türündeki `PerformanceObserver` aracılığıyla gözlemlenen bir INP olayının `startTime`'ını, aynı zamanlarda meydana gelen herhangi bir uzun görevin zamanlamalarıyla ilişkilendirebilirsiniz. Bu, kullanıcının etkileşimini tam olarak hangi JavaScript işlevinin engellediğini size söyler.
3. Belirli İşleyicileri Ölçün: Daha da ayrıntılı bilgi almak için Kullanıcı Zamanlaması API'sini kullanın. Kritik olay işleyicilerinizi ("Sepete Ekle" için 'tıklama' işleyicisi gibi) `performance.mark()` ve `performance.measure()` ile sarın. Bu, kendi kodunuzun yürütülmesinin tam olarak ne kadar sürdüğünü ve uzun görevin kaynağı olup olmadığını size söyleyecektir.

Yüksek CLS ile Mücadele Etmek

Kullanıcılar, mobil cihazlarında bir makale okurken metnin etrafta zıpladığını bildiriyor. CLS puanınız 0,3.

1. Düzen Kaymalarını Gözlemleyin: `'layout-shift'` girişlerini dinlemek için bir `PerformanceObserver` kullanın. Her girişin bir `değeri` (CLS puanına katkısı) ve taşınan DOM öğeleri olan bir `kaynak` listesi olacaktır. Bu size *neyin* taşındığını söyler.
2. Suçlu Kaynağı Bulun: Bir sonraki soru, *neden* taşındığıdır. Yaygın bir neden, geç yüklenen ve diğer içeriği aşağı iten bir kaynaktır. Bir `layout-shift` girişinin `startTime`'ını Kaynak Zamanlaması API'sinden girişlerin `responseEnd` süresiyle ilişkilendirebilirsiniz. Bir düzen kayması, bir reklam komut dosyası veya büyük bir resim yüklemeyi bitirdikten hemen sonra gerçekleşirse, muhtemelen suçluyu bulmuşsunuzdur.
3. Proaktif Çözümler: Düzeltme genellikle resimler ve reklamlar için boyutlar sağlamayı (``) veya yüklenmeden önce dinamik içerik için sayfada yer ayırmayı içerir. Kaynak Zamanlaması, proaktif olmanız gereken kaynakları belirlemenize yardımcı olur.

Pratik Uygulama: Küresel Bir İzleme Sistemi Oluşturmak

Bu API'leri anlamak bir şeydir; bunları küresel kullanıcı tabanınızın deneyimini izlemek için dağıtmak bir sonraki adımdır. Bu, Gerçek Kullanıcı İzleme (RUM) alanıdır.

`PerformanceObserver` ile Her Şeyi Bir Araya Getirmek

Tüm bu önemli verileri toplamak için tek, güçlü bir komut dosyası oluşturabilirsiniz. Amaç, ölçmeye çalıştığınız performansı etkilemeden metrikleri ve bağlamlarını toplamaktır.

Sağlam bir gözlemci kurulumunun kavramsal bir parçacığı aşağıdadır:

const collectedMetrics = {}; const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { if (entry.entryType === 'largest-contentful-paint') { collectedMetrics.lcp = entry.startTime; } else if (entry.entryType === 'layout-shift') { collectedMetrics.cls = (collectedMetrics.cls || 0) + entry.value; } else if (entry.entryType === 'event') { // Bu, INP hesaplamasının basitleştirilmiş bir görünümüdür const duration = entry.duration; if (duration > (collectedMetrics.inp || 0)) { collectedMetrics.inp = duration; } } // ... ve 'longtask' gibi diğer giriş türleri için de aynı şekilde } }); observer.observe({ entryTypes: ['largest-contentful-paint', 'layout-shift', 'event', 'longtask'] });

Verileri Güvenilir Bir Şekilde Göndermek

Verilerinizi topladıktan sonra, depolama ve analiz için bir analiz arka ucuna göndermeniz gerekir. Sayfa kaldırmalarını geciktirmeden veya sekmelerini hızlı bir şekilde kapatan kullanıcılardan veri kaybetmeden bunu yapmak çok önemlidir.

`navigator.sendBeacon()` API'si bunun için mükemmeldir. Sayfa kaldırılıyor olsa bile, sunucuya az miktarda veri göndermenin güvenilir, eşzamansız bir yolunu sağlar. Bir yanıt beklemez, bu da onu hafif ve engellenmeyen hale getirir.

window.addEventListener('visibilitychange', () => { if (document.visibilityState === 'hidden') { const payload = JSON.stringify(collectedMetrics); navigator.sendBeacon('/api/performance-analytics', payload); } });

Küresel Bir Görünümün Önemi

Lighthouse gibi laboratuvar test araçları çok değerlidir, ancak kontrollü bir ortamda çalışırlar. Bu API'lerden toplanan RUM verileri, farklı ülkeler, ağ koşulları ve cihazlardaki kullanıcılarınızın deneyimlediği gerçeği size söyler.

Verilerinizi analiz ederken, her zaman bölümlere ayırın. Şunları keşfedebilirsiniz:

• LCP'niz Kuzey Amerika'daki kullanıcılar için mükemmel, ancak birincil görüntü sunucunuz ABD'de bulunduğu için Avustralya'daki kullanıcılar için kötü.
• INP'niz, JavaScript'iniz onlar için çok CPU yoğun olduğu için gelişmekte olan pazarlarda popüler olan orta sınıf Android cihazlarda yüksek.
• CLS'niz yalnızca bir CSS medya sorgusunun bir reklamın yanlış şekilde yeniden boyutlandırılmasına neden olduğu belirli ekran boyutlarında bir sorundur.

Bu düzeyde bölümlenmiş içgörü, gerçek kullanıcı tabanınız üzerinde en önemli etkiye sahip olacak optimizasyonlara öncelik vermenizi sağlar, nerede olurlarsa olsunlar.

Sonuç: Ölçümden Uzmanlığa

Web performansı dünyası olgunlaştı. Basit teknik zamanlamalardan, kullanıcının algılanan deneyiminin karmaşık bir anlayışına geçtik. Yolculuk üç temel adım içerir:

1. Deneyimi Ölçün: Temel Web Verilerini (LCP, INP, CLS) toplamak için `PerformanceObserver` kullanın. Bu size *ne* olduğunu ve kullanıcıya *nasıl hissettirdiğini* söyler.
2. Nedeni Teşhis Edin: Daha derine inmek için temel Zamanlama API'lerini (Navigasyon, Kaynak, Kullanıcı, Uzun Görevler) kullanın. Bu size deneyimin *neden* kötü olduğunu söyler.
3. Hassasiyetle Hareket Edin: Belirli kullanıcı segmentleri için sorunun temel nedenini ele alan bilinçli, hedeflenmiş optimizasyonlar yapmak için birleştirilmiş verileri kullanın.

Hem üst düzey kullanıcı metriklerine hem de düşük düzeyli teşhis API'lerine hakim olarak, bütünsel bir performans stratejisi oluşturabilirsiniz. Tahmin etmeyi bırakır ve yalnızca teknik olarak hızlı olmayan, aynı zamanda her cihazda, dünyanın her yerindeki her kullanıcı için hızlı, duyarlı ve keyifli hissettiren bir web deneyimi tasarlamaya başlarsınız.