Web Vitals Metriklerini İyileştiren İleri Düzey Frontend Taktikleri

Bir web sitesini hızlandırırken en kolay hata, birkaç dosyayı küçültüp Lighthouse skorunun yükselmesini gerçek performans iyileşmesi sanmaktır. On yılı aşan frontend geliştirme deneyimimde en kalıcı sonuçları, tek bir skorun peşinden koşmak yerine gerçek kullanıcıların hangi cihazda, hangi sayfada ve hangi etkileşimde beklediğini ölçen ekiplerde gördüm. Web Vitals Metriklerini İyileştiren İleri Düzey Frontend Taktikleri tam olarak bu nedenle yalnızca görsel sıkıştırma veya JavaScript minification konusu değildir. Core Web Vitals metrikleri nasıl iyileştirilir sorusuna doğru cevap verebilmek için LCP, INP ve CLS değerlerini alt bileşenlerine ayırmak, field data ile laboratuvar verisini birlikte okumak ve değişikliğin production etkisini ölçmek gerekir. Bu rehberde frontend optimizasyonu ile LCP INP ve CLS nasıl düşürülür sorusunu JavaScript, CSS, görsel, font, rendering, hydration, network, RUM ve CI/CD perspektifleriyle adım adım inceleyeceğiz.

Core Web Vitals Nedir ve 2026'da Hangi Metrikler Geçerlidir?

2026 itibarıyla Core Web Vitals üç temel kullanıcı deneyimi boyutunu ölçmeye devam ediyor: yükleme performansı için LCP, etkileşim yanıt hızı için INP ve görsel kararlılık için CLS. Bu metriklerin ortak özelliği yalnızca sentetik testlerde değil, gerçek kullanıcı deneyiminde anlam taşımasıdır. Bir sayfanın iyi kabul edilmesi için üç metriğin de önerilen eşikleri 75. yüzdelik dilimde karşılaması beklenir. Mobil ve masaüstü deneyimleri ayrı değerlendirildiği için güçlü masaüstü sonuçları zayıf mobil deneyimi gizleyemez. Performans çalışmasına başlarken ilk yapılması gereken, ekibin hâlâ FID veya eski Lighthouse varsayımlarıyla hareket edip etmediğini kontrol etmektir.

Largest Contentful Paint (LCP)

LCP, viewport içinde görünen en büyük anlamlı içerik öğesinin kullanıcıya ne zaman boyandığını ölçer. Bu öğe çoğu ticari sayfada hero görseli, büyük başlık alanı veya ürün görseli olabilir. LCP yalnızca dosyanın indirilme süresine bağlı değildir ve TTFB, resource discovery, download ve render delay birlikte sonucu oluşturur. Bu nedenle 4 saniyelik LCP gördüğünüzde otomatik olarak görsel sıkıştırmaya başlamak yanlış teşhis olabilir. Önce LCP breakdown çıkarılmalı ve en fazla sürenin hangi alt aşamada harcandığı belirlenmelidir.

İyi: ≤ 2,5 saniye

2,5 saniye veya daha düşük p75 LCP değeri iyi kullanıcı deneyimi aralığı olarak değerlendirilir. Buradaki p75 ifadesi tek bir hızlı testin yeterli olmadığı anlamına gelir. Sayfa ziyaretlerinin büyük çoğunluğunda bu seviyeyi koruyabilmek için sunucu, network ve cihaz farklarının birlikte yönetilmesi gerekir. Özellikle mobil kullanıcıların düşük CPU gücü ve daha yüksek ağ gecikmesi nedeniyle desktop laboratuvar ölçümlerinden farklı sonuç vermesi doğaldır. İyi aralığa girdikten sonra bile alt parçaları izlemek, yeni release'lerin değeri yeniden kötüleştirmesini önlemek açısından önemlidir.

İyileştirilmeli: 2,5–4 saniye

LCP değeri 2,5 ile 4 saniye arasındaysa sayfa iyileştirme gerektirir. Bu aralık genellikle tek bir büyük problem yerine birkaç orta ölçekli gecikmenin birleşiminden oluşabilir. Örneğin 900 ms TTFB, geç keşfedilen hero görseli ve render-blocking CSS birlikte sonucu 3 saniyenin üzerine taşıyabilir. Burada yalnızca dosya boyutuna odaklanmak toplam LCP üzerinde beklenen etkiyi vermeyebilir. En iyi yaklaşım waterfall, LCP subpart ve field attribution verisini birlikte okuyarak en büyük gecikme alanından başlamaktır.

Zayıf: > 4 saniye

4 saniyenin üzerindeki p75 LCP değeri kullanıcının ana içeriği görmek için belirgin süre beklediğini gösterir. Bu seviyede problemin yalnızca frontend asset boyutundan kaynaklandığını varsaymamak gerekir. Ağır SSR, uzak origin, API waterfall, JavaScript tarafından oluşturulan hero alanı veya third-party script de render zamanını uzatabilir. Kritik sayfa şablonlarında LCP elementi ve alt süreleri ayrı ayrı toplanmalıdır. En yüksek trafik ve gelir getiren sayfalardan başlanması optimizasyon çalışmasının iş değerini hızlandırır.

Interaction to Next Paint (INP)

INP, kullanıcının sayfa yaşam döngüsü boyunca yaptığı etkileşimlerin yanıt verebilirliğini ölçer ve kötü etkileşim deneyimini görünür hale getirir. Bir butona basmak, input'a yazmak veya klavye etkileşimi sonrasında browser'ın bir sonraki görsel frame'i sunmasına kadar geçen süre metriğin temelini oluşturur. FID yalnızca ilk giriş gecikmesini ölçerken INP input delay, event processing ve presentation delay dahil daha geniş deneyimi değerlendirir. Bu nedenle bir sayfa ilk açıldığında hızlı görünüp birkaç dakika sonra ağır etkileşimler üretse bile INP problemi yaşayabilir. JavaScript çalışma süresi, render maliyeti ve main thread yoğunluğu bu metriğin merkezindedir.

İyi: ≤ 200 ms

200 milisaniye veya daha düşük p75 INP değeri kullanıcı etkileşimlerinin hızlı ve doğal hissedilmesi için hedeflenen aralıktır. Ancak bütün interaction'ların tam olarak 200 ms altında olması gerektiği şeklinde yorumlanmamalıdır. INP sayfadaki etkileşim dağılımını değerlendirerek kötü deneyimleri öne çıkarır. Üretim sistemlerinde hangi target ve interaction type'ın kötü sonuca yol açtığını toplamak bu nedenle çok değerlidir. 200 ms altında kalmak için event handler süresini azaltmanın yanında main thread üzerindeki alakasız uzun görevleri de kontrol etmek gerekir.

İyileştirilmeli: 200–500 ms

200 ile 500 ms arasındaki INP kullanıcının bazı etkileşimlerde gecikmeyi hissedebileceği anlamına gelir. Bu aralıkta özellikle düşük segment mobil cihazlar incelendiğinde masaüstünde görülmeyen main thread problemleri ortaya çıkabilir. Ağır state güncellemesi, büyük component tree render'ı, synchronous parsing veya third-party script ortak nedenler arasındadır. Interaction breakdown input delay, processing duration ve presentation delay olarak ayrılmalıdır. Hangi bölüm baskınsa optimizasyon stratejisi ona göre değiştirilmelidir.

Zayıf: > 500 ms

500 ms üzerindeki INP kullanıcı açısından belirgin biçimde gecikmeli bir arayüz anlamına gelir. Kullanıcı butona bastığını tekrar tekrar düşünebilir veya işlemin gerçekleşmediğini sanabilir. Bu durum duplicate action, form tekrar gönderimi veya sepet davranışında kullanıcı güvenini doğrudan etkileyebilir. Production attribution verisi hangi elementin ve hangi script'in bu gecikmeye katkı verdiğini ortaya çıkarmalıdır. Yalnızca JavaScript dosyasını minify etmek yerine interaction sırasında çalışan gerçek code path ölçülmelidir.

Cumulative Layout Shift (CLS)

CLS, kullanıcı etkileşimi olmadan gerçekleşen beklenmedik layout kaymalarının görsel istikrara etkisini ölçer. Görselin boyutu belli olmadan yüklenmesi, font değişimi, reklam slotunun sonradan açılması veya üstten eklenen banner bu metriği kötüleştirebilir. Kullanıcı okumaya veya bir butona basmaya hazırlanırken içerik yer değiştiriyorsa deneyim hızlı olsa bile güvenilir hissettirmez. CLS optimizasyonunun önemli kısmı browser'a yükleme öncesinde doğru alan bilgisini vermektir. Görsel ve iframe boyutlarını önceden ayırmak çoğu projede en hızlı kazanımlardan biridir.

İyi: ≤ 0,1

0,1 veya daha düşük p75 CLS değeri iyi görsel kararlılık aralığıdır. Buna ulaşmak yalnızca görsellere width ve height vermekle sınırlı değildir. Font fallback ölçüleri, cookie banner, skeleton ve dinamik widget'lar da layout davranışına katkı verir. Field data hangi route veya template'te shift'in yoğunlaştığını gösterebilir. Production'da attribution toplanması gerçek kullanıcıda kaymaya neden olan elementlerin bulunmasını kolaylaştırır.

İyileştirilmeli: 0,1–0,25

0,1 ile 0,25 arasındaki CLS değeri bazı kullanıcıların sayfa düzeninde rahatsız edici hareketler yaşadığını gösterir. Bu aralık özellikle reklam ve kişiselleştirilmiş içerik kullanan sayfalarda sık görülür. Tek büyük shift yerine birkaç küçük hareket toplam skoru yükseltebilir. Layout shift cluster analizi hangi zaman diliminde problemin oluştuğunu daha iyi gösterir. Placeholder, reserved space ve font metrics override gibi çözümler sorunun kaynağına göre seçilmelidir.

Zayıf: > 0,25

0,25 üzerindeki CLS ciddi görsel istikrarsızlık anlamına gelir. Kullanıcı yanlış elemana basabilir veya okumakta olduğu içerik ekranın başka yerine taşınabilir. E-ticaret checkout ve form ekranlarında bu problem güven duygusunu daha fazla zedeler. Öncelikle viewport üstündeki dinamik elementler ve third-party bileşenler incelenmelidir. Layout shift'in kaynağı yalnızca kendi kodunuz olmayabileceği için reklam, chat ve consent scriptleri de audit kapsamına alınmalıdır.

Neden 75. Yüzdelik Dilim (p75) Kullanılır?

p75, yalnızca ortalama kullanıcıyı değil daha zor koşullarda deneyim yaşayan önemli bir kullanıcı grubunu da ölçüme dahil eder. Ortalama değer çok hızlı cihazların etkisiyle iyileşebilir ve kötü mobil deneyimi gizleyebilir. 75. yüzdelik dilim, ziyaretlerin en az yüzde 75'inde hedeflenen deneyime ulaşılması gerektiğini ifade eder. Bu nedenle RUM dashboard'larında p50 yanında p75 ve daha yüksek yüzdelikleri görmek yararlıdır. p90 ve p95 doğrudan Core Web Vitals geçiş kriteri olmasa bile uzun kuyruktaki sorunları ve cihaz segmentlerini teşhis etmek için güçlü sinyal sağlar.

Mobil ve Masaüstü Verilerinin Ayrı Değerlendirilmesi

Mobil ve desktop kullanıcıların CPU gücü, network özellikleri ve viewport düzeni farklı olduğu için aynı sayfa farklı performans karakteri gösterebilir. Hero görseli mobilde farklı source kullanabilir ve LCP elementi tamamen değişebilir. JavaScript execution düşük segment Android cihazda masaüstünden birkaç kat daha uzun sürebilir. Bu nedenle tek birleşik dashboard problemi gizleyebilir. Core Web Vitals çalışmasında mobile ve desktop segmentleri ayrı baseline, ayrı p75 ve gerektiğinde ayrı optimizasyon önceliğiyle yönetilmelidir.

FID'in Yerini Neden INP Aldı?

FID yalnızca kullanıcının ilk etkileşiminin event processing başlamadan önce ne kadar beklediğini ölçüyordu. Bu yaklaşım sayfanın daha sonraki etkileşimlerini ve event handler çalışma süresini kapsamıyordu. INP ise sayfanın yaşam döngüsü boyunca gerçekleşen etkileşimleri değerlendirir ve sonraki paint'e kadar olan deneyimi dikkate alır. Böylece gerçek responsiveness problemlerini daha geniş biçimde görünür kılar. 12 Mart 2024 itibarıyla INP Core Web Vital olarak FID'in yerini aldı ve 2026 performans çalışmalarında odak metriği olarak kullanılmalıdır.

Web Vitals Optimizasyonunda Önce Ölçüm, Sonra Kod

Web Vitals için JavaScript CSS görsel ve font optimizasyonu yapmaya başlamadan önce doğru ölçüm sistemi kurulmalıdır. Ölçmeden yapılan performans çalışmaları ekipleri genellikle en görünür dosyaya yöneltir, ancak asıl problem başka katmanda olabilir. Laboratuvar verisi tekrar üretilebilir debugging ortamı sunarken field data gerçek kullanıcı dağılımını gösterir. İki veri türü birbirinin alternatifi değildir ve birlikte kullanılmalıdır. Sağlam audit süreci önce baseline oluşturur, ardından hipotez kurar, küçük değişiklik yayınlar ve production etkisini yeniden ölçer.

Laboratory Data ve Field Data Arasındaki Fark

Laboratuvar verisi kontrol edilen cihaz, ağ ve senaryo koşullarında üretilir. Lighthouse veya DevTools trace belirli bir yüklemenin ayrıntılı waterfall ve main thread davranışını görmenizi sağlar. Field data ise gerçek kullanıcıların cihaz, network, browser ve coğrafi dağılımını içerir. Laboratuvarda iyi görünen sayfa gerçek kullanıcıda kötü olabilir çünkü production koşulları daha çeşitlidir. Debugging için lab, öncelik ve doğrulama için field data birlikte kullanıldığında daha güvenilir sonuç alınır.

CrUX Verisinin Rolü

Chrome User Experience Report gerçek Chrome kullanıcılarından anonimleştirilmiş performans dağılımları sunar. PageSpeed Insights ve Search Console gibi araçlardaki Core Web Vitals field değerlendirmesinin önemli kaynaklarından biridir. CrUX origin ve yeterli veri varsa URL düzeyinde trendleri görmeyi sağlar. Buna rağmen kendi business segmentlerinizi veya component target'larını CrUX üzerinden ayrıntılı analiz edemezsiniz. Bu nedenle CrUX dış referans ve SEO görünümü için, kendi RUM sisteminiz ise kök neden analizi için birlikte kullanılmalıdır.

Search Console Core Web Vitals Raporu

Search Console benzer sorun yaşayan URL gruplarını Core Web Vitals durumuna göre görünür hale getirir. SEO sorumluları açısından hangi sayfa gruplarının iyi veya zayıf deneyim sunduğunu takip etmek için kullanışlıdır. Ancak rapor doğrudan hangi JavaScript function veya hangi hero image'ın problemi oluşturduğunu söylemez. Teknik ekip URL grubundan representative sayfaları seçerek daha ayrıntılı field ve lab analizi yapmalıdır. Search Console sinyali teşhis aracı değil, önceliklendirme ve takip aracı olarak görülmelidir.

PageSpeed Insights

PageSpeed Insights field data ile Lighthouse tabanlı laboratuvar analizini aynı görünümde bir araya getirir. Bu durum hızlı audit için oldukça kullanışlıdır. Field ve lab sonuçlarının aynı çıkmaması hata değildir çünkü farklı veri kaynaklarını ve zaman aralıklarını temsil ederler. Bir URL için yeterli field data yoksa origin seviyesi değerlendirme görülebilir. Teknik karar vermeden önce hangi bölümde field, hangi bölümde lab verisi okuduğunuzu açıkça ayırmak gerekir.

Lighthouse

Lighthouse kontrollü ortamda performans fırsatları ve teşhis bilgileri sağlar. Render-blocking resource, unused JavaScript ve image sizing gibi sorunları hızlı bulabilir. Ancak Lighthouse skorunu ana iş hedefi yapmak yanlış öncelik oluşturabilir. Tek sentetik koşul bütün gerçek kullanıcı dağılımını temsil etmez. Lighthouse CI regresyon kontrolü için güçlüdür, fakat production Core Web Vitals başarısı RUM ve CrUX verisiyle doğrulanmalıdır.

Chrome DevTools Performance Panel

Performance Panel main thread task'ları, network timing, rendering ve interaction davranışını ayrıntılı trace üzerinde gösterir. INP problemi araştırırken event timing ve long frame ilişkisini görebilirsiniz. LCP tarafında hangi resource'un ne zaman keşfedildiği ve elementin neden geç render olduğu incelenebilir. CPU throttling farklı cihaz koşullarını yaklaşık simüle etmeye yardımcı olur. Trace okuma yetkinliği ileri frontend performans çalışmalarında en değerli becerilerden biridir.

WebPageTest

WebPageTest farklı coğrafya, browser, network ve cihaz profillerinde ayrıntılı waterfall analizi sunar. Filmstrip görünümü kullanıcının sayfayı hangi aşamalarda gördüğünü anlamayı kolaylaştırır. Connection setup, TTFB ve render progression gibi veriler özellikle LCP root cause analizinde değerlidir. Tek test yerine birden fazla run kullanmak network varyansını azaltır. Production URL'lerini farklı bölge ve bağlantı profilleriyle test etmek CDN ve origin kararlarının gerçek etkisini ortaya çıkarabilir.

Gerçek Kullanıcı İzleme (RUM)

RUM kendi kullanıcılarınızın gerçek tarayıcılarında Core Web Vitals ve attribution verisini toplar. Route, device, release ve interaction target gibi business açısından anlamlı segmentler eklenebilir. Böylece yalnızca “INP kötü” demek yerine belirli checkout butonunun düşük segment Android cihazlarda sorun ürettiğini görebilirsiniz. Veri örnekleme ve privacy kuralları baştan belirlenmelidir. Kurumsal performans programının sürdürülebilir olması için RUM dashboard ve alert sistemi release sürecinin kalıcı parçası olmalıdır.

web-vitals JavaScript Kütüphanesi

web-vitals kütüphanesi LCP, INP ve CLS değerlerini browser tarafında toplamayı kolaylaştırır. Attribution build kullanıldığında metric değerine ek olarak kök neden analizini destekleyen bilgiler elde edilebilir. INP tarafında interaction target ve alt süreler, LCP tarafında resource timing ayrıntıları özellikle değerlidir. Kütüphaneyi ana application bundle'a gereksiz biçimde eklemek yerine ayrı küçük chunk olarak yüklemek tercih edilebilir. Toplanan veriyi yalnızca console'a yazmak yerine release ve route metadata ile backend analytics sistemine taşımak gerekir.

PerformanceObserver API

PerformanceObserver browser performans entry'lerini programatik olarak izlemeye yarar. LCP, layout shift, event timing ve long animation frame gibi farklı entry türleri uygun browser desteğinde gözlemlenebilir. Kendi RUM altyapısını geliştiren ekipler bu API üzerinden daha ayrıntılı attribution üretebilir. Ancak metric hesaplama ayrıntıları zaman içinde değişebildiği için resmi web-vitals implementation'ını referans almak daha güvenlidir. Custom observer daha çok ürününüze özel diagnostic telemetry eklemek için kullanılmalıdır.

navigator.sendBeacon ile Veri Gönderme

navigator.sendBeacon kullanıcı sayfadan ayrılırken küçük analytics payload'larını güvenilir biçimde göndermek için kullanılabilir. Core Web Vitals bazı metrikleri sayfa yaşam döngüsünün sonuna kadar güncelleyebildiği için bu davranış önemlidir. Payload küçük tutulmalı ve gerekli alanlarla sınırlandırılmalıdır. Sensitive kullanıcı verileri performans telemetry'sine dahil edilmemelidir. Beacon başarısız olduğunda uygulamanın kullanıcı deneyimi etkilenmemeli ve performans ölçümü ana işlem akışının önüne geçmemelidir.

Kullanıcı, Cihaz ve Sayfa Şablonu Bazlı Segmentasyon

Tek global p75 sayısı kök neden bulmak için yeterli değildir. Device class, effective connection, route template ve release ID gibi segmentler problemi daha dar alana indirir. Örneğin yalnızca product detail template'in mobil p75 LCP değeri kötü olabilir. Kullanıcı kimliğini doğrudan taşımak yerine anonim segment anahtarları kullanılmalıdır. Segmentasyon cardinality kontrolüyle tasarlanırsa dashboard hem performanslı hem karar vermeye uygun kalır.

Performance Audit Nasıl Kök Neden Analizine Dönüştürülür?

Gerçek audit, araç ekranından kırmızı uyarıları kopyalamaktan daha fazlasıdır. Önce hangi sayfa şablonunun business açısından önemli olduğu ve hangi metric alt bileşeninin problemi oluşturduğu belirlenmelidir. Ardından değişiklik öncesi baseline oluşturulur ve tek bir hipotezi test eden kontrollü optimizasyon yapılır. Bu yöntem performans iyileşmesinin hangi değişiklikten kaynaklandığını anlamayı kolaylaştırır. Kurumsal web sitesi Core Web Vitals ve frontend performans optimizasyon hizmeti çalışmasında başarı, rapor sayısından çok ölçülebilir production iyileşmesiyle değerlendirilmelidir.

URL Yerine Sayfa Şablonlarını Gruplama

Binlerce ürün URL'sini tek tek analiz etmek yerine aynı rendering ve component yapısını paylaşan template'leri gruplamak daha etkilidir. Product detail, category, article ve checkout gibi şablonlar ayrı performans profili oluşturur. RUM verisi template ID ile gönderildiğinde p75 dağılımı daha kolay okunur. Bir template düzeltmesi yüzlerce URL'yi aynı anda iyileştirebilir. URL bazlı istisnalar daha sonra content veya asset farkı açısından ayrıca incelenebilir.

Trafik ve Gelire Göre Önceliklendirme

En kötü metric her zaman ilk düzeltilmesi gereken sayfa olmayabilir. Çok düşük trafik alan sayfada büyük teknik problem bulunurken checkout veya ürün sayfasındaki orta seviye problem daha yüksek iş etkisi yaratabilir. Traffic, conversion ve revenue bilgisi performans backlog'una eklenmelidir. Böylece engineering effort business priority ile ilişkilendirilir. Teknik ekip performans iyileştirmesini yalnızca skor değil kullanıcı ve gelir etkisi üzerinden savunabilir.

p50, p75, p90 ve p95 Dağılımlarını Okuma

p50 tipik kullanıcının deneyimini, p75 Core Web Vitals değerlendirmesi için kritik sınırı, p90 ve p95 ise uzun kuyruktaki zor koşulları gösterir. Eğer p50 iyi ancak p95 çok kötüyse belirli cihaz veya network segmenti problem yaşıyor olabilir. Bütün yüzdeliklerin birlikte kötü olması daha genel architecture sorununa işaret eder. Segmentasyon ile percentile bilgisi birlikte okunmalıdır. Sadece tek p75 değeri üzerinden root cause çıkarmaya çalışmak detay kaybettirebilir.

Ortalama Değerlerin Neden Yanıltıcı Olabileceği

Performans dağılımları genellikle normal dağılım değildir ve birkaç çok yavaş deneyim ortalamayı yükseltebilir. Tersine çok hızlı desktop kullanıcılar kötü mobil grubu gizleyebilir. Ortalama business analytics için bazı durumlarda yararlı olsa da Core Web Vitals quality değerlendirmesinde percentile daha anlamlıdır. Median ve üst yüzdelikler birlikte okunmalıdır. Dashboard tasarımında average değer tek başına ana KPI olarak sunulmamalıdır.

Değişiklik Öncesi Baseline Oluşturma

Optimizasyon öncesinde yeterli süre field data toplanmalıdır. Release ID, trafik yapısı ve sezon etkisi kaydedilmelidir. Aksi halde iyileşme gibi görünen değişiklik kullanıcı kitlesinin değişmesinden kaynaklanabilir. Baseline hem metric değerlerini hem business KPI'larını içerebilir. Sonraki deployment aynı segmentler üzerinden karşılaştırılır.

Tek Değişkenli Performans Deneyleri

Bir release içinde hero image formatı, SSR strategy ve third-party scriptlerin tamamını değiştirmek hangi değişikliğin etkili olduğunu anlamayı zorlaştırır. Mümkün olduğunda tek ana hipotez küçük deployment ile test edilmelidir. Feature flag veya traffic split bunu production ortamında güvenli hale getirebilir. Sonuç olumluysa değişiklik genişletilir. Performans mühendisliği ölçülebilir deneyler halinde ilerlediğinde ekip zaman içinde kendi uygulamasına özgü güvenilir bilgi üretir.

LCP'yi Dört Alt Parçaya Ayırarak Optimize Etmek

LCP toplam süresini tek sayı olarak görmek çoğu zaman yanlış optimizasyona yol açar. LCP, TTFB, resource load delay, resource load duration ve element render delay olmak üzere dört alt parçaya ayrılabilir. Her parça farklı engineering çözümü gerektirir. Resource load delay yüksekse görsel sıkıştırmak tek başına yeterli değildir, çünkü browser kaynağı zaten geç keşfetmektedir. En etkili LCP programı önce dominant alt parçayı bulur ve teknik çalışmayı oraya yönlendirir.

TTFB

TTFB navigation başlangıcından HTML response'un ilk byte'ının gelmesine kadar geçen süredir. Server processing, CDN cache durumu, network mesafesi ve redirect zinciri bu süreyi etkileyebilir. Yüksek TTFB bütün sonraki rendering aşamalarına gecikme ekler. SSR sayfasında database ve API waterfall ayrıca TTFB'yi uzatabilir. Cache hit ve miss dağılımı ayrı izlenerek gerçek bottleneck bulunmalıdır.

Resource Load Delay

Resource load delay HTML'in ilk byte'ı geldikten sonra browser'ın LCP kaynağını istemeye başlamasına kadar geçen süredir. Hero image JavaScript tarafından oluşturuluyorsa veya external CSS içindeki background image olarak keşfediliyorsa bu süre büyür. LCP resource'un ilk HTML içinde doğrudan keşfedilebilir olması en güçlü çözümdür. Gerekli durumlarda preload ve fetch priority kullanılabilir. Bu aşamada amaç browser'ın kritik kaynağı mümkün olan en erken anda bilmesini sağlamaktır.

Resource Load Duration

Resource load duration LCP asset'in network üzerinden gerçekten indirilmesi için geçen süredir. Dosya boyutu, bağlantı hızı, origin mesafesi ve bandwidth competition bu değeri etkiler. Görsel doğru boyutta, modern formatta ve uygun CDN üzerinden sunulmalıdır. Çok sayıda aynı anda high priority request oluşturmak LCP kaynağıyla rekabet yaratabilir. Browser cache tekrar ziyaretlerde bu süreyi büyük ölçüde azaltabilir.

Element Render Delay

Element render delay resource hazır olduktan sonra LCP elementinin gerçekten ekrana boyanmasına kadar geçen süredir. Render-blocking CSS, JavaScript long task, hydration veya elementin DOM'a geç eklenmesi bu süreyi uzatabilir. Görsel indirilmiş olmasına rağmen hero component client-side state bekliyorsa LCP yine kötü olabilir. Main thread trace bu aşamanın nedenini ortaya çıkarır. Kritik içerik mümkün olduğunca ilk HTML'de ve render için az JavaScript bağımlılığıyla sunulmalıdır.

LCP'nin Hangi Alt Parçasının Darboğaz Olduğunu Bulma

DevTools ve Lighthouse local trace üzerinde LCP phases gösterebilir, production için web-vitals attribution benzer breakdown verisi sağlayabilir. Önce her page template için p75 alt süreleri toplanmalıdır. Resource load delay baskınsa discovery, TTFB baskınsa server ve caching, render delay baskınsa main thread veya hydration odaklı çalışma yapılır. Aynı sitenin farklı template'lerinde farklı bottleneck bulunması normaldir. Tek global çözüm yerine template-specific optimizasyon planı oluşturmak daha iyi sonuç verir.

TTFB Optimizasyonu

TTFB frontend ekibinin kontrolü dışında görülse de modern web uygulamalarında rendering strategy ve data fetching tercihleri bu metriği doğrudan etkiler. Cache kullanımı, server query maliyeti ve SSR waterfall doğru tasarlanmadığında HTML üretimi gereksiz bekler. CDN ve edge yaklaşımı coğrafi gecikmeyi azaltabilir. Buna karşılık her request'i edge üzerinde render etmek otomatik olarak daha hızlı değildir ve veri kaynağı uzaksa yeni network hop oluşabilir. Gerçek response timing parçaları ölçülerek hangi katmanın gecikme ürettiği belirlenmelidir.

Server-Side Cache

Server-side cache sık hesaplanan veya sık okunan data sonuçlarını tekrar kullanmayı sağlar. HTML, API response veya data query seviyesinde farklı cache katmanları oluşturulabilir. Cache key yanlış tasarlanırsa kişiselleştirilmiş veri başka kullanıcıya sızabilir, bu nedenle correctness performanstan önce gelir. Hit ratio ve miss latency ayrı ölçülmelidir. Cache invalidation business data freshness gereksinimiyle birlikte planlanmalıdır.

CDN ve Edge Caching

CDN kullanıcıya yakın edge location üzerinden static asset ve uygun HTML response'ları sunabilir. Bu yaklaşım network round trip sayısını ve origin yükünü azaltır. Cache-Control header'ları doğru değilse CDN avantajından yararlanılamaz. Kişiselleştirilmiş response için full-page cache yerine parçalı veya edge key stratejileri gerekebilir. Geographic RUM segmenti CDN iyileştirmesinin gerçek etkisini göstermelidir.

HTML Cache Stratejileri

Static ve nadiren değişen sayfalar uzun süreli HTML cache için uygundur. Dinamik ürün veya içerik sayfalarında stale-while-revalidate benzeri yaklaşım hızlı response ile freshness arasında denge sağlayabilir. Checkout gibi kullanıcıya özel sayfalarda shared cache güvenli olmayabilir. Cache vary key sayısı çok büyürse hit ratio düşer. HTML cache kararı route criticality ve data sensitivity üzerinden verilmelidir.

Database Query Maliyetini Azaltma

SSR sırasında çalışan yavaş query doğrudan TTFB'ye eklenir. N+1 query, gereksiz join ve büyük payload extraction analiz edilmelidir. Query cache ve doğru index önemli olabilir, ancak problemi ölçmeden index eklemek doğru değildir. Rendering için ihtiyaç duyulmayan data ilk request'te çekilmemelidir. Database timing trace içine eklenirse frontend performans ekibi backend bottleneck'i daha somut gösterebilir.

API Waterfall'larını Önleme

Bir server component önce kullanıcıyı, sonra kullanıcı sonucuyla ürünü ve daha sonra ürüne bağlı kampanyayı sequential şekilde çağırıyorsa TTFB hızla büyüyebilir. Bağımsız request'ler paralel başlatılmalıdır. Data dependency gerçekten sequential ise endpoint aggregation veya backend-for-frontend değerlendirilebilir. Aynı data farklı component'ler tarafından tekrar istenmemelidir. Server trace waterfall'ın hangi request zincirinden oluştuğunu göstermelidir.

SSR Maliyetini Kontrol Altında Tutma

SSR ilk HTML'i erken sunabilir fakat server CPU ve data fetching maliyeti yüksekse TTFB kötüleşebilir. Her component'i dinamik SSR yapmak zorunlu değildir. Static generation, cache veya streaming farklı route'larda daha iyi sonuç verebilir. Rendering süresi production telemetry ile izlenmelidir. SSR kullanımının amacı yalnızca “server rendering var” demek değil, kullanıcıya kritik içeriği daha erken ulaştırmaktır.

Coğrafi Gecikmeyi Edge Rendering ile Azaltma

Edge rendering kullanıcı ile compute arasındaki fiziksel mesafeyi azaltabilir. Ancak edge function veri almak için uzak merkezi database'e gidiyorsa toplam gecikme beklenenden yüksek olabilir. Data locality rendering location ile birlikte tasarlanmalıdır. Cold start ve runtime capability farkları da ölçülmelidir. Coğrafi segmentli RUM sonuçları edge migration'ın gerçekten TTFB ve LCP'yi iyileştirip iyileştirmediğini göstermelidir.

LCP Resource Discovery Problemini Çözmek

LCP resource discovery, ileri düzey LCP çalışmalarında en sık gözden kaçan alanlardan biridir. Browser hero görselini ne kadar geç öğrenirse network ne kadar hızlı olursa olsun indirme o kadar geç başlar. En iyi durumda LCP asset doğrudan ilk HTML içindeki image markup üzerinden preload scanner tarafından keşfedilebilir. JavaScript rendering, CSS background veya nested dependency bu keşfi geciktirir. Network waterfall üzerinde LCP request start zamanı HTML ve diğer critical resource'larla karşılaştırılmalıdır.

Browser Preload Scanner Nasıl Çalışır?

Browser ana HTML parser bazı kaynaklarda beklerken ayrı preload scanner gelecekte ihtiyaç duyulacak asset'leri markup içinden önceden keşfetmeye çalışır. Image, stylesheet ve script gibi açık resource reference'ları bu avantajdan yararlanabilir. Kaynak yalnızca JavaScript çalıştıktan sonra oluşuyorsa scanner onu göremez. CSS background image ise stylesheet indirilip parse edilmeden bilinemeyebilir. Bu nedenle critical asset'leri mümkün olduğunca HTML seviyesinde keşfedilebilir kılmak LCP load delay'i azaltır.

LCP Görselini İlk HTML İçinde Keşfedilebilir Hale Getirme

Hero image markup server-rendered HTML içinde gerçek src veya responsive source bilgisiyle bulunmalıdır. Data attribute içinde saklanıp JavaScript tarafından daha sonra src değerine dönüştürülmesi discovery'yi geciktirir. Image component SSR output'unun doğru markup ürettiği kontrol edilmelidir. Personalized hero gerekiyorsa server mümkün olduğunca seçim yapıp gerçek kaynağı ilk response'a ekleyebilir. Waterfall testinde LCP image request'in erken başladığı doğrulanmalıdır.

JavaScript Tarafından Sonradan Eklenen Hero Görsellerinden Kaçınma

Client-side fetch tamamlandıktan sonra hero component render ediliyorsa browser önce JavaScript'i indirip çalıştırmak ve data'yı beklemek zorunda kalır. Bu süreç resource load delay ile element render delay'i birlikte artırabilir. Kritik above-the-fold içeriği SSR veya static HTML ile sunmak daha iyi olabilir. Client-only personalization gerekiyorsa default hero erken render edilip daha sonra düşük etkili değişiklik yapılabilir. LCP elementini application boot sequence'in sonuna koymak performans açısından pahalıdır.

CSS Background Image Olarak Kullanılan LCP Kaynakları

Hero background image external stylesheet içinde tanımlandığında browser image URL'sini CSS yüklenip parse edilene kadar keşfedemeyebilir. Eğer tasarım gerçekten background gerektiriyorsa image preload bu gecikmeyi azaltabilir. Alternatif olarak semantik açıdan uygun img veya picture yapısı kullanılabilir. Responsive art direction ihtiyacı da HTML image primitives ile daha iyi yönetilebilir. Network trace ile discovery farkı ölçülmeden sadece markup tercihi üzerinden sonuç varsayılmamalıdır.

Request Dependency Chain'lerini Kısaltma

Kritik resource başka bir resource'un sonucuna bağlı oldukça loading başlangıcı gecikir. HTML önce CSS'i, CSS font veya image'ı, JavaScript ise başka chunk'ı keşfediyorsa uzun request chain oluşabilir. Critical asset'ler doğrudan document tarafından bilinmelidir. Modulepreload veya preload bazı gerekli dependency'leri erkene çekebilir. Her chain'i preload ile çözmek yerine dependency architecture'ın kendisini sadeleştirmek daha kalıcı sonuç verir.

Resource Priority ile LCP'yi İleri Seviyede Optimize Etmek

Browser kaynaklara kendi priority heuristics'iyle sıra verir, ancak kritik LCP asset bazı durumlarda beklenenden düşük priority alabilir. fetchpriority="high", preload ve preconnect gibi resource hint'ler doğru kullanıldığında başlangıç süresini iyileştirebilir. Buna karşılık çok fazla high priority veya preload network competition yaratarak sonucu kötüleştirebilir. Her hint bir bütçe gibi görülmelidir. Waterfall üzerinde gerçekten hangi request'in erkene geldiği ve LCP'nin değişip değişmediği ölçülmelidir.

fetchpriority=""high""

fetchpriority="high" browser'a belirli kaynağın göreli önceliğinin yüksek olması gerektiğini bildirir. Özellikle HTML içinde zaten keşfedilebilen LCP image için yararlı olabilir. Bu attribute resource'u kendi başına preload etmez ve discovery zamanını değiştirmez. Dolayısıyla image geç keşfediliyorsa önce discovery problemi çözülmelidir. Çok sayıda görseli high priority yapmak sinyalin değerini düşürür ve bandwidth competition oluşturabilir.

preload

Preload browser'a mevcut navigation sırasında yakında kesin olarak gerekecek kritik kaynağı erken istemesi gerektiğini söyler. LCP image, kritik font veya geç keşfedilen CSS dependency doğru aday olabilir. Yanlış resource preload edildiğinde kullanıcı ihtiyaç duymadığı byte'ları indirir ve kritik request'lerle yarış yaratır. as, type ve crossorigin davranışları doğru tanımlanmalıdır. Performance trace preload request'inin daha sonra duplicate indirme oluşturmadığını doğrulamalıdır.

Image Preload

Image preload özellikle CSS background veya JavaScript nedeniyle geç keşfedilen LCP görselinde değerlidir. Image zaten ilk HTML içinde erken bulunuyorsa preload ek fayda sağlamayabilir. Responsive image kullanılıyorsa yanlış tek source preload etmek gereksiz data tüketebilir. Modern browser'larda responsive preload seçenekleri doğru uygulanmalıdır. İyileşme gerçek mobil network profiliyle ölçülmelidir.

Font Preload

Font preload kritik above-the-fold text'in kullandığı font dosyasını stylesheet parsing'inden önce başlatabilir. Yalnızca gerçekten ilk ekranda kullanılan küçük font subset'leri preload edilmelidir. Bütün weight ve style dosyalarını preload etmek ciddi bandwidth competition yaratır. CORS behavior doğru ayarlanmazsa font yeniden indirilebilir. Font display ve fallback metrics stratejisi preload ile birlikte düşünülmelidir.

Responsive Image Preload

Responsive LCP image farklı viewport ve DPR koşullarında farklı source seçebilir. Tek büyük desktop görselini bütün cihazlarda preload etmek mobilde gereksiz byte indirir. Responsive preload veya picture markup browser'ın uygun adayı seçmesini sağlamalıdır. imagesrcset ve imagesizes gibi mekanizmalar gerektiğinde kullanılabilir. Gerçek source selection DevTools network panelinde cihaz boyutlarıyla test edilmelidir.

preconnect

Preconnect başka origin'e yapılacak kritik request öncesinde DNS, TCP ve TLS bağlantı hazırlığını erkene çekebilir. Font, image veya API kaynağı zorunlu olarak external origin'den geliyorsa yararlı olabilir. Çok fazla preconnect connection resource tüketir. Ana LCP kaynağı aynı origin'den sunulabiliyorsa ek connection maliyeti ortadan kalkabilir. Kullanıcı gerçekten erişmeyecek third-party domain'lere preconnect yapılmamalıdır.

dns-prefetch

dns-prefetch yalnızca DNS resolution aşamasını erkene alır ve preconnect'e göre daha düşük maliyetli ipucudur. Daha sonra kullanılma ihtimali bulunan ancak kesin olmayan origin'ler için değerlendirilebilir. Modern bağlantı ve cache davranışı nedeniyle etkisi her projede büyük olmayabilir. Kritik ilk-party resource için çoğu zaman doğrudan aynı origin kullanımı daha iyidir. Hint'in gerçek waterfall etkisi ölçülmelidir.

modulepreload

modulepreload ES module dependency'lerini daha erken getirip parse hazırlığı sağlayabilir. Kritik client interaction module'u veya hydration chunk'ı için yararlı olabilir. Ancak büyük module graph'ı gereksiz erken çekmek JavaScript parse ve network yükünü artırır. Bundler'ın zaten hangi modulepreload linklerini ürettiği incelenmelidir. Manual hint yalnızca trace üzerinde gerçek gap görüldüğünde eklenmelidir.

Çok Fazla Preload Kullanmanın Oluşturduğu Bandwidth Competition

Her kaynağı önemli ilan etmek browser priority sistemini anlamsız hale getirir. LCP image, font, analytics ve aşağıdaki görseller aynı anda preload edilirse sınırlı mobil bandwidth paylaşılır. Sonuçta kritik resource'un download süresi uzayabilir. Preload budget route bazında tanımlanabilir. Network waterfall ve request priority kolonları gereksiz hint'leri bulmak için düzenli audit edilmelidir.

Kritik Kaynakları Önceliklendirirken Diğer Kaynakları Deprioritize Etmek

Performans yalnızca kritik request'i yükseltmek değil, kritik olmayan request'leri doğru zamanda ertelemekle de iyileşir. Below-the-fold image lazy load edilebilir, chat widget interaction sonrasına bırakılabilir ve analytics main thread idle döneminde çalıştırılabilir. Bu yaklaşım LCP kaynağına hem network hem CPU alanı açar. Her resource'un business criticality ve loading phase'i tanımlanmalıdır. Priority sistemi bütün page lifecycle düşünülerek yönetildiğinde daha öngörülebilir sonuç verir.

LCP Görsellerinde İleri Düzey Optimizasyon

LCP image optimizasyonu yalnızca format dönüştürmekten ibaret değildir. Kaynağın erken keşfedilmesi, doğru boyutta gönderilmesi, uygun priority alması ve decode sonrasında hemen render edilmesi gerekir. Responsive image markup gereksiz büyük dosya indirilmesini önler. Image CDN cihaz ve format seçimini otomatikleştirebilir. Hero video kullanılıyorsa poster ve first frame davranışı da LCP stratejisinin parçasıdır.

LCP Görselinde Lazy Loading Neden Kullanılmamalı?

Above-the-fold LCP image kullanıcıya ilk anda gerekli olduğu için lazy loading onu gereksiz biçimde erteleyebilir. Browser lazy threshold ve viewport hesaplamasını beklerken request başlangıcı gecikebilir. LCP image normal veya eager loading davranışıyla erken keşfedilmelidir. Framework image component default olarak lazy ise LCP için özel priority seçeneği kullanılmalıdır. Bunun yalnızca gerçekten viewport üstündeki kritik image için uygulanması gerekir.

AVIF ve WebP

AVIF ve WebP aynı görsel kalite için klasik formatlardan daha küçük dosya sağlayabilir. Ancak encode ve decode maliyetleri görüntü türüne ve cihaz gücüne göre değişebilir. CDN content negotiation browser desteğine uygun format gönderebilir. Her görseli en agresif kaliteyle küçültmek marka kalitesini bozabilir. Dosya boyutu, decode zamanı ve visual fidelity birlikte test edilmelidir.

Responsive Images

Responsive image sistemi browser'ın viewport ve device pixel ratio için uygun dosyayı seçmesini sağlar. Tek 2400 piksel hero görselini 375 piksel telefona göndermek bandwidth israfıdır. srcset, sizes ve picture doğru kullanıldığında source selection browser'a bırakılır. CMS veya image CDN gerekli variant'ları üretmelidir. Gerçek network request width değerleri device emulation ile kontrol edilmelidir.

srcset

srcset bir image için farklı boyut veya density adaylarını browser'a bildirir. Browser viewport, DPR ve sizes bilgisini kullanarak uygun adayı seçer. Aday genişlikleri gerçek layout ihtiyacına göre üretilmelidir. Çok fazla gereksiz variant CDN cache fragmentation oluşturabilir. Source selection production device dağılımıyla optimize edilmelidir.

sizes

sizes image'ın viewport koşullarına göre CSS layout içinde yaklaşık ne kadar genişlik kaplayacağını browser'a bildirir. Yanlış sizes değeri browser'ın gerekenden büyük source seçmesine neden olabilir. Responsive grid ve container behavior ile uyumlu ifade yazılmalıdır. Framework default'u her layout için doğru olmayabilir. DevTools ile selected source ve rendered width karşılaştırılmalıdır.

picture

picture art direction veya format selection için farklı source'lar sunar. Mobile hero'da farklı crop kullanılması gerekiyorsa yalnızca resize etmek yerine ayrı görsel seçilebilir. Browser ilk eşleşen uygun source'u kullanır. Alt text semantic olarak ortak image içeriğini doğru açıklamalıdır. Çok sayıda source kuralı bakım yükü oluşturabileceği için gerçek design ihtiyacına göre sınırlanmalıdır.

Kullanıcının Gerçekte Göreceği Boyutta Görsel Göndermek

Rendered width 600 piksel olan görsele 2000 piksel dosya göndermek gereksiz network ve decode maliyeti üretir. DPR ihtiyacı nedeniyle source tam olarak CSS pixel kadar küçük olmayabilir. Image CDN viewport ve DPR'ye göre uygun variant oluşturabilir. CMS author çok büyük original yüklese bile frontend delivery layer optimize edilmiş output sunmalıdır. Asset audit transferred bytes ile rendered dimensions farkını raporlayabilir.

DPR ve Cihaz Boyutuna Göre Görsel Üretmek

Yüksek DPR ekran netlik için daha fazla physical pixel ister. Ancak her cihazda maksimum DPR değerine göre devasa source göndermek gerekmez. Görsel kalite algısı, compression ve layout width birlikte değerlendirilmelidir. Image service width ve quality preset'leri belirli breakpoint'lere göre üretilebilir. RUM üzerinden cihaz dağılımı hangi variant'ların gerçekten kullanıldığını gösterebilir.

Görsel CDN Kullanımı

Image CDN resize, format negotiation, compression ve geographic delivery süreçlerini merkezi hale getirir. Uygulama yalnızca semantic image request oluşturur. Origin ile image CDN arasında farklı hostname kullanılıyorsa connection maliyeti dikkate alınmalıdır. Mümkünse aynı site origin'i üzerinden proxy veya CDN mapping kullanılabilir. Cache hit oranı ve transformation latency izlenmelidir.

Decode Maliyetini Kontrol Etmek

Image network'ten geldiğinde browser pixel data oluşturmak için decode işlemi yapar. Çok büyük dimension'lı dosya sıkıştırılmış byte olarak küçük olsa bile decode ve memory açısından pahalı olabilir. Gerçek görüntü boyutunu ihtiyaç kadar sınırlandırmak bu nedenle önemlidir. Decode main thread ve rendering timeline ile birlikte trace üzerinde incelenebilir. Hero image ilk frame için hazır olsa bile uzun JavaScript task render'ı bekletebilir.

Hero Video ve Video Poster Optimizasyonu

Hero video başlangıçta büyük network ve decode maliyeti oluşturabilir. Kullanıcının ilk gördüğü poster image LCP elementine dönüşebilir ve bu poster erken optimize edilmelidir. Autoplay video için muted ve platform policy gereksinimleri dikkate alınmalıdır. İlk viewport'ta video yerine poster gösterip playback'i daha sonra başlatmak bazı projelerde daha iyi sonuç verebilir. Kullanıcı deneyimi ve brand gereksinimi performans ölçümüyle birlikte değerlendirilmelidir.

Critical Rendering Path Optimizasyonu

Browser HTML'den ekrandaki pixellere ulaşmak için parsing, style calculation, layout, paint ve composite aşamalarından geçer. Kritik CSS ve JavaScript bu zinciri doğrudan etkiler. Render-blocking stylesheet veya synchronous script LCP elementinin hazır olmasına rağmen ekrana geç gelmesine neden olabilir. Kullanılmayan CSS ve büyük scriptler parse ve processing maliyeti yaratır. İleri frontend performans çalışmasında browser rendering modelini anlamak optimizasyon araçlarından daha değerlidir.

HTML Parsing

Browser gelen HTML byte'larını token'lara ve DOM node'larına dönüştürür. Parser blocking script doğru kullanılmadığında bu süreç durabilir. Markup çok büyük olduğunda parse ve DOM construction maliyeti artabilir. Critical content document içinde erken yer almalıdır. HTML streaming kullanılıyorsa chunk sınırlarının critical resource discovery üzerindeki etkisi test edilmelidir.

CSSOM

Browser CSS kaynaklarını parse ederek CSSOM oluşturur. Render için gerekli style bilgisi hazır olmadan bazı içerikler boyanamaz. Büyük ve kullanılmayan stylesheet'ler download dışında parse ve style calculation maliyeti de taşır. Critical ve non-critical CSS ayrımı bu nedenle değerlidir. CSS architecture component veya route seviyesinde gereksiz global rule sayısını azaltmalıdır.

DOM

DOM document yapısının browser representation'ıdır. Çok büyük DOM tree style ve layout işlemlerini pahalı hale getirebilir. Framework abstraction gereksiz wrapper node üretiyorsa render maliyeti artar. Özellikle büyük table ve listelerde virtualization veya incremental rendering kullanılabilir. DOM size metriği tek başına hedef değil, interaction ve layout maliyetiyle ilişkili teşhis sinyalidir.

Render Tree

Render tree görünür DOM ve style bilgilerinden boyanacak yapı oluşturur. Display none gibi görünmeyen öğeler farklı şekilde ele alınır. Dynamic class değişiklikleri style recalculation tetikleyebilir. Büyük subtree üzerinde sık değişiklik INP presentation delay'i artırabilir. CSS containment ve component scope render etkisini küçültmeye yardımcı olabilir.

Layout

Layout her elementin geometry ve position değerlerini hesaplar. JavaScript style yazıp hemen layout bilgisi okursa forced synchronous layout oluşabilir. Büyük DOM'da bu maliyet ciddi hale gelir. Interaction sırasında tekrarlanan ölçüm ve style değişiklikleri batching ile düzenlenmelidir. DevTools forced reflow warning'leri root cause bulmaya yardımcı olur.

Paint

Paint görünür elementlerin pixel çizim talimatlarını üretir. Büyük shadow, filter ve complex clipping bazı sayfalarda paint maliyetini yükseltebilir. Scroll sırasında sık paint edilmesi frame drop ve responsiveness problemi oluşturabilir. Paint flashing gibi DevTools özellikleri hangi alanların yeniden çizildiğini görmeye yardımcı olur. Tasarım efektleri performance budget içinde değerlendirilmelidir.

Composite

Composite farklı layer'ların GPU üzerinden birleştirilmesi aşamasıdır. Transform ve opacity animation çoğu durumda layout veya paint yerine compositor üzerinden daha verimli ilerleyebilir. Gereksiz layer promotion memory maliyetini artırabilir. will-change her elemente eklenmemelidir. Animation trace gerçek compositor behavior'ını doğrulamalıdır.

Render-Blocking CSS'i Azaltma

İlk ekran için gerekli olmayan büyük stylesheet'lerin bütün rendering'i bekletmesi LCP'yi uzatabilir. Route-specific CSS splitting veya critical CSS yaklaşımı kullanılabilir. Ancak stylesheet'i asynchronous yüklerken flash ve specificity problemi oluşturulmamalıdır. CSS bytes yanında parse ve apply maliyeti de ölçülmelidir. Framework build output'unda hangi CSS chunk'larının her route'a geldiği düzenli incelenmelidir.

Critical CSS

Critical CSS ilk viewport'u render etmek için gereken minimum style set'ini erken sunmayı hedefler. Inline kullanım ek request'i ortadan kaldırabilir ancak HTML boyutunu ve cache davranışını etkiler. Otomatik extraction dynamic theme ve responsive layout'ta yanlış sonuç verebilir. Critical set küçük tutulmalı ve remaining CSS güvenli biçimde yüklenmelidir. FOUC oluşmadan LCP iyileşmesi doğrulanmalıdır.

Kullanılmayan CSS'i Temizleme

Legacy global stylesheet zaman içinde kullanılmayan binlerce rule taşıyabilir. Coverage panel ve build analysis hangi CSS'in route üzerinde kullanılmadığını gösterebilir. Dynamic class üretimi nedeniyle otomatik purge kuralları dikkatli yapılandırılmalıdır. Component-scoped CSS veya utility generation gereksiz output'u azaltabilir. CSS cleanup visual regression testleriyle güvence altına alınmalıdır.

Kritik Olmayan JavaScript'i Erteleme

JavaScript download dışında parse, compile ve execution maliyeti taşır. İlk viewport için gerekli olmayan widget, analytics veya modal kodu daha sonra yüklenebilir. Defer veya dynamic import network ve main thread alanı açar. User interaction gerektiren above-the-fold control ise fazla geç hydrate edilmemelidir. JavaScript scheduling LCP ve INP birlikte düşünülerek planlanmalıdır.

Server Rendering ve Hydration'ın LCP Üzerindeki Etkisi

Rendering strategy LCP üzerinde doğrudan etkiye sahiptir çünkü kritik content'in browser'a ne kadar erken ulaştığını belirler. Client-side rendering HTML'i hızlı döndürse bile gerçek içerik JavaScript çalışana kadar görünmeyebilir. SSR ve SSG kritik markup'ı erken sunar, ancak hydration veya server processing yeni bottleneck oluşturabilir. Streaming büyük data dependency'lerin bütün sayfayı bekletmesini azaltabilir. En iyi model route ve content karakterine göre seçilmelidir.

Client-Side Rendering

CSR uygulama shell'ini gönderip asıl içeriği browser JavaScript ile üretir. Bu model ağır bundle ve yavaş device koşullarında LCP elementini ciddi biçimde geciktirebilir. Data fetch JavaScript boot sonrasında başlıyorsa network waterfall daha da uzar. Internal dashboard gibi SEO önceliği düşük uygulamalarda yine uygun olabilir. Kritik content için pre-render veya hybrid yaklaşım değerlendirilmelidir.

Server-Side Rendering

SSR browser'a gerçek içerik markup'ını ilk response'ta sunabilir. LCP resource daha erken keşfedilir ve kullanıcı JavaScript tamamlanmadan içerik görebilir. Buna karşılık yavaş data fetch ve server render TTFB'yi artırabilir. Cache ve parallel data fetching bu maliyeti azaltır. SSR başarı kriteri yalnızca HTML varlığı değil field LCP ve server timing sonuçlarıdır.

Static Site Generation

SSG HTML'i request sırasında üretmek yerine build veya revalidation aşamasında hazırlar. İçerik uygun olduğunda düşük TTFB ve erken resource discovery sağlar. Çok büyük dynamic catalog'da bütün sayfaları build-time üretmek operasyon maliyeti oluşturabilir. Incremental veya on-demand regeneration modelleri alternatif sunar. Content freshness gereksinimi caching stratejisiyle birlikte planlanmalıdır.

Streaming SSR

Streaming SSR sayfanın hazır bölümlerini diğer yavaş bölümleri beklemeden gönderebilir. Critical shell ve LCP content doğru boundary içinde erken stream edilirse kullanıcı ana içeriği daha hızlı görür. Yanlış Suspense yerleşimi hero'nun yavaş data boundary arkasında kalmasına neden olabilir. Streaming placeholder gerçek content boyutundan farklıysa CLS oluşabilir. Server timing ve browser arrival trace birlikte incelenmelidir.

Server Components

Server Components bazı UI logic'ini client JavaScript bundle'a göndermeden server üzerinde çalıştırmayı sağlar. Bu yaklaşım client parse ve hydration maliyetini azaltabilir. Ancak her server component otomatik olarak daha hızlı değildir ve data waterfall yanlış tasarlanabilir. Interactive sınırlar küçük Client Component alanlarında tutulmalıdır. React Next.js uygulamalarında Core Web Vitals ve frontend performans optimizasyonu yapılırken component boundary'leri bundle ve interaction trace ile ölçülmelidir.

HTML Hazır Olduğu Halde Hydration'ın İçeriği Geciktirmesi

Bazı framework uygulamalarında server HTML ekranda bulunmasına rağmen client code content'i geçici olarak gizleyebilir veya state reconciliation bekleyebilir. Bu durumda resource hazır olsa da render delay artar. LCP elementinin hydration completion'a bağımlı olmaması ideal hedeftir. CSS-in-JS initialization veya client feature flag de content visibility'yi geciktirebilir. Trace üzerinde image completion ile actual LCP paint arasındaki gap analiz edilmelidir.

Hydration Waterfall'larını Önlemek

Hydration sırasında component code ve data dependency sequential yüklenirse kullanıcı interaction uzun süre hazır olmayabilir. Route chunk, component chunk ve data request mümkün olduğunca paralel başlatılmalıdır. Server rendering gerekli data'yı payload içinde sunabilir. Above-the-fold interactive controls priority kazanmalıdır. Hydration planı yalnızca LCP değil INP ve early interaction deneyimi açısından da test edilmelidir.

INP'nin Gerçekte Ölçtüğü Üç Aşama

INP yalnızca event handler süresi değildir. Bir etkileşim input delay, processing duration ve presentation delay olmak üzere üç temel bölüme ayrılabilir. Her bölümün root cause'u farklıdır ve doğru optimizasyon için hangisinin dominant olduğunu bilmek gerekir. Main thread önce başka görevle doluysa input delay, event code ağırsa processing duration, büyük render veya layout varsa presentation delay büyür. Production attribution toplamak bu ayrımı gerçek kullanıcı etkileşimleri üzerinde yapmayı mümkün hale getirir.

Input Delay

Input delay kullanıcının etkileşimi ile browser'ın ilgili event processing'e başlayabildiği an arasındaki bekleme süresidir. Main thread başka JavaScript, parsing veya rendering göreviyle doluysa input event queue'da bekler. Bu nedenle kullanıcıyla alakasız analytics script bile INP'yi bozabilir. Long task ve LoAF trace hangi işi beklediğinizi gösterir. Input delay optimizasyonunda main thread üzerindeki toplam iş ve scheduling davranışı azaltılmalıdır.

Kullanıcı Etkileşiminin İşlenmeyi Beklediği Süre

Kullanıcı fiziksel olarak tıklamayı yapmış olsa da browser JavaScript task'ı tamamlanmadan handler'ı çalıştıramaz. Özellikle sayfa yüklenirken büyük bundle evaluation bu beklemeyi artırabilir. Etkileşimin tam öncesindeki task'lar incelenmelidir. Long task parçalama ve non-critical script erteleme en etkili çözümler arasındadır. Kullanıcıya hızlı feedback vermek için main thread sürekli uzun süre bloklanmamalıdır.

Processing Duration

Processing duration interaction'a bağlı event handler'ların çalışması için geçen süredir. Büyük JSON parsing, synchronous validation, state update veya expensive calculation bu süreyi artırabilir. Handler mümkün olduğunca az iş yapmalıdır. Ağır fakat acil olmayan görev sonraki task veya worker'a taşınabilir. Framework render tetikleniyorsa handler dışında resulting render maliyeti de ayrıca değerlendirilmelidir.

Event Handler Çalışma Süresi

Event handler kullanıcıya gerekli minimum state değişikliğini hızlı yapmalıdır. Analytics, logging ve ağır hesaplama aynı callback içinde synchronous çalıştırılmamalıdır. Button click sonrasında önce visual feedback gösterip ikinci aşamada ağır işlem yapmak daha iyi hissettirebilir. Handler profiling gerçek function stack'i ortaya çıkarır. Optimizasyon code size'dan çok execution path üzerinden yapılmalıdır.

Presentation Delay

Presentation delay event processing tamamlandıktan sonra browser'ın yeni frame'i kullanıcıya göstermesine kadar geçen süredir. Bu aralıkta style, layout, paint, requestAnimationFrame callback'leri ve compositor işi bulunabilir. Büyük DOM güncellemesi veya forced layout processing bitmiş olsa bile next paint'i geciktirebilir. LoAF attribution bu bölümde hangi script ve rendering işinin zaman aldığını gösterebilir. INP çalışmasında sadece handler duration'a bakmak bu nedenle eksik analizdir.

Bir Sonraki Frame'in Render Edilmesini Bekleme

Kullanıcı event handler tamamlandıktan sonra gerçek görsel tepkiyi ancak frame çizildiğinde görür. Eğer handler yüzlerce DOM node güncellediyse style ve layout hesapları yeni gecikme oluşturabilir. Büyük chart veya table render'ı bu aşamada pahalı olabilir. Visual feedback küçük subtree üzerinde önce uygulanabilir. Rendering work interaction critical path'ten mümkün olduğunca çıkarılmalıdır.

Hangi INP Alt Süresinin Sorun Olduğunu Belirleme

web-vitals attribution veya DevTools interaction trace alt süreleri ayrı görmeyi sağlar. p75 INP kötü olan route'ta interaction target bazlı aggregation yapılabilir. Input delay yüksekse global main thread, processing yüksekse handler logic, presentation yüksekse render ve layout incelenir. Aynı interaction üç bölümde de maliyet taşıyabilir. Önce en büyük paya odaklanmak engineering effort'u daha etkili kullanır.

Main Thread'i INP İçin Optimize Etmek

Main thread JavaScript, style, layout ve birçok rendering işini yürüttüğü için INP'nin merkezi kaynaklarından biridir. Uzun task'lar kullanıcı input'unun işlenmesini erteler. Büyük işi küçük parçalara bölmek browser'a aralarda interaction ve rendering fırsatı verir. Yield yöntemi işin önceliğine ve browser desteğine göre seçilmelidir. Amaç bütün işleri geciktirmek değil, kullanıcı etkileşimini gereksiz synchronous görevlerden korumaktır.

Long Task Nedir?

Long task ana thread üzerinde uzun süre kesintisiz çalışan ve browser'ın diğer görevleri işlemesini geciktiren task'tır. Performans analizinde 50 ms üzerindeki görevler sık kullanılan teşhis eşiğidir. Bu görev doğrudan interaction handler olmayabilir. Third-party script veya initial bundle evaluation interaction'ın input delay süresini artırabilir. Trace üzerinde long task içindeki function stack ve script source incelenmelidir.

Uzun JavaScript İşlerini Parçalama

Binlerce item işleyen loop tek task içinde çalışmak zorunda değildir. İş küçük batch'lere ayrılıp aralarda browser'a kontrol bırakılabilir. Bu yöntem total compute süresini her zaman azaltmaz, ancak responsiveness'i iyileştirebilir. Batch size cihaz performansına göre test edilmelidir. Çok sık yield ise scheduling overhead oluşturabileceği için ölçerek kullanılmalıdır.

Main Thread'e Düzenli Olarak Kontrol Bırakma

Uzun işlem sırasında browser'ın input ve render görevlerini çalıştırabilmesi için task sınırları oluşturulabilir. Modern scheduling API'leri bu konuda daha açık kontrol sağlar. Eski yöntemler de uygun fallback sunabilir. Yield noktaları kullanıcıya görünür güncellemeden sonra yerleştirildiğinde perceived responsiveness iyileşir. Her birkaç satırda yield yapmak yerine gerçek compute chunk'ları profiling ile belirlenmelidir.

scheduler.yield()

scheduler.yield() uygun browser desteğinde mevcut görevi bölerek continuation'ın scheduling davranışını iyileştirmeye yardımcı olabilir. Özellikle uzun interaction callback içinde UI update sonrasında kontrolü browser'a bırakmak için değerlidir. Feature detection veya fallback stratejisi gerekebilir. Kullanımı total workload'u ortadan kaldırmaz. RUM INP dağılımında gerçek etkisi doğrulanmalıdır.

setTimeout

Sıfır gecikmeli setTimeout yeni task oluşturarak long task parçalamak için eski ve geniş destekli yöntemdir. Timer minimum delay ve scheduling behavior nedeniyle tam öncelik garantisi vermez. Küçük background work chunk'larında kullanılabilir. Çok sayıda nested timer gereksiz overhead oluşturabilir. Daha modern scheduler seçenekleri bulunan ortamlarda kullanım amacı açık olmalıdır.

requestAnimationFrame

requestAnimationFrame bir sonraki paint öncesinde görsel güncellemeyle ilişkili işi çalıştırmak için uygundur. Ağır genel hesaplamayı rAF içine taşımak doğru değildir çünkü frame deadline'ını kaçırabilirsiniz. DOM write ve animation update gibi rendering işleri burada koordine edilebilir. Work kısa tutulmalıdır. Performance trace rAF callback'in presentation delay'e katkısını gösterebilir.

requestIdleCallback

requestIdleCallback kritik olmayan background işi browser'ın idle zamanına bırakmak için kullanılabilir. Kullanıcının hemen beklediği action logic burada tutulmamalıdır. Browser uzun süre idle kalmazsa callback gecikebilir ve timeout davranışı planlanmalıdır. Analytics preprocessing gibi düşük öncelikli işlerde yararlı olabilir. Browser desteği ve product requirement doğrultusunda fallback gerekir.

Kullanıcıya Görsel Tepkiyi Ağır İşlemden Önce Gösterme

Kullanıcı butona bastığında önce pressed, loading veya selected state görmek ister. Ağır işlem bu visual update'ten önce synchronous çalışırsa arayüz donmuş gibi görünür. State update sonrası main thread'e yield etmek browser'ın paint yapmasına fırsat verir. Daha sonra parsing veya hesaplama devam edebilir. Bu yaklaşım gerçek toplam süreyi azaltmasa bile interaction'ın algılanan kalitesini önemli ölçüde artırabilir.

Interaction Overlap Problemi

Bir interaction henüz işlenirken kullanıcı yeni bir interaction başlatabilir. Özellikle typing, drag veya hızlı button click senaryolarında event'ler üst üste binebilir. Önceki ağır iş iptal edilemiyorsa input queue büyür. Abortable async work ve latest-request-wins pattern bazı use case'lerde yardımcı olur. RUM event type ve target segmentasyonu overlap problemine sahip component'leri bulmayı kolaylaştırır.

Long Animation Frames (LoAF) ile INP Kök Neden Analizi

Long Animation Frames API yalnızca uzun task görmekten daha ayrıntılı frame-level attribution sağlayabilir. Bir frame'in script, style ve layout maliyetleriyle neden uzadığını anlamak INP presentation delay analizinde özellikle değerlidir. Script source ve function bilgisi uygun durumlarda sorunlu callback'e kadar inmeyi kolaylaştırır. Production RUM içinde LoAF entry'leri örneklenerek field root cause çıkarılabilir. Veri hacmi yüksek olabileceği için yalnızca kötü interaction veya seçili session'larda toplamak daha verimli olabilir.

Long Tasks API ile LoAF Arasındaki Fark

Long Tasks API ana thread'deki uzun task sınırlarına odaklanır. LoAF ise animation frame'in bütün yaşamını ve bu frame içindeki script ile rendering maliyetlerini daha ayrıntılı ele alır. Bir frame birden fazla task ve style-layout aşaması içerebilir. INP kullanıcıya bir sonraki paint'i beklettiği için frame perspektifi daha açıklayıcı olabilir. İki API birlikte kullanıldığında scheduling ve rendering kaynakları daha net ayrılır.

Yavaş Frame'leri Production'da Yakalamak

Laboratuvar trace her production cihaz problemini tekrar üretmeyebilir. PerformanceObserver uygun browser'larda long-animation-frame entry'lerini toplamak için kullanılabilir. Yalnızca belirli süreyi aşan veya kötü INP ile kesişen frame'leri göndererek telemetry hacmi azaltılabilir. Route ve release ID eklenmelidir. Production trend hangi script'in yeni release sonrası kötüleştiğini gösterebilir.

Sorunlu Script'i Bulmak

LoAF script attribution source URL ve execution timing bilgisi sağlayabilir. Böylece first-party chunk ile third-party script ayrılabilir. Bundle hash tek başına anlaşılır olmadığı için source map veya build manifest mapping backend'de tutulabilir. Script duration route ve interaction target'a göre aggregate edilebilir. En pahalı script business value ile birlikte önceliklendirilmelidir.

Sorunlu Callback'i Bulmak

Uygun attribution function adı ve source position gibi bilgiler sağlayabilir. Minified production code source map üzerinden gerçek function'a eşlenebilir. Callback içinde forced style ve layout maliyeti ayrıca görülebilir. Bu bilgi yalnızca “bundle büyük” demek yerine belirli code path'i düzeltmeyi mümkün hale getirir. Privacy ve source metadata politikası kurum güvenlik gereksinimleriyle uyumlu olmalıdır.

Third-Party JavaScript'in INP Maliyetini Ölçmek

Third-party script kullanıcı interaction'ıyla doğrudan ilişkili olmasa bile main thread'i bloklayabilir. LoAF source URL external script maliyetini görünür hale getirir. Analytics veya experiment script'in toplam task süresi business owner ile paylaşılabilir. Script'i interaction sonrasına ertelemek veya route-specific yüklemek test edilebilir. Third-party performance budget ürün yönetimiyle birlikte uygulanmalıdır.

LoAF Verisini RUM Sistemine Göndermek

LoAF entry nesneleri büyük olabilir ve her frame'i backend'e göndermek doğru değildir. Kötü INP candidate ile kesişen frame'lerden özet bilgi çıkarılabilir. Script source, duration, forced layout ve route metadata yeterli olabilir. Sampling ve cardinality sınırı uygulanmalıdır. Dashboard top offending script ve callback'leri p75 interaction segmentleriyle ilişkilendirmelidir.

web-vitals Attribution ile Yavaş Etkileşimleri Bulmak

Güncel web-vitals attribution build yalnızca INP skorunu değil, etkileşimin neden yavaş olduğuna dair diagnostic alanları da sağlayabilir. Bu alanlar production'da kullanıcıların hangi elementte ve hangi interaction type'ta gecikme yaşadığını anlamayı kolaylaştırır. Input delay, processing duration ve presentation delay alt süreleri doğrudan karşılaştırılabilir. Long animation frame entry'leri ilgili interaction ile eşleştirilebilir. Bu veriyi RUM sistemine route ve release metadata ile göndermek frontend performans analizini tahminden gerçek davranışa taşır.

interactionTarget

interactionTarget INP candidate interaction'ın ilişkilendirildiği DOM target'ını tanımlamaya yardımcı olur. Default selector yüksek cardinality oluşturabilir, bu nedenle custom target generation ile stabil data attribute veya component adı kullanılabilir. Kullanıcıya özel veri selector içine dahil edilmemelidir. Dashboard aynı target'taki p75 ve p95 INP değerlerini gösterebilir. Böylece “hangi buton yavaş” sorusuna production verisiyle cevap verilir.

interactionType

interactionType interaction'ın pointer veya keyboard gibi temel tipini ayırmaya yardımcı olur. Aynı component pointer ile hızlı, keyboard interaction'da farklı code path nedeniyle yavaş olabilir. Event architecture ve accessibility behavior bu farkı açıklayabilir. Type bazlı segmentasyon touch-heavy mobil sayfalarda ayrıca değerlidir. Business analytics ile gereksiz kişisel veri toplamadan kullanılabilir.

inputDelay

inputDelay interaction gerçekleştiği anda main thread'in ne kadar süre meşgul kaldığını gösterir. Yüksek değer handler code'dan önce başka işin kullanıcıyı beklettiğini anlatır. Page load sırasında bundle evaluation veya third-party task sık neden olabilir. Release bazlı input delay trend'i main thread pressure değişimini gösterir. Optimizasyon non-critical workload'u bölme ve erteleme üzerine yoğunlaştırılmalıdır.

processingDuration

processingDuration interaction'a ait event processing'in ne kadar sürdüğünü gösterir. Ağır validation, state update veya synchronous library call bu değeri büyütebilir. Handler içindeki work DevTools profile ile eşleştirilmelidir. Production'da yalnızca belirli target yüksek processing duration üretiyorsa component-specific düzeltme yapılabilir. Bu ayrım global JavaScript cleanup yerine daha hedefli çalışma sağlar.

presentationDelay

presentationDelay event processing bittikten sonra next frame'in kullanıcıya görünmesine kadar geçen süreyi gösterir. Büyük React render, style recalculation veya paint bu bölümde etkili olabilir. LoAF entry'leri presentation tarafındaki script ve layout maliyetini açıklayabilir. Handler hızlı olduğu halde INP kötü ise bu alan özellikle incelenmelidir. Component tree ve CSS containment çözümleri burada değer sağlayabilir.

longAnimationFrameEntries

longAnimationFrameEntries INP candidate ile kesişen uzun frame bilgilerini attribution içinde ilişkilendirebilir. Script execution ve forced layout gibi ayrıntılar kök nedeni bulmayı kolaylaştırır. Browser desteği olmayan kullanıcıda alan boş olabilir. Telemetry pipeline bu durumu normal kabul etmelidir. LoAF verisi yüksek hacimli olduğu için özetleme ve sampling uygulanmalıdır.

Hangi Buton veya Input'un INP'yi Bozduğunu Production'da Tespit Etmek

Component'lere stabil performance label sağlayan data attribute eklemek RUM aggregation'ı kolaylaştırır. Attribution target doğrudan dynamic DOM selector yerine bu etiketi döndürebilir. Dashboard “add-to-cart”, “search-input” veya “checkout-submit” gibi business anlamlı gruplar oluşturur. INP subpart ve device segment aynı target altında karşılaştırılır. Etkileşimli arayüz tasarımının performansla ilişkisini daha geniş kullanıcı deneyimi açısından değerlendirmek için https://www.diyarbakiryazilim.com.tr/posts/etkilesimli-arayuz-tasarimi-kullanici-deneyimi-odakli-gelistirme içeriği de incelenebilir.

JavaScript Maliyetini Radikal Olarak Azaltmak

JavaScript performansının en önemli gerçeği, indirilen her byte'ın daha sonra parse ve çoğu durumda execute edilmek zorunda olmasıdır. Bu maliyet özellikle düşük segment mobil cihazlarda büyür. Bundle küçültme yalnızca network değil CPU ve memory kullanımını da azaltır. Route ve component bazlı splitting kullanıcıya ihtiyaç duymadığı code'u göndermemeyi hedefler. En etkili çözüm bazen optimize edilmiş library değil, o library'yi tamamen yüklememektir.

Bundle Analysis

Bundle analyzer hangi package ve module'ün initial chunk içinde yer aldığını görünür hale getirir. Büyük dependency yalnızca dosya boyutuyla değil execution maliyetiyle de değerlendirilmelidir. Duplicate library version'ları ve locale data sık bulunan israftır. Route bazında initial ve lazy chunk ayrı incelenmelidir. Bundle size budget pull request aşamasında regresyonu engelleyebilir.

Tree Shaking

Tree shaking kullanılmayan ESM export'larını production bundle'dan çıkarabilir. Side effect içeren package'lar bu optimizasyonu sınırlayabilir. Import biçimi library'nin bütününü yanlışlıkla bundle'a dahil edebilir. Build output gerçek kullanılan bytes üzerinden kontrol edilmelidir. Tree shaking tek başına ağır runtime logic problemini çözmez.

Route-Based Code Splitting

Her route bütün application JavaScript'ini ilk yüklemede almak zorunda değildir. Router veya framework route chunk'ları yalnızca ihtiyaç olduğunda indirebilir. Critical route bundle küçük tutulmalıdır. Route prefetch kullanıcı intent'ine göre sonraki navigation'ı hızlandırabilir. Çok küçük onlarca chunk ise request ve scheduling overhead yaratabileceği için denge gerekir.

Component-Based Lazy Loading

Modal, chart veya editor gibi ilk ekranda gerekmeyen ağır component'ler lazy yüklenebilir. Placeholder gerçek boyutu koruyarak CLS önlemelidir. Interaction sonrası ilk açılışta network gecikmesi oluşmaması için intent-based prefetch düşünülebilir. Above-the-fold critical control gereksiz lazy yapılmamalıdır. Component split kararı execution ve kullanım sıklığına göre verilmelidir.

Dynamic Import

Dynamic import() code'un yalnızca belirli koşul oluştuğunda yüklenmesini sağlar. Ağır parser veya export library kullanıcı gerçekten özelliği açtığında indirilebilir. Bundler split point'i otomatik oluşturabilir. Error handling network failure durumunu kapsamalıdır. Dynamic import'u her küçük utility için kullanmak chunk sayısını gereksiz artırabilir.

Kullanılmayan Polyfill'leri Kaldırmak

Modern browser hedefleyen uygulama eski platformlar için büyük polyfill set'leri taşıyor olabilir. Browser support policy güncel tutulmalıdır. Differential loading veya conditional polyfill gerekli kullanıcıya uygun code gönderebilir. Feature support gerçek analytics browser dağılımıyla doğrulanmalıdır. Polyfill kaldırmak yalnızca network değil parse ve initialization maliyetini azaltır.

Ağır Kütüphaneleri Native Browser API'leriyle Değiştirmek

Bazı utility library'lerin yaptığı işler modern browser API'leriyle daha küçük code kullanılarak yapılabilir. Ancak native replacement maintenance ve compatibility açısından değerlendirilmelidir. Tarih, grafik veya zengin editor gibi karmaşık domain'lerde library değeri yüksek olabilir. Bundle cost business faydayla karşılaştırılmalıdır. Sadece dependency sayısını azaltmak uğruna daha hatalı custom implementation yazılmamalıdır.

Framework Runtime Maliyetini Değerlendirmek

Framework seçimi initial JavaScript ve update cost üzerinde etkili olabilir, ancak tek başına performansı belirlemez. Büyük third-party dependency ve kötü rendering pattern küçük framework avantajını kolayca yok edebilir. Uygulamanın gerçek interaction ve component tree davranışı ölçülmelidir. Server rendering ve partial hydration gibi architecture seçenekleri runtime yükünü azaltabilir. Framework değiştirmek son derece pahalı olduğu için önce mevcut code path optimize edilmelidir.

Hydration Maliyetini INP Açısından Azaltmak

Server-rendered HTML hızlı görünse bile hydration sırasında browser büyük JavaScript graph parse edip event listener bağlayabilir. Kullanıcı bu sırada interaction yaparsa input delay artabilir. Gereksiz client component'leri azaltmak ve non-interactive UI'ı server tarafında tutmak önemli kazanım sağlar. Partial veya selective hydration architecture'ları yalnızca gerekli adaları aktive etmeyi hedefler. Above-the-fold interaction'lar mümkün olduğunca erken kullanılabilir olmalıdır.

Gereksiz Client Component'leri Azaltmak

Bir component yalnızca static text veya layout render ediyorsa client runtime gerektirmeyebilir. Client boundary geniş tutulduğunda child dependency'ler de browser bundle'a taşınabilir. Interactive leaf component'ler küçük sınırlar halinde ayrılmalıdır. Bundle graph ve hydration profile bu sınırların etkisini gösterir. Architecture convention yeni geliştirilen component'lerin varsayılan olarak client olmasını engelleyebilir.

Server Components Kullanmak

Server Components browser'a gönderilen JavaScript miktarını azaltmak için uygun içeriklerde kullanılabilir. Data fetching server tarafına taşındığında client effect waterfall da azalabilir. Interactive behavior yine Client Component gerektirir. Boundary yanlış yerde kurulursa serialization ve data duplication ortaya çıkabilir. Performans sonucu actual bundle ve INP üzerinden ölçülmelidir.

Partial Hydration

Partial hydration sayfanın yalnızca interactive parçalarının client tarafında hydrate edilmesini hedefler. Static content JavaScript runtime'a dahil olmaz. Bu yaklaşım initial CPU yükünü önemli ölçüde azaltabilir. Framework desteği ve component communication modeli architecture kararını etkiler. Dynamic island'ların layout placeholder'ları CLS yaratmamalıdır.

Selective Hydration

Selective hydration farklı UI bölümlerinin priority veya kullanıcı etkileşimine göre hydrate edilmesini sağlar. Kullanıcının tıkladığı component düşük öncelikli başka alanları beklememelidir. Streaming ve Suspense modelleri bu davranışı destekleyebilir. Hydration sırasında event replay behavior framework'e göre değişir. Early interaction senaryoları gerçek yavaş cihazda test edilmelidir.

Islands Architecture

Islands modelinde çoğu sayfa static veya server-rendered kalırken yalnızca interactive adalar client JavaScript alır. Content-heavy sitelerde bundle maliyetini ciddi biçimde azaltabilir. Global state ve adalar arası iletişim karmaşık use case'lerde ek architecture gerektirir. Her ürün tam island modeline uygun değildir. Metrik hedefi framework trend'inden önce gelmelidir.

Above-the-Fold Etkileşimleri Önceliklendirmek

Hero search, navigation veya add-to-cart gibi ilk ekranda kullanıcı tarafından hemen kullanılabilecek control'ler hydration priority almalıdır. Below-the-fold review widget daha sonra hydrate edilebilir. Component visibility ve interaction probability bu önceliği belirleyebilir. HTML görünür olup control çalışmıyorsa kullanıcı için yanıltıcı deneyim oluşur. Early interaction RUM metriği hydration başarısını ölçmeye yardımcı olur.

Hydration Sırasında Kullanıcı Etkileşimini Engellememek

Büyük hydration task'ını tek seferde çalıştırmak input delay yaratabilir. Chunk splitting ve scheduling browser'a interaction fırsatı sağlayabilir. Framework'in concurrent veya selective hydration yetenekleri doğru kullanılmalıdır. Third-party initialization hydration ile aynı anda başlamamalıdır. Production interaction timing özellikle page load'ın ilk saniyelerinde ayrıca segmentlenebilir.

Web Workers ile Ana Thread'i Boşaltmak

Web Worker CPU yoğun fakat DOM'a doğrudan ihtiyaç duymayan işleri main thread dışına taşıyabilir. Büyük parsing, search indexing veya cryptographic calculation iyi adaylardır. Worker'a taşınan işin serialization ve message transfer maliyeti göz ardı edilmemelidir. Küçük işlerde worker overhead faydadan yüksek olabilir. Performance profile hangi task'ın gerçekten interaction'ı blokladığını göstermeden worker eklemek gereksiz architecture yükü oluşturur.

Hangi İşler Worker'a Taşınmalı?

Worker için en uygun işler bağımsız, CPU yoğun ve DOM erişimine ihtiyaç duymayan görevlerdir. Uzun süre synchronous çalışan algoritmalar interaction input delay oluşturuyorsa aday olabilir. Work sonucu UI'a küçük mesajla dönebiliyorsa communication maliyeti düşüktür. DOM manipulation worker içinde yapılamaz. Main thread ile worker arasında sürekli küçük mesaj trafiği de performansı olumsuz etkileyebilir.

Büyük Veri İşleme

Binlerce kayıt üzerinde aggregation veya transformation main thread'de yüzlerce milisaniye sürebilir. Worker bu hesaplamayı kullanıcı interaction'ından ayırabilir. Result geldikten sonra UI update yine main thread'de yapılır. Büyük object clone etmek maliyetli olabileceği için data formatı optimize edilmelidir. Incremental processing bazı use case'lerde worker'dan daha basit çözüm olabilir.

Arama ve Filtreleme

Büyük local dataset üzerinde fuzzy search veya complex filtering typing sırasında INP'yi bozabilir. Search index worker içinde hazırlanabilir ve query mesajları gönderilebilir. Input UI hemen update olmaya devam eder. Sonuç stale query'ye aitse discard edilmelidir. Debounce yalnızca gereksiz request sayısını azaltır ve ağır tek query'nin CPU maliyetini çözmez.

Parsing

Büyük JSON, CSV veya custom format parsing main thread'i bloklayabilir. Worker parsing sonucu structured data döndürebilir. Streaming parser kullanmak memory ve latency açısından daha iyi olabilir. Payload worker'a aktarılırken copy maliyeti ölçülmelidir. Parsing gerçekten user interaction critical path'teyse architecture source data boyutunu da azaltmayı düşünmelidir.

Şifreleme ve Hesaplama

CPU yoğun cryptographic veya numerical calculation worker için uygun olabilir. Native Web Crypto API bazı işlemleri zaten asynchronous ve browser optimized şekilde gerçekleştirebilir. Önce native API değerlendirilmelidir. Worker security boundary değildir ve sensitive data handling aynı güvenlik kurallarına tabidir. İşin toplam enerji ve mobil battery maliyeti de göz önünde bulundurulmalıdır.

Worker Haberleşme Maliyetini Hesaba Katmak

postMessage ile büyük object gönderildiğinde structured cloning zaman ve memory maliyeti yaratabilir. Main thread'deki clone işlemi beklenen faydayı azaltabilir. Data minimal ve serializable tutulmalıdır. High-frequency message yerine batch sonuç gönderilebilir. Performance trace worker architecture'ın net INP iyileşmesi sağladığını doğrulamalıdır.

Transferable Objects Kullanımı

ArrayBuffer gibi transferable object'ler veriyi kopyalamak yerine ownership transfer ederek message maliyetini azaltabilir. Transfer sonrası source context buffer'a erişemez. Architecture bu ownership modeline uygun tasarlanmalıdır. Büyük binary veya numerical data işleme için özellikle değerlidir. Küçük payload'larda optimization farkı anlamlı olmayabilir.

Event Handling Optimizasyonu

Event handling kullanıcı interaction path'inin doğrudan parçasıdır. Handler içinde gereksiz synchronous iş, çok fazla listener veya sürekli scroll hesaplaması INP'yi kötüleştirebilir. Delegation ve passive listener doğru senaryolarda browser işini azaltır. Debounce ve throttle davranışın semantiğine göre kullanılmalıdır. Event lifecycle component unmount sonrasında temizlenmezse hem memory hem beklenmeyen processing maliyeti oluşabilir.

Ağır Event Handler'lardan Kaçınmak

Click handler içinde network dışı ağır parsing veya uzun loop bulunmamalıdır. Kullanıcıya gerekli state değişikliği önce yapılmalıdır. Analytics ve non-critical logging sonraki task'a bırakılabilir. Handler profile function bazında incelenmelidir. Ağır logic gerekliyse worker veya incremental task modeli kullanılabilir.

Event Delegation

Çok sayıda benzer child element için ayrı listener yerine parent seviyesinde delegation kullanılabilir. Bu yöntem listener sayısını ve setup maliyetini azaltabilir. Event bubbling behavior doğru anlaşılmalıdır. Her component architecture için zorunlu değildir. Framework'ün kendi event delegation sistemi varsa duplicate custom yapı eklenmemelidir.

Passive Event Listener

Scroll veya touch event listener default behavior'ı engellemeyecekse passive olarak işaretlenebilir. Browser scroll işlemini listener sonucunu beklemeden daha rahat ilerletebilir. preventDefault gereken event'te passive kullanılamaz. Framework veya browser default davranışı kontrol edilmelidir. Input responsiveness trace ile doğrulanmalıdır.

Scroll ve Pointer Event'lerini Optimize Etmek

Scroll ve pointermove çok yüksek frekansta tetiklenebilir. Her event'te DOM read-write yapmak layout thrashing oluşturabilir. requestAnimationFrame üzerinden visual update batching yapılabilir. IntersectionObserver bazı visibility hesaplarını daha verimli çözer. Event frequency ve callback duration production profile'da ölçülmelidir.

Debounce ve Throttle Ne Zaman Kullanılmalı?

Debounce kullanıcı belirli süre durduktan sonra işlemi çalıştırır ve search request gibi use case'lerde uygundur. Throttle belirli aralıkta en fazla bir işlem yapılmasını sağlar ve scroll telemetry gibi durumlarda kullanılabilir. Input'un görsel value update'i debounce edilmemelidir. Ağır calculation ayrı layer'da geciktirilebilir. Delay değeri kullanıcı beklentisine göre test edilmelidir.

Gereksiz Event Listener'ları Temizlemek

Component kaldırıldıktan sonra global listener kalırsa memory ve processing maliyeti birikir. Lifecycle cleanup standart hale getirilmelidir. AbortController listener cleanup için kullanılabilir. Duplicate registration debug edilmelidir. Long-running SPA session'larında listener count telemetry memory problemine erken sinyal verebilir.

Framework Render Maliyetini Düşürmek

Framework rendering kullanıcı interaction sonrasında presentation delay'in önemli kaynağı olabilir. Gereksiz re-render, çok geniş state propagation ve büyük listeler main thread'i gereksiz meşgul eder. Memoization her component'e otomatik uygulanmamalı ve gerçek profile sonucu üzerinden seçilmelidir. State mümkün olduğunca yalnızca ihtiyaç duyan subtree'ye yakın tutulmalıdır. Büyük update'ler kullanıcıya kritik ve düşük öncelikli işler olarak ayrılabilir.

Gereksiz Re-Render'ları Bulmak

Framework profiler hangi component'lerin interaction sonrasında tekrar render olduğunu gösterir. Parent state değişikliği binlerce child'ı gereksiz etkileyebilir. Stable props ve state partitioning render alanını küçültür. Render sayısından çok render süresi ve resulting DOM work önemlidir. Küçük component'in tekrar render olması her zaman optimize edilmeye değer değildir.

State'i Doğru Yerde Tutmak

Global state bütün uygulamayı etkileyebilecek broad subscriptions oluşturabilir. Component-local state yalnızca gerekli subtree'yi günceller. Shared state gerçekten birden fazla bağımsız alan tarafından kullanılıyorsa merkezi tutulmalıdır. Selector ve subscription granularity doğru tasarlanabilir. State architecture performance ile code readability arasında denge kurmalıdır.

Büyük Component Tree Güncellemelerini Azaltmak

Tek input değişikliğinin tüm dashboard'u render etmesi INP'yi olumsuz etkiler. Component boundaries ve stable children subtree update kapsamını sınırlar. Expensive chart veya table yalnızca ilgili data değiştiğinde güncellenmelidir. Framework profiler render flamegraph üzerinden gerçek maliyeti gösterir. DOM update sayısı da browser rendering maliyetiyle birlikte incelenmelidir.

Memoization'ı Ölçerek Kullanmak

Memoization computation veya render tekrarını azaltabilir, ancak comparison ve memory maliyeti vardır. Çok ucuz component'lerde memoization code'u daha zor anlaşılır hale getirebilir. Expensive calculation profiling sonucunda cache edilebilir. Dependency list doğru tutulmalıdır. Optimization başarısı interaction timing ile ölçülmelidir.

Büyük Listelerde Virtualization

Binlerce DOM row aynı anda render edildiğinde layout ve memory maliyeti artar. Virtualization yalnızca viewport çevresindeki item'ları render eder. Dynamic row height implementation'ı daha zor hale getirebilir. Accessibility ve browser find behavior düşünülmelidir. Product listelerinde content-visibility daha basit alternatif olabilir ve iki yaklaşım gerçek kullanım üzerinden karşılaştırılmalıdır.

Kullanıcı Etkileşimlerini Düşük Öncelikli Güncellemelerden Ayırmak

Input value veya pressed state yüksek öncelikli kullanıcı feedback'idir. Büyük filter result veya analytics hesaplaması aynı anda yapılmak zorunda değildir. Framework scheduling veya transition API'leri düşük öncelikli UI update'lerini ayırabilir. Kullanıcı control'ü hemen tepki verirken sonuç biraz sonra güncellenebilir. Bu pattern özellikle search ve complex dashboard interaction'larında INP'yi iyileştirebilir.

CLS'yi Sıfıra Yaklaştırmak

CLS optimizasyonunun temel prensibi browser'ın content gelmeden önce ne kadar alan ayırması gerektiğini bilmesidir. Görsel, video, iframe, reklam ve skeleton boyutları önceden belirlenmelidir. Dynamic banner mevcut content'i aşağı itmek yerine overlay veya reserved slot kullanabilir. Kullanıcı interaction sonrası bilinçli layout değişiklikleri CLS hesabında farklı değerlendirilse de kullanıcı deneyimi yine düşünülmelidir. Production layout shift attribution gerçek sorunlu elementleri bulmada çok değerlidir.

Görseller İçin width ve height

Image element üzerinde intrinsic width ve height browser'ın aspect ratio'yu resource yüklenmeden bilmesini sağlar. Responsive CSS ile görüntü yine container'a uyarlanabilir. Attribute değerleri gerçek kaynak oranıyla uyumlu olmalıdır. CMS image metadata bu değerleri otomatik sağlayabilir. Framework image component'leri bu davranışı default sunuyorsa doğru kullanım korunmalıdır.

CSS aspect-ratio

aspect-ratio dynamic veya responsive media container için yükleme öncesinde alan ayırmayı kolaylaştırır. Video card veya remote image dimension bilinmediğinde ratio metadata yeterli olabilir. Yanlış ratio content geldiğinde yeni shift oluşturur. Breakpoint'e göre crop değişiyorsa ratio da doğru değişmelidir. Placeholder ve gerçek media aynı box model'i paylaşmalıdır.

Video ve iframe Alanlarını Önceden Ayırmak

Embed video veya map iframe sonradan yüklenirken sıfır yükseklikten büyürse ciddi CLS oluşur. Wrapper önceden gerçek aspect ratio'yu korumalıdır. Consent nedeniyle embed geç yükleniyorsa placeholder aynı ölçüyü taşımalıdır. Responsive layout için maximum width ve ratio birlikte kullanılabilir. Third-party script'in inline style ile boyutu değiştirmesi test edilmelidir.

Reklam Slotlarını Rezerve Etmek

Ad slot auction sonucunda farklı boyutlarda creative getirebilir. Layout başlamadan önce mümkün olan slot boyutu veya minimum height ayrılmalıdır. Reklam gelmezse alanın tamamen kapanması da content shift yaratabilir. Product ve ad team boş slot davranışını birlikte belirlemelidir. Revenue ile CLS trade-off'u A/B test üzerinden değerlendirilebilir.

Skeleton Tasarımının Gerçek İçerikle Aynı Boyutlarda Olması

Skeleton yalnızca yükleniyor hissi vermek değil layout reservation görevi de görür. Gerçek content geldiğinde skeleton farklı yüksekliğe sahipse kullanıcı yine shift görür. Card title line count ve image ratio mümkün olduğunca gerçek layout'a yakın modellenmelidir. Dynamic text tam tahmin edilemiyorsa minimum stable box kullanılabilir. Streaming SSR fallback'lerinde bu konu özellikle önemlidir.

Çerez Banner'larının İçeriği Aşağı İtmesini Önlemek

Consent banner page load sonrasında document flow'un üstüne eklenirse bütün content aşağı kayabilir. İlk HTML'de alan ayırmak veya viewport overlay kullanmak daha stabil yaklaşım olabilir. Overlay accessibility ve content obstruction açısından dikkatli tasarlanmalıdır. Kullanıcının seçimi sonrası banner kaybolurken yeni layout shift oluşup oluşmadığı kontrol edilmelidir. Consent management third-party script davranışı da audit edilmelidir.

Font Kaynaklı CLS'yi İleri Seviyede Önlemek

Web font yüklenirken fallback font ile final font arasındaki glyph metrics farkı text box boyutunu değiştirebilir. Bu durum heading ve navigation alanlarında belirgin CLS oluşturabilir. Font preload yüklemeyi erkene çekebilir, fakat metrics uyumsuzluğunu tek başına çözmez. Fallback seçimi ve CSS font metric override özellikleri daha yakın ilk render sağlar. FOIT ve FOUT arasında marka, okunabilirlik ve performans ihtiyacı dengelenmelidir.

font-display

font-display web font yüklenirken text'in nasıl gösterileceğini kontrol eder. swap kullanıcıya hemen fallback text gösterir, ancak sonradan font değişimi layout shift yaratabilir. optional bazı koşullarda geç font swap'ını önleyebilir. Brand typography gereksinimi hangi stratejinin uygun olduğunu etkiler. Field CLS ve perceived text availability birlikte değerlendirilmelidir.

Font Preload

Above-the-fold critical font preload edildiğinde download daha erken başlayabilir. Yalnızca gerçekten ilk viewport'ta kullanılan format ve weight seçilmelidir. Çok fazla font preload LCP image ile bandwidth rekabeti yaratır. CORS attribute doğru olmalıdır. Font subset ve unicode-range ile transferred bytes azaltılabilir.

Self-Hosted Font Kullanımı

Self-hosted font external connection setup ihtiyacını azaltabilir ve cache header kontrolünü artırır. Lisans koşulları mutlaka uygun olmalıdır. CDN üzerinden site origin'ine yakın dağıtım yapılabilir. Font file compression ve subset ayrı optimize edilir. Self-hosting tek başına CLS'yi çözmez ve fallback metrics yine önemlidir.

Fallback Font Seçimi

Fallback font final font'a benzer x-height, width ve line metrics taşıdığında swap sırasında daha az layout değişir. Sadece generic sans-serif kullanmak bazı brand fontlarda büyük fark oluşturabilir. System font alternatifleri farklı platformlarda test edilmelidir. Fallback chain operating system dağılımına göre değişir. Metric override ile kalan fark daha da azaltılabilir.

size-adjust

size-adjust fallback font glyph'lerini final font'a daha yakın görünür ölçüye getirmek için kullanılabilir. Amaç font swap sırasında text width ve line break değişimini azaltmaktır. Değer font pair üzerinden hesaplanmalıdır. Her brand font için farklı adjustment gerekebilir. Visual ve CLS testleri sonucu doğrulamalıdır.

ascent-override

ascent-override font ascent metric'ini kontrol ederek line box uyumunu iyileştirir. Fallback ve final font arasındaki vertical metrics farkını azaltabilir. Tek başına değil descent ve line-gap ayarlarıyla birlikte kullanılır. Değerler gerçek font metrics üzerinden hesaplanmalıdır. Yanlış override text clipping veya alignment problemi oluşturabilir.

descent-override

descent-override baseline altındaki font metric alanını ayarlamaya yarar. Fallback text'in line box yüksekliğini final font'a yaklaştırır. Form control ve heading alignment gibi alanlarda fark görülebilir. Cross-browser rendering test edilmelidir. Otomatik font metric tooling hesaplama sürecini kolaylaştırabilir.

line-gap-override

line-gap-override font'un varsayılan line gap değerini değiştirebilir. Farklı font family'ler aynı CSS line-height altında farklı line box davranışı gösterebilir. Fallback ve final font eşleştirmesinde bu özellik yararlıdır. Body text readability göz ardı edilmemelidir. CLS azaltmak uğruna satırların gereğinden fazla sıkışmasına izin verilmemelidir.

FOIT ve FOUT Arasındaki Trade-Off

FOIT font gelene kadar text'i görünmez tutarken FOUT fallback text'i hemen gösterir ve sonra swap yapar. FOIT content visibility ve LCP açısından olumsuz olabilir. FOUT daha hızlı içerik sunar fakat metrics uyumsuzsa CLS yaratabilir. Modern yaklaşım hızlı fallback display ve yakın font metrics kombinasyonudur. Business branding gereksinimi gerçek user data ile birlikte değerlendirilmelidir.

Animasyonların CLS ve INP Üzerindeki Etkisi

Animasyon doğru property kullanmadığında hem layout shift hem main thread rendering maliyeti üretebilir. top, left veya geometry değişiklikleri layout hesaplamasını tetikleyebilir. Transform ve opacity çoğu durumda compositor-friendly alternatiflerdir. JavaScript animation loop'ları frame budget içinde kalmalıdır. Reduced-motion preference kullanıcının hareket ihtiyacına saygı gösterecek şekilde bütün animation system'e uygulanmalıdır.

Layout Tetikleyen CSS Özellikleri

Geometry etkileyen property değişiklikleri browser'ın layout ve bazen paint yapmasını gerektirir. Animation her frame'de bu hesaplamayı tetiklerse düşük cihazlarda frame drop görülür. Kullanıcı interaction sırasında aynı main thread işi INP'yi uzatabilir. Layout animation gerekli olduğunda FLIP gibi teknikler transform tabanlı görsel hareket oluşturabilir. DevTools rendering trace gerçek maliyeti ölçmelidir.

top

top positioned elementin geometry'sini değiştirir ve layout etkisi oluşturabilir. Sürekli animation için transform translate çoğu zaman daha uygun olur. Static state değişikliğinde top kullanımı sorun değildir. Problem her animation frame'inde tekrar hesaplamadır. Component animation guideline hangi property'lerin kullanılacağını açıkça belirtmelidir.

left

left horizontal position değiştirirken layout veya paint maliyeti yaratabilir. Drag interaction'da her pointer event'te left güncellemek jank oluşturabilir. Transform translateX daha compositor-friendly olabilir. Final layout position gerekiyorsa animation sonunda gerçek property güncellenebilir. Trace üzerinde style ve layout süresi karşılaştırılmalıdır.

width

width değişikliği element ve çevresindeki layout'u etkileyebilir. Progress bar gibi görsel animation transform scaleX ile daha ucuz uygulanabilir. Content gerçek anlamda yeniden akacaksa width değişikliği kaçınılmaz olabilir. Bu durumda update frequency sınırlandırılmalıdır. Large subtree containment maliyeti azaltabilir.

height

Height animation accordion gibi component'lerde sık kullanılır. height:auto transition zor olduğu için JavaScript measurement yapılabilir ve forced layout oluşabilir. CSS grid veya transform tabanlı alternatifler değerlendirilebilir. Kullanıcı interaction'ın hemen ardından büyük subtree layout'u INP'yi etkileyebilir. Component gerçek content size ve accessibility davranışıyla birlikte test edilmelidir.

margin

Margin değişikliği çevredeki sibling layout'unu etkileyebilir. Animated spacing için transform daha ucuz olabilir. Static responsive layout'ta margin tamamen normal ve güvenli kullanımdır. Performance problemi property'nin varlığından değil yüksek frekansta değiştirilmesinden doğar. Style recalculation ve layout timeline bunu açıkça gösterir.

Compositor-Friendly Animations

Transform ve opacity browser'ın çoğu durumda layout yapmadan compositor üzerinde güncelleyebileceği property'lerdir. Bu durum daha stabil frame rate sağlar. Ancak büyük layer veya filter kullanımı GPU memory maliyeti oluşturabilir. Her elemente will-change vermek doğru değildir. Animation profiling gerçek layer ve paint behavior'ını doğrulamalıdır.

transform

transform translate, scale ve rotate hareketlerinde geometry hesabını sınırlamaya yardımcı olur. Drag ve micro-interaction için güçlü seçenektir. Transform visual position değiştirirken document flow'u değiştirmez. Accessibility veya hit target behavior bunun farkında tasarlanmalıdır. Çok büyük transformed layer raster memory maliyeti yaratabilir.

opacity

Opacity fade animation için genellikle düşük maliyetli property'dir. Hidden element opacity sıfır olsa bile interaction veya layout içinde kalabilir. Visibility ve pointer behavior ayrıca kontrol edilmelidir. Büyük full-screen layer opacity animation GPU compositing maliyeti oluşturabilir. Reduced-motion kullanıcılarında gereksiz fade bile azaltılabilir.

requestAnimationFrame Kullanımı

JavaScript visual update'leri browser paint döngüsüyle senkronize etmek için requestAnimationFrame kullanılabilir. Callback frame deadline içinde kısa kalmalıdır. DOM read ve write batching layout thrashing'i azaltır. Heavy calculation rAF içinde yapılmamalıdır. Animation cancellation component lifecycle sırasında doğru yönetilmelidir.

prefers-reduced-motion

Kullanıcının azaltılmış hareket tercihi yalnızca decorative animation'ı değil large transition ve parallax behavior'ı da etkilemelidir. CSS media query ve JavaScript matchMedia birlikte kullanılabilir. Kullanıcı state değişikliğini yine anlamalıdır. Motion tamamen kaldırıldığında farklı visual feedback sağlanabilir. Accessibility pipeline bu modu da screenshot ve interaction testlerine dahil etmelidir.

JavaScript Animasyonlarını Minimuma İndirmek

CSS compositor animation yeterliyse JavaScript loop eklemek gereksiz main thread yükü yaratır. Complex physics veya canvas animation gerçekten JS gerektirebilir. Bu durumda frame work küçük tutulmalıdır. Offscreen veya tab hidden olduğunda animation durdurulmalıdır. INP interaction sırasında animation script'in long frame'e katkısı LoAF ile izlenebilir.

content-visibility ile Ekran Dışı Render Maliyetini Azaltmak

content-visibility uzun sayfalarda viewport dışındaki bölümlerin rendering işini erteleyerek initial style, layout ve paint maliyetini azaltabilir. Bu özellik özellikle uzun article ve büyük product listing senaryolarında değerlidir. Ancak browser'ın görünmeyen content için tahmini boyuta ihtiyacı vardır. Yanlış intrinsic size kullanıcı scroll ederken layout shift üretebilir. Gerçek content yapısına göre contain-intrinsic-size değerleri test edilmelidir.

content-visibility: auto

content-visibility:auto browser'a viewport dışındaki subtree rendering işini atlama fırsatı verir. Element viewport'a yaklaşınca gerekli layout ve paint yapılır. Initial rendering time ve memory kullanımı azalabilir. Interactive veya programatik ölçülen element davranışı test edilmelidir. Her küçük elemente uygulamak yerine büyük bağımsız section'larda kullanmak daha anlamlıdır.

contain-intrinsic-size

contain-intrinsic-size content henüz render edilmediğinde browser'ın yaklaşık boyut kullanmasını sağlar. Bu değer scroll bar ve layout stability için önemlidir. Gerçek section boyutundan çok farklı tahmin görünür hale geldiğinde shift yaratabilir. Browser geçmiş rendered size bilgisinden yararlanabilen syntax seçenekleri destekleyebilir. Uygulama representative content üzerinden uygun başlangıç değeri seçmelidir.

Uzun Makalelerde Kullanım

Çok uzun article sayfasında ekranın altında onlarca section initial paint için gerekli değildir. Section wrapper'larında content-visibility render cost'i azaltabilir. Heading anchor navigation ve browser find behavior test edilmelidir. Advertisement veya embedded content farklı height üretebilir. Field INP ve LCP yanında scroll smoothness de ölçülmelidir.

Büyük Ürün Listelemelerinde Kullanım

Yüzlerce product card DOM'da bulunduğunda style ve layout maliyeti artar. Content-visibility offscreen card gruplarını daha ucuz hale getirebilir. Virtualization kadar agresif değildir ve DOM semantic yapısını korur. Image lazy loading ile birlikte uygulanabilir. Card height tahmini doğru tutulmalıdır.

Infinite Scroll Senaryoları

Infinite scroll yeni content ekledikçe DOM sürekli büyüyebilir. Content-visibility eski offscreen sections rendering maliyetini azaltabilir fakat memory tamamen çözülmez. Çok uzun session'da virtualization veya DOM pruning gerekebilir. Scroll position korunmalıdır. RUM session length bazında INP ve memory trend'i izlenebilir.

Yanlış Boyut Tahmininin CLS Oluşturmasını Önlemek

Intrinsic size gerçek content'ten belirgin farklıysa viewport'a yaklaşırken layout boyutu değişir. Bu durum kullanıcıya shift olarak yansıyabilir. Section type bazlı farklı tahmin değerleri kullanılabilir. Render olduktan sonra gerçek size browser tarafından yeniden kullanılabilir. Visual test yalnızca initial viewport'ta değil scroll senaryosunda yapılmalıdır.

CSS Containment ile Rendering Scope'u Küçültmek

CSS containment belirli subtree'nin layout, paint veya size etkisini çevresinden izole etmeye yardımcı olabilir. Karmaşık dashboard ve bağımsız widget yapılarında style değişikliğinin bütün sayfaya yayılmasını sınırlar. Yanlış containment content sizing ve overflow behavior'ını bozabilir. Hangi containment türünün gerçekten gerekli olduğu anlaşılmalıdır. DevTools rendering profile before-after farkını göstermelidir.

contain: layout

Layout containment element içindeki geometry değişikliklerinin dış layout üzerindeki etkisini sınırlar. Bağımsız widget'larda pahalı relayout kapsamını azaltabilir. Element dışındaki positioning behavior değişebilir. Component design bu constraint'e uygun olmalıdır. Her container'a otomatik uygulanmamalıdır.

contain: paint

Paint containment element içeriğinin kendi bounds dışına boyanmasını sınırlar. Browser invalidation scope'u küçültebilir. Dropdown veya tooltip taşması gereken component'te sorun oluşturabilir. Overflow behavior test edilmelidir. Dashboard tile gibi bağımsız yüzeyler iyi aday olabilir.

contain: size

Size containment elementin child content'inin parent sizing hesabına etkisini sınırlar. Explicit veya intrinsic size stratejisi gerektirir. Yanlış kullanım elementin sıfır veya beklenmeyen boyuta düşmesine yol açabilir. Bu nedenle daha ileri use case olarak görülmelidir. Content-visibility ile kullanılan intrinsic size davranışı ayrıca anlaşılmalıdır.

contain: content

contain:content layout ve paint gibi containment davranışlarını bir araya getiren shorthand yaklaşımıdır. Bağımsız component subtree'lerinde kullanışlı olabilir. Size containment içermediği için bazı use case'lerde daha güvenlidir. Sticky veya positioned child davranışı test edilmelidir. Performance benefit actual rendering workload'a göre değişir.

Karmaşık Dashboard ve Widget Yapılarında Kullanımı

Dashboard birçok bağımsız chart ve panel içerdiğinde bir widget update'i bütün page style-layout işini büyütebilir. Containment widget sınırlarını browser rendering açısından daha net hale getirir. Chart library canvas veya SVG behavior'ı test edilmelidir. Resize observer interaction'ları yeni feedback loop oluşturabilir. Widget bazlı INP attribution optimizasyonun gerçek etkisini gösterebilir.

Üçüncü Taraf JavaScript İçin Performance Budget

Third-party JavaScript çoğu kurumda frontend ekibinin doğrudan sahip olmadığı ancak kullanıcı performansını etkileyen önemli bir maliyettir. Analytics, reklam, chat ve experiment araçlarının her biri network ve main thread kullanır. Her script'in iş değeri ile kullanıcıya getirdiği CPU ve bandwidth maliyeti birlikte değerlendirilmelidir. Varsayılan olarak bütün route'larda yüklemek yerine ihtiyaç duyulan sayfalara ve doğru lifecycle aşamasına taşınabilir. Third-party inventory ve owner bilgisi performans governance'ın parçası olmalıdır.

Analytics

Analytics business kararları için gerekli olabilir, ancak page load sırasında büyük SDK initialize etmek zorunlu değildir. Minimal first-party event collector daha sonra ağır processing yapabilir. Event batching network request sayısını azaltır. Consent durumu script load zamanını da etkileyebilir. Analytics loss ile performance gain A/B veya controlled test üzerinden değerlendirilebilir.

Tag Manager

Tag manager merkezi yönetim sağlarken performans açısından görünmeyen script eklenmesine yol açabilir. Container içindeki bütün tag'ler düzenli audit edilmelidir. Marketing team yeni tag eklerken performance budget kontrolü görmelidir. Route ve event trigger şartları dar tutulmalıdır. Production RUM third-party source duration trend'i governance'a veri sağlar.

Reklam Scriptleri

Ad technology çoğu zaman birden fazla auction ve tracking request oluşturur. Main thread script maliyeti yanında layout shift ve bandwidth rekabeti de yaratabilir. Ad slot reservation CLS açısından zorunludur. Above-the-fold ad ve LCP resource priority birlikte değerlendirilmelidir. Revenue impact performance experiment ile ölçülmelidir.

Chat Widget'ları

Chat widget kullanıcıların küçük bölümünde kullanılırken bütün ziyaretçilere büyük initial bundle gönderebilir. Widget interaction, idle veya user intent sonrasında yüklenebilir. Support business requirement response time'ı belirler. Bubble placeholder küçük first-party UI olarak gösterilip gerçek widget sonra initialize edilebilir. Route bazlı ihtiyaç kontrolü de gereksiz yüklemeyi azaltır.

Heatmap Araçları

Heatmap araçları mouse, scroll ve DOM snapshot işlemleri nedeniyle CPU ve network maliyeti oluşturabilir. Yüzde yüz session yerine sampling kullanılabilir. Kritik conversion route'larında performans etkisi ayrı ölçülmelidir. Recording sırasında sensitive data masking doğru yapılandırılmalıdır. Tool kullanımı belirli research dönemleriyle sınırlandırılabilir.

A/B Testing Scriptleri

Client-side experiment script hero veya content'i gizleyip variant belirleyene kadar render delay oluşturabilir. Server-side assignment veya edge variant delivery LCP açısından daha iyi olabilir. Flicker prevention snippet'leri element render delay'i ciddi artırabilir. Experiment platformunun business değeri gerçek performance maliyetiyle değerlendirilmelidir. Test altyapısı kullanıcı deneyimini ölçerken kullanıcı deneyimini bozacak şekilde çalışmamalıdır.

Her Script İçin İş Değeri / Main Thread Maliyeti Karşılaştırması

Third-party inventory script owner, transferred bytes, execution time ve business purpose bilgilerini içerebilir. LoAF ve performance trace gerçek main thread maliyetini ölçer. Kullanılmayan veya düşük değerli script kaldırılabilir. Yüksek değerli script loading strategy ile optimize edilir. Performance budget kararları yalnızca frontend ekibinin sorumluluğu olmamalı ve ürün sahipleriyle birlikte alınmalıdır.

Etkileşim Sonrasına Erteleme

Kullanıcı bir widget'ı açmadan gerçek third-party code yüklememek önemli kazanım sağlayabilir. Placeholder veya lightweight first-party trigger kullanılır. İlk interaction sonrası code download küçük gecikme oluşturabilir ve intent-based prefetch ile dengelenebilir. Critical functionality bu modele uygun olmayabilir. Field data loading strategy'nin INP ve conversion etkisini ölçmelidir.

Sadece Gereken Route'larda Yükleme

Checkout payment SDK ana sayfada gereksizdir. Heatmap yalnızca araştırılan route'larda çalışabilir. Route-specific dynamic import ve script loader initial bundle'ı azaltır. SPA navigation sırasında script cleanup ve duplicate initialization kontrol edilmelidir. Third-party route matrix documentation deployment review'un parçası olabilir.

Network Waterfall'ı Optimize Etmek

Network waterfall sayfanın kaynakları hangi sırada ve hangi bağımlılıklarla istediğini gösterir. Kritik request chain uzun olduğunda hızlı CDN bile LCP'yi kurtaramaz. Compression, caching ve modern protocol transferred data ve connection kullanımını iyileştirir. Origin sayısının artması DNS ve TLS maliyetlerini çoğaltabilir. Redirect ve gereksiz request'leri kaldırmak en basit ama sık unutulan optimizasyonlardandır.

Kritik Request Chain'lerini Bulmak

Critical chain LCP veya first interaction için gereken resource'ların birbirini sequential beklediği zincirdir. HTML, CSS, font ve image ilişkisi waterfall üzerinden incelenir. Chain uzunluğu ve toplam latency hesaplanabilir. Resource'u HTML'de erkene taşımak veya dependency kaldırmak çoğu zaman preload eklemekten daha kalıcıdır. Lighthouse critical request bilgisi başlangıç için kullanılabilir.

HTTP/2 ve HTTP/3

HTTP/2 multiplexing aynı connection üzerinde birden fazla request taşımayı sağlar. HTTP/3 QUIC üzerinden bazı network koşullarında connection ve packet loss davranışını iyileştirebilir. Protocol upgrade kötü cache veya büyük bundle problemini çözmez. CDN ve origin desteği test edilmelidir. RUM network segmentleri gerçek etkiyi gösterebilir.

Brotli Compression

Brotli text tabanlı JavaScript, CSS ve HTML transfer boyutunu azaltabilir. Static asset için yüksek compression level build-time uygulanabilir. Dynamic response için aşırı yüksek level server CPU maliyeti oluşturabilir. Already compressed image ve video dosyalarında ek text compression faydası beklenmez. Response header ve actual transferred size kontrol edilmelidir.

Cache-Control

Cache-Control browser ve intermediary cache'in resource'u ne kadar süre saklayacağını belirler. Fingerprinted static asset uzun immutable cache alabilir. HTML daha kısa veya revalidation tabanlı policy kullanabilir. User-specific response public cache edilmemelidir. Cache policy asset lifecycle ile birlikte tasarlanmalıdır.

Immutable Assets

Hash içeren JS, CSS ve image filename değiştiğinde yeni URL üretildiği için uzun süre immutable cache güvenle kullanılabilir. Repeat visit network maliyeti ciddi azalır. HTML yeni asset URL'lerini referans eder. Deploy rollback eski asset'lerin CDN'de hâlâ bulunmasını gerektirebilir. Asset retention policy buna göre belirlenmelidir.

CDN

CDN static resource'u kullanıcıya yakın noktadan sunar ve origin load'u azaltır. Cache hit ratio en önemli operasyon metriklerinden biridir. Query string veya cookie vary gereksiz fragmentation oluşturabilir. Purge ve versioning stratejisi birlikte çalışmalıdır. Edge logları coğrafi latency sorunlarını teşhis etmeye yardımcı olur.

Origin Sayısını Azaltmak

Her yeni origin DNS, connection ve TLS maliyeti ekleyebilir. Browser connection reuse aynı origin içinde avantaj sağlar. Font, image ve API mümkün olduğunda uygun proxy veya shared domain strategy kullanabilir. Security ve caching gereksinimleri origin consolidation kararını etkiler. Waterfall connection setup süreleri gerçek maliyeti gösterir.

Gereksiz Redirect'leri Kaldırmak

Navigation redirect her adımda yeni round trip ekler. HTTP'den HTTPS, www mapping veya eski route zincirleri tek hop'a indirilebilir. Marketing tracking redirect'leri mobile latency'de daha pahalıdır. Internal link'ler doğrudan final URL'yi kullanmalıdır. Redirect map düzenli crawl ile audit edilebilir.

SPA ve Client-Side Navigation Performansı

SPA uygulamalarında initial load ile sonraki route navigation aynı performans problemi değildir. Core Web Vitals page load odaklı field metrikler sunarken kullanıcı route transition sırasında da yavaşlık yaşayabilir. Route chunk, data fetch ve render maliyeti ayrı RUM event'leriyle ölçülmelidir. Prefetch doğru kullanıldığında navigation hızlanır. Ancak route change sırasında büyük synchronous render INP'yi yine kötüleştirebilir.

İlk Sayfa Yüklemesi ile Route Navigation'ı Ayrı Ölçmek

Initial page load network connection ve HTML rendering maliyeti taşır. SPA navigation mevcut runtime üzerinden data ve new chunk yükler. İki süreci aynı latency metriğinde toplamak teşhisi zorlaştırır. Navigation timing custom measure route transition başlangıç ve usable state arasını ölçebilir. Dashboard entry navigation ve in-app navigation'ı ayrı segmentlemelidir.

Route-Level Code Splitting

Her route yalnızca gerekli JavaScript chunk'ını yüklemelidir. Shared dependency common chunk içinde cache edilebilir. Route split boundaries bundler tarafından otomatik oluşturulabilir. Çok büyük common chunk bütün route'ları tekrar ağırlaştırabilir. Bundle analyzer per-route transferred ve executed bytes göstermelidir.

Route Prefetch

Link görünür olduğunda veya hover intent oluştuğunda route chunk önceden indirilebilir. Bu yöntem click sonrası network bekleme süresini azaltır. Her linki otomatik prefetch etmek mobil bandwidth tüketebilir. Save-Data ve connection quality dikkate alınabilir. Conversion funnel içindeki yüksek olasılıklı navigation'lar önceliklendirilebilir.

Data Prefetch

Route code hazır olsa bile data request click sonrasında başlıyorsa kullanıcı beklemeye devam eder. Product card hover veya viewport visibility sonraki page data prefetch için sinyal olabilir. Personalized data cache ve freshness kuralları doğru yönetilmelidir. Gereksiz prefetch server load oluşturur. Prediction accuracy telemetry ile ölçülmelidir.

Navigation Sonrası Ağır Render'ları Önlemek

Data ve code cache'te olsa bile yeni route binlerce DOM node render ediyorsa transition yavaş hissedilir. Large list virtualization, content-visibility ve incremental rendering kullanılabilir. Route change sonrası analytics synchronous çalışmamalıdır. Skeleton gerçek layout ölçüsünü korumalıdır. Custom navigation metric usable frame zamanını takip edebilir.

Client-Side Transition'larda INP

Link click bir interaction olduğu için navigation sırasında uzun event processing veya render INP candidate olabilir. Router handler minimum work yapmalıdır. Data processing ve heavy component mount interaction critical path'ten ayrılabilir. Visual pending state hızlı gösterilmelidir. Attribution route link target'ın kötü INP üretip üretmediğini production'da gösterebilir.

Back/Forward Cache (bfcache) ile Anlık Geri Dönüş Deneyimi

bfcache browser'ın sayfanın tam durumunu memory'de saklayıp geri veya ileri navigasyonda neredeyse anında restore etmesini sağlar. Bu deneyim tekrar navigation sırasında yeni network ve render işini büyük ölçüde ortadan kaldırabilir. Sayfanın cache'e uygunluğunu bozan event handler ve resource kullanımını bilmek gerekir. Chrome DevTools Not Restored Reasons teşhisi neden cache kullanılmadığını gösterebilir. Özellikle content ve commerce sitelerinde back navigation hit rate kullanıcı deneyimi açısından önemli optimizasyon alanıdır.

bfcache Nedir?

Back/forward cache normal HTTP cache'den farklıdır ve sayfanın in-memory snapshot'ını korur. Kullanıcı geri döndüğünde DOM ve JavaScript state yeniden kurulmadan restore edilebilir. pageshow event'inin persisted bilgisi restore durumunu anlamaya yardımcı olur. Analytics normal load ile bfcache restore'u ayırmalıdır. Bu davranış kullanıcıya çok hızlı geri dönüş sağlar.

Hangi Sayfalar bfcache'e Giremez?

Browser güvenlik ve lifecycle nedenleriyle bazı sayfaları bfcache dışında bırakabilir. Kullanılan API ve header'lar browser'a göre farklı etki gösterebilir. DevTools Application paneli test sonucu ve actionable reason sunabilir. Third-party script bile eligibility'yi bozabilir. Düzenli bfcache audit release sürecine eklenebilir.

Not Restored Reasons

NotRestoredReasons API ve DevTools bilgisi sayfanın neden bfcache'ten restore edilmediğini açıklamaya yardımcı olur. Developer hangi frame veya feature'ın problemi oluşturduğunu görebilir. Field telemetry ile bfcache miss reason toplamak advanced RUM programında değerlidir. Browser support dikkate alınmalıdır. Önce en sık actionable reason'lar çözülmelidir.

unload Handler Problemleri

unload handler güvenilir değildir ve bfcache eligibility üzerinde olumsuz etkisi olabilir. Modern guidance pagehide gibi lifecycle event'lerini tercih eder. Third-party library unload listener ekliyor olabilir. Lighthouse ve DevTools bunu tespit etmeye yardımcı olur. Analytics ve cleanup logic daha modern page lifecycle pattern'lerine taşınmalıdır.

SPA ve MPA'larda Kullanımı

bfcache özellikle document navigation yaşayan MPA sayfalarında güçlü fayda sağlar. SPA internal route navigation browser document history davranışıyla farklı çalışır. SPA'dan başka document'e gidip geri dönüldüğünde yine bfcache kullanılabilir. Framework lifecycle restore senaryosunda stale data kontrolü gerektirebilir. pageshow event'inde gerekli minimal refresh yapılabilir.

Prefetch ve Prerender ile Gelecek Navigasyonu Hızlandırmak

Bir sonraki navigation yüksek olasılıkla biliniyorsa browser kaynakları kullanıcı tıklamadan önce hazırlayabilir. Prefetch document veya resource'u önceden alırken prerender sayfayı daha ileri aşamada hazırlayabilir. Speculation Rules modern Chromium tabanlı browser'larda bu stratejileri tanımlamak için kullanılabilir. Yanlış tahmin bandwidth, CPU ve server maliyeti oluşturur. Prediction confidence, Save-Data ve connection condition kararın parçası olmalıdır.

Kullanıcının Bir Sonraki Sayfasını Tahmin Etmek

Product listing'de kullanıcı belirli card üzerinde hover ediyorsa product detail'e gitme olasılığı yükselir. Checkout funnel'da sonraki step daha tahmin edilebilirdir. Viewport visibility tek başına düşük confidence sinyal olabilir. Interaction intent ile analytics probability birlikte kullanılabilir. Prediction sistemi kullanıcıya gereksiz kaynak indirmeyecek kadar muhafazakar olmalıdır.

Prefetch

Prefetch sonraki navigation için resource veya document'i düşük priority ile önceden alabilir. Cache behavior kullanılan mekanizmaya göre değişir. Personalized document için prefetch privacy ve cache açısından dikkat gerektirir. Network yavaşsa kritik current page resource'larıyla yarışmamalıdır. Prefetch hit rate ve wasted bytes ölçülmelidir.

Prerender

Prerender gelecek page'i arka planda daha kapsamlı hazırlayarak navigation'ı çok hızlı hale getirebilir. JavaScript ve resource processing de çalışabileceği için maliyeti prefetch'ten daha yüksektir. Yalnızca kullanıcı intent'i güçlü olduğunda kullanılmalıdır. Analytics prerendered ama hiç activate edilmeyen page'i normal view saymamalıdır. Security ve side effect üreten scriptler prerender lifecycle'ına uyumlu olmalıdır.

Speculation Rules

Speculation Rules API JSON tabanlı kurallarla prefetch veya prerender adaylarını tanımlamayı sağlar. Static URL listesi veya document rule yaklaşımı kullanılabilir. Browser bu hint'i her zaman uygulamak zorunda değildir. E-ticaret gibi yüksek olasılıklı navigation akışlarında etkili olabilir. Fallback olmayan browser'larda normal navigation çalışmaya devam etmelidir.

Gereksiz Prefetch'in Bandwidth Maliyetini Kontrol Etmek

Yanlış tahmin edilen prefetch kullanıcı data kotasını ve server capacity'yi gereksiz tüketir. Mobile Save-Data durumunda prefetch kapatılabilir. Slow connection segmentinde confidence threshold yükseltilebilir. Session başına prefetch budget belirlenebilir. RUM wasted prefetch oranını business conversion ile birlikte değerlendirmelidir.

React ve Next.js İçin İleri Web Vitals Taktikleri

React ve Next.js performansında temel hedef browser'a gereksiz client JavaScript göndermemek ve kritik content'i mümkün olduğunca erken sunmaktır. Server Components, streaming ve route splitting bu hedefi destekler. Next.js Image component responsive image ve sizing konusunda güçlü varsayımlar sunar. 2026 itibarıyla Next.js 16'da eski priority prop'u preload lehine kullanımdan kaldırılmıştır ve çoğu durumda loading="eager" veya fetchPriority="high" seçeneğinin ihtiyaca göre değerlendirilmesi önerilir. Framework özelliği kullanmak tek başına yeterli değildir ve final network, bundle ve RUM sonucu mutlaka ölçülmelidir.

React Server Components

Server Components static ve data-heavy UI'ı client bundle dışında tutabilir. Browser'a gönderilen JavaScript azaldığında parse ve hydration maliyeti düşebilir. Interactive leaf component'ler client sınırında kalır. Server data request'leri waterfall oluşturmamalıdır. Bundle analyzer ve RUM INP component boundary kararlarını doğrulamalıdır.

Client Component Sınırlarını Küçültmek

Üst seviyede geniş bir use client sınırı altında birçok static child dependency browser bundle'a taşınabilir. Interactive component'i mümkün olduğunca aşağı seviyede tutmak daha küçük client graph sağlar. Context ve state gereksinimi boundary'yi bazen büyütebilir. Architecture yalnızca theoretical küçüklük değil maintainability de dikkate almalıdır. Initial JS ve hydration duration before-after ölçülmelidir.

Dynamic Import

next/dynamic veya standard dynamic import non-critical component ve library'leri split edebilir. Modal, rich editor veya chart ilk load'dan çıkarılabilir. LCP content dynamic import arkasında bırakılmamalıdır. Client-only heavy library SSR dışında tutulabilir. User intent prefetch ilk açılış gecikmesini azaltabilir.

Route-Level Splitting

Next.js route architecture gerekli code'u route bazında ayırmayı destekler. Shared layout dependency'leri common bundle davranışını etkileyebilir. Büyük client library root layout'ta import edilirse bütün route'lara yayılabilir. Bundle output route bazında incelenmelidir. Marketing ve application area farklı client runtime ihtiyacı taşıyabilir.

next/image Stratejisi

next/image intrinsic sizing, responsive source ve image optimization süreçlerini kolaylaştırır. sizes prop responsive fill image'da doğru verilmezse browser gereğinden büyük source seçebilir. Remote source policy güvenlik açısından doğru yapılandırılmalıdır. Her image'ı framework optimizer üzerinden geçirmek zorunlu değildir ve CDN architecture ile birlikte değerlendirilmelidir. LCP ve below-the-fold images farklı loading strategy kullanmalıdır.

LCP Görseli Priority Yönetimi

Next.js 16'da priority prop'u deprecated edilmiştir ve güncel Image API preload, loading ile fetchPriority seçeneklerini daha açık biçimde sunar. LCP image için doğru mekanizma resource discovery durumuna göre seçilmelidir. Image HTML içinde zaten erken keşfediliyorsa fetchPriority="high" yeterli olabilir. Birden fazla viewport adayı olduğunda gereksiz preload bütün source'ları erkene çekmemelidir. Final decision network waterfall ve LCP phases ile doğrulanmalıdır.

Streaming

Next.js App Router Suspense ve loading boundaries üzerinden route parçalarını stream edebilir. Slow data block bütün page'i bekletmek zorunda değildir. LCP content yavaş boundary arkasına yerleştirilirse streaming avantajı azalır. Skeleton boyutu final content'le uyumlu olmalıdır. Kullanıcı kritik navigation ve header ile daha erken etkileşime geçebilmelidir.

Hydration Maliyetini Ölçmek

React Profiler ve browser performance trace client hydration sırasında hangi component graph'ın çalıştığını gösterir. Initial JS bytes tek başına yeterli metric değildir. Parse, execution, event attachment ve first interaction timing birlikte değerlendirilmelidir. RUM interaction loadState bilgisi kötü INP'nin hydration döneminde oluşup oluşmadığını gösterebilir. Client boundary azaltma çalışması bu verilerle önceliklendirilmelidir.

Vue ve Nuxt İçin İleri Web Vitals Taktikleri

Vue ve Nuxt tarafında da ana prensip initial JavaScript'i azaltmak, uygun route'larda server veya static rendering kullanmak ve ağır component'leri ihtiyaç olduğunda yüklemektir. Vue resmi performans rehberi bundle size, code splitting ve büyük listelerde virtualization konularını özellikle öne çıkarır. Nuxt universal rendering ilk HTML'i server'dan sunar ve hydration ile interactivity ekler. Güncel Nuxt sürümleri lazy hydration stratejileriyle non-critical component'leri görünürlük veya idle zamanına kadar erteleyebilir. Framework default'ları gerçek site field data'sıyla doğrulanmalıdır.

SSR ve SSG

Nuxt universal SSR initial content'i HTML içinde sunarak LCP discovery avantajı sağlayabilir. Static content için prerender veya hybrid route rules TTFB'yi azaltabilir. Admin gibi SEO önceliği düşük route client-only olabilir. Her route için aynı rendering mode'u kullanmak zorunlu değildir. Data freshness ve server cost ile field metric birlikte değerlendirilmelidir.

Async Components

Vue defineAsyncComponent ile non-critical component'i ayrı chunk olarak yükleyebilir. Component gerçekten render edildiğinde network request başlar. Modal ve aşağıdaki widget'lar iyi adaydır. Above-the-fold LCP component'i async yapıldığında content geç görünebilir. Loading placeholder CLS oluşturmayacak ölçüde tasarlanmalıdır.

Route-Level Splitting

Vue Router lazy route component kullanımını destekler. Her route ilk navigation'da gerekli code'u alır. Shared heavy dependency yanlış import edilirse common chunk büyüyebilir. Route prefetch uygulama behavior'ına göre eklenebilir. Production bundle analyzer chunk graph'ı doğrulamalıdır.

Hydration Stratejileri

Nuxt lazy hydration belirli component'i viewport'a yaklaşana, idle zamana veya başka trigger'a kadar hydrate etmeyi erteleyebilir. Bu özellik initial main thread işini azaltır. İlk ekrandaki interactive control gereksiz ertelenmemelidir. Placeholder ve server markup hydration mismatch üretmemelidir. Low-end mobile trace ile gerçek INP etkisi ölçülmelidir.

Görsel Optimizasyonu

Nuxt image module veya uygun image service responsive source ve modern format sunabilir. Hero LCP image lazy yapılmamalıdır. Width, height veya ratio CLS'i önceden engellemelidir. CDN ve source origin connection maliyeti analiz edilmelidir. Framework helper final HTML'in doğru srcset ve sizes ürettiği kontrol edilmelidir.

Angular İçin İleri Web Vitals Taktikleri

Angular uygulamalarında route lazy loading, SSR, hydration ve deferrable views başlangıç yükünü azaltmak için birlikte kullanılabilir. Büyük component tree ve change detection maliyeti interaction sırasında INP üzerinde etkili olabilir. Güncel Angular @defer blokları initial rendering için zorunlu olmayan dependency'leri ayrı chunk'a taşıyabilir. Viewport üstündeki kritik content'i yanlış defer etmek CLS veya LCP problemini büyütebilir. Performance kararları profiler ve RUM verisiyle desteklenmelidir.

Lazy Routes

Feature route'lar ayrı chunk olarak yüklenebilir ve initial bundle küçülür. Root module veya shared dependency yanlış yapılandırılırsa ağır code yine initial chunk'a girebilir. Route preloading strategy user journey'e göre seçilebilir. Authentication ve guard logic navigation waterfall oluşturmamalıdır. Bundle budget CI'da route bazlı takip edilebilir.

Change Detection Maliyeti

Büyük Angular tree sık change detection çalıştırdığında interaction processing ve presentation süresi artabilir. Stable data ve uygun change detection stratejileri update kapsamını azaltır. Expensive template function her cycle'da çalıştırılmamalıdır. Angular profiler ve browser trace gerçek hot path'i bulur. Micro-optimization yerine büyük subtree ve data flow davranışı önceliklendirilmelidir.

Server-Side Rendering

Angular SSR kritik content'i initial HTML içinde sunabilir. Hydration existing DOM'u yeniden kullanarak client tarafında interactivity ekler. Server data query ve render süresi TTFB açısından izlenmelidir. Static route prerender daha düşük server cost sunabilir. SEO ve kullanıcı deneyimi yüksek olan public page'lerde SSR veya SSG güçlü seçenektir.

Deferrable Views

@defer initial render için zorunlu olmayan component, directive ve pipe dependency'lerini daha sonra yüklemeyi sağlar. Trigger idle, viewport veya interaction gibi koşullara bağlanabilir. İlk viewport'ta görünen content'i yanlış defer etmek layout shift yaratabilir. Placeholder final component boyutuna yakın olmalıdır. Bu özellik özellikle ağır below-the-fold widget'larda bundle ve main thread maliyetini azaltabilir.

Büyük Component Tree'lerinde Render Maliyetini Azaltmak

Tree büyüdükçe change detection ve DOM update maliyeti artar. Component boundaries ve stable input values update scope'u küçültebilir. Büyük listeler virtualization kullanabilir. Expensive chart ve widget görünür olana kadar defer edilebilir. INP attribution belirli interaction sonrası rendering maliyetini production'da gösterebilir.

Mobil Cihazlarda Core Web Vitals Optimizasyonu

Mobil performans çalışması desktop tarayıcıyı daraltarak tamamlanamaz. Düşük CPU, yüksek network latency, memory pressure ve thermal throttling gerçek kullanıcı deneyimini belirler. Özellikle JavaScript execution ve image decode süreleri düşük segment cihazlarda belirgin biçimde uzar. Core Web Vitals p75 mobile segmenti bu nedenle ayrı ele alınmalıdır. Device lab testi RUM verisinin gösterdiği gerçek cihaz sınıflarına göre seçilmelidir.

Düşük CPU Gücü

Desktop'ta 30 ms süren JavaScript task düşük segment telefonda 150 ms sürebilir. Bu fark input delay ve processing duration'ı büyütür. CPU throttling yaklaşık simülasyon sağlar ancak gerçek cihaz testinin yerini tamamen tutmaz. Framework hydration ve third-party execution mobile trace üzerinde incelenmelidir. JavaScript budget cihaz sınıfına göre gerçekçi tutulmalıdır.

Yüksek Network Latency

Mobil bağlantıda round trip süresi yüksek olabilir ve request chain'ler daha pahalı hale gelir. Preconnect ve request dependency azaltma bu nedenle daha fazla değer kazanır. Çok sayıda küçük sequential API call ciddi gecikme yaratır. CDN coğrafi mesafeyi azaltabilir. Field effective connection segmentleri hangi kullanıcı grubunun daha fazla etkilendiğini gösterir.

Bellek Baskısı

Büyük image, DOM tree ve JavaScript heap düşük memory cihazlarda garbage collection ve tab discard riskini artırır. Infinite scroll session boyunca memory büyütebilir. Lazy component gerçekten memory'den temizlenmelidir. Image decode dimension ihtiyaca göre sınırlandırılmalıdır. Memory problemi doğrudan Core Web Vital olmayabilir ama interaction ve stability üzerinde etkili olur.

Thermal Throttling

Uzun CPU yoğun işlem mobil cihazın ısınmasına ve işlem hızını düşürmesine neden olabilir. Tek kısa synthetic test bu durumu yakalamayabilir. Uzun session, game-like animation veya dashboard use case'lerinde tekrarlı interaction testi yapılmalıdır. Worker compute toplam enerji tüketimini ortadan kaldırmaz. Performance ve battery verimliliği birlikte düşünülmelidir.

Düşük Segment Android Cihazlarla Test

Gerçek düşük segment Android cihaz uygulamanın CPU ve memory sınırlarını daha doğru gösterir. Device farm veya fiziksel test set'i kullanılabilir. Network shaping ile farklı bağlantılar denenebilir. Test route'ları RUM'da en kötü segmentleri temsil etmelidir. Sadece flagship cihazlarla QA yapmak production p75 riskini gizler.

Gerçek Mobil RUM Verisinin Önceliği

Lab testi repeatable debug sağlar fakat gerçek kullanıcı dağılımı RUM'da görülür. Device memory, connection ve browser metadata sınırlı ve privacy-safe segmentler halinde saklanabilir. Mobile p75 ve p95 release bazında izlenmelidir. En kötü device group için sample session trace oluşturulabilir. Optimization tamamlandıktan sonra success production RUM ile doğrulanmalıdır.

Core Web Vitals İçin CI/CD Performance Budget Kurmak

Performans bir defa düzeltilip bırakıldığında yeni feature'lar zaman içinde regresyon oluşturur. CI/CD performance budget bu nedenle code review sırasında sınırları görünür hale getirir. Bundle, CSS, LCP asset ve third-party script maliyeti ölçülebilir. Lighthouse CI sentetik kontrol sağlarken field RUM release sonrası doğrulama yapar. Budget teknik dokümanda kalan hedef değil, gerektiğinde build'i bloklayan engineering requirement olmalıdır.

JavaScript Bundle Boyutu Limiti

Initial route compressed ve uncompressed JavaScript budget ayrı izlenebilir. Byte limit tek başına execution maliyetini açıklamaz ama güçlü erken sinyaldir. Yeni dependency budget'ı aşıyorsa lazy loading veya alternatif çözüm değerlendirilir. Route-specific threshold kullanmak global tek limitten daha gerçekçi olabilir. Baseline zaman içinde düşürülerek teknik borç kontrollü azaltılabilir.

CSS Boyutu Limiti

CSS budget route başına transferred ve generated bytes üzerinden takip edilebilir. Global stylesheet'e sürekli yeni rule eklenmesi hızlı fark edilir. Unused CSS coverage düzenli audit edilir. Critical CSS inline miktarı da ayrıca sınırlandırılmalıdır. Theme ve brand duplication final bundle analiziyle kontrol edilmelidir.

LCP Asset Boyutu Limiti

Hero image veya critical font için maksimum byte budget belirlenebilir. CMS upload pipeline çok büyük asset'i publish etmeden optimize edebilir. Responsive source her viewport için ayrı threshold taşıyabilir. Asset size tek başına LCP'yi açıklamaz ve resource discovery kontrolü de gerekir. CI static metadata ile riskli değişikliği erken yakalayabilir.

Third-Party Script Limiti

Yeni third-party tag ownership ve performance review olmadan production'a eklenmemelidir. Byte ve execution budget tanımlanabilir. Tag manager değişiklikleri de software release kadar görünür olmalıdır. Script yalnızca gereken route'ta yüklenmelidir. Business owner maliyet artışını kabul etmeden exception verilmemelidir.

Lighthouse CI

Lighthouse CI belirli route'larda tekrar eden synthetic performance audit çalıştırabilir. Score yerine LCP, TBT, asset size ve specific audit threshold'ları daha anlamlı olabilir. CI hardware variance nedeniyle birkaç run median kullanılabilir. Field INP doğrudan Lighthouse ile ölçülemez ve TBT yalnızca lab proxy olarak değerlendirilmelidir. Son karar production RUM ile doğrulanmalıdır.

Pull Request Performance Check

PR bot bundle diff ve Lighthouse değişimini developer'a merge öncesinde gösterebilir. Yeni dependency'nin hangi chunk'a eklendiği açıklanır. Visual ve performance preview aynı environment üzerinde çalışabilir. Warning threshold başlangıç adoption'ını kolaylaştırır. Kritik limitler daha sonra blocking hale getirilebilir.

Regresyonda Build'i Durdurmak

Performance budget yalnızca rapor üretip kimse bakmıyorsa etkisini kaybeder. Kritik threshold aşımı build'i durdurabilir. Exception mekanizması business gerekçesi ve son kullanma tarihi taşımalıdır. Emergency release süreci yine ayrı tanımlanabilir. Blocking rule false positive üretmeyecek kadar stabil olmalıdır.

Performans Bütçesini Teknik Gereksinime Dönüştürmek

Feature acceptance kriterlerine “mobile p75 INP regresyonu yaratmamalı” veya “initial JS budget içinde kalmalı” gibi hedefler eklenebilir. Product ve engineering performansı ortak quality özelliği olarak görür. Design decision büyük hero video gerektiriyorsa maliyet daha geliştirme başlamadan konuşulur. Budget documentation team onboarding'in parçası olur. Böylece performans sprint sonunda yapılan temizlik işinden çıkar.

Production'da Sürekli Web Vitals İzleme

Core Web Vitals kullanıcı cihazı ve network koşullarına bağlı olduğu için production monitoring kalıcı olmalıdır. Release ID, route ve device metadata metric değişikliğinin kaynağını bulmayı kolaylaştırır. Deploy sonrası p75 yalnızca global seviyede değil segment bazında karşılaştırılmalıdır. Alert sistemi kısa trafik dalgalanmasında gereksiz alarm üretmeyecek kadar doğru tasarlanmalıdır. Web Vitals Metriklerini İyileştiren İleri Düzey Frontend Taktikleri sürdürülebilir olduğunda optimization tek proje değil sürekli engineering feedback loop haline gelir.

Deploy Öncesi ve Sonrası Karşılaştırma

Deployment timestamp metric dashboard'a işaretlenmelidir. Önceki ve sonraki aynı trafik saatleri karşılaştırılabilir. Marketing campaign veya sezon etkisi kontrol edilmelidir. Canary release yeni code'un küçük kullanıcı grubundaki etkisini daha erken gösterir. Regresyon varsa hızlı rollback veya feature flag kapatma yapılabilir.

Release ID ile Metrik İlişkilendirme

Her RUM metric event current frontend release ID taşıyabilir. Aynı anda CDN cache nedeniyle iki release kullanıcıda bulunuyorsa ayrım yapılır. Dashboard hangi release'in p75 INP veya LCP değerini bozduğunu gösterebilir. Source map ve bundle manifest release ID üzerinden ilgili code'a bağlanır. Bu metadata incident root cause süresini ciddi biçimde azaltabilir.

Route Bazlı Dashboard

Homepage, category ve checkout performans karakteri farklıdır. Global aggregate bu farkı gizler. Route template bazında LCP, INP ve CLS ayrı izlenmelidir. Dynamic URL cardinality route pattern'e normalize edilmelidir. Business owner kendi funnel sayfalarının performans trendini kolayca görebilmelidir.

Device Class Segmentasyonu

Device memory veya user agent doğrudan tam cihaz modeli olarak saklanmadan geniş performans sınıfları oluşturulabilir. Low, mid ve high class segmentleri main thread problemine dair güçlü sinyal sağlar. Privacy ve cardinality sınırı korunmalıdır. Mobile p75 içinde düşük segmentin ağırlığı ayrı görülebilir. Optimization önceliği gerçek kullanıcı dağılımına göre belirlenir.

Network Segmentasyonu

Effective connection veya navigation timing bilgileri yavaş network kullanıcılarını ayırmaya yardımcı olur. LCP load duration bu segmentte daha fazla etkilenebilir. Network bilgisinin browser desteği sınırlı olabilir. CDN region ve server timing ek data sağlar. Slow network için asset ve request chain optimization ayrı değerlendirilir.

Coğrafi Segmentasyon

Kullanıcıya en yakın region veya ülke seviyesi aggregate latency farkını gösterebilir. Kişisel hassas konum bilgisi toplanmamalıdır. Origin'e uzak region'da TTFB yüksekse CDN veya edge strategy değerlendirilebilir. Data residency requirements architecture'ı etkileyebilir. Geographic p75 rollout sonrası edge iyileşmesini doğrular.

Browser Segmentasyonu

Browser engine ve version rendering ve API behavior farkı gösterebilir. Yeni feature belirli browser'da performance regression oluşturabilir. Çok küçük version segmentleri cardinality büyütebilir ve major version seviyesinde gruplanabilir. Browser-specific workaround ölçümle doğrulanmalıdır. Core Web Vitals field population Chrome ağırlıklı olsa da kendi RUM sisteminiz bütün desteklenen browser'ları izleyebilir.

Performans Regresyonu İçin Alert Oluşturmak

Alert tek request veya kısa spike yerine yeterli sample ve rolling percentile üzerinden çalışmalıdır. p75 INP belirli oranda yükseldiğinde veya good rate düştüğünde notification gönderilebilir. Route criticality threshold'u etkileyebilir. Release deployment ile alert otomatik ilişkilendirilir. Alert mesajı yalnızca “yavaşladı” demek yerine affected segment ve attribution bilgisini içermelidir.

Performans Optimizasyonunun İş Sonuçlarını Ölçmek

Web performansı kullanıcı deneyimini etkiler, ancak teknik metric iyileşmesini doğrudan gelir artışı olarak varsaymak bilimsel değildir. Conversion, bounce ve checkout tamamlanma oranı aynı dataset'te analiz edilebilir. Device ve traffic source gibi confounder faktörler kontrol edilmelidir. A/B test veya controlled rollout nedensellik hakkında daha güçlü kanıt sağlar. Performans business KPI ile ilişkilendirildiğinde investment kararları daha sağlam hale gelir.

Conversion Rate

Hızlı product ve checkout deneyimi conversion ile ilişkili olabilir. Ancak campaign quality veya fiyat değişikliği aynı anda conversion'ı etkileyebilir. Web Vital bucket'ları conversion segmentleriyle karşılaştırılabilir. Kullanıcı session boyunca birden fazla page performansı yaşayabilir. A/B test mümkünse performance intervention'ın gerçek etkisini daha güvenilir ölçer.

Bounce ve Engagement

Yavaş first load kullanıcının content'e ulaşmadan ayrılmasına katkı sağlayabilir. Engagement time ve page depth LCP segmentleriyle analiz edilebilir. Content quality ve search intent farkı kontrol edilmelidir. CLS veya kötü interaction da engagement'i azaltabilir. Tek metric yerine journey perspektifi kullanılmalıdır.

Sepet ve Checkout Tamamlama

Commerce funnel'da yavaş add-to-cart veya checkout interaction doğrudan kullanıcı frustrasyonu yaratabilir. INP target bazlı data sepet ve payment control'leriyle ilişkilendirilebilir. Third-party payment script maliyeti ayrıca analiz edilir. Checkout completion performans cohort'larıyla karşılaştırılabilir. Security ve correctness hiçbir zaman hız uğruna azaltılmamalıdır.

Kullanıcı Başına Gelir

Revenue per user performans segmentleriyle incelenebilir. High-end device kullanıcıların daha fazla gelir üretmesi metric ile gelir arasında sahte korelasyon yaratabilir. Device ve geography kontrolü gereklidir. Experiment aynı kullanıcı segmentinde daha güçlü sonuç verir. Performance business case modelleri bu sınırlamaları açıkça belirtmelidir.

Web Vitals ile İş KPI'larını Aynı Dataset'te Analiz Etmek

RUM session ID anonim analytics session ile privacy-safe biçimde ilişkilendirilebilir. Metric, route ve business event aynı zaman çizelgesinde analiz edilir. PII bu dataset'e dahil edilmemelidir. Data warehouse aggregate cohort analizi sunabilir. Engineering ve product aynı dashboard üzerinden teknik ve iş etkisini birlikte görebilir.

Korelasyon ile Nedenselliği Karıştırmamak

Hızlı kullanıcılar aynı zamanda daha yeni cihaz ve daha iyi network kullandığı için daha yüksek conversion gösterebilir. Bu durum performansın tek başına neden olduğunu kanıtlamaz. Segment control ve randomized experiment gereklidir. Observational analysis yine hipotez üretmek için değerlidir. Sonuç iletişiminde veri sınırları açık belirtilmelidir.

A/B Test ile Performans Etkisini Doğrulamak

Control ve treatment arasında yalnızca performance intervention farklı tutulduğunda nedensellik daha iyi değerlendirilir. Örneğin third-party script'in interaction sonrasına ertelenmesi iki kullanıcı grubunda test edilebilir. Web Vitals ve conversion birlikte ölçülür. Sample size ve experiment duration istatistiksel olarak yeterli olmalıdır. Performans farkı oluşmadıysa business sonucu yorumlamak da anlamsız hale gelir.

Gerçek Dünya Örneği: E-Ticaret Sitesinde Core Web Vitals Audit

E-ticaret sitesi performans audit'inde bütün URL'lere aynı checklist'i uygulamak yerine funnel şablonlarını ayrı değerlendirmek daha faydalıdır. Ana sayfa hero LCP ve third-party script açısından, category uzun listeler açısından, product detail image gallery açısından farklı profile sahiptir. Sepet ve checkout interaction responsiveness ile layout stability açısından daha kritiktir. Her template için baseline ve business KPI ayrı tutulmalıdır. Diyarbakır Yazılım Topluluğu kapsamında ele alınan farklı yazılım proje yaklaşımlarını görmek için https://www.diyarbakiryazilim.com.tr/projects adresi incelenebilir.

Ana Sayfa

Ana sayfa genellikle yüksek trafik alır ve marketing script yoğunluğu taşır. Hero alanı çoğu ziyaretçinin LCP elementidir. Campaign personalization JavaScript üzerinden geç uygulanıyorsa render delay büyüyebilir. Analytics ve experimentation scriptleri main thread competition yaratabilir. Audit ilk HTML, hero request ve third-party timeline üzerinde yoğunlaşmalıdır.

Hero LCP

Hero image HTML içinde erken keşfedilebilir olmalıdır. Mobile ve desktop source'lar responsive biçimde seçilmelidir. Lazy loading kullanılmamalıdır. Image download tamamlandıktan sonra JavaScript nedeniyle bekliyorsa render delay ayrıca çözülmelidir. LCP subpart before-after değerleri optimization başarısını gösterir.

Third-Party Scriptler

Ana sayfa marketing tool'ların toplandığı alan olabilir. Her script source ve main thread duration raporlanmalıdır. Düşük değerli tag kaldırılabilir veya consent sonrası yüklenebilir. Hero experiment flicker-prevention script'i LCP'yi engellememelidir. Tag governance performans budget ile birleştirilmelidir.

Kategori Sayfası

Kategori sayfası onlarca veya yüzlerce product card render edebilir. Initial viewport dışındaki card'lar style, layout ve image maliyeti taşır. Filter interaction büyük listede INP problemi oluşturabilir. Responsive image ve content-visibility birlikte değerlendirilebilir. Search bot ve accessibility gereksinimi virtualization kararını etkileyebilir.

Uzun Ürün Listeleri

Çok uzun DOM tree mobile layout maliyetini artırır. Pagination, infinite scroll veya virtualization product deneyimine göre seçilebilir. Filter sonrası bütün listeyi tekrar render etmek INP'yi bozabilir. Stable keys ve memoization ölçerek kullanılmalıdır. RUM category interaction target'larını ayrı izlemelidir.

content-visibility

Offscreen product section'larında content-visibility initial rendering cost'i azaltabilir. Intrinsic size card layout'a yakın olmalıdır. Browser find ve anchor navigation behavior test edilmelidir. Image lazy loading ayrı devam eder. Field improvement özellikle low-end device segmentinde ölçülmelidir.

Responsive Images

Product thumbnail gerçek card width'e uygun source kullanmalıdır. Grid desktop ve mobile'da farklı column sayısı taşıdığı için sizes doğru tanımlanmalıdır. 1000 piksel image küçük card için gereksizdir. CDN format negotiation modern format sunabilir. Transfer byte tasarrufu category scroll deneyimini de iyileştirir.

Ürün Detay Sayfası

Product detail yüksek conversion değeri ve zengin media içeriği nedeniyle kritik şablondur. Ana product image LCP olabilir. Gallery code, recommendation widget ve review library initial JavaScript'i büyütebilir. Product data waterfall SSR süresini etkileyebilir. Above-the-fold satın alma interaction'ı hydration sırasında kullanılabilir olmalıdır.

Galeri Optimizasyonu

İlk product image high priority, diğer gallery görselleri lazy olabilir. Thumbnail ve zoom source'ları ayrı çözünürlük kullanabilir. İlk image size reservation CLS'i önler. Zoom library kullanıcı intent'ine kadar lazy yüklenebilir. Mobile swipe interaction handler uzun task üretmemelidir.

Dynamic Import

360 derece viewer veya review modal initial route için zorunlu değildir. Dynamic import initial JS'i azaltır. Product page idle olduğunda intent-based preload yapılabilir. Loading fallback gerçek component layout'unu bozmamalıdır. Bundle diff ile gerçek tasarruf ölçülmelidir.

Sepet

Sepet interaction yoğun bir ekran olduğu için INP önceliklidir. Quantity update, coupon ve remove action aynı anda büyük state tree güncellememelidir. Optimistic visual feedback kullanıcıya hızlı tepki verir. Server validation daha sonra doğrulanabilir. Attribution hangi control'ün en kötü interaction olduğunu göstermelidir.

State Güncellemeleri

Tek item quantity değiştiğinde bütün cart ve recommendation panel'i render olmamalıdır. State slice ve selector granularity optimize edilebilir. Price calculation ağırsa worker veya server calculation değerlendirilebilir. Immediate UI feedback critical path'te kalır. Framework profiler render scope'u gösterir.

INP

Cart update interaction input, processing ve presentation olarak ayrılır. Third-party analytics aynı click içinde synchronous çalışmamalıdır. Loading state önce paint edilebilir. Device segment low-end Android'de ayrıca ölçülmelidir. p75 hedef 200 ms altında tutulmaya çalışılmalıdır.

Checkout

Checkout performans kadar güvenlik ve correctness açısından da hassastır. Third-party payment SDK ve fraud script main thread maliyeti oluşturabilir. Form error ve address autocomplete interaction'ları INP için ölçülmelidir. Payment iframe ve banner alanı CLS oluşturmayacak şekilde ayrılmalıdır. Performance değişikliği payment compliance gereksinimlerini etkilememelidir.

Third-Party Payment Scriptleri

Payment SDK yalnızca checkout route'ta yüklenmelidir. Mümkünse kullanıcı ilgili payment method'u seçtiğinde daha ağır module getirilebilir. Script preconnect gerekli origin connection'ını erkene çekebilir. Main thread attribution third-party cost'i gösterir. Business owner ile performans trade-off'u belgelenmelidir.

CLS

Payment method iframe sonradan büyürse checkout content'i kayabilir. Minimum height veya known ratio ayrılmalıdır. Error message alanları layout'u beklenmedik biçimde itmemelidir. Consent ve security notice ilk render'da yer alabilir. Shift attribution critical submit button'ın hareket edip etmediğini göstermelidir.

Optimizasyon Öncesi ve Sonrası Metrikler

Örnek audit'te yalnızca Lighthouse score değil template p75 LCP, INP ve CLS karşılaştırılır. Hero resource discovery düzeltmesi LCP load delay'i azaltabilir. Cart render scope değişikliği INP presentation delay'i düşürebilir. Payment slot reservation CLS'i azaltabilir. Business KPI aynı dönemde izlenerek teknik iyileşmenin kullanıcı yolculuğundaki etkisi değerlendirilir.

Core Web Vitals Optimizasyonunda Sık Yapılan Hatalar

Performans ekiplerinin en sık yaptığı hata araç önerisini doğrudan çözüm olarak kabul etmektir. Aynı Lighthouse uyarısı farklı sayfalarda farklı business ve rendering etkisine sahip olabilir. Field data olmadan yalnızca synthetic skor optimize etmek production problemini kaçırabilir. Preload, worker ve memoization gibi teknikler her yerde kullanılacak sihirli çözümler değildir. Her değişiklik kök neden, ölçüm ve doğrulama zinciri içinde uygulanmalıdır.

Lighthouse 100 Skorunu Ana Hedef Yapmak

Lighthouse 100 faydalı bir sentetik başarı olabilir ancak gerçek kullanıcı p75 deneyimini garanti etmez. Lab cihaz ve network koşulları belirli profildir. Gerçek kullanıcı farklı interaction ve session length yaşar. Skor uğruna business-critical script kaldırmak doğru olmayabilir. Hedef field Core Web Vitals ve kullanıcı outcome olmalıdır.

Yalnızca Ortalama Değere Bakmak

Average hızlı ve yavaş kullanıcıları tek sayıya indirir. Kötü mobile tail görünmez hale gelebilir. p75 Core Web Vitals değerlendirmesi için temel olmalıdır. p90 ve p95 root cause için ek sinyal verir. Segment bazlı percentile dashboard daha doğru karar sağlar.

Field Data'yı Görmezden Gelmek

Local laptop'ta hızlı sayfa gerçek 3G benzeri network ve düşük CPU'da yavaş olabilir. CrUX ve RUM gerçek user distribution'ı gösterir. Lab yalnızca reproduction ve debugging için kullanılır. Release success production verisiyle onaylanmalıdır. Field data olmadan optimization impact tahmin seviyesinde kalır.

LCP Görselini Lazy Load Etmek

Hero image ilk viewport'ta gerekli olduğu için lazy loading request başlangıcını geciktirebilir. Framework default davranışı kontrol edilmelidir. LCP image normal veya eager loading ve uygun priority kullanmalıdır. Below-the-fold image'lar lazy kalabilir. Waterfall request start zamanı doğrulanmalıdır.

Her Kaynağı Preload Etmek

Preload sadece gerçekten kritik ve yakında kullanılacak resource içindir. Çok fazla preload bandwidth'i böler. Font, image ve script aynı anda yarışabilir. Unused preload browser warning'leri dikkate alınmalıdır. Route başına preload budget uygulanabilir.

Gereksiz JavaScript'i Yalnızca Minify Etmek

Minification transferred bytes azaltır ama code yine parse ve execute edilir. Kullanılmayan feature bundle'dan tamamen çıkarılmalıdır. Code splitting ve dependency removal daha büyük kazanç sağlar. Tree shaking doğru ESM structure gerektirir. Main thread time final metric olmalıdır.

Görsel Tepkiyi Ağır İşlemden Sonra Göstermek

Kullanıcı click sonrası loading state'i ağır calculation bittikten sonra görürse arayüz donmuş hissedilir. Visual feedback önce render edilmelidir. Yield ile browser'a paint fırsatı verilir. Heavy work daha sonra devam eder. Bu pattern interaction perceived quality'yi ciddi biçimde iyileştirebilir.

Web Worker'ı Her Soruna Çözüm Sanmak

Worker DOM work veya framework rendering'i çözmez. Message serialization ve coordination maliyeti vardır. Küçük calculation worker'a taşındığında daha yavaş olabilir. Önce main thread profile yapılmalıdır. CPU yoğun ve bağımsız iş gerçek adaydır.

Cookie Banner ile CLS Üretmek

Consent UI page load sonrasında üstten eklenirse bütün layout'u kaydırabilir. Overlay veya reserved space kullanılabilir. İlk HTML consent state'i biliyorsa doğru layout baştan render edilebilir. Banner close sırasında da shift kontrol edilmelidir. Accessibility ve legal requirement korunmalıdır.

Third-Party Scriptlerin Maliyetini Ölçmemek

External script first-party code kadar kullanıcı main thread'ini kullanır. Owner bilgisinin dış ekipte olması performans etkisini değiştirmez. LoAF ve network waterfall gerçek maliyeti gösterir. Low-value script kaldırılabilir. Performance governance marketing ve product ekiplerini kapsamalıdır.

Tek Sefer Optimizasyon Yapıp İzlemeyi Bırakmak

Yeni feature ve dependency zaman içinde performansı tekrar bozar. CI budget regresyonu merge öncesinde yakalar. RUM release sonrası gerçek kullanıcı etkisini izler. Quarterly audit teknik borç trendini gösterir. Performans sürekli software quality süreci olmalıdır.

Frontend Performansı Öğrenme, Open Source ve İşbirliği

Web performansını öğrenmenin en iyi yolu yalnızca araç skorlarını okumak değil browser'ın nasıl çalıştığını anlamaktır. HTML parsing, event loop, rendering ve network bilgisi farklı framework'lerde aynı kalır. Open source issue ve gerçek production trace üzerinde çalışmak teoriyi pratiğe dönüştürür. Chromium ve Web Platform dokümantasyonu yeni API'lerin neden geliştirildiğini anlamaya yardımcı olur. Yerel topluluklarda yapılan ortak audit çalışmaları farklı cihaz ve problem örnekleri görme fırsatı verir.

Web Vitals Öğrenmek İçin En İyi Programlama Dili Hangisidir?

Web Vitals için tek bir en iyi programlama dili yoktur. JavaScript browser main thread davranışını anlamak açısından önemli olsa da HTML, CSS ve network bilgisi aynı derecede gereklidir. Backend dili TTFB ve SSR performansını etkileyebilir. Dil seçimi yerine browser execution modelini öğrenmek daha kalıcı yetkinlik sağlar. Gerçek proje profiling deneyimi syntax bilgisinden daha değerlidir.

Yazılımcı Olmak İçin Web Performansı Ne Zaman Öğrenilmeli?

HTML, CSS ve temel JavaScript öğrendikten sonra performans kavramlarına erken başlamak yararlıdır. İlk projelerde image sizing, cache ve bundle farkını anlamak yeterli olabilir. Deneyim arttıkça RUM, event timing ve rendering trace gibi konular eklenir. Performans ileri seviye uzmanların sonradan yaptığı özel iş olarak görülmemelidir. Her geliştirici feature'ın kullanıcı cihazında ne kadara mal olduğunu temel düzeyde anlayabilmelidir.

Browser Rendering Mantığını Öğrenmenin Önemi

DOM, CSSOM, layout, paint ve composite ilişkisini bilmeden performance audit önerileri ezbere dönüşebilir. Hangi CSS değişikliğinin layout tetiklediğini anlamak animation kararını değiştirir. Event loop bilgisi long task ve INP sorunlarını açıklamayı kolaylaştırır. Preload scanner bilgisi LCP discovery problemini görünür hale getirir. Browser mechanics framework değişse bile geçerliliğini korur.

Open Source ve İşbirliği ile Performans Yetkinliği Geliştirmek

Open source project issue'larında bundle regression veya slow interaction problemi çözmek gerçek dünya deneyimi sağlar. Pull request benchmark ve trace paylaşmayı öğretir. Farklı cihaz ve browser geri bildirimleri tek ortamda göremeyeceğiniz problemlere erişim sunar. Küçük documentation ve test contribution ile başlanabilir. İşbirliği performans kararlarını gerekçeli biçimde anlatma becerisini de geliştirir.

Chromium ve Web Platformu Kaynak Kodlarından Öğrenmek

Browser source code doğrudan günlük geliştirme için okunması zor olabilir, ancak ilgili design document ve API implementation notları çok öğreticidir. Event timing veya LoAF gibi API'lerin hangi problem için geliştirildiği daha iyi anlaşılır. Standards discussion behavior sınırlarını gösterir. Her geliştiricinin bütün browser engine'i incelemesi gerekmez. Belirli performance problemi hakkında kaynak seviyesine inmek ileri uzmanlık için güçlü yöntemdir.

Gerçek Açık Kaynak Projelerde Performance Issue Çözmek

Gerçek repository'de bundle size, hydration veya rendering sorunu bulmak farklı trade-off'larla karşılaşmanızı sağlar. Benchmark repeatable oluşturulmalıdır. Değişiklik öncesi ve sonrası trace paylaşılmalıdır. Optimization code readability'yi gereksiz bozuyorsa maintainer feedback önemlidir. Bu süreç performans mühendisliğini yalnızca teorik tavsiye olmaktan çıkarır.

Diyarbakır Yazılım Topluluğu Gibi Yerel Topluluklarda Web Vitals Çalışmaları Yapmak

Yerel toplulukta aynı açık kaynak sayfa üzerinde performance audit workshop düzenlemek etkili öğrenme yöntemidir. Katılımcılar LCP waterfall, INP interaction ve CLS shift analizini ekipler halinde yapabilir. Farklı cihazlardan RUM benzeri test sonuçları karşılaştırılabilir. Çalışmaların kod ve ölçüm sonuçları topluluk projelerine katkı sunabilir. Diyarbakır Yazılım Topluluğu hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresi ziyaret edilebilir.

Sık Sorulan Sorular

Core Web Vitals konusunda en sık sorulan sorular genellikle skor, SEO, framework ve hangi optimizasyonun önce yapılması gerektiği etrafında toplanır. En önemli nokta LCP, INP ve CLS'nin birbirinden farklı kullanıcı deneyimi problemlerini ölçtüğünü hatırlamaktır. Tek bir teknik bütün metrikleri aynı anda düzeltmeyebilir. Field data ile kök neden bulunmadan yapılan genel tavsiyeler bazı sayfalarda ters etki oluşturabilir. Aşağıdaki yanıtlar pratik karar sürecinde kullanılabilecek temel çerçeveyi sunar.

Core Web Vitals SEO'yu Etkiler mi?

Core Web Vitals Google'ın sayfa deneyimi sinyalleri kapsamında dikkate alınan kullanıcı deneyimi göstergeleridir. Ancak iyi skor tek başına güçlü arama sıralaması garantisi vermez. İçerik kalitesi, alaka ve diğer arama sistemleri çok daha geniş değerlendirme yapar. Performans kullanıcı deneyimi ve conversion açısından SEO dışında da doğrudan önemlidir. Bu nedenle Core Web Vitals yalnızca sıralama taktiği değil ürün kalitesi olarak ele alınmalıdır.

İyi LCP Değeri Kaç Olmalı?

İyi LCP hedefi 75. yüzdelik dilimde 2,5 saniye veya daha düşük değerdir. Mobil ve masaüstü ayrı değerlendirilmelidir. Tek hızlı local test bu hedefin karşılandığını göstermez. LCP dört alt parçaya ayrılıp bottleneck belirlenmelidir. Field p75 sonucu optimization başarısının temel göstergesidir.

INP Nasıl 200 ms Altına İndirilir?

Önce interaction input delay, processing duration ve presentation delay olarak ayrılmalıdır. Main thread long task'ları input delay'i artırıyorsa script azaltılmalı veya bölünmelidir. Event handler ağırsa processing logic sadeleştirilmelidir. Büyük render varsa component update scope'u küçültülmelidir. Production attribution hangi interaction'ın problemi oluşturduğunu göstermelidir.

CLS Nasıl Sıfıra Yaklaştırılır?

Image, iframe ve video alanları yükleme öncesi rezerve edilmelidir. Font fallback metrics final font'a yaklaştırılmalıdır. Dynamic banner ve reklam slotları mevcut content'i beklenmedik biçimde itmemelidir. Skeleton final content boyutuna yakın olmalıdır. Layout shift attribution kalan sorunlu elementleri production'da bulmaya yardımcı olur.

INP ile FID Arasındaki Fark Nedir?

FID yalnızca ilk interaction'ın processing başlamadan önceki input delay'ini ölçüyordu. INP sayfa yaşam döngüsündeki etkileşimleri daha geniş biçimde değerlendirir. Event processing ve next paint'e kadar olan presentation süresini dikkate alır. Bu nedenle sayfa açıldıktan çok sonra oluşan responsiveness problemini yakalayabilir. 2024'ten beri FID yerine Core Web Vital olarak INP kullanılmaktadır.

Lighthouse Skoru ile Core Web Vitals Aynı Şey midir?

Hayır, Lighthouse kontrollü laboratuvar koşullarında sentetik analiz yapar. Core Web Vitals field değerlendirmesi gerçek kullanıcı verisindeki p75 performansına dayanır. Lighthouse'ta INP'nin doğrudan gerçek kullanıcı karşılığı yerine interaction olmayan load testlerinde TBT gibi diagnostic metrikler bulunabilir. Skor debugging ve CI için yararlıdır. Production başarısı CrUX ve RUM ile doğrulanmalıdır.

TBT ile INP Arasındaki İlişki Nedir?

Total Blocking Time laboratuvar yükleme sırasında main thread blocking süresini gösterir. Yüksek TBT kötü responsiveness riskine işaret edebilir. INP ise gerçek kullanıcı interaction'larını ölçer ve page lifetime boyunca farklı aşamalarda oluşabilir. TBT iyi olsa bile daha sonra ağır interaction kötü INP yaratabilir. TBT diagnostic proxy, INP field kullanıcı metriği olarak görülmelidir.

LCP Görseline Lazy Loading Uygulanmalı mı?

Genellikle hayır, viewport üstündeki LCP image lazy yüklenmemelidir. Kaynağın mümkün olduğunca erken keşfedilip request edilmesi gerekir. Responsive sizing ve priority doğru ayarlanmalıdır. Below-the-fold image'lar lazy loading için uygundur. LCP elementinin gerçekten hangi image olduğu mobile ve desktop field data'da kontrol edilmelidir.

fetchpriority ile preload Arasındaki Fark Nedir?

Fetch priority zaten keşfedilen request'in relative priority'sine browser için ipucu verir. Preload ise browser'ın kaynağı normal discovery'den önce request etmesini sağlayabilir. Image HTML'de erken bulunuyorsa fetchpriority yeterli olabilir. CSS background gibi geç keşfedilen resource preload'dan daha fazla yararlanabilir. İkisini gereksiz birlikte kullanmak network davranışını ölçmeden yapılmamalıdır.

Server Components Web Vitals'ı İyileştirir mi?

Server Components client JavaScript'i azaltabildiği için LCP ve INP üzerinde fayda sağlayabilir. Ancak data waterfall veya yavaş server rendering TTFB'yi kötüleştirebilir. Interactive client boundary yanlış tasarlanırsa hydration maliyeti devam eder. Framework feature otomatik performans garantisi değildir. Bundle, server timing ve RUM sonucu birlikte ölçülmelidir.

Web Worker INP'yi Her Zaman İyileştirir mi?

Hayır, worker yalnızca uygun CPU yoğun işi main thread dışına taşıdığında yardımcı olur. DOM rendering ve framework update worker'da yapılamaz. Message serialization overhead küçük işlerde faydayı yok edebilir. Önce performance profile yapılmalıdır. Worker sonucu gerçek production INP ile doğrulanmalıdır.

content-visibility Ne Zaman Kullanılmalı?

Uzun page section, büyük product list ve viewport dışındaki bağımsız content bloklarında değerlendirilebilir. Initial rendering cost'i azaltabilir. contain-intrinsic-size gerçek boyuta yakın olmalıdır. Yanlış tahmin scroll sırasında CLS yaratabilir. Browser behavior ve accessibility use case'i test edilmelidir.

PageSpeed'de 100 Almak Gerekli mi?

Hayır, 100 skor business ve kullanıcı başarısının zorunlu koşulu değildir. Gerçek field Core Web Vitals, conversion ve usability daha önemlidir. Skoru 98'den 100'e taşımak için yüksek engineering effort yerine kötü mobile p75 sayfasını düzeltmek daha değerlidir. Lighthouse fırsat bulma ve regresyon testinde kullanılmalıdır. Hedef skor değil sürdürülebilir hızlı deneyimdir.

Core Web Vitals'ı Production'da Nasıl Ölçerim?

CrUX ve PageSpeed Insights genel field görünümü sağlar. Kendi kullanıcılarınız için web-vitals library ile RUM telemetry toplanabilir. Route, release ve device segmentleri eklenebilir. Attribution build root cause analizini kolaylaştırır. Veri privacy-safe biçimde analytics endpoint'e gönderilmelidir.

En İyi Programlama Dili Web Performansı Açısından Hangisidir?

Web performansında tek bir en iyi dil yoktur. Browser'a gönderilen HTML, CSS ve JavaScript miktarı ile rendering architecture daha belirleyicidir. Backend dili TTFB açısından implementation kalitesine göre farklı sonuç verebilir. Native browser API'lerini ve network modelini anlamak dil seçmekten daha önemlidir. Ölçüm gerçek kullanıcı sonucuna göre yapılmalıdır.

Yazılımcı Olmak İçin Ne Yapmalı ve Web Performansını Ne Zaman Öğrenmeli?

Önce HTML, CSS, JavaScript ve temel network kavramları öğrenilmelidir. Sonra küçük projelerde DevTools waterfall ve performance panel kullanmak iyi başlangıçtır. Framework öğrenirken browser davranışını gözden kaçırmamak gerekir. RUM ve advanced profiling deneyim arttıkça eklenebilir. Performansı erken öğrenmek daha sonra teknik borç temizlemekten daha kolaydır.

Open Source ve İşbirliği Web Vitals Yetkinliğini Nasıl Geliştirir?

Açık kaynak projelerde gerçek bundle, rendering ve interaction problemleri görülebilir. Issue çözmek trace okuma becerisini geliştirir. Pull request benchmark sonuçlarını açıklama alışkanlığı kazandırır. Community review farklı çözüm trade-off'larını gösterir. Küçük performance bug'larından başlayarak ileri profiling çalışmalarına geçilebilir.

Diyarbakır'daki En İyi Yazılımcılar Frontend Performansı Konusunda Nasıl Yetkinlik Gösterebilir?

Frontend performans yetkinliği yalnızca bir framework'ü hızlı kullanmakla gösterilmez. Geliştirici gerçek kullanıcı verisini okuyabilmeli, browser trace üzerinde root cause bulabilmeli ve yaptığı değişikliğin production etkisini kanıtlayabilmelidir. LCP resource discovery, INP attribution ve CLS layout analysis gibi konularda ölçülebilir örnek çalışmalar güçlü portföy oluşturur. Open source katkı ve topluluk içinde performans audit'leri de deneyimi görünür hale getirir. Diyarbakır Yazılım Topluluğu üzerinden yerel teknik çalışmalar ve paylaşım ortamı hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr adresi kullanılabilir.

Core Web Vitals nedir ve LCP, INP ile CLS metrikleri nasıl iyileştirilir?

Core Web Vitals yükleme, etkileşim yanıtı ve görsel kararlılığı LCP, INP ve CLS üzerinden ölçen kullanıcı odaklı metriklerdir. LCP iyileştirmesi için TTFB, resource discovery, download ve render delay ayrı analiz edilmelidir. INP için main thread, event processing ve presentation delay incelenmelidir. CLS için media alanları, font metrics ve dynamic content layout'u önceden planlanmalıdır. En doğru süreç laboratuvar teşhisini production p75 RUM verisiyle birleştirmektir.

LCP süresini düşürmek için görsel optimizasyonu, preload ve kritik CSS teknikleri nasıl uygulanır?

Önce LCP elementinin hangi resource olduğu ve request'in ne zaman başladığı belirlenmelidir. Görsel doğru size, modern format ve responsive source ile sunulmalıdır. Geç keşfedilen kritik asset için preload, erken bulunan image için uygun fetch priority kullanılabilir. Render-blocking CSS azaltılmalı ve critical viewport style mümkün olduğunca erken sağlanmalıdır. Çok fazla preload eklemek yerine waterfall üzerinde yalnızca gerçek bottleneck'e müdahale edilmelidir.

INP performansını iyileştirmek için JavaScript ana iş parçacığı ve uzun görevler nasıl optimize edilir?

Önce kötü interaction'ın input delay, processing duration veya presentation delay bölümünün hangisinde zaman kaybettiği ölçülmelidir. Uzun main-thread task'lar küçük parçalara bölünüp browser'a düzenli kontrol bırakılabilir. Handler içinde yalnızca kullanıcıya gerekli minimum iş yapılmalı ve ağır hesaplama worker veya sonraki task'a taşınmalıdır. Büyük framework render'ları subtree seviyesinde azaltılmalıdır. LoAF ve web-vitals attribution production'da gerçek script ve target'ı bulmak için kullanılabilir.

CLS sorunlarını azaltmak için fontlar, görseller ve dinamik içerikler nasıl yönetilmelidir?

Görsel ve iframe için width-height veya aspect ratio ile alan önceden ayrılmalıdır. Font fallback final font metrics'ine size-adjust ve ilgili metric override özellikleriyle yaklaştırılabilir. Skeleton gerçek content boyutuna yakın olmalıdır. Cookie banner ve reklam slotları mevcut içeriği beklenmedik biçimde itmemelidir. Layout shift attribution kalan problemlerin hangi elementten geldiğini production'da gösterebilir.

Yakınımda Core Web Vitals ve ileri düzey frontend performans optimizasyonu hizmeti veren yazılım firması nasıl bulabilirim?

Web Vitals ve frontend performans danışmanlığı yakınımda araması yaparken yalnızca PageSpeed skoru sunan hizmet yerine RUM, root cause analysis, frontend architecture ve CI/CD regresyon kontrolünü birlikte değerlendiren yaklaşım aranmalıdır. Sağlıklı çalışma mevcut p75 baseline, kritik sayfa şablonları ve business KPI'larla başlamalıdır. LCP, INP ve CLS ayrı teknik planlara dönüştürülmelidir. Diyarbakır ve çevresinde kurumsal web sitesi Core Web Vitals ve frontend performans optimizasyon hizmeti hakkında iletişim kurmak için https://www.diyarbakiryazilim.com.tr adresini kullanabilirsiniz. Projenin mevcut metric dağılımı paylaşılarak küçük audit'ten sürekli RUM ve CI/CD performans programına kadar uygun kapsam değerlendirilebilir.

Sonuç: Web Vitals Optimizasyonu Bir Hız Eklentisi Değil, Sürekli Frontend Mühendisliği Sürecidir

Web Vitals optimizasyonu birkaç image sıkıştırıp bir kerelik Lighthouse raporu almakla tamamlanmaz. İyi sonuç gerçek kullanıcıyı ölçen, metriği alt parçalarına ayıran ve yapılan her değişikliği production verisiyle doğrulayan süreçten gelir. Web Vitals Metriklerini İyileştiren İleri Düzey Frontend Taktikleri yaklaşımında LCP network ve rendering, INP main thread ve interaction, CLS ise layout stability perspektifleriyle ayrı ele alınır. CI/CD budget yeni regresyonu engellerken RUM release sonrası gerçek cihaz ve network dağılımını izler. Kurumsal frontend performans sürecinizi değerlendirmek, mevcut darboğazları ölçmek ve sürdürülebilir bir optimizasyon planı oluşturmak için https://www.diyarbakiryazilim.com.tr üzerinden Diyarbakır Yazılım Topluluğu ile iletişim kurabilirsiniz.

Önce Gerçek Kullanıcıyı Ölç

İlk adım local geliştirme bilgisayarında skor üretmek değil production kullanıcı dağılımını görmektir. CrUX genel referans, kendi RUM sisteminiz ise route ve interaction seviyesinde ayrıntı sağlar. Mobile ve desktop p75 ayrı izlenmelidir. Device, network ve release segmentleri root cause analizini güçlendirir. Ölçüm olmadan performans backlog'u tahmine dayanır.

Metriği Alt Bileşenlerine Ayır

LCP TTFB, load delay, load duration ve render delay olarak ayrılmalıdır. INP input delay, processing duration ve presentation delay üzerinden analiz edilmelidir. CLS shift cluster ve target bilgisiyle incelenmelidir. Tek sayı hangi code'u değiştirmeniz gerektiğini söylemez. Alt parçalar engineering çözümünü doğrudan yönlendirir.

Kök Nedeni Tespit Et

Bir LCP problemi image size değil JavaScript render delay olabilir. INP problemi click handler değil alakasız third-party task olabilir. CLS problemi image değil font swap olabilir. DevTools, LoAF ve attribution gerçek nedeni bulmak için birlikte kullanılmalıdır. Düzeltme yalnızca gözlenen root cause'a uygulanmalıdır.

En Küçük Etkili Değişikliği Yayınla

Aynı anda çok sayıda optimization yapmak hangi değişikliğin işe yaradığını anlamayı zorlaştırır. Küçük ve kontrollü release daha güvenli sonuç verir. Feature flag veya canary rollout riskli performance değişikliğini sınırlayabilir. Before-after aynı segment üzerinde karşılaştırılır. Başarılı müdahale sonra genişletilir.

Production Verisiyle Doğrula

Lab sonucu iyileşse bile production p75 değişmeyebilir. Kullanıcı cihazları ve gerçek content yapısı farklıdır. Release ID metric event'lerine eklenmelidir. Business KPI aynı dönemde izlenebilir. Gerçek başarı kullanıcıların daha iyi deneyim yaşamasıyla doğrulanır.

Regresyonu CI/CD'de Engelle

Performans yalnızca uzman bir kişinin düzenli kontrolüne bağlı kalmamalıdır. Bundle, CSS, critical asset ve third-party budget pipeline içinde çalışmalıdır. Pull request yeni maliyeti görünür hale getirmelidir. Production RUM alert'i sentetik testin kaçırdığı regresyonu yakalar. Böylece performans geçici optimizasyon çalışması değil, kurumun sürekli frontend mühendisliği standardı haline gelir.