Sayfa Yükleme Hızı (Pagespeed) İçin Varlık (Asset) Optimizasyonu

Bir web sitesi birkaç saniye geç açıldığında kullanıcı çoğu zaman teknik sebebi düşünmez, yalnızca sayfanın yavaş olduğunu hisseder. Bu gecikmenin arkasında büyük görseller, gereksiz JavaScript, kullanılmayan CSS, ağır fontlar veya yanlış önceliklendirilmiş üçüncü taraf kaynakları bulunabilir. Sayfa Yükleme Hızı (Pagespeed) İçin Varlık (Asset) Optimizasyonu, bu kaynakların doğru boyutta, doğru sırada ve doğru yöntemle kullanıcıya ulaştırılmasını hedefler. On yıllık web performansı çalışmalarında gördüğüm en önemli nokta, hız problemlerinin tek bir dosyadan değil, çoğu zaman birbirini tetikleyen küçük kararların toplamından oluşmasıdır. Bu rehberde PageSpeed için CSS JavaScript ve görsel optimizasyonu nasıl yapılır, web sitesi asset optimizasyonu ile sayfa yükleme hızı nasıl artırılır ve gerçek kullanıcı deneyimi hangi ölçümlerle doğrulanır sorularını adım adım ele alacağız.

Asset Optimizasyonu Nedir?

Asset optimizasyonu, tarayıcının bir sayfayı oluşturmak için indirdiği kaynakların boyutunu, yüklenme sırasını ve çalışma maliyetini azaltma sürecidir. Buradaki amaç yalnızca dosyaları küçültmek değildir. Doğru kaynağın doğru anda çağrılması da en az dosya boyutu kadar önemlidir. Örneğin kullanıcı ilk ekranda tek bir görsel görüyorsa sayfanın alt bölümündeki on görselin aynı anda yüklenmesi gereksiz ağ tüketimi yaratabilir. Sayfa Yükleme Hızı (Pagespeed) İçin Varlık (Asset) Optimizasyonu bu nedenle ağ, tarayıcı ve kullanıcı deneyimini birlikte değerlendiren bir performans çalışmasıdır.

Web Asset Nedir?

Web asset, bir internet sayfasının görünmesi veya çalışması için tarayıcıya gönderilen kaynakların genel adıdır. CSS, JavaScript, font, görsel, video ve ikon dosyaları bu gruba girer. Bir asset küçük görünse bile başka kaynakları tetiklediğinde toplam yükleme süresini büyütebilir. Özellikle ilk ekranda ihtiyaç duyulmayan kaynaklar kritik yükleme yoluna girdiğinde kullanıcı sayfayı geç görmeye başlar. Bu nedenle asset analizi yalnızca dosya listesini değil, dosyaların birbirleriyle ilişkisini de kapsamalıdır.

Hangi Kaynaklar Asset Olarak Değerlendirilir?

Tarayıcının sayfayı göstermek için indirdiği veya çalıştırdığı hemen her dış kaynak asset kapsamında değerlendirilebilir. Bunların bazıları doğrudan HTML içinde tanımlanır, bazıları ise başka CSS veya JavaScript dosyaları tarafından çağrılır. Performans açısından asıl soru, kaynağın ne olduğu kadar ne zaman gerektiğidir. İlk ekranda kullanılmayan bir kaynak erken indiriliyorsa ağ kapasitesini daha önemli dosyalardan çalabilir. Bu yüzden aşağıdaki asset türlerinin her biri farklı bir optimizasyon yaklaşımı gerektirir.

Görseller

Görseller çoğu web sitesinde toplam sayfa ağırlığının önemli bölümünü oluşturur. Gereğinden büyük çözünürlükte sunulan fotoğraflar mobil kullanıcıya yüzlerce kilobayt fazladan veri gönderebilir. WebP veya AVIF gibi modern formatlar uygun içerikte önemli boyut avantajı sağlayabilir. Responsive image kullanımı, cihazın gerçekten ihtiyaç duyduğu boyuttaki dosyayı seçmesini kolaylaştırır. LCP görseli ise diğer görsellerden farklı değerlendirilerek mümkün olduğunca erken keşfedilebilir olmalıdır.

CSS

CSS dosyaları sayfanın görünümünü belirlediği için render sürecinde özel bir yere sahiptir. Büyük bir global stylesheet içinde yalnızca küçük bir bölümü kullanılıyor olsa bile tarayıcı tüm dosyayı indirmek zorunda kalabilir. Kritik stillerin belirlenmesi ve kullanılmayan kuralların azaltılması ilk görünümü hızlandırabilir. Render blocking CSS JavaScript dosyaları nasıl optimize edilir sorusunun CSS tarafındaki cevabı, kritik stilleri öne almak ve diğerlerini doğru zamanda yüklemektir. Her CSS dosyasını otomatik olarak inline etmek ise doğru çözüm değildir.

JavaScript

JavaScript yalnızca indirilmez, aynı zamanda ayrıştırılır, derlenir ve çalıştırılır. Bu nedenle aynı boyuttaki bir görsel ile JavaScript dosyasının performans maliyeti aynı değildir. Özellikle düşük işlem gücüne sahip mobil cihazlarda büyük JavaScript paketleri ana iş parçacığını uzun süre meşgul edebilir. Kullanılmayan kodların kaldırılması, code splitting ve doğru async veya defer kullanımı önemli kazanımlar sağlayabilir. Etkileşim performansının iyileştirilmesinde JavaScript yükünün azaltılması temel adımlardan biridir.

Fontlar

Font dosyaları görsel kimlik açısından önemli olsa da gereksiz ağırlıklar hız üzerinde olumsuz etki yaratabilir. Dört farklı font ailesi ve her aile için çok sayıda weight yüklemek çoğu sayfada gereksizdir. WOFF2 formatı modern web projelerinde genellikle iyi bir temel seçenektir. Font subsetting ve unicode-range kullanımı indirilen karakter setini küçültmeye yardımcı olabilir. Fallback font metriklerinin doğru ayarlanması da yazı tipi değişiminden kaynaklanan CLS sorunlarını azaltabilir.

Video ve Ses

Video ve ses dosyaları diğer statik asset türlerinden çok daha büyük olabilir. Sayfa açılır açılmaz otomatik indirilen bir video, ziyaretçinin hiç izlemeyeceği megabaytlarca verinin aktarılmasına yol açabilir. Poster görseli ve etkileşim sonrası yükleme yaklaşımı birçok sayfada daha sağlıklı sonuç verir. Uzun videolarda uyarlanabilir yayın teknikleri bağlantı kalitesine göre uygun kaliteyi sunabilir. Medya yükleme stratejisi hazırlanırken kullanıcı niyeti ve sayfanın temel amacı birlikte değerlendirilmelidir.

SVG ve İkonlar

SVG özellikle logo, ikon ve basit vektör çizimlerinde çok verimli olabilir. Ancak gereksiz metadata, karmaşık path yapıları ve tekrar eden tanımlar dosya boyutunu artırabilir. Çok sayıda küçük ikon ayrı ağ isteği oluşturuyorsa sprite veya inline kullanım seçenekleri değerlendirilebilir. Buna karşılık her SVG dosyasını inline etmek HTML boyutunu gereksiz artırabilir. En doğru yöntem ikon sayısı, tekrar kullanımı ve cache davranışı dikkate alınarak seçilmelidir.

Third-Party Kaynaklar

Third-party kaynaklar sizin sunucunuz dışında çalışan analiz, sohbet, harita, video veya başka servislerden gelebilir. Bu dosyaların ağ gecikmesi ve JavaScript çalışma maliyeti üzerinde tam kontrolünüz olmayabilir. Bir üçüncü taraf scripti görünürde küçük olsa bile ardından çok sayıda ek istek başlatabilir. Bu nedenle üçüncü taraf kaynaklar ayrı bir performans bütçesiyle izlenmelidir. Kullanılmayan veya düşük değer sağlayan scriptlerin tamamen kaldırılması çoğu zaman en etkili optimizasyondur.

Asset Boyutu ile Sayfa Hızı Arasındaki İlişki

Asset boyutu büyüdükçe indirme süresi genellikle artar, ancak ilişki yalnızca megabayt hesabından ibaret değildir. Bağlantı gecikmesi, dosya önceliği, cache durumu ve sunucu yanıt süresi de sonucu etkiler. Büyük bir JavaScript dosyası indirildikten sonra ek işlem süresi oluşturduğu için etkisi daha da belirgin olabilir. Aynı dosyanın cache içindeki tekrar ziyaret performansı ile ilk ziyaret performansı farklıdır. Bu nedenle sayfa ağırlığı tek başına değil request count, CPU süresi ve kritik yükleme zinciriyle birlikte okunmalıdır.

Asset Optimizasyonu ile SEO Arasındaki İlişki

Asset optimizasyonu doğrudan kullanıcıların sayfaya ne kadar hızlı eriştiğini etkiler. Daha hızlı yüklenen ve etkileşime daha çabuk cevap veren sayfalar kullanıcı deneyimini destekler. Core Web Vitals verileri de gerçek kullanıcı performansının değerlendirilmesinde önemli bir rol oynar. Teknik SEO çalışmasında hız, içerik kalitesinin veya arama niyetinin yerine geçmez fakat teknik temeli güçlendirir. E-ticaret SEO yapılarında performans ile metadata kurgusunun birlikte düşünülmesine ilişkin farklı bir teknik yaklaşım için https://www.diyarbakiryazilim.com.tr/posts/e-ticaret-sistemlerinde-otomatik-seo-metadata-kurgulari adresindeki içeriği de inceleyebilirsiniz.

PageSpeed Skoru ile Gerçek Sayfa Hızı Aynı Şey midir?

PageSpeed skoru ile gerçek kullanıcı deneyimi aynı kavram değildir. Bir laboratuvar testi kontrollü koşullarda tekrar üretilebilir sonuç verirken gerçek kullanıcılar farklı cihaz, ağ ve coğrafi koşullardan siteye bağlanır. Bu nedenle tek bir skor üzerinden site hızına kesin hüküm vermek yanıltıcı olabilir. Teknik ekiplerin laboratuvar ölçümlerini teşhis için, saha verilerini ise gerçek deneyimi anlamak için birlikte kullanması gerekir. Ben performans projelerinde skorun kendisinden çok hangi metriğin neden kötüleştiğine odaklanmayı daha faydalı buluyorum.

PageSpeed Insights Neyi Ölçer?

PageSpeed Insights bir URL için laboratuvar verilerini ve mevcut olduğunda gerçek kullanıcı verilerini birlikte sunabilir. Araç, yükleme ve etkileşim performansındaki sorunlara ilişkin çeşitli teşhisler gösterir. Burada görülen her öneri aynı öncelikte değildir. Bir tavsiyenin LCP, INP veya başka bir kullanıcı metriğine etkisi ayrıca değerlendirilmelidir. Bu yüzden raporu bir yapılacaklar listesi gibi değil, sorun araştırma başlangıcı olarak görmek daha sağlıklıdır.

Lighthouse Performance Score

Lighthouse Performance Score belirli laboratuvar koşullarında oluşturulan bileşik bir performans puanıdır. Puan çeşitli metriklerin ağırlıklı değerlendirilmesiyle hesaplanır. Aynı sayfa farklı koşullarda küçük puan değişimleri gösterebilir. Bu nedenle tek ölçüm yerine birden fazla testin eğilimine bakmak daha anlamlıdır. Puan iyileşirken gerçek kullanıcı deneyiminin kötüleşmediğinden de emin olunmalıdır.

Lab Data Nedir?

Lab data kontrollü cihaz ve ağ koşullarında yapılan sentetik testlerden elde edilir. Bu verinin en önemli avantajı tekrar edilebilir olmasıdır. Geliştirici bir değişiklik yaptıktan sonra önceki ve sonraki sonucu karşılaştırabilir. Ancak laboratuvar koşulları gerçek kullanıcı kitlesinin tamamını temsil etmez. Bu nedenle lab data sorun tespiti ve regresyon analizi için güçlü, fakat tek başına yeterli olmayan bir kaynaktır.

Field Data Nedir?

Field data gerçek kullanıcıların siteyi kullanırken oluşturduğu performans ölçümleridir. Farklı cihazlar, bağlantı türleri ve kullanım koşulları bu veriye yansır. Bu nedenle saha verisi gerçek deneyim hakkında laboratuvar testlerinden farklı bir perspektif sağlar. Ancak yeni bir değişikliğin etkisinin field data üzerinde görünmesi belirli bir süre gerektirebilir. En iyi yaklaşım hızlı teşhis için lab data, uzun dönem doğrulama için field data kullanmaktır.

CrUX ve Gerçek Kullanıcı Verileri

Chrome UX Report, uygun veri hacmine sahip sayfalar veya origin seviyeleri için gerçek kullanıcı performansı hakkında bilgi sağlar. Bu veri özellikle Core Web Vitals değerlendirmesinde önemlidir. CrUX değerleri tek bir hızlı cihazı değil geniş bir kullanıcı örneklemini temsil eder. Bu yüzden masaüstü geliştirme ortamında hızlı görünen bir sayfanın mobil kullanıcıda neden yavaş hissedildiğini anlamaya yardımcı olabilir. Veri bulunmadığında kendi Real User Monitoring yapınız da değerli bir alternatif oluşturur.

Neden Sadece “100/100” Hedeflenmemeli?

100/100 puanı teknik ekip için motive edici görünse de kullanıcı deneyiminin tek ölçüsü değildir. Puanı yükseltmek uğruna gerekli işlevleri kaldırmak veya kullanıcıya değer sağlayan özellikleri bozmak doğru değildir. Bir e-ticaret sayfasındaki ürün galerisi, filtre veya ödeme davranışı performans ile birlikte değerlendirilmelidir. Bazen 95 puanlı dengeli bir sayfa, işlevleri kırpılmış 100 puanlı bir sayfadan daha iyi sonuç verir. Hedef, laboratuvar skorunu değil kullanıcıya hızlı ve kararlı bir deneyim sunmayı merkezde tutmalıdır.

Asset Optimizasyonu Hangi Core Web Vitals Metriklerini Etkiler?

Asset optimizasyonu özellikle LCP, INP ve CLS üzerinde doğrudan veya dolaylı etki oluşturabilir. Büyük hero görseli LCP'yi, yoğun JavaScript INP'yi, boyutu tanımlanmamış görseller ise CLS'yi kötüleştirebilir. Aynı sayfada bu üç problemin birlikte bulunması oldukça yaygındır. Bu nedenle performans çalışmasını tek dosya türüne göre değil metrik bazlı yürütmek daha verimlidir. Her optimizasyonun hangi kullanıcı metriğini hedeflediği baştan tanımlandığında ölçüm yapmak da kolaylaşır.

Largest Contentful Paint (LCP)

LCP, görünür alandaki büyük içerik öğelerinden birinin ne zaman çizildiğini ölçmeye yardımcı olur. Birçok kurumsal veya tanıtım sayfasında bu öğe hero görselidir. Görselin geç keşfedilmesi, fazla büyük olması veya düşük öncelikte yüklenmesi LCP süresini uzatabilir. Sunucu gecikmesi de zincirin başlangıcını yavaşlattığı için yalnızca görsel dosyasına odaklanmak yeterli değildir. LCP optimizasyonunda kaynağın keşfedilme zamanı, transfer süresi ve render gecikmesi ayrı ayrı incelenmelidir.

İyi Değer: 2,5 Saniye ve Altı

LCP için iyi kullanıcı deneyimi eşiği genel olarak 2,5 saniye ve altıdır. Ancak tek bir laboratuvar sonucunun bu sınırın altında olması yeterli doğrulama değildir. Gerçek kullanıcı verisinin dağılımı ayrıca incelenmelidir. Mobil kullanıcıların daha yavaş bağlantılarda yaşadığı deneyim özellikle önemlidir. Hedef, yalnızca testi geçmek değil kullanıcı kitlesinin büyük bölümünde tutarlı performans sağlamaktır.

Interaction to Next Paint (INP)

INP sayfanın kullanıcı etkileşimlerine ne kadar hızlı görsel geri bildirim verdiğini değerlendirmeye yardımcı olur. Büyük JavaScript görevleri, ağır event handler kodları ve üçüncü taraf scriptleri kötü INP sonuçlarına yol açabilir. Bir butona tıklayan kullanıcı arayüzün donduğunu hissediyorsa problem çoğu zaman yalnızca ağ hızından kaynaklanmaz. Ana iş parçacığının meşgul olması da önemli bir etkendir. JavaScript asset optimizasyonu bu nedenle etkileşim performansının temel bileşenlerinden biridir.

İyi Değer: 200 ms ve Altı

INP için iyi değer 200 milisaniye ve altı olarak değerlendirilir. Bu hedefe ulaşmak için uzun görevlerin bölünmesi ve gereksiz işlemlerin azaltılması gerekir. Tıklama anında ihtiyaç duyulmayan hesaplamalar daha sonra çalıştırılabilir. Büyük DOM güncellemeleri de etkileşim süresini uzatabilir. Ölçüm yaparken gerçek kullanıcı cihazlarının işlem gücü dikkate alınmalıdır.

Cumulative Layout Shift (CLS)

CLS sayfadaki beklenmedik yerleşim kaymalarını ölçer. Görselin boyutu tanımlanmamışsa içerik yüklendiğinde metin aşağı kayabilir. Font değişimleri veya sonradan eklenen reklam alanları da benzer kaymalara yol açabilir. Asset optimizasyonu yalnızca hızlı yükleme değil kararlı yerleşim için de önemlidir. Kullanıcı tıklamak üzere olduğu bir butonun yer değiştirmesi ciddi deneyim problemi oluşturabilir.

İyi Değer: 0,1 ve Altı

CLS için iyi değer 0,1 ve altı olarak kabul edilir. Bu değeri korumak için medya alanlarına önceden yer ayrılması gerekir. Görsellerde width ve height nitelikleri kullanmak basit ama etkili bir uygulamadır. Fallback font ile web fontu arasındaki metrik farklarının azaltılması da fayda sağlar. Dinamik içerik eklenecek alanlarda sabit veya öngörülebilir container yapıları tercih edilmelidir.

FCP ve TBT'nin Teşhis Amaçlı Kullanımı

FCP ve TBT, doğrudan üç Core Web Vitals metriğinden biri olmasa da performans teşhisinde yararlıdır. FCP ilk içeriğin görünmeye başlaması hakkında fikir verir. TBT laboratuvar ortamında ana iş parçacığının uzun görevlerle ne kadar bloklandığını anlamaya yardımcı olabilir. Yüksek TBT çoğu zaman ağır JavaScript yürütülmesiyle ilişkilidir. Bu değerler, asıl kullanıcı problemine giden teknik nedeni bulmak için yardımcı sinyaller olarak kullanılmalıdır.

Asset Optimizasyonuna Nereden Başlanmalı?

Performans optimizasyonunda en sık yapılan hata ölçmeden değişiklik yapmaktır. Önce mevcut durumu kaydetmek gerekir. Sayfa ağırlığı, request sayısı, LCP, INP veya laboratuvar tarafında TBT gibi değerler başlangıç noktası oluşturabilir. Daha sonra waterfall ve DevTools incelemeleriyle hangi assetin darboğaz yarattığı belirlenir. Ölçüm olmadan yapılan değişikliklerin gerçekten fayda sağlayıp sağlamadığını doğrulamak mümkün değildir.

PageSpeed Insights

PageSpeed Insights hızlı bir başlangıç analizi için kullanışlıdır. Araç laboratuvar teşhislerini ve mevcutsa gerçek kullanıcı verilerini aynı arayüzde görmenizi sağlar. Özellikle LCP öğesi, kullanılmayan kod ve kaynak önceliği gibi alanlar ilk ipuçlarını verebilir. Ancak rapordaki her satırı eşit önemde ele almak doğru değildir. Kullanıcı deneyimini en çok etkileyen darboğazdan başlamak gerekir.

Lighthouse

Lighthouse geliştirme sürecinde tekrar edilebilir performans testleri oluşturmak için kullanılabilir. Aynı sayfayı değişiklik öncesi ve sonrası karşılaştırmak pratiktir. Rapor yalnızca skor değil çeşitli teşhis bilgileri de sunar. CI ortamında Lighthouse tabanlı eşikler tanımlanarak regresyonlar erken yakalanabilir. Yine de gerçek kullanıcı verisiyle sonuçların daha sonra doğrulanması gerekir.

Chrome DevTools Network

Network paneli asset optimizasyonunda en sık kullandığım araçlardan biridir. Burada her isteğin başlangıç zamanı, boyutu, türü, domain bilgisi ve süresi görülebilir. Büyük dosyaları veya geç başlayan kritik kaynakları hızlıca fark etmek mümkündür. Disable cache seçeneği ilk ziyaret senaryosunu analiz etmeyi kolaylaştırır. Throttling ile daha yavaş mobil bağlantılara yakın koşullar oluşturulabilir.

Performance Panel

Performance paneli tarayıcının yükleme ve çalışma sırasında ne yaptığını daha ayrıntılı gösterir. JavaScript görevleri, layout hesaplamaları, paint işlemleri ve uzun görevler burada incelenebilir. INP veya ana iş parçacığı sorunlarının kaynağını bulmak için Network panelinden daha derin bilgi sağlar. Büyük script dosyası bulmak tek başına yeterli olmadığında hangi fonksiyonların zaman tükettiği araştırılabilir. Böylece optimizasyon dosya boyutundan kod davranışına kadar ilerletilebilir.

Coverage

Coverage aracı yüklenen CSS ve JavaScript dosyalarının ne kadarının gerçekten kullanıldığını görmeye yardımcı olur. Bir sayfa 300 KB CSS indirip yalnızca küçük bir bölümünü kullanıyorsa güçlü bir optimizasyon fırsatı vardır. Ancak dinamik etkileşimler nedeniyle başlangıçta kullanılmayan kod sonradan gerekli olabilir. Bu yüzden sayfada menü, modal ve diğer durumlar test edilmelidir. Coverage verisi doğrudan silme talimatı değil araştırma başlangıcıdır.

WebPageTest

WebPageTest farklı bağlantı, cihaz ve konum senaryolarında ayrıntılı performans incelemesine yardımcı olur. Waterfall görünümü özellikle kaynak zincirlerini okumak için değerlidir. Filmstrip benzeri görsel ilerleme kayıtları kullanıcıya içeriğin ne zaman görünmeye başladığını anlamayı kolaylaştırır. Tek bir puandan ziyade sayfanın zaman içinde nasıl oluştuğunu görürsünüz. Büyük performans projelerinde bu zaman çizgisi yaklaşımı oldukça öğreticidir.

Waterfall Analizi

Waterfall analizi her assetin ne zaman başladığını ve ne kadar sürdüğünü sıralı biçimde gösterir. HTML'den sonra geç keşfedilen font veya hero görseli kolayca fark edilebilir. Aynı zamanda üçüncü taraf scriptlerin oluşturduğu uzun istek zincirlerini görebilirsiniz. Kritik kaynağın başka bir dosya tamamlanana kadar beklediği durumlar performans açısından önemlidir. Web sitesi asset optimizasyonu ile sayfa yükleme hızı nasıl artırılır sorusunun en net cevaplarından biri iyi bir waterfall okumasıdır.

Asset Envanteri Nasıl Çıkarılır?

Asset envanteri sayfada kullanılan tüm kaynakların ölçülebilir bir listesidir. Bu liste yalnızca URL'leri değil boyut, domain, cache ve yüklenme zamanı gibi alanları da içermelidir. İlk envanter çıkarıldığında beklenmedik üçüncü taraf kaynaklar çoğu zaman hemen ortaya çıkar. Aynı kütüphanenin birden fazla sürümünün indirildiği durumlar da görülebilir. Envanteri düzenli güncellemek performans yönetişiminin temel parçalarından biridir.

Asset URL

Asset URL her kaynağın nereden çağrıldığını gösterir. URL yapısı cache stratejisi ve versiyonlama hakkında önemli ipuçları verebilir. Hash içeren dosya adları uzun süreli cache için uygundur. Sürekli değişen query parametreleri ise bazı altyapılarda cache davranışını zorlaştırabilir. Envanterde tam URL tutulması hangi kaynağın hangi origin veya CDN üzerinden geldiğini anlamayı kolaylaştırır.

Resource Type

Resource type kaynağın CSS, JavaScript, görsel, font veya başka bir tür olduğunu belirtir. Performans bütçeleri hazırlanırken tür bazlı ayrım oldukça kullanışlıdır. Örneğin JavaScript için daha düşük bütçe tanımlamak isteyebilirsiniz. Görsel ağırlığı ise sayfa türüne göre daha yüksek olabilir. Kaynak türü sınıflandırması hangi optimizasyon tekniğinin uygulanacağını belirlemeyi kolaylaştırır.

Transfer Size

Transfer size ağ üzerinden gerçekten aktarılan veri miktarını gösterir. Sıkıştırma etkin olduğunda bu değer kaynak dosyanın açılmış boyutundan daha küçük olabilir. Mobil bağlantılarda transfer size önemli bir maliyet göstergesidir. Ancak cache üzerinden gelen bir asset ikinci ziyarette farklı davranabilir. Bu nedenle ilk ve tekrar ziyaret senaryoları ayrı incelenmelidir.

Uncompressed Size

Uncompressed size dosyanın tarayıcı tarafından açıldığında kapladığı yaklaşık büyüklüğü anlamaya yardımcı olur. CSS ve JavaScript için transfer boyutu düşük olsa bile açılmış içerik büyük olabilir. JavaScript tarafında bu durum parse ve çalışma maliyetini de etkileyebilir. Yalnızca sıkıştırılmış boyuta bakmak gerçek işlem maliyetini gözden kaçırabilir. Envanterde iki değerin birlikte tutulması daha doğru karar verilmesini sağlar.

Domain

Domain bilgisi bir kaynağın first-party veya başka bir sağlayıcı üzerinden geldiğini anlamaya yardımcı olur. Yeni domain bağlantıları DNS, TCP ve güvenli bağlantı maliyeti oluşturabilir. Çok sayıda farklı origin performansı olumsuz etkileyebilir. Preconnect bazı kritik originler için yardımcı olabilir, fakat sınırsız kullanılmamalıdır. Domain kırılımı third-party bütçe çalışmasının da temel girdisidir.

Cache Status

Cache status assetin ağdan mı yoksa tarayıcı önbelleğinden mi geldiğini gösterir. Tekrar ziyaret performansını anlamak için bu bilgi önemlidir. Uzun ömürlü statik assetlerde cache hit görmek beklenen bir durumdur. Sık değişmeyen dosyaların her ziyarette yeniden indirilmesi gereksiz maliyet oluşturur. Cache politikasının dosya versiyonlama yöntemiyle birlikte tasarlanması gerekir.

Priority

Priority tarayıcının kaynaklar arasında hangi isteğe daha fazla önem verdiğini anlamaya yardımcı olur. LCP görselinin düşük öncelikte olması ilk ekran performansını geciktirebilir. Buna karşılık sayfanın altındaki bir görselin çok yüksek öncelikle yüklenmesi kritik kaynaklarla rekabet yaratabilir. fetchpriority gibi araçlar yalnızca gerçekten gerekli durumlarda kullanılmalıdır. Öncelik yönetiminde amaç her şeyi hızlandırmak değil doğru şeyi önce yüklemektir.

Load Start

Load start bir assetin ne zaman keşfedilip yüklenmeye başladığını gösterir. Kritik bir kaynak geç başlıyorsa dosya boyutunu küçültmek tek başına yeterli olmayabilir. Örneğin CSS içindeki background image ancak stylesheet indirildikten sonra keşfedilebilir. JavaScript ile eklenen görseller daha da geç başlayabilir. Bu nedenle keşfedilme zamanı LCP optimizasyonunda merkezi bir metriktir.

Duration

Duration isteğin tamamlanmasının ne kadar sürdüğünü gösterir. Uzun süre yalnızca büyük dosyadan kaynaklanmaz. DNS, connection setup, server wait ve transfer süresi birlikte değerlendirilmelidir. CDN veya cache iyileştirmesi bazı durumlarda dosya sıkıştırmadan daha fazla kazanım sağlayabilir. Waterfall üzerinde duration bileşenlerini ayrı ayrı okumak sorunun kaynağını netleştirir.

First-Party / Third-Party

First-party kaynaklar doğrudan sizin kontrolünüzdeki altyapıdan gelir. Third-party kaynaklar ise harici hizmetlerin kontrolündedir. Performans iyileştirmesinde first-party assetleri değiştirmek genellikle daha kolaydır. Third-party tarafta geciktirme, etkileşim sonrası yükleme veya tamamen kaldırma seçenekleri öne çıkar. Envanterde bu ayrım yapılmadığında ekip hangi problemin üzerinde ne kadar kontrol sahibi olduğunu göremeyebilir.

Critical Rendering Path Asset Optimizasyonunu Nasıl Etkiler?

Critical Rendering Path, tarayıcının HTML'i alıp kullanıcıya piksel olarak gösterebilmesi için geçtiği temel aşamaları ifade eder. Kritik yükleme yoluna giren gereksiz kaynaklar ilk görünümü geciktirebilir. CSS ve senkron JavaScript bu süreçte özel öneme sahiptir. Performans iyileştirmesinde yalnızca toplam dosya boyutunu değil kritik yol üzerindeki bağımlılıkları azaltmak gerekir. İlk ekranın ihtiyaç duyduğu kaynakları erken, diğerlerini daha sonra yüklemek temel yaklaşımdır.

HTML Parsing

Tarayıcı HTML belgesini sırayla okuyarak sayfa yapısını anlamaya başlar. Bu süreç sırasında CSS, JavaScript, görsel ve font gibi kaynak referansları keşfedilir. Bazı scriptler parsing işlemini durdurabilir. Kritik kaynakların HTML içinde erken bulunması yükleme başlangıcını hızlandırabilir. Bu nedenle kaynak keşfedilebilirliği performansın önemli parçalarından biridir.

DOM

DOM HTML yapısının tarayıcıdaki nesne temsilidir. Büyük ve gereksiz derin DOM yapıları layout ve JavaScript işlemlerinin maliyetini artırabilir. Asset optimizasyonu doğrudan DOM küçültme çalışması değildir, fakat JavaScript tarafından oluşturulan büyük arayüzler iki alanı birbirine bağlar. İlk render için gerekmeyen bileşenlerin geciktirilmesi faydalı olabilir. Performans incelemesi sırasında markup ve asset davranışı birlikte değerlendirilmelidir.

CSSOM

CSSOM tarayıcının CSS kurallarını işleyerek oluşturduğu yapı olarak düşünülebilir. Tarayıcı görünümü hesaplamak için gerekli stil bilgilerini bu yapı üzerinden değerlendirir. Büyük veya bloklayıcı stylesheetler ilk render sürecini geciktirebilir. Kritik CSS yaklaşımı ilk ekran için gerekli stillerin daha erken kullanılmasını hedefler. Ancak aşırı inline CSS HTML boyutunu büyütebileceği için dengeli uygulanmalıdır.

Render Tree

Render tree görünür öğeler ile ilgili stil bilgilerinin birleşiminden oluşur. Tarayıcı hangi öğelerin çizileceğini bu yapı üzerinden belirler. Kritik CSS veya font gecikmesi render tree oluşumunu etkileyebilir. Kullanıcıya ilk anlamlı görüntünün hızlı sunulması için gerekli kaynakların zamanında hazır olması gerekir. Gereksiz render-blocking kaynakları azaltmak bu nedenle önemlidir.

Layout

Layout aşamasında öğelerin ekrandaki konumu ve boyutu hesaplanır. Sonradan gelen görsel veya font bu hesaplamayı tekrar tetikleyebilir. Çok sık layout değişimi performans ve görsel kararlılık sorunları oluşturabilir. Görsel boyutlarının önceden tanımlanması bu maliyeti azaltır. JavaScript ile art arda DOM ölçümü ve değişikliği yapmak da layout performansını kötüleştirebilir.

Paint

Paint aşamasında hesaplanan görsel öğeler ekrana çizilir. Büyük efektler, karmaşık gölgeler ve sık yeniden çizim bazı sayfalarda maliyet yaratabilir. Asset optimizasyonu paint maliyetini her zaman doğrudan çözmez. Ancak daha az DOM güncellemesi ve daha kontrollü JavaScript davranışı bu yükü azaltabilir. Performance paneli paint darboğazlarını anlamak için kullanılabilir.

Render-Blocking Resources

Render-blocking kaynaklar tarayıcının ilk görünümü oluşturmasını geciktirebilir. CSS burada en yaygın örneklerden biridir. Kritik olmayan büyük stylesheetlerin başlangıçta yüklenmesi ilk ekranı gereksiz bekletebilir. Render blocking CSS JavaScript dosyaları nasıl optimize edilir sorusunda önce hangi kaynağın gerçekten kritik olduğu belirlenmelidir. Her bloklayıcı dosyayı geciktirmek doğru değildir, çünkü ilk ekranın stilleri de zamanında hazır olmalıdır.

Parser-Blocking JavaScript

Senkron çalışan bazı JavaScript dosyaları HTML parsing sürecini durdurabilir. Tarayıcı scripti indirip çalıştırana kadar belgenin kalan kısmını işlemeyebilir. Bu durum özellikle büyük scriptlerde ilk render süresini uzatabilir. Bağımlılık yapısı uygunsa defer kullanımı sık tercih edilen çözümlerden biridir. Ancak kritik inline davranışlar ve sıra bağımlılıkları değerlendirilmeden otomatik dönüşüm yapılmamalıdır.

Critical ve Non-Critical Asset Ayrımı

Her asset aynı anda gerekli değildir. Kullanıcının ilk ekranda gördüğü içerik için gereken kaynaklar kritik, daha sonra ihtiyaç duyulanlar ise non-critical kabul edilebilir. Bu ayrım doğru yapıldığında ağ kapasitesi önemli kaynaklara ayrılır. İlk ekranın hızlı görünmesi kullanıcı deneyimini belirgin biçimde iyileştirebilir. Asset optimizasyonunda en etkili kararların çoğu bu önceliklendirme yaklaşımından çıkar.

İlk Ekran İçin Gereken Asset'ler

İlk ekran için gereken assetler kullanıcının sayfa açıldığında gördüğü alanı oluşturur. Hero görseli, temel CSS ve bazı fontlar bu gruba girebilir. Bu kaynakların geç keşfedilmesi doğrudan algılanan hızı etkiler. Sayfanın altındaki içerikler aynı öncelikle yüklenmemelidir. İlk ekran ihtiyaçlarını sayfa türüne göre tanımlamak gerekir.

LCP Asset'i

LCP asseti ilk görünüm performansında en önemli kaynaklardan biri olabilir. Bu öğe büyük bir görsel, metin alanı veya başka bir içerik olabilir. Görselse yüksek çözünürlüklü ama gereğinden büyük dosyadan kaçınılmalıdır. Asset mümkün olduğunca erken keşfedilmeli ve gereksiz lazy loading uygulanmamalıdır. Waterfall üzerinde LCP isteğinin başlama zamanı mutlaka kontrol edilmelidir.

Kritik CSS

Kritik CSS ilk ekranı oluşturmak için gereken minimum stil kümesidir. Bu kuralların erken kullanılabilir olması ilk görünümü hızlandırabilir. Ancak kritik CSS üretimi otomatik sistemlerde dikkatli test edilmelidir. Responsive breakpoint veya dinamik bileşenlerin stilleri yanlışlıkla dışarıda kalabilir. Bu nedenle farklı cihaz genişliklerinde görsel regresyon testi yapılması faydalıdır.

Kritik Font

Kritik font ilk ekranda marka veya temel metin görünümü için gerçekten gerekli olan yazı tipidir. Tüm font ailelerini preload etmek yerine yalnızca kritik dosya önceliklendirilebilir. Fallback font kullanımı içerik görünürlüğünü korumaya yardımcı olur. font-display ayarı kullanıcıya boş metin göstermemek için önemlidir. Font seçimi görsel tasarım ve performans arasında dengeli yapılmalıdır.

Sonradan Yüklenebilecek Asset'ler

Sayfanın altındaki görseller, bazı videolar ve etkileşimle açılan bileşenler ilk yüklemede gerekli olmayabilir. Bu kaynakları geciktirmek başlangıç ağ yükünü azaltabilir. Lazy loading burada güçlü bir araçtır. Ancak kullanıcı hızlı kaydırdığında içeriğin geç görünmemesi için yükleme eşiği doğru seçilmelidir. Geciktirme stratejisi gerçek kullanım davranışlarıyla test edilmelidir.

Etkileşim Sonrası Gereken Asset'ler

Bazı kaynaklara yalnızca kullanıcı bir butona tıkladığında ihtiyaç duyulur. Modal kütüphanesi, gelişmiş editör veya harita bileşeni buna örnek olabilir. Bu kodu başlangıç paketine eklemek gereksiz JavaScript maliyeti yaratabilir. Dynamic import ile ilgili modül etkileşim anında veya hemen öncesinde yüklenebilir. Böylece ilk payload küçülürken özellik korunmuş olur.

Performance Budget Nedir?

Performance budget, bir sayfanın kabul edilebilir performans sınırlarını sayısal olarak tanımlayan kural setidir. Örneğin ilk JavaScript yükünün belirli bir boyutu aşmaması istenebilir. Aynı şekilde toplam görsel ağırlığı veya üçüncü taraf CPU süresi için sınır belirlenebilir. Bütçe olmadan sayfa zaman içinde küçük eklemelerle ağırlaşabilir. Ekiplerin performansı bir defalık proje yerine sürekli kalite kriteri olarak yönetmesini sağlar.

Asset Budget

Asset budget sayfaya gönderilen kaynakların toplam veya tür bazlı sınırlarını belirler. CSS, JavaScript, görsel ve font için ayrı limitler tanımlanabilir. Bu limitler her projede aynı olmak zorunda değildir. İçerik yoğun bir medya sayfası ile sade landing page farklı bütçelere ihtiyaç duyar. Önemli olan limitlerin ölçülebilir ve iş hedefleriyle uyumlu olmasıdır.

Network Budget

Network budget toplam transfer boyutu ve istek sayısı gibi ağ maliyetlerini sınırlar. Özellikle mobil kullanıcı oranı yüksek projelerde bu bütçe önemlidir. Çok sayıda küçük dosya da bağlantı ve öncelik rekabeti oluşturabilir. HTTP/2 ve HTTP/3 bazı ağ maliyetlerini azaltır fakat sınırsız istek anlamına gelmez. Network bütçesi waterfall davranışıyla birlikte değerlendirilmelidir.

Rendering Budget

Rendering budget tarayıcının layout, paint ve diğer görsel işlemler için harcadığı zamanı kontrol etmeyi hedefler. Assetler küçük olsa bile karmaşık arayüzler yüksek render maliyeti oluşturabilir. Özellikle animasyonlu ve dinamik sayfalarda bu bütçe önem kazanır. Performance paneli bu tür maliyetleri görmek için kullanılabilir. Kullanıcı etkileşimleri sırasında oluşan render yükü de test edilmelidir.

JavaScript Budget

JavaScript budget başlangıçta indirilen ve çalıştırılan JavaScript miktarını sınırlar. Mobil cihazlarda parse ve execution maliyeti nedeniyle bu bütçe özellikle değerlidir. Yeni bir kütüphane eklendiğinde toplam paketin ne kadar büyüdüğü kontrol edilmelidir. CI/CD sürecinde limit aşımı build uyarısı veya hata olarak ele alınabilir. Bu yaklaşım performans gerilemesini üretime çıkmadan yakalamaya yardımcı olur.

CSS Budget

CSS budget stil dosyalarının toplam boyutunu ve kullanılmayan kural oranını kontrol altında tutmayı amaçlar. Büyük global stylesheetler zaman içinde fark edilmeden büyüyebilir. Route veya component düzeyinde CSS bölmek bu sorunu azaltabilir. Ancak aşırı parçalama da yönetim maliyeti doğurabilir. Bütçe, gerçek kullanım oranıyla birlikte değerlendirilmelidir.

Image Budget

Image budget sayfadaki toplam görsel ağırlığı için sınır koyar. Hero görseli ile küçük ikonların aynı kurala tabi olması gerekmez. Responsive çözünürlükler ve format dönüşümü bütçeyi korumayı kolaylaştırır. CMS yükleme sırasında boyut kontrolü yapmak manuel hataları azaltabilir. Yeni görsel limiti aştığında editöre uyarı vermek etkili bir yönetişim yöntemidir.

Font Budget

Font budget kullanılan font aileleri, weight sayısı ve toplam transfer boyutunu sınırlar. Birkaç yüz kilobaytlık font yükü özellikle ilk ziyaret performansını etkileyebilir. Variable font bazı projelerde çok sayıda ayrı weight dosyasına göre avantaj sağlayabilir. Subsetting ile yalnızca kullanılan karakterler tutulabilir. Tasarım sisteminde font kullanım standartlarının baştan tanımlanması en iyi sonucu verir.

Third-Party Budget

Third-party budget harici script ve iframe kaynaklarının oluşturduğu ağ ve CPU maliyetini sınırlar. Yeni bir pazarlama aracı eklendiğinde performans etkisi ölçülmelidir. Üçüncü taraf kodu çoğu zaman kontrol dışı olduğu için limit daha da önemlidir. Kullanılmayan servisler düzenli aralıklarla kaldırılmalıdır. Her yeni third-party entegrasyonu teknik review sürecinden geçmelidir.

Sayfa Türüne Göre Asset Budget Nasıl Belirlenir?

Tek bir performans bütçesini tüm sayfa türlerine uygulamak çoğu projede gerçekçi değildir. Ana sayfa, blog, ürün sayfası ve uygulama ekranlarının işlevsel ihtiyaçları farklıdır. Bu nedenle kullanıcı yolculuğu ve içerik yoğunluğu dikkate alınmalıdır. Bütçeler mümkün olduğunca gerçek cihaz testleriyle doğrulanmalıdır. Amaç teknik olarak düşük sayılar üretmek değil kullanıcı deneyimini koruyan sürdürülebilir sınırlar belirlemektir.

Ana Sayfa

Ana sayfa genellikle marka görselleri, menü, kampanya alanları ve farklı içerik bloklarını birlikte taşır. Bu nedenle asset bütçesi dikkatli hazırlanmalıdır. Hero görseli LCP açısından özel öncelik alabilir. Sayfanın altındaki kampanya görselleri lazy loading ile ertelenebilir. İlk ekran için gereken CSS ve JavaScript mümkün olduğunca sınırlı tutulmalıdır.

Blog

Blog sayfalarında metin okunabilirliği temel önceliktir. Büyük içerik görselleri optimize edilmeli, fakat ilk paragrafın görünmesi gereksiz scriptler tarafından geciktirilmemelidir. Sosyal paylaşım veya embed scriptleri etkileşim sonrası yüklenebilir. Font yükü metin yoğun sayfalarda dikkatle yönetilmelidir. Kullanıcıya içeriği erken göstermek çoğu blog için en doğru performans hedefidir.

Ürün Sayfası

Ürün sayfasında yüksek kaliteli görseller, varyantlar ve etkileşimli alanlar bulunabilir. Bu nedenle görsel bütçesi diğer sayfalardan daha yüksek olabilir. İlk ürün görseli önceliklendirilirken galeri içindeki sonraki görseller geciktirilebilir. İnceleme widgetları veya ek öneri bileşenleri ilk render dışında tutulabilir. Satın alma akışındaki JavaScript ise hızlı etkileşim için dikkatle optimize edilmelidir.

Kategori Sayfası

Kategori sayfalarında çok sayıda ürün görseli bulunması toplam transfer boyutunu hızla artırabilir. Responsive image ve lazy loading burada temel araçlardır. İlk viewport içindeki ürünlerin görselleri daha erken, aşağıdaki ürünler daha sonra yüklenebilir. Filtreleme JavaScript'i büyükse code splitting değerlendirilebilir. Pagination veya kontrollü içerik yükleme yaklaşımı da ağ maliyetini azaltabilir.

Landing Page

Landing page genellikle tek bir dönüşüm hedefi etrafında tasarlanır. Bu nedenle performans bütçesi agresif biçimde sade tutulabilir. İlk ekran görseli, form ve temel CTA dışındaki bileşenler geciktirilebilir. Pazarlama etiketlerinin sayısı kontrol altında tutulmalıdır. Dönüşüm ölçümü ile performans arasında dengeli bir kurgu yapılmalıdır.

SaaS Uygulaması

SaaS uygulamalarında JavaScript ihtiyacı statik sayfalardan daha yüksek olabilir. Bu durumda ilk route için gereken kod ile sonradan kullanılacak modülleri ayırmak önemlidir. Kullanıcı oturum açtıktan sonra ihtiyaç duyulmayan yönetim ekranları başlangıç paketinde yer almamalıdır. Route-level splitting ve lazy module loading güçlü kazanımlar sağlayabilir. Performans bütçesi yalnızca transfer boyutunu değil etkileşim süresini de kapsamalıdır.

Görsel Optimizasyonu Nasıl Yapılır?

Görsel optimizasyonu çoğu web sitesinde en hızlı kazanımlardan birini sağlar. Önce gereksiz görseller kaldırılmalı, ardından kalan dosyalar doğru boyutta ve formatta sunulmalıdır. Görsel sıkıştırma WebP AVIF lazy loading CDN ve cache optimizasyonu birlikte ele alındığında sonuç çok daha güçlü olur. Tek başına format dönüşümü yeterli değildir. Responsive sunum, boyut rezervasyonu ve doğru yükleme önceliği de performansın temel parçalarıdır.

Gereksiz Görselleri Kaldırmak

En iyi optimize edilmiş görsel bile kullanıcıya değer sağlamıyorsa gereksiz byte anlamına gelir. Bu nedenle ilk soru dosyayı nasıl küçülteceğimiz değil, görsele gerçekten ihtiyaç olup olmadığıdır. Özellikle dekoratif arka planlar mobil görünümde kaldırılabilir. Aynı bilgiyi tekrar eden görseller de sadeleştirilebilir. Kaynağı hiç yüklememek her zaman en güçlü optimizasyondur.

Görüntülendiği Boyutta Görsel Sunmak

300 piksel genişliğinde gösterilen bir alana 2500 piksel genişliğinde görsel göndermek gereksiz veri tüketir. Responsive image teknikleri cihazın ihtiyacına uygun dosyayı seçmesini sağlar. CMS tarafında farklı çözünürlüklerin otomatik üretilmesi işi kolaylaştırır. Retina ekranlar için çözünürlük ihtiyacı hesaba katılmalıdır. Yine de gerçek render boyutunun çok üzerinde dosya göndermekten kaçınılmalıdır.

Sıkıştırma

Görsel sıkıştırma dosyadaki gereksiz veriyi azaltarak transfer boyutunu küçültür. Fotoğraf ile logo aynı sıkıştırma ayarını kullanmamalıdır. Görsel kalite kaybı kullanıcı tarafından fark edilmeden önemli boyut kazanımı elde edilebilir. Otomatik pipeline kalite ve boyut sınırlarını standardize eder. Manuel yüklemeye güvenmek büyük ekiplerde zaman içinde tutarsız sonuçlar üretir.

Lossy

Lossy sıkıştırma dosya boyutunu azaltmak için görüntüdeki bazı bilgileri geri dönüşsüz biçimde çıkarır. Fotoğraflarda çoğu zaman güçlü sonuç verir. Kalite seviyesi fazla düşürülürse bloklaşma veya detay kaybı görülebilir. Bu nedenle görseller temsilî ekran boyutlarında kontrol edilmelidir. Amaç en küçük dosya değil kabul edilebilir görsel kalite ile düşük transfer boyutu arasında denge kurmaktır.

Lossless

Lossless sıkıştırma görsel bilgisini kaybetmeden dosya yapısını daha verimli hale getirir. Logo, grafik veya keskin kenarlı bazı görsellerde tercih edilebilir. Boyut kazancı lossy yöntemlere göre daha sınırlı olabilir. PNG optimizasyonunda gereksiz metadata temizliğiyle birlikte kullanılabilir. İçerik türüne göre yöntemi seçmek tek ayarı tüm görsellere uygulamaktan daha doğrudur.

Metadata Temizliği

Görsel dosyalarında kamera bilgisi, konum verisi veya düzenleme yazılımı metadata'sı bulunabilir. Web sunumunda bu bilgilerin çoğuna ihtiyaç duyulmaz. Gereksiz metadata dosya boyutunu artırabilir. Pipeline aşamasında otomatik temizleme uygulanabilir. Kullanıcı açısından gerekli renk profilleri veya erişilebilirlik bilgileri ise bilinçsizce silinmemelidir.

Otomatik Görsel Pipeline'ı

Otomatik görsel pipeline yüklenen dosyaları belirli kalite, format ve boyut kurallarına göre işler. WebP veya AVIF üretimi, responsive çözünürlükler ve CDN yükleme aynı süreçte yapılabilir. Böylece editörün teknik ayrıntılarla uğraşması gerekmez. Büyük içerik ekiplerinde bu yaklaşım performans standardını korur. Yeni görsel eklemek siteyi fark edilmeden ağırlaştırmaz.

WebP ve AVIF Ne Zaman Kullanılmalı?

Görsel formatı seçimi içerik türüne, kalite beklentisine ve tarayıcı desteğine göre yapılmalıdır. Tek bir formatı tüm dosyalarda zorunlu kılmak doğru değildir. Fotoğraflarda WebP veya AVIF güçlü seçenekler olabilir. Basit vektörlerde SVG çoğu zaman daha uygundur. Gerçek dosyalar üzerinde kalite ve boyut karşılaştırması yaparak karar vermek en sağlıklı yöntemdir.

JPEG

JPEG fotoğraf içerikleri için uzun süredir kullanılan yaygın bir formattır. Modern alternatifler bazı fotoğraflarda daha düşük dosya boyutu sağlayabilir. Yine de mevcut pipeline veya uyumluluk gereksinimleri nedeniyle kullanılmaya devam edebilir. Kalite seviyesi optimize edilmeden kaydedilen JPEG dosyaları gereğinden büyük olabilir. Dönüşüm yapılırken görsel kalite mutlaka gözle kontrol edilmelidir.

PNG

PNG şeffaflık ve keskin grafiklerde güçlü bir seçenektir. Fotoğraf gibi karmaşık görsellerde dosya boyutu çok büyüyebilir. Bu nedenle her görseli PNG olarak yüklemek performans açısından yanlış bir alışkanlıktır. Basit logo veya arayüz grafikleri için SVG daha iyi sonuç verebilir. Format kararı dosyanın içeriğine göre verilmelidir.

WebP

WebP hem kayıplı hem kayıpsız sıkıştırma seçenekleri sunar. Fotoğraflarda ve birçok web görselinde iyi boyut avantajı sağlayabilir. Modern tarayıcı desteği geniştir. Otomatik pipeline içinde fallback gereksinimi proje kitlesine göre değerlendirilebilir. WebP dönüşümü tek başına yeterli olmayıp doğru çözünürlük ve lazy loading stratejisiyle birlikte kullanılmalıdır.

AVIF

AVIF bazı görsellerde WebP'den daha düşük dosya boyutuna ulaşabilir. Ancak encode süresi ve görsel türüne göre kalite sonucu değişebilir. Her görselde otomatik olarak en iyi seçenek olmayabilir. Görsel pipeline gerçek içerikler üzerinde karşılaştırma yapmalıdır. Desteklenen tarayıcılara AVIF, uygun fallback olarak WebP veya başka format sunmak mümkündür.

SVG

SVG vektörel grafikler için çözünürlükten bağımsız bir formattır. Logo ve ikonlarda çok küçük dosya boyutları sağlayabilir. Karmaşık SVG dosyalarında gereksiz path ve metadata temizlenmelidir. Harici dosya olarak sunulduğunda cache avantajı elde edilebilir. Inline kullanım ise küçük ve kritik ikonlarda ekstra isteği azaltabilir.

Format Seçim Matrisi

Format seçimi görsel türü, şeffaflık ihtiyacı, animasyon, kalite ve hedef tarayıcı desteğine göre yapılmalıdır. Fotoğraflarda AVIF veya WebP güçlü adaylardır. Logo ve ikonlarda SVG sık tercih edilir. Şeffaf raster görsellerde WebP veya optimize PNG değerlendirilebilir. En iyi karar teorik format sıralamasından değil gerçek dosya üzerinde yapılan kalite ve boyut testinden çıkar.

Responsive Images ile Gereksiz Byte Nasıl Önlenir?

Responsive images farklı ekran ve çözünürlüklerde gereğinden büyük görsel indirilmesini önlemeye yardımcı olur. Mobil cihazın masaüstü için hazırlanmış geniş görseli indirmesine çoğu zaman gerek yoktur. srcset, sizes ve picture elemanı tarayıcıya doğru seçimi yapması için bilgi verir. Bu yaklaşım görsel CDN ile birlikte kullanıldığında otomatikleştirilebilir. Özellikle görsel yoğun sayfalarda toplam transfer boyutunda belirgin düşüş sağlar.

srcset

srcset aynı görselin farklı çözünürlükteki sürümlerini tarayıcıya bildirir. Tarayıcı ekran genişliği ve cihaz özelliklerine göre uygun dosyayı seçebilir. Bu sayede tek bir büyük görseli herkese göndermekten kaçınılır. Kaynakların gerçek boyutlarda üretilmesi gerekir. Yanlış srcset yapılandırması beklenen tasarrufu sağlamayabilir.

sizes

sizes tarayıcıya görselin farklı viewport koşullarında yaklaşık ne kadar alan kaplayacağını bildirir. Bu bilgi srcset içindeki doğru adayın seçilmesine yardım eder. sizes değeri tasarımla uyuşmuyorsa tarayıcı gereğinden büyük dosya indirebilir. Responsive breakpointler değiştiğinde sizes tanımı da güncellenmelidir. Bu nedenle tasarım sistemi ile frontend kuralının senkron tutulması önemlidir.

<picture>

picture elemanı farklı format veya farklı görsel kompozisyonları sunmak için kullanılabilir. AVIF destekleyen tarayıcıya AVIF, diğerine uygun fallback sunmak mümkündür. Art direction durumlarında mobil için farklı kırpılmış görsel de tanımlanabilir. Bu yaklaşım yalnızca format seçimi değil içerik uyarlaması sağlar. Ancak markup gereksiz seçeneklerle aşırı büyütülmemelidir.

Device Pixel Ratio

Device Pixel Ratio fiziksel ekran pikseli ile CSS pikseli arasındaki ilişkiyi ifade eder. Yüksek yoğunluklu ekranlar daha yüksek çözünürlüklü görselden faydalanabilir. Ancak bu durum her zaman sınırsız büyük dosya göndermek anlamına gelmez. Görselin gerçek ekrandaki boyutu ve kalite ihtiyacı birlikte değerlendirilmelidir. Responsive image adayları bu farkı dengeli biçimde karşılamalıdır.

Art Direction

Art direction aynı görselin yalnızca küçültülmesi yerine farklı ekranlarda farklı kadraj kullanılmasını sağlar. Masaüstünde geniş yatay hero, mobilde daha dar portre kompozisyonu tercih edilebilir. Böylece önemli içerik küçük ekranda daha görünür olur. Aynı zamanda mobil dosyanın boyutu azaltılabilir. picture elemanı bu tür senaryolarda kullanışlıdır.

Mobil Kullanıcıya Desktop Görseli Göndermemek

Masaüstü için hazırlanmış 2000 piksel genişliğinde görseli 375 piksel mobil ekrana göndermek gereksiz ağ maliyeti yaratır. Bu hata görsel yoğun sayfalarda toplam sayfa ağırlığını birkaç kat artırabilir. Responsive kaynak üretimi sorunu büyük ölçüde çözer. CDN tabanlı dinamik resize sistemleri de kullanılabilir. Mobil performans testlerinde transfer edilen gerçek görsel boyutları ayrıca kontrol edilmelidir.

LCP Görseli Nasıl Optimize Edilir?

LCP görseli kullanıcıya ilk ekranın tamamlandığını hissettiren en önemli assetlerden biri olabilir. Bu görselin yalnızca küçük olması yeterli değildir. Tarayıcının görseli erken keşfetmesi ve yüksek öncelikle indirmesi gerekir. LCP görseli JavaScript ile geç ekleniyorsa indirme başlangıcı gecikebilir. En iyi yaklaşım kaynağı initial HTML içinde görünür kılmak ve gereksiz lazy loading kullanmamaktır.

LCP Asset'ini Tespit Etmek

Önce hangi öğenin LCP olduğunu doğru belirlemek gerekir. PageSpeed Insights, Lighthouse ve Performance araçları bu konuda yardımcı olabilir. Masaüstü ile mobilde LCP öğesi farklı olabilir. Tasarım değiştikçe LCP asseti de değişebilir. Bu nedenle optimizasyon sonrası yeniden ölçüm yapılmalıdır.

Initial HTML İçinden Keşfedilebilir Olması

Tarayıcı kritik görseli HTML'i okurken doğrudan keşfedebilirse indirme daha erken başlayabilir. Görsel ancak JavaScript çalıştıktan sonra DOM'a ekleniyorsa gereksiz gecikme oluşabilir. Hero görselini mümkün olduğunda temel markup içinde tanımlamak daha iyi sonuç verir. Responsive kaynak bilgileri de HTML içinde bulunabilir. Bu yaklaşım preload kullanımına ihtiyaç duymadan doğal erken keşif sağlayabilir.

CSS Background Image Problemi

CSS background image tarayıcı tarafından stylesheet işlendikten sonra keşfedilebilir. Bu durum LCP görseli için gecikme oluşturabilir. Hero görseli içerik açısından önemliyse img veya picture kullanımı daha uygun olabilir. Tasarım gereği background kullanılması gerekiyorsa preload seçeneği test edilebilir. Ancak preload yalnızca gerçekten kritik kaynak için uygulanmalıdır.

JavaScript ile Geç Eklenen Hero Görseller

Hero görselinin JavaScript renderından sonra eklenmesi indirme başlangıcını belirgin biçimde geciktirebilir. Script önce indirilecek, çalışacak ve ardından görsel URL'si keşfedilecektir. Bu zincir LCP'yi olumsuz etkileyebilir. Server-rendered veya initial HTML içindeki markup daha erken keşif sağlar. Uygulama mimarisi değiştirilmeden önce waterfall ile gecikmenin gerçek boyutu ölçülmelidir.

fetchpriority="high"

fetchpriority="high" kritik bir görselin tarayıcı önceliğini artırmak için kullanılabilir. Özellikle LCP görselinde yararlı olabileceği durumlar vardır. Ancak sayfadaki birçok görsele aynı değer verilirse kaynaklar birbirleriyle yarışır. Yalnızca gerçekten yüksek öncelik gerektiren assetlerde kullanmak gerekir. Kullanımdan sonra waterfall ve LCP değişimi test edilmelidir.

Gerektiğinde preload

Preload tarayıcıya belirli bir kaynağın erken gerekli olacağını bildirebilir. CSS background içindeki kritik görseller veya geç keşfedilen bazı fontlar için yararlı olabilir. Fakat gereksiz preload ağ kapasitesini önemli kaynaklardan çalabilir. Ayrıca preload edilen kaynağın gerçekten kısa sürede kullanılması gerekir. Her kritik görünen dosyayı preload etmek yerine ölçümle karar verilmelidir.

LCP Görselinde Lazy Load Kullanmamak

LCP görseline loading="lazy" eklemek çoğu durumda yanlış bir tercihtir. Tarayıcı bu kaynağın yüklenmesini geciktirebilir. İlk ekranın ana görseli mümkün olduğunca erken indirilmelidir. Lazy loading sayfanın altındaki görseller için daha uygundur. LCP üzerinde yapılan bu tek düzeltme bazı projelerde gözle görülür kazanım sağlayabilir.

Lazy Loading Doğru Nasıl Uygulanır?

Lazy loading kritik olmayan medya kaynaklarının kullanıcıya yaklaşana kadar yüklenmesini geciktirir. Doğru kullanıldığında ilk sayfa ağırlığını ve ağ rekabetini azaltır. Ancak her görseli lazy yüklemek performansı otomatik olarak iyileştirmez. İlk ekran ve LCP kaynakları genellikle erken yüklenmelidir. Kullanıcı hızlı kaydırdığında içeriğin boş kalmaması için tarayıcının doğal davranışı ve gerçek kullanım koşulları test edilmelidir.

loading="lazy"

loading="lazy" modern tarayıcılarda görsel ve iframe yüklemesini ertelemek için pratik bir yöntemdir. Karmaşık bir özel JavaScript çözümüne her zaman ihtiyaç yoktur. Tarayıcı viewport yakınlığını değerlendirerek yüklemeyi yönetebilir. İlk ekrandaki kritik medya için kullanılmamalıdır. Uygulama sonrası Network panelinde hangi isteklerin başlangıçta ertelendiği kontrol edilebilir.

Below-the-Fold Görseller

Below-the-fold görseller kullanıcı ilk açılışta görmediği için lazy loading için iyi adaylardır. Özellikle uzun blog ve kategori sayfalarında büyük veri tasarrufu sağlanabilir. Kullanıcı hiç aşağı kaydırmazsa bu dosyalar indirilmeyebilir. Bu yaklaşım mobil veri kullanımını da azaltır. Yine de sayfaya çok yakın görselleri aşırı geciktirmek kaydırma sırasında boşluk hissi yaratabilir.

iframe'ler

iframe içerikleri harici sayfa ve scriptleri beraberinde getirebilir. Harita veya başka bir embed ilk ekranda gerekli değilse lazy loading uygulanabilir. Böylece üçüncü taraf bağlantıları başlangıçta kurulmaz. İlk yükleme sırasında ağ ve CPU maliyeti azalabilir. Kullanıcı iframe alanına yaklaştığında içerik yüklenmeye başlayabilir.

Video Embed'leri

Video embedleri çoğu zaman tek bir görselden çok daha fazla kaynak yükler. İlk açılışta video oynatılmayacaksa facade yaklaşımı daha verimli olabilir. Kullanıcı önce poster görselini görür. Oynat düğmesine bastığında gerçek video bileşeni yüklenir. Bu yöntem özellikle uzun içerik sayfalarında third-party maliyetini önemli ölçüde azaltabilir.

LCP Görselini Lazy-Load Etme Hatası

LCP görseli görünür alanın parçasıdır ve kullanıcı onu mümkün olduğunca erken görmelidir. Lazy loading bu hedefin tersine çalışabilir. Tarayıcı kaynağı bekletirse LCP süresi uzar. Bu nedenle ilk viewport içindeki büyük hero görseli eager davranışla sunulmalıdır. LCP kaynağının yükleme önceliği ayrıca kontrol edilmelidir.

Fazla Agresif Lazy Loading

Her şeyi mümkün olduğunca geç yüklemek de kullanıcı deneyimini bozabilir. Kullanıcı hızlı kaydırdığında görsellerin boş kalması bunun tipik sonucudur. Etkileşimle açılacak bileşen çok geç yüklenirse tıklama sonrası bekleme oluşabilir. Doğru strateji, kritik olmayanı geciktirirken kullanıcı davranışına yakın zamanda ihtiyaç duyulacak kaynakları hazır tutmaktır. Gerçek kullanım senaryolarıyla test yapmak bu dengeyi kurmaya yardımcı olur.

Görsel Boyutları CLS'yi Nasıl Etkiler?

Görsel alanı önceden ayrılmadığında dosya yüklendikten sonra sayfa düzeni değişebilir. Bu değişim metinleri ve butonları aşağı iterek CLS değerini kötüleştirir. width, height veya aspect-ratio bilgisi tarayıcıya gerekli alanı önceden hesaplama imkânı verir. Placeholder teknikleri de algılanan kararlılığı destekleyebilir. Görsel optimizasyonu bu nedenle yalnızca byte azaltma çalışması değildir.

width ve height

img elemanında width ve height değerlerinin bulunması tarayıcının görsel oranını önceden bilmesini sağlar. Responsive CSS kullanılsa bile oran korunabilir. Böylece görsel yüklenmeden önce sayfada alan ayrılır. İçerik aşağı doğru itilmez. Bu basit uygulama birçok CLS problemini önleyebilir.

aspect-ratio

aspect-ratio CSS özelliği medya alanının oranını açık biçimde tanımlamaya yardımcı olur. Responsive container yapılarında kullanışlıdır. Görsel henüz yüklenmemiş olsa bile tarayıcı uygun yüksekliği hesaplayabilir. Video ve iframe alanlarında da aynı yaklaşım kullanılabilir. Dinamik tasarımlarda yerleşim kararlılığını korur.

Responsive Container

Responsive container farklı ekran genişliklerinde medya alanının kontrollü biçimde ölçeklenmesini sağlar. Sabit piksel yüksekliği yerine oran temelli yaklaşım daha esnek olabilir. Container boyutu önceden bilindiğinde CLS riski azalır. İçerik geldikten sonra beklenmedik sıçrama oluşmaz. Tasarım sistemindeki kart ve medya bileşenlerinde bu kural standardize edilebilir.

Image Placeholder

Image placeholder gerçek görsel yüklenene kadar medya alanını doldurur. Asıl faydası kullanıcının sayfa yapısını daha erken algılamasıdır. Placeholder doğru boyutta olduğunda yerleşim kayması oluşmaz. Ancak placeholder görseli gereksiz büyük olmamalıdır. Basit renk veya hafif bir önizleme çoğu durumda yeterlidir.

Skeleton

Skeleton ekran yüklenmekte olan içeriğin yaklaşık yapısını gösterir. Dinamik kart veya listelerde kullanıcıya görsel bir hazırlık sinyali verir. Fakat skeleton alanının gerçek içerikle aynı boyuta yakın olması gerekir. Aksi durumda içerik geldiğinde yeni layout shift oluşabilir. Yükleme göstergesinin kendisi performans sorununu gizlemek için kullanılmamalıdır.

Blur Placeholder

Blur placeholder küçük ve bulanık bir önizlemeyi gerçek görsel gelene kadar gösterebilir. Kullanıcı sayfayı boş alan yerine içerik hissiyle görür. Önizleme çok küçük tutulmalıdır, aksi halde ek transfer maliyeti oluşur. Gerçek görsel geldiğinde aynı container boyutu korunmalıdır. Böylece hem algılanan hız hem yerleşim kararlılığı desteklenir.

Video Asset'leri Nasıl Optimize Edilir?

Video dosyaları sayfa performansını en hızlı ağırlaştırabilecek kaynaklar arasındadır. Kullanıcı videoyu izlemeyecekse ilk açılışta tamamını indirmek anlamsızdır. Poster görseli, lazy loading ve etkileşim sonrası yükleme yöntemleri güçlü kazanımlar sağlayabilir. Uzun videolarda adaptif streaming bağlantı kalitesine göre uygun kaliteyi sunar. Video stratejisi içerik hedefi ve kullanıcı davranışına göre hazırlanmalıdır.

GIF Yerine Video

Uzun veya yüksek çözünürlüklü GIF dosyaları çok büyük olabilir. Aynı animasyon uygun video formatında çok daha düşük transfer boyutuyla sunulabilir. Otomatik oynatılan kısa sessiz animasyonlarda video seçeneği test edilmelidir. Kullanıcı tercihlerine ve erişilebilirlik ayarlarına saygı gösterilmelidir. Animasyon yalnızca dekoratifse tamamen kaldırmak da düşünülebilir.

Poster Image

Poster image video yüklenmeden önce kullanıcıya önizleme sunar. Bu görsel doğru boyutta ve sıkıştırılmış olmalıdır. Video aşağıdaki içerikteyse poster bile lazy yüklenebilir. İlk ekranda yer alan poster LCP adayı olabileceği için ayrı değerlendirilmelidir. Poster alanına boyut rezervasyonu yapmak CLS riskini azaltır.

Lazy Loading

Video player ve embed bileşenleri viewport dışında ise başlangıçta yüklenmeyebilir. Bu yöntem hem ağ hem JavaScript maliyetini azaltabilir. Kullanıcı videoya yaklaştığında gerekli dosyalar getirilebilir. Büyük video platform embedleri için facade yaklaşımı daha da etkili olabilir. Gerçek kullanıcı davranışında yükleme gecikmesi test edilmelidir.

Autoplay Video Problemi

Autoplay video sayfa açılır açılmaz yüksek veri tüketimine sebep olabilir. Mobil bağlantılarda bu maliyet daha belirgin hissedilir. Video gerçekten içerik için vazgeçilmez değilse kullanıcı etkileşimine kadar bekletmek daha mantıklıdır. Otomatik oynatma görsel dikkat dağınıklığı da oluşturabilir. Performans ve kullanıcı deneyimi birlikte düşünülmelidir.

Adaptive Streaming

Adaptive streaming kullanıcının bağlantı koşullarına uygun video kalitesini seçmeye yardımcı olur. Yavaş bağlantıda daha düşük bitrate sunulabilir. Güçlü bağlantıda daha yüksek kaliteye geçilebilir. Böylece tüm kullanıcılar tek büyük dosyayı indirmek zorunda kalmaz. Uzun form video içeriklerinde bu yöntem özellikle faydalıdır.

Video CDN

Video CDN medya dosyalarını kullanıcıya coğrafi olarak daha yakın noktalardan sunabilir. Origin sunucunun yükü azalabilir. Büyük dosyalarda edge delivery gecikmeyi düşürmeye yardımcı olur. Cache stratejisi medya segmentlerine göre yapılandırılmalıdır. Kullanıcı kitlesi farklı ülkelere dağılıyorsa kazanım daha belirgin olabilir.

Kullanıcı Etkileşimine Kadar Video Yüklememek

Kullanıcı videoyu oynatmadığı sürece player kodunu ve medya akışını yüklememek güçlü bir optimizasyon yöntemidir. İlk aşamada yalnızca hafif bir poster gösterilir. Tıklama sonrasında gerçek video bileşeni oluşturulur. Böylece sayfanın açılış maliyeti içerikle ilgilenmeyen ziyaretçiye yüklenmez. Landing page ve blog embedlerinde bu yöntem oldukça etkilidir.

CSS Asset Optimizasyonu

CSS asset optimizasyonu yalnızca minification uygulamakla sınırlı değildir. Kullanılmayan kuralların azaltılması, kritik stillerin erken sunulması ve route bazlı ayrım daha büyük kazanımlar sağlayabilir. Brotli gibi HTTP compression yöntemleri transfer boyutunu küçültür. Ancak tarayıcı yine de açılmış stylesheeti işlemek zorundadır. Bu nedenle kaynak boyutu ve kullanım oranı birlikte değerlendirilmelidir.

Unused CSS

Unused CSS sayfaya gönderildiği halde mevcut görünüm veya etkileşimlerde kullanılmayan stil kurallarını ifade eder. Tema ve UI kütüphaneleri bu sorunun yaygın kaynağıdır. Coverage aracı yüksek kullanılmayan oranları tespit etmeye yardımcı olabilir. Ancak dinamik class ve sonradan açılan bileşenler unutulmamalıdır. Silme işlemi görsel regresyon testleriyle desteklenmelidir.

Minification

Minification gereksiz boşluk, yorum ve biçimlendirmeyi kaldırarak CSS dosyasını küçültür. Build aşamasında otomatik uygulanabilir. Kazanç tek başına devasa olmayabilir fakat uygulanması düşük maliyetlidir. Source map dosyaları üretim ortamında doğru şekilde yönetilmelidir. Minification kullanılmayan CSS sorununu çözmez.

Brotli Compression

Brotli metin tabanlı assetlerde transfer boyutunu azaltmak için güçlü bir HTTP sıkıştırma yöntemidir. CSS dosyaları bu yöntemden iyi faydalanabilir. Sunucu veya CDN doğru Content-Encoding başlığını göndermelidir. Sıkıştırma seviyesi çok yüksek seçildiğinde dinamik üretim maliyeti artabilir. Statik assetler önceden sıkıştırılarak sunulabilir.

Critical CSS

Critical CSS ilk viewport için gereken stil kurallarının erkenden kullanılabilir hale getirilmesidir. Küçük bir kritik stil kümesi HTML içinde inline edilebilir. Geri kalan stylesheet daha sonra yüklenebilir. Ancak çok büyük inline CSS HTML'i şişirir ve cache avantajını azaltabilir. Uygulama sayfa şablonlarına göre dikkatli tasarlanmalıdır.

Non-Critical CSS

Non-critical CSS ilk ekranda ihtiyaç duyulmayan stil kurallarını içerir. Sayfanın alt bölümleri veya sonradan açılan bileşenler buna örnektir. Bu stiller uygun yöntemlerle daha sonra yüklenebilir. Ama kullanıcı ihtiyaç duyduğunda stilin geç gelmesi de kötü deneyim yaratır. Geciktirme stratejisi tahmin yerine kullanım davranışıyla test edilmelidir.

Route-Level CSS

Route-level CSS her sayfa veya route için yalnızca gerekli stil dosyalarını yüklemeyi hedefler. Uygulamanın tüm stilini tek dosyada göndermekten daha verimli olabilir. Özellikle büyük SaaS projelerinde önemli kazanım sağlar. Ancak ortak stiller tekrar eden bundle parçaları oluşturmamalıdır. Build aracının chunk stratejisi analiz edilmelidir.

Component-Level CSS

Component-level CSS stilleri ilgili bileşene yakın tutarak kullanım alanını sınırlar. Bir bileşen yüklenmediğinde ona ait CSS de yüklenmeyebilir. Bu yaklaşım kullanılmayan stil oranını azaltabilir. Çok küçük parçaların aşırı ayrılaştırılması ise request veya build yönetim maliyeti yaratabilir. Mimari karar gerçek proje boyutuna göre verilmelidir.

Render-Blocking CSS Nasıl Azaltılır?

Render-blocking CSS ilk ekranın görünmesini geciktirebileceği için performans çalışmalarında sık incelenir. Ama CSS'in doğası gereği sayfanın doğru görünmesi için bazı stillerin erken gelmesi gerekir. Bu nedenle amaç tüm stylesheetleri geciktirmek değildir. Kritik stilleri erken, kritik olmayanları uygun zamanda sunmak gerekir. Yanlış uygulama hızlı ama stilleri geç oturan bir sayfaya yol açabilir.

Critical CSS'i Inline Etmek

İlk ekranın küçük bir kritik CSS kümesi HTML içine eklenebilir. Böylece tarayıcı ayrı stylesheet isteğini beklemeden temel görünümü oluşturabilir. Bu yöntem özellikle başlangıç ağ gecikmesinin yüksek olduğu senaryolarda yardımcı olabilir. Fakat inline edilen içerik her sayfada tekrar taşınır. Dosya boyutu ve cache kaybı nedeniyle yalnızca gerçekten kritik kurallar eklenmelidir.

Kritik Olmayan Stilleri Ertelemek

Sayfanın aşağı bölümlerine ait stiller ilk render sonrasına bırakılabilir. Böylece kritik kaynaklarla ağ rekabeti azalır. Ancak stillerin gerektiği anda hazır olması gerekir. Kullanıcı hızlı kaydırdığında içerik kısa süreli biçimsiz görünmemelidir. Erteleme yaklaşımı gerçek cihazlarda test edilmelidir.

CSS Request Chain

Bir CSS dosyası başka CSS'i @import ile çağırıyorsa istek zinciri uzayabilir. Tarayıcı ikinci kaynağı ilk dosya geldikten sonra keşfeder. Bu durum özellikle kritik stylesheetlerde gecikme oluşturur. Bağımlılık zincirlerini waterfall üzerinde görmek kolaydır. Kritik CSS referanslarını mümkün olduğunca doğrudan HTML içinde tanımlamak daha iyi olabilir.

@import Kullanımının Etkisi

@import ek stylesheetlerin keşfini geciktirebilir. Tarayıcı önce ana CSS dosyasını indirip parse eder. Sonra import edilen kaynağı keşfeder. Kritik stillerde bu zincir gereksiz bekleme yaratabilir. Build aşamasında importların birleştirilmesi veya doğrudan link kullanımı değerlendirilebilir.

Büyük Global Stylesheet Problemi

Büyük global stylesheet tüm sayfalara kullanılmayan kurallar gönderebilir. Bir admin paneli stilinin pazarlama sayfasında indirilmesi bunun tipik örneğidir. Route ve component bazlı ayrım bu yükü azaltabilir. Coverage raporu hangi sayfalarda fazla CSS gönderildiğini gösterebilir. Tasarım sistemi büyüdükçe CSS bütçesi düzenli izlenmelidir.

Kullanılmayan CSS Nasıl Tespit Edilir?

Kullanılmayan CSS tespiti yalnızca dosyayı açıp manuel gözden geçirmekle yapılmamalıdır. Tarayıcı Coverage verisi başlangıç için güçlü bir sinyal sunar. Ardından komponent, tema ve üçüncü taraf kaynaklar ayrı ayrı incelenebilir. Dinamik class sistemleri yanlış pozitif üretebilir. Bu nedenle otomatik purge süreçleri güvenli liste ve görsel testlerle desteklenmelidir.

Chrome Coverage

Chrome Coverage yüklenen CSS satırlarının ne kadarının mevcut test sırasında kullanıldığını gösterir. Yüksek kırmızı alanlar optimizasyon fırsatı olarak değerlendirilebilir. Ancak kullanıcı henüz menüyü açmadıysa menü stilleri kullanılmamış görünebilir. Farklı etkileşim senaryoları tekrar test edilmelidir. Coverage sonucu doğrudan silme kararı olarak kullanılmamalıdır.

Component Audit

Component audit uygulamadaki bileşenlerin hangi stilleri gerçekten kullandığını inceler. Kullanımdan kaldırılmış componentlerin CSS'i build içinde kalmış olabilir. Tasarım sistemi zaman içinde eski sınıfları biriktirebilir. Düzenli audit bu birikimi azaltır. Kod sahipliği tanımlanırsa kullanılmayan stil temizliği daha sürdürülebilir olur.

CMS / Theme CSS

Hazır tema veya CMS yapıları çok sayıda özelliğin stilini tüm sayfalara gönderebilir. Kullanılmayan modüller kapatılsa bile CSS yüklenmeye devam edebilir. Sayfa bazlı dequeue veya özel build yaklaşımı değerlendirilebilir. Değişikliklerden sonra tema güncellemeleriyle uyumluluk test edilmelidir. Görsel regresyon kontrolü bu alanda özellikle önemlidir.

Third-Party CSS

Harici widgetlar kendi büyük stylesheetlerini yükleyebilir. Sayfada küçük bir bileşen için yüzlerce stil kuralı gelebilir. Kaynağı değiştiremiyorsanız bile widgetı etkileşim sonrası yüklemek mümkün olabilir. Bazı durumlarda bileşeni daha hafif yerel bir arayüzle göstermek tercih edilebilir. Üçüncü taraf stiller de performans bütçesine dahil edilmelidir.

Purge Süreçleri

Purge araçları kullanılmayan class ve stil kurallarını build sırasında kaldırabilir. Statik template yapılarında çok etkili olabilir. Dinamik class üretimi varsa yanlışlıkla gerekli kurallar silinebilir. Safelist veya belirli pattern tanımları bu riski azaltır. Üretime çıkmadan önce tüm önemli ekranlar görsel olarak test edilmelidir.

Dynamic Class Riskleri

JavaScript ile dinamik oluşturulan class adları statik analiz araçları tarafından görülemeyebilir. Bu durumda purge işlemi gerekli stilleri kaldırabilir. Özellikle template string ile üretilen sınıflar dikkatle ele alınmalıdır. Açık class eşleme yapısı build araçları için daha güvenlidir. Otomatik temizlik hız kazandırırken işlev bozmamalıdır.

JavaScript Asset Optimizasyonu

JavaScript asset optimizasyonu indirme boyutundan daha geniş bir konudur. Tarayıcı kodu indirdikten sonra parse eder, derler ve çalıştırır. Bu süreç düşük güçlü cihazlarda yüksek CPU maliyeti oluşturabilir. Büyük bundle küçültülse bile çalışma süresi uzun kalabilir. Bu nedenle JavaScript performansı network ve main thread perspektifinden birlikte analiz edilmelidir.

JavaScript Download Cost

Download cost JavaScript dosyasının ağ üzerinden aktarılma maliyetidir. Sıkıştırma bu değeri düşürebilir. Ancak kullanıcı ilk ziyarette dosyayı yine de indirmek zorundadır. Code splitting başlangıçta gerekli olmayan modülleri ayırabilir. CDN ve cache tekrar ziyaretlerde ek avantaj sağlar.

Parse Cost

Tarayıcı indirilen JavaScript kodunu anlamak için parse eder. Büyük dosyalar daha fazla parse zamanı oluşturabilir. Bu maliyet güçlü masaüstünde düşük görünürken orta seviye mobil cihazda artabilir. Kullanılmayan kodun bundle içinde kalması bu nedenle yalnızca byte sorunu değildir. Daha az kod göndermek doğrudan CPU maliyetini de azaltır.

Compile Cost

JavaScript motoru kodu çalıştırılabilir hale getirmek için derleme aşamalarından geçirir. Büyük ve karmaşık kod tabanı bu maliyeti artırabilir. Modern motorlar birçok optimizasyon yapsa da gereksiz kod hâlâ kaynak tüketir. Dependency audit bu yükü azaltmanın iyi başlangıçlarından biridir. Paket boyutu ile çalışma davranışı birlikte incelenmelidir.

Execution Cost

Execution cost JavaScript fonksiyonlarının gerçekten çalıştırılması sırasında oluşur. Bir dosya küçük olsa bile yoğun hesaplama yapıyorsa uzun görevler oluşturabilir. Başlangıçta tüm veriyi işlemek yerine ihtiyaç oldukça hesaplama yapılabilir. Event handler içinde ağır işlerden kaçınılmalıdır. Performance paneli execution darboğazlarını bulmak için kullanılabilir.

Main Thread Maliyeti

Ana iş parçacığı kullanıcı etkileşimleri, JavaScript ve birçok render görevini yürütür. Uzun JavaScript görevleri bu iş parçacığını bloke ettiğinde tıklamalar geç cevap verebilir. Bu durum INP üzerinde olumsuz etki oluşturabilir. Ağ optimizasyonu tamamlanmış olsa bile kullanıcı arayüzü ağır hissedebilir. Task splitting ve Web Worker gibi yöntemler uygun işlerde yardımcı olabilir.

Mobil Cihazlarda JavaScript Maliyeti

Mobil cihazların işlem gücü masaüstüne göre daha sınırlı olabilir. Aynı JavaScript bundle mobilde birkaç kat daha uzun sürede işlenebilir. Termal sınırlama ve düşük güç modu gibi koşullar da deneyimi etkiler. Bu yüzden performans testi yalnızca güçlü geliştirme bilgisayarında yapılmamalıdır. Orta seviye gerçek cihazlar önemli test hedefleridir.

Kullanılmayan JavaScript Nasıl Azaltılır?

Kullanılmayan JavaScript kullanıcıya gönderilip mevcut sayfa veya akışta çalışmayan kod yüküdür. Büyük kütüphaneler, eski polyfilller ve aynı bağımlılığın birden fazla sürümü bu sorunu büyütebilir. İlk adım dependency audit yaparak hangi paketlerin neden bulunduğunu anlamaktır. Ardından tree shaking ve code splitting gibi build teknikleri uygulanabilir. Hedef yalnızca bundle raporunu küçültmek değil gerçek kullanıcıya gönderilen kodu azaltmaktır.

Dependency Audit

Dependency audit projedeki paketlerin gerçekten gerekli olup olmadığını inceler. Uzun süredir kullanılmayan kütüphaneler package dosyasında kalmış olabilir. Aynı işi yapan birden fazla paket de bulunabilir. Her bağımlılığın boyutu ve kullanım alanı değerlendirilmelidir. Gereksiz bağımlılığı tamamen kaldırmak en etkili küçültme yöntemidir.

Dead Code Elimination

Dead code elimination çalışma sırasında erişilemeyecek kodun build çıktısından kaldırılmasını hedefler. Modern bundler araçları belirli koşullarda bunu otomatik yapabilir. Ancak modül yapısı ve side effect tanımları sonucu etkiler. CommonJS veya dinamik kullanım bazı optimizasyonları zorlaştırabilir. Build raporu ile gerçekten çıkarılan kod kontrol edilmelidir.

Tree Shaking

Tree shaking modül içindeki kullanılmayan exportları bundle dışında bırakmaya yardımcı olur. ESM tabanlı yapılar bu konuda daha elverişlidir. Tüm kütüphaneyi tek import ile almak yerine gerekli parçalar seçilebilir. Yine de her paket tree shaking için aynı derecede uygun değildir. Bundle analiz aracı sonuçları doğrulamak için kullanılmalıdır.

Gereksiz Polyfill'ler

Polyfilller eski tarayıcılara modern özellik desteği sağlamak için kullanılır. Hedef kullanıcı kitlesi değiştiği halde eski polyfill seti projede kalabilir. Bu durum gereksiz JavaScript yükü oluşturur. Browserslist benzeri hedefleme yapılandırmaları güncel kullanıcı gereksinimleriyle uyumlu tutulmalıdır. Destek politikasını değiştirmeden önce analiz verileri kontrol edilmelidir.

Duplicate Dependencies

Aynı kütüphanenin farklı sürümleri bundle içinde tekrar bulunabilir. Bu durum monorepo veya büyük dependency ağlarında sık görülür. Bundle analyzer kopyaları tespit etmeye yardımcı olur. Paket sürümlerini hizalamak veya dependency resolution kurallarını düzenlemek çözüm sağlayabilir. Değişiklik sonrası uyumluluk testleri yapılmalıdır.

Büyük Framework Bağımlılıkları

Büyük framework veya UI kütüphaneleri tek başına sorun değildir. Problem ihtiyaç duyulmayan modüllerin başlangıç payloadına eklenmesidir. Route ve component bazlı splitting bu yükü azaltabilir. Küçük bir etkileşim için tüm uygulama runtime'ını göndermek gereksiz olabilir. Mimari seçim kullanım senaryosuna göre değerlendirilmelidir.

Code Splitting Nedir?

Code splitting JavaScript uygulamasını tek büyük paket yerine ihtiyaç anına göre yüklenen parçalara ayırır. Kullanıcı ilk ekranda yalnızca o route için gerekli kodu indirebilir. Sonraki özellikler etkileşim veya navigasyon sırasında yüklenebilir. Bu yöntem ilk JavaScript payloadını azaltır. Ancak aşırı küçük chunk üretmek ağ ve cache yönetimini zorlaştırabileceği için denge gerekir.

Route-Level Splitting

Route-level splitting her sayfa veya uygulama rotasının kodunu ayrı yüklemeyi sağlar. Kullanıcı ana sayfadayken yönetim ekranı JavaScript'ini indirmek zorunda kalmaz. SPA yapılarında önemli kazanım sağlayabilir. Ortak bağımlılıkların duplicate chunk oluşturmaması gerekir. Router ve bundler yapılandırması birlikte değerlendirilmelidir.

Component-Level Splitting

Component-level splitting yalnızca gerektiğinde açılan büyük bileşenleri ayrı paketler. Grafik editörü, harita veya gelişmiş modal buna örnek olabilir. Kullanıcı bileşeni kullanmazsa kod indirilmez. Etkileşim sonrası yükleme gecikmesini azaltmak için yakın zamanda ihtiyaç duyulacak chunk önceden getirilebilir. Bu karar kullanıcı davranışına göre verilmelidir.

Dynamic Import

Dynamic import bir JavaScript modülünün çalışma zamanında ihtiyaç olduğunda yüklenmesini sağlar. Modern bundler bu çağrıyı ayrı chunk oluşturmak için kullanabilir. İlk paket küçülür. Ancak hata yönetimi ve loading state tasarlanmalıdır. Ağ yavaş olduğunda kullanıcı etkileşimi gecikmemelidir.

Lazy Module Loading

Lazy module loading özelliğin kodunu hemen değil ihtiyaç anına yakın yükler. Büyük uygulamalarda başlangıç CPU ve transfer maliyetini düşürebilir. Modül kullanıcının kesin olarak ihtiyaç duyacağı bir adımda ise ön yükleme stratejisi düşünülebilir. Çok geç yükleme etkileşim gecikmesi yaratabilir. Bu nedenle ölçüm temelli denge önemlidir.

İlk JavaScript Payload'ını Azaltmak

İlk payload kullanıcının sayfayı açabilmek için beklediği JavaScript yüküdür. Bu paketi azaltmak mobil performansta büyük fark yaratabilir. Kullanılmayan modüller kaldırılmalı ve sonraki route kodları ayrılmalıdır. Third-party scriptler de aynı bütçeye dahil edilmelidir. Başlangıç payloadı transfer boyutu kadar parse ve execution süresiyle izlenmelidir.

Async ve Defer Nasıl Kullanılır?

Script yükleme davranışı HTML parsing sürecini doğrudan etkileyebilir. async ve defer nitelikleri uygun scriptlerde bloklamayı azaltmak için kullanılır. Fakat iki seçenek aynı davranışı göstermez. Bağımlılık sırası önemli olan kodlarda yanlış seçim hata oluşturabilir. Script türü ve çalışma zamanı gereksinimi belirlenmeden tüm dosyalara tek ayar uygulanmamalıdır.

Normal Script

Normal script etiketi uygun konumda kullanıldığında HTML parsing sürecini durdurabilir. Tarayıcı scripti indirir ve çalıştırır. Ardından belgeyi işlemeye devam eder. Büyük dosyalarda bu davranış render gecikmesi oluşturabilir. Kritik olmayan scriptler için async veya defer seçenekleri değerlendirilebilir.

async

async script dosyasının HTML parsing ile paralel indirilmesini sağlar. Dosya hazır olduğunda çalıştırılabilir ve execution sırası belge sırasına bağlı olmayabilir. Bu nedenle bağımsız scriptlerde daha uygundur. Analytics benzeri sıra bağımsız kodlar bazı durumlarda async yüklenebilir. Birbirine bağlı dosyalarda dikkatli kullanılmalıdır.

defer

defer scriptin belge parsing sürerken paralel indirilmesini ve parsing tamamlandıktan sonra çalışmasını sağlar. Defer scriptler belge sırasını koruma açısından daha tahmin edilebilir davranabilir. Uygulama JavaScript'inde sık kullanılan bir seçenektir. Yine de scriptin DOM ve diğer bağımlılık gereksinimleri kontrol edilmelidir. Test sonrası waterfall ve execution zamanlaması incelenmelidir.

Dependency Sırası

Bazı scriptler başka bir kütüphanenin önce çalışmasına ihtiyaç duyar. async bu sırayı bozabilir. defer ise belge sırasını korumaya yardımcı olabilir. Modern module yapılarında dependency ilişkileri bundler tarafından yönetilebilir. Eski script yapılarında yükleme niteliği değiştirilmeden önce bağımlılık haritası çıkarılmalıdır.

Analytics Scriptleri

Analytics scriptleri çoğu sayfada ilk görsel render için kritik değildir. Bu nedenle async, consent sonrası veya geciktirilmiş yükleme yaklaşımları değerlendirilebilir. Ancak ölçüm doğruluğu ile performans arasında denge gerekir. Çok sayıda ayrı analytics servisi kullanmak CPU ve network maliyetini artırır. Kullanılmayan etiketler düzenli olarak temizlenmelidir.

Kritik Uygulama Scriptleri

Bazı uygulama scriptleri sayfanın temel etkileşimini oluşturduğu için tamamen geciktirilemez. Yine de kod küçültülebilir ve kritik olmayan modüller ayrılabilir. İlk kullanıcı aksiyonu için gerekli işlev öncelikli tutulmalıdır. Büyük framework başlangıç işleri mümkün olduğunca sadeleştirilmelidir. Etkileşim performansı gerçek cihazlarda ölçülmelidir.

INP İçin JavaScript Nasıl Optimize Edilir?

INP optimizasyonunda ana hedef kullanıcı etkileşiminden sonraki işi mümkün olduğunca kısa tutmaktır. Büyük event handler, uzun JavaScript görevi ve yoğun DOM güncellemesi gecikme oluşturabilir. Kullanıcı bir butona bastığında yüzlerce milisaniyelik hesaplama yapılması kötü deneyim yaratır. İşleri küçük görevlere bölmek ve kritik olmayan kısmı sonraya bırakmak yardımcı olur. Third-party JavaScript de aynı ana iş parçacığını kullandığı için hesaba katılmalıdır.

Long Tasks

Long task ana iş parçacığını uzun süre meşgul eden görevdir. Bu sırada kullanıcı etkileşimi beklemek zorunda kalabilir. Performance paneli uzun görevleri görmeye yardımcı olur. Büyük işlemler daha küçük parçalara ayrılabilir. İşin tamamı gerçekten ana thread üzerinde yapılmak zorunda mı sorusu da ayrıca sorulmalıdır.

Main Thread Blocking

Ana thread bloklandığında tarayıcı tıklama, input ve render görevlerini zamanında işleyemez. Yoğun JavaScript bunun yaygın nedenidir. Third-party scriptler de aynı problemi oluşturabilir. İlk açılışta gereksiz kod çalıştırmamak önemlidir. Etkileşim anında çalışan fonksiyonların süreleri ayrıca profillenmelidir.

Büyük Event Handler'lar

Event handler içinde büyük veri işleme veya çok sayıda DOM güncellemesi yapmak gecikmeye yol açabilir. Handler mümkün olduğunca hızlı geri dönmelidir. Ağ isteği veya ağır hesaplama kullanıcıya ilk görsel cevaptan sonra başlatılabilir. Debounce ve throttle belirli olaylarda yardımcı olabilir. Ancak bunlar her performans probleminin otomatik çözümü değildir.

Task Splitting

Task splitting uzun bir işi daha küçük parçalara bölerek tarayıcıya arada kullanıcı görevlerini işleme fırsatı verir. Bu yaklaşım ana thread bloklanmasını azaltabilir. İş parçaları arasında uygun scheduling yöntemi seçilmelidir. Gereksiz parçalama kod karmaşasını artırabilir. Önce profiling yaparak gerçekten uzun görevleri hedeflemek gerekir.

Web Workers

Web Workers bazı yoğun hesaplamaları ana iş parçacığından ayrı yürütmeye yardımcı olabilir. Görsel işleme veya büyük veri hesaplamaları buna örnek olabilir. DOM'a doğrudan erişemedikleri için her iş Worker'a taşınamaz. Mesajlaşma ve veri kopyalama maliyeti de vardır. Uygun görevlerde INP ve genel arayüz akıcılığı açısından fayda sağlayabilir.

Event Delegation

Event delegation çok sayıda benzer öğeye ayrı listener eklemek yerine üst kapsayıcıdan olayları yönetebilir. Büyük listelerde listener sayısını azaltabilir. DOM değiştiğinde yeni öğeler için ek bağlama gereksinimini de azaltır. Ancak handler içindeki hedef kontrolü verimli yapılmalıdır. Gereksiz global delegation kodu da performans avantajını azaltabilir.

Third-Party JavaScript

Third-party JavaScript ana thread üzerinde sizin kodunuzla aynı kaynakları tüketir. Büyük analiz veya reklam scriptleri etkileşim gecikmesi oluşturabilir. Bu kaynakları tamamen optimize edemediğiniz için kullanım zamanı önemlidir. Consent veya interaction sonrası yükleme değerlendirilebilir. Kullanılmayan servisleri kaldırmak çoğu zaman en etkili çözümdür.

Font Asset Optimizasyonu

Font optimizasyonu sayfa hızında sık gözden kaçan alanlardan biridir. Çok sayıda aile ve weight hem ağ yükünü hem render davranışını etkiler. WOFF2, subsetting ve doğru font-display kullanımı güçlü iyileştirmeler sağlayabilir. Fallback font metrikleri de CLS açısından önemlidir. Tasarım ekibiyle birlikte font ihtiyaçlarını sadeleştirmek teknik optimizasyondan önce gelen en güçlü adımdır.

Kaç Font Ailesi Kullanılmalı?

Her proje için tek doğru font ailesi sayısı yoktur. Ancak her ek aile yeni dosyalar ve stil kombinasyonları oluşturabilir. Çoğu kurumsal sitede bir veya iki aile yeterli olabilir. Başlık ve gövde için gereksiz üçüncü veya dördüncü font eklemek yükü artırır. Marka tasarımı ile performans hedefi birlikte değerlendirilmelidir.

Gereksiz Font Weight'leri

100'den 900'e kadar tüm weight dosyalarını yüklemek çoğu sitede gereksizdir. Gerçekte kullanılan 400, 600 ve 700 gibi birkaç ağırlık yeterli olabilir. Kullanılmayan weightleri kaldırmak doğrudan transfer boyutunu azaltır. CSS içindeki font-family ve font-weight kullanımları audit edilmelidir. Variable font kullanılıyorsa dosya boyutu yine ölçülmelidir.

WOFF2

WOFF2 modern web fontları için verimli bir sıkıştırılmış formattır. Genellikle eski WOFF veya TTF dosyalarından daha düşük transfer boyutu sağlar. Hedef tarayıcı kitlesine göre temel format olarak kullanılabilir. Gereksiz fallback font formatları modern projelerde kaldırılabilir. Ancak uyumluluk gereksinimi gerçek kullanıcı verisine göre değerlendirilmelidir.

Variable Fonts

Variable font tek dosya içinde birden fazla ağırlık veya stil eksenini barındırabilir. Çok sayıda ayrı font dosyasına alternatif olabilir. Fakat her variable font otomatik olarak daha küçük değildir. Yalnızca iki weight kullanılıyorsa ayrı dosyalar daha verimli olabilir. Gerçek boyut ve kullanılan eksenlere göre karşılaştırma yapılmalıdır.

Font Subsetting

Font subsetting kullanılmayan karakterleri dosyadan çıkararak boyutu azaltır. Türkçe karakterlerin tamamı korunmalıdır. Yalnızca İngilizce karakter setine göre yanlış subset hazırlanırsa metinlerde eksik glif oluşabilir. Çok dilli sitelerde dil bazlı alt kümeler kullanılabilir. Otomatik pipeline karakter ihtiyaçlarını proje içeriğine göre yönetmelidir.

Unicode Range

unicode-range tarayıcıya belirli font dosyasının hangi karakter aralıklarını kapsadığını bildirir. Farklı alfabeler için ayrı subset dosyaları sunulabilir. Kullanıcı yalnızca gerekli karakter setini indirebilir. Çok dilli sitelerde önemli tasarruf sağlayabilir. Yapılandırma yapılırken Türkçe karakterler ve özel semboller unutulmamalıdır.

Font Loading Stratejisi

Font dosyalarının ne zaman ve nasıl yüklendiği metin görünürlüğünü etkiler. Kullanıcı metni font beklediği için boş görmemelidir. font-display, preload ve fallback ayarları birlikte ele alınmalıdır. Her font dosyasını preload etmek ağ önceliğini bozabilir. Kritik metin için gerekli fontlar belirlenip sınırlı sayıda öne alınmalıdır.

font-display

font-display web fontu yüklenirken tarayıcının metni nasıl göstereceğini kontrol eder. Doğru seçenek içerik görünürlüğünü iyileştirebilir. swap ve optional yaygın kullanılan seçeneklerdir. Her projede aynı ayar ideal olmayabilir. Marka fontuna bağlı görsel gereksinim ile hız arasında denge kurulmalıdır.

swap

swap metni fallback font ile hızlıca gösterip web fontu geldiğinde değiştirebilir. Bu yaklaşım boş metin süresini azaltır. Fallback metrikleri farklıysa font değişiminde layout shift oluşabilir. size-adjust gibi araçlar bu farkı azaltmaya yardımcı olabilir. Görsel geçiş gerçek cihazlarda kontrol edilmelidir.

optional

optional tarayıcıya web fontunu yüklememe konusunda daha fazla esneklik tanıyabilir. Yavaş bağlantılarda fallback font ile devam edilebilir. Bu davranış performansı destekleyebilir. Ancak marka fontunun kesin görünmesi gereken projelerde uygun olmayabilir. Kullanıcı deneyimi ve tasarım gereksinimi birlikte değerlendirilmelidir.

Font Preload

Font preload kritik font dosyasının daha erken indirilmesini sağlayabilir. İlk ekranda gerçekten kullanılan sınırlı fontlarda yararlı olabilir. Çok sayıda weight preload etmek ağ rekabetini artırır. crossorigin ve doğru type tanımları yapılandırmaya göre gerekebilir. Preload edilen fontun gerçekten kısa sürede kullanıldığı doğrulanmalıdır.

Self-Hosted Fonts

Self-hosted fonts font dosyalarının kendi domain veya CDN altyapınızdan sunulmasını sağlar. Cache ve header kontrolü daha kolay olabilir. Ek üçüncü taraf bağlantı kurulumu azalabilir. Ancak font lisans koşulları ve güncelleme sorumluluğu dikkate alınmalıdır. Sadece self-hosting yapmak dosyayı otomatik olarak hızlı hale getirmez.

Third-Party Font Provider

Third-party font sağlayıcı kullanıldığında yeni origin bağlantısı gerekebilir. Bu durum bağlantı gecikmesi oluşturabilir. Preconnect belirli senaryolarda yardımcı olabilir. Fakat harici font hizmetini kullanmanın bakım ve cache avantajları da olabilir. Karar gerçek performans ölçümü ve proje ihtiyacına göre verilmelidir.

Kritik Fontların Önceliklendirilmesi

İlk ekranda kullanılan font dosyası diğer fontlardan daha önemli olabilir. Bu dosya için preload düşünülebilir. Sayfanın alt kısmında kullanılan dekoratif fontun başlangıçta yüklenmesi gerekmez. Font weight ve karakter subsetleri ayrı ayrı değerlendirilmelidir. Önceliklendirme yapılırken metin görünürlüğü her zaman korunmalıdır.

Fontlar CLS'ye Nasıl Sebep Olur?

Web fontu ile fallback fontun karakter genişlikleri farklıysa font değiştiğinde metin yeniden akabilir. Bu durum satırların ve çevredeki öğelerin yer değiştirmesine yol açar. CLS özellikle büyük başlıklarda daha görünür olabilir. Font metriklerini hizalamak ve uygun fallback seçmek kaymayı azaltır. Performans testi sırasında yalnızca yükleme süresine değil font swap sonrası yerleşime de bakılmalıdır.

FOIT

FOIT font yüklenirken metnin bir süre görünmez kalması durumudur. Kullanıcı içeriği okuyamaz. Uzun font yükleme süresinde deneyim belirgin biçimde kötüleşir. font-display ayarları bu davranışı yönetmeye yardımcı olur. İçerik görünürlüğü çoğu durumda özel fontu beklemekten daha önemlidir.

FOUT

FOUT içerik önce fallback fontla, ardından web fontuyla gösterildiğinde oluşur. Metin görünür kalır fakat görsel geçiş yaşanır. Metrikler çok farklıysa layout shift oluşabilir. Uygun fallback ve size-adjust gibi teknikler geçişi azaltabilir. Tasarım testleri gerçek metin içerikleriyle yapılmalıdır.

Fallback Font

Fallback font web fontu henüz hazır değilken içeriği göstermek için kullanılır. Seçilen fallbackin karakter genişlikleri ana fonta yakın olmalıdır. Aksi durumda font swap sırasında satır kırılımları değişebilir. Sistem fontları hızlı başlangıç sağlar. CSS font stack dikkatle tasarlanmalıdır.

Font Metric Mismatch

Font metric mismatch iki fontun x-height, karakter genişliği veya diğer ölçülerinin belirgin biçimde farklı olmasıdır. Bu fark font değişiminde layout hareketi oluşturabilir. Özellikle büyük başlıklarda etkisi artar. CSS font metric override özellikleri bu farkı azaltmaya yardımcı olabilir. Görsel karşılaştırma ile sonuç doğrulanmalıdır.

size-adjust

size-adjust fallback veya web font ölçeğini düzenleyerek görsel metrikleri birbirine yaklaştırmaya yardımcı olabilir. Amaç font swap sırasında metnin yaklaşık aynı alanı kaplamasıdır. Değerler rastgele seçilmemelidir. Kullanılan fontların gerçek metrikleri üzerinden hesaplama yapılmalıdır. CLS ölçümüyle değişikliğin etkisi doğrulanmalıdır.

Layout Shift'i Azaltmak

Font kaynaklı layout shift azaltmak için önce kullanılan font dosyalarının sayısı düşürülmelidir. Uygun fallback ve font-display stratejisi seçilmelidir. Metrik farkları mümkün olduğunca hizalanmalıdır. Kritik fontlar doğru öncelikte yüklenmelidir. Sonuç gerçek kullanıcı verisi ve görsel testlerle doğrulanmalıdır.

Third-Party Asset Optimizasyonu

Third-party kaynaklar analiz, pazarlama, harita, sohbet veya medya işlevleri için sık kullanılır. Bu kaynakların kodunu doğrudan kontrol edemediğiniz için performans yönetimi daha zordur. En güçlü yöntem gerçekten gerekli olmayan entegrasyonları kaldırmaktır. Gerekli olanlar consent veya etkileşim sonrası yüklenebilir. Third-party CPU time ve request sayısı ayrı bütçelerle izlenmelidir.

Analytics

Analytics kullanıcı davranışını ölçmek için değerli olabilir. Ancak birden fazla benzer ölçüm scripti gereksiz yük oluşturabilir. Etiketler düzenli aralıklarla gözden geçirilmelidir. İlk render için gerekli olmayan kodlar uygun yükleme stratejisiyle geciktirilebilir. Veri doğruluğu ile performans arasındaki denge korunmalıdır.

Tag Manager

Tag Manager tek bir container üzerinden çok sayıda script eklenmesini kolaylaştırır. Bu kolaylık kontrolsüz kullanıldığında performans borcu oluşturabilir. Kullanılmayan etiketler zaman içinde birikebilir. Her yeni tag teknik etki değerlendirmesinden geçmelidir. Container sürümleri ve değişiklik geçmişi düzenli denetlenmelidir.

Reklam Scriptleri

Reklam scriptleri ek network istekleri ve ana thread çalışması oluşturabilir. Dinamik reklam alanları layout shift riskini de artırır. Reklam alanlarına önceden boyut ayrılmalıdır. Görünür olmayan reklamlar lazy yüklenebilir. Gelir etkisi ve performans maliyeti birlikte değerlendirilmelidir.

Chat Widget'ları

Chat widgetları çoğu kullanıcı tarafından ilk saniyede kullanılmaz. Buna rağmen başlangıçta büyük script ve stil dosyaları indirebilir. Etkileşim tabanlı veya geciktirilmiş yükleme önemli kazanç sağlayabilir. İlk aşamada hafif bir buton gösterilebilir. Kullanıcı tıkladığında gerçek sohbet bileşeni yüklenebilir.

Social Embed

Sosyal medya embedleri iframe, script ve ek istekler oluşturabilir. Uzun blog içeriklerinde birkaç embed toplam sayfa ağırlığını ciddi biçimde artırabilir. Statik placeholder veya facade yaklaşımı kullanılabilir. Kullanıcı embed alanına yaklaştığında gerçek içerik yüklenebilir. Erişilebilirlik ve içerik erişimi korunmalıdır.

Maps

Harita embedleri başlangıçta çok sayıda tile, script ve stil isteği başlatabilir. Harita ilk ekranda kritik değilse başlangıçta yüklenmesi gerekmez. Statik önizleme veya etkileşim sonrası yükleme kullanılabilir. Kullanıcı haritayı açtığında tam bileşen devreye girer. Bu yaklaşım kurumsal iletişim sayfalarında önemli performans kazancı sağlayabilir.

Video Embed

Harici video embedleri tek iframe ile sınırlı görünse de arka planda ek kaynaklar çağırabilir. Facade pattern ile başlangıçta yalnızca poster gösterilebilir. Kullanıcı oynat düğmesine bastığında gerçek player yüklenir. Böylece kullanıcı videoyu izlemiyorsa gereksiz JavaScript ve bağlantılar oluşturulmaz. Blog ve landing page için oldukça etkili bir yöntemdir.

Third-Party Scriptler Nasıl Hafifletilir?

Third-party scriptleri optimize etmenin ilk adımı envanter çıkarmaktır. Hangi scriptin hangi ekip tarafından ve hangi amaçla eklendiği bilinmelidir. Kullanılmayan kaynaklar kaldırılmalı, gerekli olanların yüklenme zamanı yeniden düzenlenmelidir. Facade veya lazy iframe yaklaşımı görünür olmayan entegrasyonlarda fayda sağlar. Third-party performance budget yeni eklemelerin kontrolsüz büyümesini önler.

Gereksiz Scriptleri Kaldırmak

Hiç kullanılmayan scripti optimize etmeye çalışmak yerine kaldırmak daha etkilidir. Eski kampanya etiketleri sık görülen örnektir. Kod birkaç kilobayt olsa bile ekstra bağlantı ve CPU çalışması oluşturabilir. Tag Manager ve kaynak kod düzenli audit edilmelidir. Her scriptin açık bir iş sahibi olmalıdır.

Consent Sonrası Yükleme

Bazı üçüncü taraf kaynaklar kullanıcı onayı sonrasında çalıştırılabilir. Bu yaklaşım başlangıç yükünü azaltabilir. Uygulama aynı zamanda yürürlükteki gizlilik ve izin gereksinimleriyle uyumlu tasarlanmalıdır. Kullanıcının onay vermediği scriptlerin hiç yüklenmemesi gerekir. Performans faydası hukuki gerekliliklerin yerine geçmez.

Interaction-Based Loading

Interaction-based loading bir bileşenin kaynaklarını kullanıcı gerçekten etkileşim gösterdiğinde yükler. Chat, harita veya gelişmiş video player buna uygundur. İlk açılışta hafif bir placeholder sunulur. Kullanıcı tıklayınca gerçek assetler çağrılır. Bu yöntem kullanılmayan third-party maliyetini büyük ölçüde azaltabilir.

Facade Pattern

Facade pattern ağır üçüncü taraf bileşeninin yerine başlangıçta hafif yerel bir arayüz gösterir. Kullanıcı etkileşim gösterdiğinde gerçek bileşen yüklenir. Video ve harita embedlerinde sık kullanılır. İlk render sırasında üçüncü taraf scripti ve iframe yüklenmez. Görsel görünüm kullanıcıya yeterli önizleme sağlayacak şekilde tasarlanmalıdır.

Lazy iframe

Lazy iframe görünür alan dışındaki embed kaynaklarını başlangıçta yüklememeye yardımcı olur. loading="lazy" bu iş için basit bir seçenek sunar. İframe görünür alana yaklaştığında tarayıcı yüklemeye başlayabilir. Bu yaklaşım uzun içerik sayfalarında ağ maliyetini azaltır. İlk viewport içindeki kritik iframe için ise dikkatli değerlendirme gerekir.

Self-Hosting

Bazı üçüncü taraf statik assetleri lisans ve güncelleme koşulları uygunsa self-host etmek bağlantı kontrolünü artırabilir. Cache header ve CDN ayarları sizin tarafınızdan yönetilebilir. Fakat kaynak güncellemelerini takip etme sorumluluğu doğar. Her script self-hosting için uygun değildir. Güvenlik ve kullanım şartları mutlaka kontrol edilmelidir.

Third-Party Performance Budget

Third-party performance budget harici kaynakların kabul edilebilir maliyetini sınırlar. Toplam transfer, request sayısı veya CPU süresi için eşikler tanımlanabilir. Yeni servis eklendiğinde bu bütçeye etkisi ölçülür. Limit aşılırsa teknik review zorunlu hale getirilebilir. Böylece pazarlama veya ürün ihtiyaçları performansı görünmez biçimde kötüleştirmez.

Resource Hints Nasıl Kullanılmalıdır?

Resource hints tarayıcıya gelecekte hangi bağlantı veya kaynağın önemli olabileceğine dair ipucu verir. preload, preconnect, dns-prefetch, prefetch ve fetchpriority farklı amaçlara hizmet eder. Hepsini aynı anda kullanmak doğru değildir. Gereksiz hintler ağ kaynaklarını kritik assetlerden uzaklaştırabilir. Her ipucu gerçek waterfall problemi çözmek için uygulanmalıdır.

preload

preload sayfanın yakında ihtiyaç duyacağı kritik kaynağı erken indirmek için kullanılır. Font veya geç keşfedilen LCP asseti buna örnek olabilir. Yanlış kaynak preload edilirse ağ rekabeti artar. Kaynak kısa süre içinde gerçekten kullanılmalıdır. Öncesi ve sonrası waterfall karşılaştırması yapılmalıdır.

preconnect

preconnect kritik üçüncü taraf origin için bağlantı kurulumunu erken başlatabilir. DNS, TCP ve güvenli bağlantı süreçlerinin bir bölümünü öne alabilir. Fakat her domain için preconnect eklemek kaynak israfıdır. Yalnızca erken kullanılacağı kesin olan originler seçilmelidir. Fazla bağlantı özellikle mobilde olumsuz etki oluşturabilir.

dns-prefetch

dns-prefetch olası gelecekteki domain için DNS çözümlemesini erkenden başlatabilir. preconnect kadar kapsamlı değildir. Daha düşük öncelikli harici originler için düşünülebilir. Tarayıcı desteği ve gerçek kullanım davranışı değerlendirilmelidir. Modern sayfalarda gereksiz hint kalabalığından kaçınılmalıdır.

prefetch

prefetch gelecekte ihtiyaç duyulması muhtemel kaynağı düşük öncelikle önceden getirebilir. Sonraki route JavaScript'i buna örnek olabilir. Kullanıcı gerçekten o sayfaya gitmeyecekse gereksiz veri tüketilebilir. Mobil veri kullanımı bu nedenle düşünülmelidir. Kullanıcı navigasyon olasılığı yüksek olduğunda daha anlamlıdır.

fetchpriority

fetchpriority belirli kaynakların tarayıcı önceliğini yönlendirmeye yardımcı olur. LCP görselinde high kullanımı bazı sayfalarda faydalıdır. Aşağıdaki görsellerde low seçeneği düşünülebilir. Ancak tarayıcının doğal öncelik algoritmasını gereksiz yere değiştirmemek gerekir. Ölçüm sonrası gerçekten kazanım olup olmadığı kontrol edilmelidir.

Hangi Kaynak İçin Hangisi Kullanılmalı?

Geç keşfedilen kritik font veya LCP kaynağı için preload düşünülebilir. Kritik dış origin için preconnect kullanılabilir. Gelecekteki route asseti için prefetch uygun olabilir. fetchpriority mevcut isteğin önemini ayarlamaya yardımcı olur. Seçim dosya türüne göre değil kaynak keşif ve öncelik problemine göre yapılmalıdır.

Preload Ne Zaman Zararlı Olabilir?

Preload güçlü olduğu kadar yanlış kullanımda zararlı bir araçtır. Tarayıcı preload edilen kaynağa erken ağ kapasitesi ayırır. Bu kaynak gerçekten kritik değilse CSS, HTML veya LCP görseli gibi daha önemli dosyalar gecikebilir. Birçok projede sorun preload eksikliğinden değil fazla preload kullanımından doğar. Bu nedenle her preload kaydının ölçülebilir bir gerekçesi olmalıdır.

Çok Fazla Kaynağı Preload Etmek

On farklı font ve beş görseli preload etmek kaynak önceliği sistemini bozar. Tarayıcı hepsini erken indirmeye çalışır. Mobil bağlantıda bant genişliği hızla dolar. Gerçek kritik kaynaklar beklemek zorunda kalabilir. Preload listesi mümkün olduğunca kısa tutulmalıdır.

Yanlış Kaynak Önceliği

Sayfanın altındaki görselin preload edilmesi LCP görseliyle rekabet oluşturabilir. Benzer şekilde kullanılmayan font yüksek öncelik alabilir. Bu durumda teorik optimizasyon gerçek performansı kötüleştirir. Waterfall değişiklik öncesi ve sonrası karşılaştırılmalıdır. Kritik kaynak sırası gözle doğrulanmalıdır.

Kullanılmayan Preload

Preload edilen kaynak kısa süre içinde kullanılmıyorsa tarayıcı uyarı verebilir. Bu durum ağ kapasitesinin boşa harcandığını gösterir. Eski bir tasarımdan kalan preload kayıtları sık görülen problemdir. Deploy sonrası head içeriği düzenli audit edilmelidir. Kullanılmayan hint kaldırılmalıdır.

Font Preload Fazlalığı

Her font weightini preload etmek sık yapılan bir hatadır. İlk ekranda yalnızca bir veya iki dosyaya ihtiyaç duyulabilir. Diğer fontlar normal akışta yüklenebilir. Fazla preload CSS ve LCP kaynağıyla rekabet yaratır. Kritik font listesi gerçek render üzerinden belirlenmelidir.

Priority Competition

Tarayıcı aynı anda sınırsız kritik kaynak indiremez. Çok sayıda yüksek öncelikli asset bant genişliğini paylaşır. Sonuçta gerçekten önemli dosyaların bitiş süresi uzayabilir. Resource hint kullanımında bu rekabet mutlaka düşünülmelidir. Öncelik sisteminin amacı her şeyi high yapmak değildir.

Asset'lerde HTTP Compression

HTTP compression metin tabanlı assetlerin ağ üzerinden daha küçük aktarılmasını sağlar. HTML, CSS, JavaScript ve SVG bu yöntemlerden önemli ölçüde faydalanabilir. GZIP ve Brotli en yaygın seçenekler arasındadır. JPEG, WebP veya AVIF gibi zaten sıkıştırılmış dosyalarda ek HTTP compression çoğu zaman anlamlı değildir. Sunucu ve CDN yapılandırması dosya türüne göre doğru Content-Encoding göndermelidir.

GZIP

GZIP uzun süredir yaygın kullanılan bir sıkıştırma yöntemidir. Metin tabanlı dosyalarda iyi boyut tasarrufu sağlar. Eski istemcilerle uyumluluğu geniştir. Modern sistemlerde Brotli ile birlikte fallback olarak bulunabilir. Dosya türü yanlış yapılandırılırsa fayda azalabilir.

Brotli

Brotli birçok metin tabanlı assette GZIP'den daha iyi sıkıştırma sağlayabilir. Özellikle statik CSS ve JavaScript dosyaları için uygundur. CDN üzerinde hazır Brotli dosyaları saklanabilir. Çok yüksek sıkıştırma seviyesi dinamik cevaplarda CPU maliyeti oluşturabilir. Statik assetleri build aşamasında önceden sıkıştırmak iyi bir yöntemdir.

HTML

HTML metin tabanlı olduğu için HTTP compression'dan iyi faydalanır. Büyük server-rendered sayfalarda aktarım boyutu belirgin biçimde düşebilir. Dinamik HTML için makul sıkıştırma seviyesi seçilmelidir. TTFB ile CPU maliyeti birlikte değerlendirilmelidir. Gereksiz markup yine de ayrıca temizlenmelidir.

CSS

CSS tekrar eden selector ve property yapıları nedeniyle iyi sıkıştırılabilir. Minification ile compression birlikte kullanılabilir. Ancak sıkıştırma açılmış boyutu ve parse edilen kural sayısını azaltmaz. Bu nedenle unused CSS temizliği hâlâ önemlidir. CDN veya web server doğru mime type üzerinden sıkıştırma uygulamalıdır.

JavaScript

JavaScript de metin tabanlı olduğu için Brotli veya GZIP ile önemli ölçüde küçülebilir. Minification transfer boyutuna ek katkı sağlar. Ancak tarayıcı dosyayı açıp parse etmeye devam eder. Bu nedenle yalnızca sıkıştırma ile büyük bundle problemi çözülmez. Kod miktarının azaltılması temel hedeftir.

SVG

SVG XML tabanlı metin yapısına sahip olduğu için HTTP compression'dan iyi faydalanabilir. Gereksiz metadata ve path bilgisi önce optimize edilmelidir. Harici SVG dosyaları cache avantajı sağlayabilir. Inline SVG ise HTML sıkıştırmasına dahil olur. Kullanım şekli ikon sayısı ve tekrar oranına göre seçilmelidir.

Hangi Dosyalar Zaten Sıkıştırılmıştır?

JPEG, WebP, AVIF, MP4 ve benzeri medya formatları kendi sıkıştırma yöntemlerini kullanır. Bunlara yeniden GZIP uygulamak çoğu zaman anlamlı kazanç sağlamaz. Bazı durumlarda işlem yükü oluşturabilir. Sunucu yapılandırmasında metin ve medya türleri ayrı ele alınmalıdır. Performans testi gerçek transfer boyutu üzerinden yapılmalıdır.

Browser Cache Asset Performansını Nasıl İyileştirir?

Browser cache daha önce indirilen assetlerin sonraki ziyaretlerde tekrar ağdan alınmasını önleyebilir. Statik CSS, JavaScript, font ve görseller bu yöntemden büyük fayda görür. Uzun cache süresi özellikle tekrar ziyaret performansını iyileştirir. Ancak dosya içeriği değiştiğinde kullanıcıya yeni sürümün ulaşması gerekir. Bu nedenle cache stratejisi content hash ile birlikte kullanılmalıdır.

Cache-Control

Cache-Control tarayıcı ve ara cache katmanlarına kaynağın nasıl saklanacağını bildirir. max-age ve immutable gibi direktifler burada tanımlanabilir. Her asset türü aynı cache politikasına sahip olmamalıdır. HTML daha kısa, hashlenmiş statik dosyalar daha uzun süre saklanabilir. Header yapılandırması CDN ile birlikte kontrol edilmelidir.

max-age

max-age kaynağın kaç saniye boyunca taze kabul edileceğini belirler. Hashlenmiş statik assetlerde uzun süreler güvenli biçimde kullanılabilir. Dosya içeriği değiştiğinde URL de değişmelidir. Aynı URL altında farklı içerik yayınlamak uzun cache süresinde sorun yaratabilir. Bu nedenle versiyonlama yöntemi kritik önemdedir.

immutable

immutable tarayıcıya kaynağın cache süresi boyunca değişmeyeceğini bildirebilir. Content hash içeren dosyalar için uygundur. Tarayıcı gereksiz revalidation isteklerinden kaçınabilir. HTML veya sürekli değişen API cevapları için kullanılmamalıdır. Asset pipeline dosya URL'sini içerik değişiminde yenilemelidir.

Validation

Validation cache süresi dolduğunda kaynağın değişip değişmediğini kontrol etmeye yarar. ETag veya Last-Modified gibi mekanizmalar kullanılabilir. Kaynak değişmediyse tam dosya yeniden gönderilmeyebilir. Yine de ağ round trip maliyeti oluşur. Hashlenmiş uzun ömürlü statik assetlerde revalidation ihtiyacı büyük ölçüde azaltılabilir.

Repeat Visit Performance

Tekrar ziyaret performansı iyi cache stratejisinin en görünür faydalarından biridir. Kullanıcı CSS, JavaScript ve fontları yeniden indirmek zorunda kalmayabilir. Sayfa çok daha düşük transferle açılabilir. Ancak HTML ve dinamik veri yine güncel alınmalıdır. İlk ve tekrar ziyaret senaryoları ayrı test edilmelidir.

Uzun Süreli Asset Cache Nasıl Güvenli Kullanılır?

Uzun cache süresi statik dosyalarda güçlü performans avantajı sağlar. Risk, dosya değiştiği halde URL aynı kalırsa kullanıcıların eski sürümü görmesidir. Content hash bu problemi çözmenin en yaygın yöntemlerinden biridir. Dosya içeriği değiştiğinde yeni hash ve yeni URL oluşur. Böylece eski dosya güvenle uzun süre cache içinde kalabilir.

Content Hash

Content hash dosya içeriğine göre üretilen benzersiz bir tanımlayıcıdır. İçerik değişirse hash de değişir. Bu değer dosya adına eklenebilir. Tarayıcı yeni URL'yi farklı kaynak olarak görür. Uzun cache süresi böylece güvenli hale gelir.

Fingerprinted Filenames

Fingerprinted filename dosya adına hash veya versiyon bilgisi eklenmesi yaklaşımıdır. app.abc123.js bunun tipik örneğidir. Yeni deployda içerik değişirse yeni dosya adı üretilir. Eski cache yeni sürümü engellemez. Build araçları bu süreci otomatik yapabilir.

app.abc123.js

app.abc123.js gibi dosya adı content hash kullanımını somutlaştırır. abc123 bölümü dosyanın belirli sürümünü temsil eder. Kod değiştiğinde örneğin app.def456.js oluşabilir. HTML yeni dosyaya referans verir. Önceki sürüm kullanıcı cacheinde kalsa bile sorun oluşturmaz.

Yeni Deploy'da Yeni Asset URL'si

Yeni deploy sırasında değişen assetin URL'si de değişmelidir. Böylece tarayıcı güncel kaynağı otomatik indirir. Değişmeyen dosyaların URL'si aynı kalabilir ve cache avantajı korunur. Bu yaklaşım yalnızca JavaScript için değil CSS ve görsellerde de kullanılabilir. Pipeline dosya referanslarını otomatik güncellemelidir.

Cache Busting

Cache busting kullanıcıya yeni asset sürümünü ulaştırmayı sağlar. Content hash en güvenilir yöntemlerden biridir. Rastgele query parametresi her deployda tüm cache avantajını yok edebilir. Yalnızca değişen dosyaların URL'sinin yenilenmesi daha verimlidir. CDN purge ihtiyacı da bu yapı sayesinde azalabilir.

CDN ile Asset Optimizasyonu

CDN statik assetleri kullanıcıya coğrafi olarak yakın edge noktalarından sunabilir. Bu yaklaşım özellikle farklı şehir ve ülkelerden trafik alan sitelerde gecikmeyi azaltabilir. CDN aynı zamanda cache, compression ve görsel dönüşüm özellikleri sunabilir. Fakat yanlış cache header veya düşük hit rate performans avantajını sınırlar. CDN kullanımının başarılı olup olmadığı gerçek kullanıcı ve cache verileriyle ölçülmelidir.

Edge Delivery

Edge delivery kaynağın origin yerine kullanıcıya daha yakın bir noktadan verilmesini sağlar. Fiziksel mesafe ve ağ rotası gecikmeyi etkileyebilir. Global kullanıcı kitlesinde fark daha belirgin olabilir. Statik assetler edge cache için iyi adaylardır. Dinamik içeriğin cache gereksinimleri ise ayrıca değerlendirilmelidir.

Static Asset Caching

CSS, JavaScript, font ve görseller CDN üzerinde uzun süre cachelenebilir. Content hash kullanımı bu yapıyı güvenli hale getirir. Cache hit olduğunda origin isteği oluşmaz. Bu durum sunucu yükünü ve gecikmeyi azaltabilir. Cache-Control headerlarının CDN davranışıyla uyumlu olması gerekir.

Image CDN

Image CDN istenen ölçü ve formatta görseli dinamik olarak üretebilir. Mobil kullanıcıya daha küçük çözünürlük sunulabilir. AVIF veya WebP dönüşümü otomatik yapılabilir. Kalite ayarları merkezi biçimde yönetilir. Böylece içerik ekibi her dosyayı manuel optimize etmek zorunda kalmaz.

Compression

CDN HTML, CSS ve JavaScript gibi kaynaklar için Brotli veya GZIP uygulayabilir. Edge üzerinde sıkıştırılmış varyantların cachelenmesi origin CPU yükünü azaltır. İstemcinin Accept-Encoding başlığına göre doğru format sunulur. Yanlış mime type bazı dosyaların sıkıştırılmamasına sebep olabilir. Headerlar gerçek response üzerinden kontrol edilmelidir.

Cache Hit Rate

Cache hit rate isteklerin ne kadarının edge cache üzerinden karşılandığını gösterir. Düşük oran CDN kullanımından beklenen faydayı azaltabilir. Sık query parametreleri veya kısa cache süresi hit rate'i düşürebilir. Asset URL stratejisi bu metriği doğrudan etkiler. CDN paneli ile origin request sayısı birlikte izlenmelidir.

Origin Requests

Origin request sayısı cache verimliliğinin önemli göstergelerinden biridir. Statik dosyalar her istekte origin'e gidiyorsa CDN doğru çalışmıyor olabilir. Cache key ve header ayarları incelenmelidir. Gereksiz purge işlemleri de origin yükünü artırabilir. Content hash ile uzun cache bu sorunu azaltır.

Global Kullanıcılar

Farklı ülke ve bölgelerden gelen kullanıcılar origin sunucuya farklı ağ mesafelerinde olabilir. CDN bu farkı azaltmaya yardımcı olur. Yakın edge noktasından statik kaynak sunmak bağlantı süresini düşürebilir. Ancak gerçek sonuç kullanıcı lokasyonları üzerinden test edilmelidir. Yerel kullanıcı kitlesi olan küçük projelerde kazanım daha sınırlı olabilir.

HTTP/2 ve HTTP/3 Asset Stratejisini Nasıl Değiştirir?

HTTP/2 ve HTTP/3 modern bağlantı özellikleri sayesinde çoklu kaynak teslimini önceki yaklaşımlardan farklı hale getirir. Eski dönemde her şeyi tek bundle yapmak bağlantı maliyetini azaltmak için yaygın bir yöntemdi. Günümüzde aşırı büyük tek bundle cache ve code splitting avantajlarını ortadan kaldırabilir. Yine de binlerce küçük dosya göndermek de doğru değildir. Dosya stratejisi protokol avantajları, cache kullanımı ve uygulama mimarisi birlikte değerlendirilerek hazırlanmalıdır.

Multiplexing

Multiplexing aynı bağlantı üzerinden birden fazla isteğin birlikte taşınabilmesini sağlar. Bu durum çok sayıda kaynak için bağlantı sayısını azaltabilir. Ancak ağ kapasitesi hâlâ sınırlıdır. Gereksiz istekler kritik assetlerle rekabet etmeye devam eder. Bu nedenle multiplexing sınırsız asset yüklemek için gerekçe değildir.

Paralel Resource Delivery

Modern protokoller birden fazla kaynağın paralel biçimde teslim edilmesini kolaylaştırır. CSS, JavaScript ve görseller aynı bağlantı üzerinden ilerleyebilir. Tarayıcı önceliklendirme mekanizması hangi kaynağın önce tamamlanacağını etkiler. Çok sayıda high priority isteği bu dengeyi bozabilir. Asset sayısı yine kontrol altında tutulmalıdır.

Connection Reuse

Connection reuse aynı origin için kurulmuş bağlantının birden fazla istekte kullanılmasını sağlar. Yeni bağlantı kurulum maliyeti azalır. Assetleri çok sayıda farklı domaine bölmek bu avantajı azaltabilir. Eski domain sharding yaklaşımı modern protokollerde çoğu zaman gerekli değildir. Domain sayısı waterfall üzerinden kontrol edilmelidir.

Çok Sayıda Küçük Dosya ile Büyük Bundle Dengesi

Tek dev bundle başlangıçta kullanılmayan çok sayıda kodu kullanıcıya gönderebilir. Aşırı küçük dosyalar ise yönetim ve istek maliyetini artırabilir. Route ve component düzeyinde mantıklı chunklar iyi bir denge sağlar. Cache tekrar kullanım oranı da dikkate alınmalıdır. Bundle analizi gerçek kullanıcı akışlarına göre yapılmalıdır.

“Her Şeyi Tek Dosyada Birleştir” Yaklaşımının Sınırları

Her şeyi tek CSS veya JavaScript dosyasına koymak eski performans tavsiyelerinden biridir. Modern uygulamalarda bu yöntem ilk payloadı gereksiz büyütebilir. Kullanıcı tek sayfa için tüm uygulama kodunu indirir. Küçük bir değişiklik tüm bundle hashini değiştirerek cache'i de etkileyebilir. Mantıklı code splitting günümüzde daha esnek bir yaklaşım sunar.

Asset Request Chain Nasıl Kısaltılır?

Request chain bir kaynağın başka bir kaynak keşfedildikten sonra yüklenmeye başlaması durumunda oluşur. Zincir uzadıkça kritik assetin başlangıç zamanı gecikebilir. HTML içindeki doğrudan referanslar daha erken keşif sağlayabilir. Waterfall analizi zincirleri görmenin en pratik yöntemidir. Özellikle LCP görseli, font ve kritik CSS zincirleri yakından incelenmelidir.

HTML → CSS → Font

Font çoğu zaman CSS içindeki @font-face kuralı işlendikten sonra keşfedilir. Kritik font gerekiyorsa bu doğal zincir gecikme yaratabilir. Uygun durumda font preload kullanılabilir. Ancak yalnızca ilk ekranda kullanılan sınırlı fontlar seçilmelidir. Fazla preload diğer kaynakları geciktirebilir.

HTML → CSS → Background Image

Background image CSS dosyası indirilmeden keşfedilemeyebilir. Hero görseli background olarak kullanılıyorsa LCP başlangıcı gecikebilir. img veya picture elemanı kullanımı daha erken keşif sağlar. Tasarım nedeniyle background gerekli ise preload test edilebilir. Karar waterfall verisiyle doğrulanmalıdır.

HTML → JS → Image

Görsel JavaScript çalıştıktan sonra DOM'a ekleniyorsa üç aşamalı keşif zinciri oluşur. Önce HTML, sonra script, ardından görsel yüklenir. LCP assetinde bu yapı ciddi gecikme yaratabilir. Server-rendered markup veya initial HTML içinde görsel referansı daha iyi olabilir. Uygulama mimarisi gerçek performans kazanımına göre değerlendirilmelidir.

Kritik Asset'i İlk HTML'de Keşfedilebilir Yapmak

Kritik kaynakların initial HTML içinde doğrudan bulunması tarayıcının preload scanner özelliğinden faydalanmasını kolaylaştırır. Görsel veya stylesheet daha erken keşfedilebilir. JavaScript beklemek zorunda kalmaz. Bu yaklaşım gereksiz manuel preload kullanımını da azaltabilir. İlk HTML yapısı performans tasarımının önemli bir parçasıdır.

Waterfall ile Chain Analizi

Waterfall üzerinde her isteğin hangi noktada başladığı görülür. Kritik asset diğer bir dosyanın bitişinden hemen sonra başlıyorsa bağımlılık zinciri olabilir. Initiator bilgisi kaynağın kim tarafından çağrıldığını gösterir. Bu sayede HTML, CSS veya JavaScript kaynaklı keşif gecikmesi belirlenir. Zincir kısaltıldıktan sonra LCP ve load start değişimleri tekrar ölçülmelidir.

WordPress'te Asset Optimizasyonu

WordPress sitelerinde tema, eklenti ve üçüncü taraf servisler zaman içinde çok sayıda asset ekleyebilir. Her eklentinin CSS ve JavaScript'i her sayfada gerekli olmayabilir. Sayfa bazlı asset unload, görsel pipeline, cache ve CDN birlikte ele alınmalıdır. Otomatik optimizasyon eklentileri yardımcı olabilir fakat ayarların gerçek site davranışıyla test edilmesi gerekir. Özellikle kritik işlevleri bozabilecek geciktirme seçenekleri staging ortamında doğrulanmalıdır.

Theme Asset'leri

Tema dosyaları tüm sayfalara global CSS ve JavaScript gönderebilir. Kullanılmayan bileşenlerin assetleri yine de yüklenebilir. Child theme veya özel build yaklaşımıyla gereksiz kaynaklar azaltılabilir. Güncelleme sonrası değişikliklerin korunması önemlidir. Tema performansı sadece dosya boyutuyla değil DOM ve render davranışıyla da değerlendirilmelidir.

Plugin CSS

Eklentiler çoğu zaman kendi stylesheetlerini tüm sayfalarda enqueue eder. Form eklentisinin CSS'i form olmayan sayfada bile yüklenebilir. Sayfa bazlı dequeue işlemi bu gereksiz yükü azaltabilir. Eklenti güncellemeleri sonrası handle adları veya bağımlılıklar değişebilir. Bu nedenle düzenli regresyon testi gerekir.

Plugin JavaScript

Plugin JavaScript dosyaları ana thread maliyetini artırabilir. Özellikle slider, form ve analiz eklentileri birden fazla script yükleyebilir. Gereksiz modüller devre dışı bırakılmalıdır. Uygun scriptlerde defer veya etkileşim sonrası yükleme kullanılabilir. Kritik işlevlerin bozulmadığı gerçek kullanıcı akışlarıyla test edilmelidir.

Sayfa Bazlı Asset Unload

Sayfa bazlı asset unload belirli CSS veya JavaScript dosyasını ihtiyaç olmayan sayfalarda yüklememeyi sağlar. Bu yöntem WordPress performansında güçlü sonuç verebilir. Ancak eklenti bağımlılıkları dikkatle kontrol edilmelidir. Bir dosya görünürde kullanılmasa bile başka script ona bağlı olabilir. Staging ve otomatik test olmadan geniş kapsamlı unload yapılmamalıdır.

Görsel Optimizasyonu

WordPress medya kütüphanesi yüklenen görseller için farklı boyutlar üretebilir. Tema doğru responsive image yapısını kullanırsa tarayıcı uygun çözünürlüğü seçebilir. WebP veya AVIF dönüşümü otomatikleştirilebilir. Orijinal dosya gereğinden büyük yüklenmemelidir. Görsel CDN kullanımı trafik ve altyapıya göre değerlendirilebilir.

Cache

WordPress'te page cache ve browser cache farklı katmanlardır. Statik assetler uzun süreli tarayıcı cache'inden faydalanabilir. Sayfa HTML'i ise içerik güncellemelerine uygun politikayla yönetilmelidir. Cache eklentilerindeki tüm seçenekleri rastgele açmak yerine header davranışı kontrol edilmelidir. Üyelik veya dinamik sepet sayfaları gibi özel alanlar ayrı ele alınmalıdır.

CDN

WordPress assetlerini CDN üzerinden sunmak coğrafi gecikmeyi ve origin yükünü azaltabilir. Görseller, CSS, JavaScript ve fontlar edge cache için uygundur. URL rewrite işlemi doğru yapılmalıdır. Cache purge ve versiyonlama süreçleri deploy yapısıyla uyumlu olmalıdır. CDN kullanımının gerçek etkisi alan verileriyle doğrulanmalıdır.

CMS İçin Otomatik Asset Pipeline Nasıl Kurulur?

CMS kullanıcılarının her yüklemede performans kurallarını manuel uygulamasını beklemek sürdürülebilir değildir. Otomatik pipeline dosya geldiği anda sıkıştırma, format dönüşümü, responsive boyut üretimi ve CDN gönderimi yapabilir. Böylece içerik ekibi iş akışını değiştirmeden performans standardı korunur. Filename hashing ve cache headerları da aynı sistemin parçası olabilir. Büyük kurumsal sitelerde bu otomasyon zaman içinde ciddi teknik borcu önler.

Upload Sırasında Görsel Sıkıştırma

Görsel yüklendiği anda otomatik sıkıştırma uygulanabilir. Dosya boyutu belirli limitin üzerindeyse işlem zorunlu hale getirilebilir. Fotoğraf ve grafikler farklı profillerle işlenmelidir. Orijinal dosyanın saklanıp saklanmayacağı depolama politikasına göre belirlenir. Editörler performans ayarlarıyla manuel uğraşmaz.

WebP / AVIF Generation

Pipeline JPEG veya PNG kaynağından WebP ve AVIF türevleri üretebilir. Tarayıcı desteğine göre uygun format sunulur. Kalite parametreleri tek merkezden yönetilir. Her içerik editörü farklı dönüştürme aracı kullanmak zorunda kalmaz. Üretilen dosyalar gerçek boyut ve kalite testlerinden geçirilmelidir.

Responsive Sizes

Farklı ekranlar için birden fazla görsel çözünürlüğü otomatik üretilebilir. Örneğin küçük, orta ve büyük varyantlar oluşturulur. Frontend srcset üzerinden bu kaynakları tarayıcıya sunar. Cihaz gereksiz büyük dosyayı indirmez. Tasarım breakpointleri değiştiğinde pipeline boyutları da güncellenmelidir.

Filename Hashing

Üretilen assetlere içerik tabanlı hash eklenebilir. Böylece uzun süreli cache güvenli hale gelir. Dosya değiştiğinde URL otomatik yenilenir. Eski cache kullanıcıya güncel olmayan dosya göstermez. CDN üzerinde de versiyon yönetimi kolaylaşır.

CDN Upload

Pipeline optimize edilen assetleri otomatik olarak CDN storage alanına gönderebilir. Uygulama yalnızca CDN URL'sini kullanır. Deploy veya medya güncellemesi sırasında manuel kopyalama gerekmez. Cache purge işlemleri minimumda tutulabilir. Dosya bütünlüğü ve hata yönetimi otomasyon içinde kontrol edilmelidir.

Cache Headers

Asset pipeline dosya türüne göre doğru Cache-Control headerlarını belirleyebilir. Hashlenmiş statik dosyalarda uzun max-age kullanılabilir. HTML veya dinamik dosyalar farklı politika izler. CDN ve origin headerlarının çakışmadığı kontrol edilmelidir. Otomatik testler beklenen header değerlerini doğrulayabilir.

Asset Optimizasyonunu CI/CD Sürecine Dahil Etmek

Asset optimizasyonu yalnızca bir kez yapılan manuel temizlik olarak kalırsa birkaç ay içinde eski performans sorunları geri dönebilir. CI/CD entegrasyonu her deployda dosya boyutlarını ve performans eşiklerini kontrol eder. Minification, tree shaking, image compression ve hashing build sırasında otomatik uygulanabilir. Lighthouse CI ve bundle diff testleri regresyonları üretime çıkmadan yakalayabilir. Böylece performans ekip kültürünün sürekli bir kalite kriteri haline gelir.

Build-Time Minification

CSS ve JavaScript minification build aşamasında otomatik yapılmalıdır. Geliştiricinin manuel dosya küçültmesine ihtiyaç kalmaz. Üretim ve geliştirme konfigürasyonları ayrı tutulabilir. Source map politikası güvenlik ve hata ayıklama gereksinimine göre belirlenir. Build çıktısında minification'ın gerçekten uygulandığı kontrol edilmelidir.

Tree Shaking

Tree shaking üretim bundleında kullanılmayan exportların çıkarılmasına yardımcı olur. CI sistemi beklenmedik bundle büyümesini takip edebilir. Yeni dependency tree shaking davranışını bozarsa boyut artışı hemen fark edilir. ESM yapısı ve side effects ayarları doğrulanmalıdır. Bundle analyzer çıktıları build artefact olarak saklanabilir.

Image Compression

Build sırasında projeye eklenen statik görseller otomatik sıkıştırılabilir. Belirli boyut limitini aşan dosya build hatası oluşturabilir. Böylece yanlışlıkla birkaç megabaytlık hero görseli üretime çıkmaz. Modern format türevleri de aynı aşamada üretilebilir. İçerik yönetim sistemi görselleri ayrı pipeline ile işleyebilir.

Bundle Analysis

Bundle analysis hangi paketlerin çıktıda ne kadar yer kapladığını gösterir. Yeni pull request sonrası büyük artışlar kolayca fark edilir. Duplicate dependency veya gereksiz locale dosyaları görülebilir. Rapor geçmiş buildlerle karşılaştırılabilir. Yalnızca toplam boyut değil chunk dağılımı da incelenmelidir.

Asset Hashing

Build sistemi değişen statik assetler için yeni content hash üretebilir. HTML veya manifest dosyaları güncel URL'leri otomatik referans eder. Uzun cache süreleri güvenli hale gelir. Değişmeyen dosyalar cache avantajını korur. CDN üzerinde gereksiz toplu purge ihtiyacı azalır.

Lighthouse CI

Lighthouse CI belirli sayfalar için otomatik performans testleri çalıştırabilir. Score veya metrik eşikleri tanımlanabilir. Tek ölçüm değişken olabileceği için birkaç koşunun medyanı tercih edilebilir. Laboratuvar ortamı gerçek kullanıcı verisinin yerine geçmez. Ama regresyonları erken yakalamak için oldukça kullanışlıdır.

Performance Regression Test

Performance regression test yeni sürümün önceki sürüme göre belirgin biçimde yavaşlayıp yavaşlamadığını kontrol eder. Bundle size, LCP veya TBT gibi değerler karşılaştırılabilir. Sabit eşik yanında yüzde değişim de izlenebilir. Küçük doğal ölçüm dalgalanmaları için tolerans tanımlanmalıdır. Kritik regresyonlarda deploy durdurulabilir.

Performance Budget Quality Gate

Quality gate performans bütçesini yalnızca raporlanan bir sayı olmaktan çıkarıp dağıtım kararına bağlar. Yeni kod belirlenen limitleri aşıyorsa uyarı veya build failure üretilebilir. Bu yaklaşım performans sorumluluğunu geliştirme sürecinin doğal parçası haline getirir. Her eşik aynı derecede kritik olmak zorunda değildir. Kullanıcı deneyimini doğrudan etkileyen metriklerde daha güçlü kurallar uygulanabilir.

JavaScript Budget Aşılırsa Build Fail

Başlangıç JavaScript bütçesi kritikse limit aşımı build failure olarak tanımlanabilir. Geliştirici yeni dependency eklediğinde etkisini hemen görür. Yanlış pozitifleri azaltmak için gzip veya Brotli boyutu yerine uygun ölçüm seçilmelidir. Route bazlı bütçeler daha anlamlı olabilir. İstisnalar kod review ile belgelenmelidir.

CSS Budget Aşılırsa Uyarı

CSS boyutunda küçük artışlar hemen deploy engeli gerektirmeyebilir. Önce warning seviyesi kullanılabilir. Sürekli artış eğilimi görülürse eşik sertleştirilebilir. Unused CSS oranı da tek başına dosya boyutundan daha anlamlı sinyal olabilir. Tasarım sistemi ekipleri bu raporlara erişebilmelidir.

Yeni Görsel Fazla Büyükse Reject

Belirlenen limitin üzerinde yeni görsel repository'ye eklenirse build reddedilebilir. Geliştirici veya içerik sorumlusu dosyayı optimize etmek zorunda kalır. Bu yöntem performans problemini daha siteye girmeden önler. Farklı görsel türleri için farklı limitler tanımlanabilir. Hero görseli ile küçük ikon aynı bütçeyi paylaşmamalıdır.

Third-Party Script Eklenirse Review

Yeni third-party script otomatik olarak teknik review gerektirebilir. İş amacı, transfer boyutu, CPU maliyeti ve gizlilik gereksinimleri değerlendirilir. Scriptin ne zaman yükleneceği baştan belirlenir. Alternatif olarak interaction-based loading uygulanabilir. Böylece birkaç ay sonra sahibi bilinmeyen scriptler birikmez.

LCP Regresyonunda Deployment Engeli

Kritik sayfalarda LCP belirli oranda kötüleşirse deployment engellenebilir. Laboratuvar ölçüm dalgalanmasını azaltmak için birden fazla test kullanılmalıdır. Küçük doğal sapmalar için tolerans tanımlanır. Büyük ve tekrar eden regresyonlar araştırılmadan üretime çıkarılmaz. Field data daha sonra uzun vadeli doğrulama için kullanılır.

Asset Boyutundaki Regresyon Nasıl Yakalanır?

Asset boyutundaki regresyon çoğu zaman tek büyük değişiklikten değil küçük eklemelerin birikmesinden oluşur. Pull request seviyesinde diff üretmek bu artışı erken görünür hale getirir. Bundle, görsel, request sayısı ve toplam page weight ayrı ayrı karşılaştırılabilir. Takım yalnızca üretim yavaşladıktan sonra problem fark etmez. Sürekli ölçüm performans borcunu yönetilebilir tutar.

Pull Request Comparison

Her pull request mevcut production veya ana branch ile karşılaştırılabilir. Toplam JavaScript ve CSS boyutu değişimi raporlanabilir. Kritik route metrikleri otomatik test edilebilir. Geliştirici performans etkisini merge öncesinde görür. Büyük artışlar açıklama gerektirebilir.

Bundle Diff

Bundle diff hangi chunk veya dependency'nin büyüdüğünü gösterir. Toplam boyut artışının kaynağı hızlıca bulunabilir. Yeni kütüphane veya duplicate paketler görünür olur. Diff raporu CI artefact olarak saklanabilir. Boyut düşüşleri de teknik iyileştirmenin sonucunu gösterir.

Image Diff

Image diff yeni veya değişen görsellerin toplam ağırlığını karşılaştırır. Bir tasarım değişikliğinde birkaç büyük dosya eklendiğinde etkisi hemen ortaya çıkar. Çözünürlük ve format bilgisi de rapora eklenebilir. Limit aşan görseller otomatik uyarı oluşturabilir. CMS tarafında benzer kontrol upload pipeline içinde yapılabilir.

Request Count Diff

Request count diff sayfanın kaç yeni ağ isteği oluşturduğunu gösterir. Yeni third-party entegrasyon bazen onlarca request ekleyebilir. Tek dosya değişikliğine bakarak bu etki anlaşılamaz. Waterfall diff daha ayrıntılı inceleme sağlar. Kritik sayfalarda request sayısı için bütçe tanımlanabilir.

Page Weight Diff

Page weight diff sayfanın toplam transfer boyutundaki değişimi gösterir. Görsel, JavaScript, CSS ve font kırılımı ayrıca raporlanmalıdır. Toplam değer aynı kalırken JavaScript artışı kullanıcı deneyimini yine kötüleştirebilir. Bu nedenle tür bazlı dağılım önemlidir. Mobil ilk ziyaret senaryosu temel referans olarak kullanılabilir.

Lab Test ile Field Data Birlikte Nasıl Kullanılır?

Lab test hızlı ve tekrar edilebilir teşhis sağlar. Field data ise gerçek kullanıcıların farklı koşullarda ne yaşadığını gösterir. İki veri türünü rakip değil tamamlayıcı görmek gerekir. Bir değişiklik önce laboratuvar ortamında test edilir, ardından saha verisindeki eğilim izlenir. PageSpeed ve web performans optimizasyonu danışmanlığı yakınımda araması yapan işletmeler için de sağlıklı çalışma modeli yalnızca skor raporu değil bu iki veri kaynağını birlikte yorumlayan süreç olmalıdır.

Lighthouse

Lighthouse geliştirme aşamasında hızlı karşılaştırmalar için uygundur. Aynı cihaz profili ve koşullarla tekrarlanan testler regresyonu görünür kılar. Rapor teknik teşhis önerileri sağlar. Ancak tek kullanıcı senaryosunu temsil eder. Bu nedenle field data ile tamamlanmalıdır.

PageSpeed Insights

PageSpeed Insights laboratuvar ve mevcut olduğunda saha verisini aynı noktada değerlendirme fırsatı sunar. Bu özellik ilk inceleme için pratiktir. LCP veya diğer değerlerde lab ile field arasında fark görülebilir. Fark gerçek cihaz veya ağ dağılımından kaynaklanabilir. Araştırma her iki veri setini açıklamaya odaklanmalıdır.

CrUX

CrUX Chrome kullanıcılarından elde edilen toplu gerçek deneyim verilerini sunar. Yeterli trafik olmadığında URL seviyesinde veri bulunmayabilir. Origin seviyesinde daha geniş veri görülebilir. Tarihsel eğilimler değişikliklerin uzun vadeli etkisini anlamaya yardımcı olur. Kendi kullanıcı segmentleriniz için RUM daha ayrıntılı bilgi sağlayabilir.

Search Console Core Web Vitals

Search Console Core Web Vitals raporu benzer performans davranışı gösteren URL gruplarını değerlendirmeye yardımcı olur. Sorunun tek sayfa mı yoksa şablon düzeyinde mi olduğunu anlamak kolaylaşır. Ancak rapor ayrıntılı JavaScript veya waterfall teşhisi sunmaz. Sorunlu grup belirlendikten sonra teknik araçlarla derin inceleme yapılmalıdır. Veri değişikliklerinin görünmesi zaman alabilir.

Real User Monitoring

Real User Monitoring kendi ziyaretçilerinizden ayrıntılı performans verisi toplamayı sağlar. Cihaz, sayfa türü, bölge veya kullanıcı akışı bazında kırılım yapılabilir. LCP ve INP gibi metriklerin hangi segmentte kötü olduğunu görmek mümkündür. Kişisel veri ve gizlilik gereksinimleri dikkate alınmalıdır. RUM sonuçları ürün ve performans ekiplerinin ortak karar almasını kolaylaştırır.

Sentetik Test vs Gerçek Kullanıcı

Sentetik test kontrollü ve tekrar edilebilir olduğu için geliştirme sürecinde güçlüdür. Gerçek kullanıcı verisi ise değişken ama gerçek koşulları yansıtır. Sentetik testte hızlı görünen sayfa düşük güçlü cihazlarda yavaş olabilir. Field data bu farkı ortaya çıkarabilir. En güçlü performans yaklaşımı iki yöntemi birlikte kullanır.

Asset Optimizasyonunun Başarısı Nasıl Ölçülür?

Optimizasyonun başarılı olduğunu söylemek için yalnızca PageSpeed skorunun yükselmesi yeterli değildir. Transfer size, request count, LCP, INP, CLS, cache hit rate ve third-party CPU time birlikte değerlendirilebilir. Her değişiklik öncesi baseline kaydedilmelidir. Sonuçlar mümkün olduğunca gerçek kullanıcı verisiyle doğrulanmalıdır. İş hedefi olan dönüşüm veya etkileşim oranları da performans iyileştirmesinin kullanıcı davranışına etkisini anlamaya yardımcı olabilir.

Transfer Size

Transfer size kullanıcıya ağ üzerinden ne kadar veri gönderildiğini gösterir. Görsel ve JavaScript optimizasyonları bu değeri doğrudan azaltabilir. İlk ziyaret ve cacheli tekrar ziyaret ayrı ölçülmelidir. Toplam değer yanında dosya türü kırılımı da önemlidir. Daha az transfer mobil kullanıcı için daha düşük veri tüketimi anlamına gelir.

Request Count

Request count sayfanın kaç ayrı kaynak istediğini gösterir. Modern protokoller çoklu istekleri daha iyi yönetir. Yine de her istek sıfır maliyetli değildir. Third-party entegrasyonlar request sayısını hızla artırabilir. Kritik yol üzerindeki istekler toplam sayıdan daha yüksek öncelikle değerlendirilmelidir.

LCP

LCP ilk ekrandaki büyük içerik öğesinin görünme süresini değerlendirir. Asset optimizasyonu sonrası hero görselinin daha erken yüklenmesi LCP'yi iyileştirebilir. Sunucu yanıt süresi de metriği etkiler. Bu nedenle yalnızca görsel dosyasına odaklanmamak gerekir. Field data uzun dönem doğrulama için önemlidir.

INP

INP kullanıcı etkileşimlerine verilen görsel cevabın gecikmesini anlamaya yardımcı olur. JavaScript yükü azaltıldığında değer iyileşebilir. Long task ve third-party scriptler yakından izlenmelidir. Gerçek kullanıcı cihazları bu metrikte büyük fark oluşturabilir. RUM ayrıntılı segment analizi sağlayabilir.

CLS

CLS görsel kararlılığı ölçer. Görsel boyutlarının tanımlanması ve font metriklerinin uyarlanması kaymaları azaltabilir. Dinamik banner ve embed alanlarına önceden yer ayrılmalıdır. Performans değişikliği sonrası sayfanın beklenmedik şekilde sıçramadığı kontrol edilmelidir. Mobil ve masaüstü tasarımlar ayrı test edilmelidir.

TBT

TBT laboratuvar ortamında ana thread üzerindeki bloklayıcı uzun görevleri anlamaya yardımcı olur. Büyük JavaScript bundle veya yoğun execution yüksek TBT oluşturabilir. Code splitting ve task splitting ile değer düşebilir. TBT doğrudan field metriği değildir. INP problemlerinin teknik nedenlerini araştırırken yardımcı sinyal olarak kullanılabilir.

Cache Hit Rate

Cache hit rate CDN veya cache katmanının ne kadar verimli çalıştığını gösterir. Hashlenmiş statik assetlerde yüksek oran beklenir. Düşük oran cache key veya header problemine işaret edebilir. Origin request ve transfer süresi birlikte izlenmelidir. Tekrar ziyaret performansı bu metrikten doğrudan fayda görür.

Third-Party CPU Time

Third-party CPU time harici scriptlerin ana thread üzerinde ne kadar zaman tükettiğini gösterir. Büyük analytics veya widget kodları burada öne çıkabilir. Script boyutu küçük olsa bile çalışma süresi yüksek olabilir. Kullanılmayan servislerin kaldırılması ve geciktirilmiş yükleme etkili çözümlerdir. Bu değer INP değerlendirmesiyle birlikte okunmalıdır.

PageSpeed Sonucunu Yanlış Yorumlamanın Yaygın Örnekleri

PageSpeed raporları faydalıdır fakat yanlış yorumlandığında gereksiz geliştirme işi oluşturabilir. Tek skora bakmak, her öneriyi otomatik uygulamak veya gerçek kullanıcı verisini yok saymak sık yapılan hatalardır. Teknik kararın hangi kullanıcı metriğini iyileştireceği açık olmalıdır. Bazı öneriler belirli sayfalarda çok düşük etki yaratabilir. Öncelik her zaman ölçülen darboğaza göre verilmelidir.

Sadece Skora Bakmak

Performance Score genel bir özet sağlar. Ancak hangi metriğin kötü olduğunu tek başına anlatmaz. Aynı puana sahip iki sayfanın sorunları tamamen farklı olabilir. Biri LCP, diğeri JavaScript execution problemi yaşayabilir. Bu nedenle skorun altındaki ölçümler incelenmelidir.

100/100 İçin Kullanıcı Deneyimini Bozmak

Skoru yükseltmek için kullanıcıya değer sağlayan bir özelliği kaldırmak her zaman doğru değildir. Performans işlevsellikle birlikte değerlendirilmelidir. Örneğin ödeme veya ürün filtreleme deneyimi korunmalıdır. Kullanıcıya hızlı ama eksik bir sayfa sunmak hedef olmamalıdır. Teknik optimizasyon iş hedefleriyle dengeli yürütülmelidir.

Field Data'yı Görmezden Gelmek

Lab test iyi sonuç verirken gerçek kullanıcılar hâlâ yavaşlık yaşayabilir. Farklı cihaz ve bağlantılar bu durumu açıklar. Field data geniş kullanıcı kitlesini temsil eder. Bu veriyi yok saymak yanlış güven hissi oluşturabilir. Lab ve field verileri birlikte değerlendirilmelidir.

Her Lighthouse Önerisini Körü Körüne Uygulamak

Lighthouse önerileri önemli teşhis ipuçları verir. Ancak her önerinin etkisi aynı değildir. Birkaç kilobaytlık kazanç için karmaşık mimari değişikliği yapmak gereksiz olabilir. Önce kullanıcı metriğine olası katkı değerlendirilmelidir. En büyük darboğazdan başlamak daha verimlidir.

Tek Test Sonucuyla Karar Vermek

Performans testleri doğal dalgalanma gösterebilir. Arka plan süreçleri veya ağ koşulları sonucu etkileyebilir. Tek Lighthouse koşusu kesin karar için yeterli değildir. Birkaç tekrarın ortanca değerine bakmak daha sağlıklıdır. Field data ile uzun dönem eğilim ayrıca kontrol edilmelidir.

Asset Optimizasyonunda En Sık Yapılan Hatalar

Asset optimizasyonunda bazı hatalar farklı projelerde tekrar tekrar karşımıza çıkar. LCP görseline lazy loading eklemek, her dosyayı preload etmek ve tüm JavaScript'i tek bundle'a koymak bunların başında gelir. Kullanılmayan CSS ve kontrolsüz third-party scriptler de performansı zaman içinde ağırlaştırır. Cache ve asset versiyonlaması yanlış yapılandırıldığında tekrar ziyaret avantajı kaybolur. Bu hataları başlangıçta kontrol listesine eklemek birçok performans sorununu daha oluşmadan önleyebilir.

LCP Görselini Lazy-Load Etmek

LCP görseli ilk ekranda görünmesi gereken kritik bir kaynaktır. loading="lazy" ile geciktirmek genellikle yanlış sonuç verir. Görsel mümkün olduğunca erken keşfedilmelidir. Gerekliyse fetchpriority="high" test edilebilir. Sonuç waterfall ve LCP ölçümüyle doğrulanmalıdır.

Desktop Görselini Mobilde Göndermek

Masaüstü görselinin mobil cihaza gönderilmesi gereksiz transfer maliyetidir. Responsive image adayları üretilmelidir. sizes ve srcset doğru yapılandırılmalıdır. Görsel CDN bu işi otomatikleştirebilir. Mobil Network panelinde indirilen gerçek dosya boyutu kontrol edilmelidir.

Her Asset'i Preload Etmek

Preload yalnızca kritik kaynaklar için kullanılmalıdır. Her asseti preload etmek tarayıcı öncelik sistemini bozar. Bant genişliği aynı anda çok sayıda dosya arasında bölünür. LCP veya CSS gibi gerçekten önemli kaynaklar gecikebilir. Preload listesi kısa ve gerekçeli tutulmalıdır.

Çok Fazla Font Weight Yüklemek

Her font weightini ayrı dosya olarak yüklemek toplam font maliyetini artırır. Tasarımda gerçekten kullanılan ağırlıklar belirlenmelidir. Gerekirse variable font alternatifi test edilebilir. Subsetting ile karakter seti küçültülebilir. Kritik fontlar dışındaki dosyalar başlangıçta öncelik almamalıdır.

Bütün JavaScript'i Tek Bundle'a Koymak

Tek büyük bundle kullanıcıya ihtiyaç duymadığı modülleri de gönderir. İlk parse ve execution maliyeti artar. Route ve component seviyesinde splitting uygulanabilir. Ortak dependencyler verimli chunklarda tutulmalıdır. Bundle analizi sonuçları düzenli izlenmelidir.

Kullanılmayan CSS Göndermek

Büyük global stylesheetler kullanılmayan yüzlerce kural içerebilir. Bu dosyalar yine indirilmeli ve işlenmelidir. Coverage aracı sorunu görünür kılar. Component veya route bazlı CSS yaklaşımı düşünülebilir. Purge işlemleri dinamik class riskine karşı test edilmelidir.

Third-Party Scriptleri Kontrolsüz Eklemek

Her yeni widget veya analytics servisi ek performans maliyeti getirir. Harici kod ana thread üzerinde çalışabilir. Yeni entegrasyonlar review sürecinden geçmelidir. Kullanılmayan servisler düzenli olarak kaldırılmalıdır. Third-party budget bu kontrolü sistematik hale getirir.

Cache Süresini Çok Kısa Tutmak

Hashlenmiş statik assetleri kısa süre cachelemek tekrar ziyaretlerde gereksiz download yaratır. Uzun max-age daha verimli olabilir. Dosya değiştiğinde content hash URL'yi yeniler. Böylece eski sürüm problemi oluşmaz. HTML ve statik asset cache politikaları ayrı tasarlanmalıdır.

Asset Versiyonlaması Yapmamak

Dosya adı değişmeden içerik güncellenirse uzun cache kullanan ziyaretçiler eski kaynağı görebilir. Query parametreleri bazı yapılarda çözüm olabilir, ancak content hash daha güçlü yaklaşım sunar. Build sistemi hash üretimini otomatik yapmalıdır. CSS ve JavaScript referansları yeni URL'ye güncellenir. Cache busting manuel işlem olmaktan çıkar.

Önceliklendirilmiş Asset Optimizasyon Modeli

Performans çalışmasında yüzlerce öneriyi aynı anda uygulamak yerine net bir öncelik sırası kullanmak daha etkilidir. Önce gereksiz kaynak kaldırılır, sonra kritik kaynak erken keşfedilir hale getirilir. Ardından boyut, yükleme önceliği, cache ve CDN düzenlenir. Her adım ölçülür. Son aşamada gerçek kullanıcı verisiyle kazanım doğrulanır.

1. Kullanılmayan Asset'i Kaldır

Hiç kullanılmayan asset için en iyi optimizasyon onu yüklememektir. Eski script, kullanılmayan font veya gereksiz görsel tamamen kaldırılabilir. Bu yöntem transfer, CPU ve cache maliyetini birlikte azaltır. Dependency ve third-party audit ilk adım olmalıdır. Teknik ekip önce varlık envanterini temizlemelidir.

2. Kritik Asset'i Erken Keşfedilebilir Yap

LCP görseli ve kritik CSS gibi kaynaklar tarayıcı tarafından erken bulunmalıdır. Initial HTML doğrudan referans için en iyi yerlerden biridir. JavaScript aracılığıyla geç ekleme zinciri uzatabilir. Gerekirse preload veya fetchpriority test edilebilir. Ama önce doğal kaynak keşfi iyileştirilmelidir.

3. Dosya Boyutunu Küçült

Görseller sıkıştırılmalı ve doğru çözünürlükte sunulmalıdır. CSS ve JavaScript minify edilmelidir. Kullanılmayan kod kaldırılmalıdır. Fontlar subset edilebilir. Brotli gibi compression yöntemleri transfer boyutunu daha da azaltabilir.

4. Doğru Öncelikte Yükle

Her asset high priority olmamalıdır. İlk ekran kaynakları daha önce, aşağıdaki içerikler daha sonra yüklenmelidir. fetchpriority gerektiğinde kullanılabilir. Tarayıcı öncelik sistemi mümkün olduğunca korunmalıdır. Waterfall doğru sıralamayı doğrulamak için kullanılmalıdır.

5. Kritik Olmayanı Ertele

Below-the-fold görseller lazy yüklenebilir. Etkileşimle açılan modüller dynamic import ile ayrılabilir. Third-party widgetlar kullanıcı etkileşimine kadar bekletilebilir. Bu yöntem başlangıç ağ ve CPU maliyetini azaltır. Geciktirilen kaynak kullanıcı ihtiyaç duyduğunda hazır olmalıdır.

6. Cache'le

Hashlenmiş statik assetler uzun süre tarayıcı ve CDN cacheinde tutulabilir. Tekrar ziyaret performansı ciddi biçimde iyileşir. Cache-Control ve immutable gibi direktifler doğru kullanılmalıdır. HTML farklı politika izleyebilir. Cache stratejisi versiyonlama ile birlikte tasarlanmalıdır.

7. CDN'den Sun

CDN kullanıcıya yakın edge üzerinden asset teslimi yapabilir. Statik dosyalar edge cache için uygundur. Görsel CDN responsive resize ve format dönüşümü sağlayabilir. Cache hit rate izlenmelidir. Global kullanıcı kitlesinde CDN etkisi daha belirgin olabilir.

8. Gerçek Kullanıcı Verisiyle Doğrula

Laboratuvar testindeki iyileşme ilk doğrulamadır. Asıl sonuç gerçek kullanıcı verisinde görülmelidir. LCP, INP ve CLS trendleri izlenebilir. Cihaz ve bağlantı segmentleri ayrı incelenebilir. Performans çalışması ölçüm olmadan tamamlanmış sayılmamalıdır.

30 Günlük PageSpeed Asset Optimizasyon Planı

Otuz günlük plan performans çalışmasını ölçüm, uygulama ve doğrulama aşamalarına böler. İlk hafta mevcut durum çıkarılır. İkinci hafta görsel, font ve CSS üzerinde çalışılır. Üçüncü hafta JavaScript ve third-party kaynaklar ele alınır. Son hafta cache, CDN, performans bütçesi ve CI/CD kuralları kalıcı hale getirilir.

1. Hafta — Ölçüm ve Asset Audit

İlk hafta hiçbir şeyi rastgele değiştirmek yerine baseline oluşturulur. Kritik sayfalar belirlenir. Masaüstü ve mobil testler ayrı yapılır. Asset envanteri hazırlanır. En büyük darboğazlar etki sırasına göre listelenir.

Waterfall

Her kritik sayfanın waterfall çıktısı incelenir. Geç başlayan LCP kaynakları işaretlenir. Uzun request chain ve third-party bağlantılar kaydedilir. Büyük transferler ayrı listelenir. Sonraki haftalarda bu kayıt karşılaştırma noktası olur.

Page Weight

Toplam sayfa ağırlığı dosya türlerine göre ayrılır. Görsel, JavaScript, CSS ve font payları hesaplanır. Mobil ilk ziyaret temel senaryo olabilir. Büyük görseller ve bundlelar önceliklendirilir. Performans bütçesi için ilk sınırlar bu veriden çıkarılır.

Requests

Toplam request sayısı ve domain dağılımı incelenir. First-party ve third-party kaynaklar ayrılır. Gereksiz bağlantılar belirlenir. Aynı dependency veya dosyanın tekrar yüklenip yüklenmediği kontrol edilir. Kritik yol üzerindeki istekler ayrıca etiketlenir.

CWV Baseline

LCP, INP ve CLS için mevcut saha değerleri kaydedilir. Lab tarafında Lighthouse sonuçları da saklanır. Tek test yerine birkaç koşu yapılır. Cihaz ve URL türleri ayrı tutulur. Ay sonundaki karşılaştırma bu baseline üzerinden yapılır.

2. Hafta — Görsel, Font ve CSS

İkinci hafta yüksek etkili statik assetlere odaklanılır. Görseller doğru format ve çözünürlükte üretilir. Font aileleri ve weight sayıları sadeleştirilir. Critical CSS ve unused CSS çalışmaları yapılır. Değişiklikler her gün performans testiyle doğrulanır.

Image Pipeline

Görseller için otomatik sıkıştırma ve format dönüşümü kurulur. Responsive boyutlar üretilir. LCP görseli ayrı yapılandırılır. Lazy loading yalnızca uygun görsellere uygulanır. CDN veya cache başlıkları kontrol edilir.

Critical CSS

İlk ekran için gerekli stiller belirlenir. Kritik olmayan kurallar ertelenebilir. Büyük global stylesheetler analiz edilir. Coverage ile unused CSS oranı ölçülür. Görsel regresyon testleri tüm ana şablonlarda çalıştırılır.

Font Optimization

Gereksiz font aileleri ve weightler kaldırılır. WOFF2 kullanımı kontrol edilir. Subsetting ve unicode-range değerlendirilebilir. Kritik font preload sayısı minimum tutulur. Fallback metrikleri CLS açısından test edilir.

3. Hafta — JavaScript ve Third-Party

Üçüncü hafta JavaScript maliyeti ve harici scriptler hedeflenir. Bundle analyzer ile en büyük dependencyler belirlenir. Code splitting ve tree shaking uygulanır. Third-party scriptler iş değerine göre gözden geçirilir. INP ve laboratuvar TBT sonuçları değişikliklerle birlikte izlenir.

Code Splitting

Route ve component bazlı splitting fırsatları belirlenir. İlk payload içindeki kullanılmayan modüller ayrılır. Dynamic import uygulanabilecek büyük bileşenler seçilir. Chunk dağılımı bundle analyzer ile kontrol edilir. Etkileşim sonrası yükleme kullanıcıda gecikme oluşturmayacak şekilde test edilir.

Tree Shaking

ES module yapısı ve bundler ayarları incelenir. Kullanılmayan exportlar üretim bundleından çıkarılır. Duplicate dependencyler temizlenir. Gereksiz locale veya polyfill dosyaları kaldırılır. Build çıktısı önceki sürümle karşılaştırılır.

Third-Party Audit

Tüm harici scriptlerin amacı ve sahibi belirlenir. Kullanılmayan etiketler kaldırılır. Chat, harita ve video bileşenleri interaction-based loading için değerlendirilir. Consent sonrası yüklenebilecek kaynaklar ayrılır. Third-party performance budget tanımlanır.

4. Hafta — Cache, CDN ve Governance

Son hafta kazanımların kalıcı hale gelmesi hedeflenir. Cache headerları ve content hash sistemi kontrol edilir. CDN cache hit rate iyileştirilir. Performance budget CI/CD sürecine eklenir. Böylece sonraki geliştirmeler siteyi sessizce yeniden ağırlaştırmaz.

Cache Headers

Statik hashlenmiş assetlerde uzun max-age uygulanır. immutable uygun kaynaklarda kullanılabilir. HTML için farklı cache politikası tanımlanır. CDN ve browser header davranışı ayrı kontrol edilir. Repeat visit testleri yapılır.

Content Hash

CSS, JavaScript ve gerekli statik dosyalar content hash ile versiyonlanır. Değişen asset yeni URL alır. Değişmeyen dosya cache avantajını korur. Deploy manifesti otomatik güncellenir. Manuel cache busting ihtiyacı azaltılır.

Performance Budget

JavaScript, CSS, görsel ve third-party bütçeleri belirlenir. Kritik route için ayrı limitler kullanılabilir. Eşikler gerçek mevcut performans ve kullanıcı hedeflerine göre seçilir. CI raporları limit aşımını gösterir. Zaman içinde bütçeler düzenli gözden geçirilir.

CI/CD

Lighthouse CI ve bundle diff kontrolleri pipeline'a eklenir. Kritik regresyonlar build'i durdurabilir. Küçük sapmalar warning olarak raporlanabilir. Görsel ve asset boyutu kontrolleri otomatikleştirilir. Performans sürekli kalite kriteri haline gelir.

Asset Optimizasyonu Kontrol Listesi

Sayfa Yükleme Hızı (Pagespeed) İçin Varlık (Asset) Optimizasyonu düzenli kontrol edildiğinde performans sorunlarının tekrar oluşma ihtimali azalır. Kontrol listesi görsel, font, CSS, JavaScript, cache ve CDN gibi temel alanları birlikte kapsamalıdır. Her madde gerçek test çıktısıyla doğrulanmalıdır. Yalnızca ayarın açık olması yeterli değildir. Son kullanıcı metriğinde iyileşme görülmesi hedeflenmelidir.

Görseller

Görseller doğru çözünürlükte sunulmalıdır. WebP veya AVIF uygun içeriklerde değerlendirilmelidir. srcset ve sizes doğru olmalıdır. LCP görseli lazy yüklenmemelidir. Below-the-fold görseller için lazy loading kullanılabilir.

Fontlar

Gereksiz font aileleri kaldırılmalıdır. Kullanılmayan weight dosyaları yüklenmemelidir. WOFF2 ve subsetting değerlendirilebilir. Kritik font preload sayısı sınırlı tutulmalıdır. Fallback metrikleri CLS açısından test edilmelidir.

CSS

Unused CSS oranı ölçülmelidir. Critical CSS ihtiyacı değerlendirilmelidir. Büyük global stylesheetler bölünebilir. Minification ve Brotli etkin olmalıdır. @import kaynak zincirleri azaltılmalıdır.

JavaScript

Başlangıç bundle boyutu takip edilmelidir. Kullanılmayan dependencyler kaldırılmalıdır. Tree shaking ve code splitting uygulanmalıdır. async ve defer doğru scriptlerde kullanılmalıdır. Long task ve INP etkisi ölçülmelidir.

Third-Party

Her third-party kaynağın iş amacı belli olmalıdır. Kullanılmayan servisler kaldırılmalıdır. Interaction-based loading uygun bileşenlerde uygulanmalıdır. CPU time ve request sayısı ölçülmelidir. Yeni entegrasyonlar review sürecinden geçmelidir.

Video

GIF yerine video seçeneği değerlendirilmelidir. Video player ilk ekranda gerekli değilse lazy yüklenebilir. Poster görseli optimize edilmelidir. Büyük medya dosyaları CDN üzerinden sunulabilir. Kullanıcı etkileşimine kadar medya akışı bekletilebilir.

Resource Priority

LCP asseti erken keşfedilmelidir. Gereksiz preload kayıtları kaldırılmalıdır. fetchpriority yalnızca uygun kaynaklarda kullanılmalıdır. Kritik origin için sınırlı preconnect düşünülebilir. Waterfall kaynak önceliğini doğrulamak için incelenmelidir.

Cache

Hashlenmiş statik assetler uzun süre cachelenmelidir. Cache-Control headerları kontrol edilmelidir. immutable uygun dosyalarda kullanılabilir. HTML farklı cache politikası izlemelidir. Repeat visit testi ayrıca yapılmalıdır.

CDN

Statik assetler edge cache üzerinden sunulabilir. Cache hit rate takip edilmelidir. Origin request sayısı incelenmelidir. Görsel CDN format ve resize işlemlerini otomatikleştirebilir. Global kullanıcılar için bölgesel performans ölçülmelidir.

Compression

HTML, CSS, JavaScript ve SVG sıkıştırılmalıdır. Brotli mümkün olduğunda değerlendirilebilir. GZIP fallback olarak kullanılabilir. Zaten sıkıştırılmış görsel ve videolara gereksiz HTTP compression uygulanmamalıdır. Gerçek response headerları kontrol edilmelidir.

Performance Budget

JavaScript, CSS, görsel ve font bütçeleri tanımlanmalıdır. Third-party için ayrı limit bulunmalıdır. Kritik route eşikleri CI/CD sistemine bağlanmalıdır. Regresyon olduğunda ekip otomatik bilgilendirilmelidir. Bütçeler ürün ihtiyaçları değiştikçe güncellenmelidir.

Monitoring

Lighthouse ve sentetik testler düzenli çalıştırılmalıdır. CrUX veya başka field data kaynakları izlenmelidir. Real User Monitoring uygun projelerde kurulabilir. LCP, INP ve CLS trendleri takip edilmelidir. Performans değişiklikleri release kayıtlarıyla ilişkilendirilmelidir.

Sıkça Sorulan Sorular

Asset optimizasyonuyla ilgili sorular çoğu zaman tek bir teknik ayara cevap arıyor gibi görünür. Oysa gerçek performans sonucu ağ, tarayıcı, içerik ve kullanıcı davranışının ortak etkisidir. Bu nedenle aşağıdaki yanıtlar tek başına kural değil başlangıç çerçevesi olarak görülmelidir. Her değişiklik gerçek sayfanızda ölçülmelidir. Kurumsal web sitesi PageSpeed ve Core Web Vitals optimizasyon hizmeti alırken de raporun yalnızca skoru değil bu teknik nedenleri açıklamasına dikkat edilmelidir.

Asset optimizasyonu nedir?

Asset optimizasyonu web sayfasında kullanılan görsel, CSS, JavaScript, font, video ve benzeri kaynakların daha verimli sunulmasıdır. Amaç dosyaları yalnızca küçültmek değildir. Gereksiz kaynaklar kaldırılır, kritik dosyalar erken yüklenir ve diğerleri ertelenir. Cache ve CDN stratejisi de sürece dahildir. Sonuç LCP, INP, CLS ve gerçek kullanıcı verisiyle ölçülmelidir.

PageSpeed skoru kaç olmalıdır?

PageSpeed skoru tek başına kullanıcı deneyimini tanımlamaz. Yüksek skor elbette olumlu bir sinyal olabilir. Ancak LCP, INP, CLS ve gerçek kullanıcı verisi daha ayrıntılı bilgi sağlar. Hedef yalnızca belirli bir sayı değil istikrarlı ve hızlı kullanıcı deneyimi olmalıdır. Tek test yerine zaman içindeki eğilim değerlendirilmelidir.

PageSpeed 100 olmak zorunda mıdır?

Hayır, PageSpeed skorunun mutlaka 100 olması gerekmez. Kullanıcı deneyimini bozmadan yüksek performans sağlamak daha önemlidir. Bir işlevi sırf puan yükselsin diye kaldırmak doğru değildir. Gerçek kullanıcı metrikleri ve iş hedefleri birlikte değerlendirilmelidir. 100 puanı sonuç değil olası bir laboratuvar göstergesi olarak görmek gerekir.

Site hızını en çok hangi dosyalar etkiler?

Bu cevap sayfadan sayfaya değişir. Büyük hero görseli LCP'yi etkileyebilir. Ağır JavaScript INP ve TBT üzerinde baskı oluşturabilir. Büyük font veya render-blocking CSS ilk görünümü geciktirebilir. En doğru cevap waterfall, Coverage ve Performance analiziyle bulunur.

WebP mi AVIF mi daha hızlıdır?

Dosya boyutu açısından AVIF bazı görsellerde daha avantajlı olabilir. WebP ise geniş kullanım ve encode hızı açısından pratik bir seçenektir. Her görselde aynı format kazanmaz. Gerçek görseller kalite ve dosya boyutu açısından karşılaştırılmalıdır. Format seçimi responsive boyutlandırma ve cache stratejisiyle birlikte düşünülmelidir.

LCP görseline lazy loading uygulanır mı?

LCP görseli ilk ekranda yer alıyorsa genellikle lazy loading uygulanmamalıdır. Kaynak mümkün olduğunca erken keşfedilmelidir. loading="lazy" indirme başlangıcını geciktirebilir. Gerekirse fetchpriority="high" ve preload seçenekleri test edilebilir. Öncesi ve sonrası LCP ölçümü yapılmalıdır.

fetchpriority="high" ne zaman kullanılmalıdır?

fetchpriority="high" gerçekten kritik ve erken yüklenmesi gereken kaynağın önceliğini artırmak için kullanılabilir. En yaygın aday LCP görselidir. Aynı sayfadaki birçok kaynağa high vermek doğru değildir. Priority competition kritik dosyayı yavaşlatabilir. Kullanım waterfall ve gerçek metriklerle doğrulanmalıdır.

CSS ve JavaScript dosyaları birleştirilmeli midir?

Modern HTTP/2 ve HTTP/3 ortamında her şeyi tek dosyada birleştirmek zorunlu değildir. Büyük tek bundle başlangıçta gereksiz kod gönderebilir. Route ve component bazlı splitting çoğu uygulamada daha etkili olabilir. Çok fazla küçük dosya da kontrolsüz bırakılmamalıdır. Karar cache, request ve kullanım desenine göre verilmelidir.

Kullanılmayan JavaScript nasıl bulunur?

Chrome Coverage ve bundle analyzer başlangıç için iyi araçlardır. Dependency audit ile kullanılmayan paketler belirlenebilir. Duplicate dependency ve gereksiz polyfilller kontrol edilmelidir. Dynamic kullanım nedeniyle raporlar tüm kullanıcı akışlarında test edilmelidir. Kullanılmayan kod kaldırıldıktan sonra bundle ve execution süresi tekrar ölçülmelidir.

Critical CSS nedir?

Critical CSS ilk viewport'u doğru göstermek için gereken minimum stil kümesidir. Bu stiller erken erişilebilir hale getirilebilir. Geri kalan CSS daha sonra yüklenebilir. Fazla inline CSS HTML boyutunu büyütebilir. Uygulama responsive tasarım ve dinamik bileşenlerle birlikte test edilmelidir.

Fontlar sayfa hızını nasıl etkiler?

Fontlar ek ağ istekleri ve render gecikmesi oluşturabilir. Çok sayıda aile veya weight toplam transferi artırır. Font swap sırasında metin ölçüleri değişirse CLS oluşabilir. WOFF2, subsetting ve doğru font-display kullanımı yardımcı olur. Kritik fontları sınırlı sayıda önceliklendirmek gerekir.

WOFF2 neden tercih edilir?

WOFF2 web fontları için verimli bir sıkıştırılmış formattır. Modern tarayıcılarda geniş biçimde kullanılabilir. Eski font formatlarına göre daha düşük transfer boyutu sağlayabilir. Yine de dosyanın karakter seti ve weight kapsamı optimize edilmelidir. Format tek başına gereksiz font yükünü çözmez.

CDN site hızını artırır mı?

CDN özellikle coğrafi olarak dağılmış kullanıcı kitlesinde asset gecikmesini azaltabilir. Statik dosyalar kullanıcıya yakın edge noktasından sunulur. Cache hit rate yüksekse origin yükü de azalır. Görsel dönüşümü ve compression gibi ek avantajlar sağlanabilir. Gerçek performans etkisi farklı bölgelerden yapılan ölçümlerle doğrulanmalıdır.

Brotli ile GZIP arasındaki fark nedir?

Her ikisi de metin tabanlı içeriklerin transfer boyutunu azaltmak için kullanılan sıkıştırma yöntemidir. Brotli çoğu statik web assetinde daha iyi sıkıştırma sağlayabilir. GZIP ise çok geniş uyumluluğa sahiptir. Sunucu istemci desteğine göre uygun encoding sunabilir. Statik dosyalar build veya CDN aşamasında önceden sıkıştırılabilir.

Statik asset'ler ne kadar süre cache'lenmelidir?

Content hash içeren ve URL'si içerik değişiminde yenilenen statik assetler uzun süre cachelenebilir. Bir yıl gibi uzun max-age değerleri bu modelde kullanılabilir. Ancak aynı URL altında içerik değiştiriliyorsa bu kadar uzun süre sorun yaratır. HTML için genellikle daha farklı cache politikası gerekir. Cache kararı deploy ve versiyonlama mimarisiyle birlikte verilmelidir.

Performance budget nedir?

Performance budget bir sayfanın kabul edilebilir dosya boyutu, request veya metrik sınırlarını tanımlar. JavaScript, CSS ve görseller için ayrı limitler belirlenebilir. CI/CD bu limitleri otomatik kontrol edebilir. Yeni geliştirme bütçeyi aşarsa uyarı veya build failure oluşturulabilir. Böylece performans zaman içinde kontrolsüz kötüleşmez.

PageSpeed optimizasyonunun işe yaradığı nasıl doğrulanır?

Önce değişiklik öncesi baseline kaydedilir. Sonra Lighthouse ve waterfall gibi lab testleri karşılaştırılır. LCP, INP ve CLS gibi gerçek kullanıcı metriklerinin eğilimi izlenir. Transfer size ve request sayısı gibi teknik değerler de kontrol edilir. Başarı yalnızca skor artışıyla değil gerçek kullanıcı deneyimindeki iyileşmeyle doğrulanmalıdır.

Ek Sıkça Sorulan Sorular

Aşağıdaki sorular uygulama aşamasında en fazla karşılaşılan teknik konuları daha doğrudan ele alır. Yanıtların temel amacı geliştirici, işletme sahibi ve teknik SEO ekibinin aynı performans hedefinde buluşmasını sağlamaktır. Her site farklı teknoloji ve kullanıcı kitlesine sahip olduğu için ölçüm yapılmadan kesin sonuç çıkarılmamalıdır. Özellikle kurumsal projelerde PageSpeed ve asset optimizasyonu tek seferlik düzenleme yerine sürekli izlenen bir süreç olmalıdır. Diyarbakır Yazılım Topluluğu'nun proje yaklaşımını incelemek için https://www.diyarbakiryazilim.com.tr/projects adresine göz atabilirsiniz.

Sayfa yükleme hızını artırmak için CSS, JavaScript, görsel ve font gibi varlıklar (asset) nasıl optimize edilir?

Önce asset envanteri çıkarılmalı ve kullanılmayan kaynaklar kaldırılmalıdır. Görseller responsive boyutlarda, uygun WebP veya AVIF varyantlarıyla ve doğru lazy loading stratejisiyle sunulmalıdır. CSS tarafında unused rules azaltılmalı, kritik stiller öne alınmalı ve JavaScript tarafında code splitting ile başlangıç payloadı küçültülmelidir. Font aileleri ve weight sayıları sınırlanmalı, WOFF2 ve subsetting kullanılmalıdır. Son olarak cache, CDN ve Brotli yapılandırması tamamlanıp sonuç LCP, INP ve CLS ile ölçülmelidir.

PageSpeed Insights’ta render-blocking ve kullanılmayan CSS/JavaScript sorunları nasıl çözülür?

İlk adım hangi dosyanın gerçekten kritik olduğunu belirlemektir. CSS için Coverage ile kullanılmayan kurallar incelenebilir ve ilk viewport dışındaki stiller geciktirilebilir. JavaScript için dependency audit, tree shaking, dynamic import ve defer seçenekleri değerlendirilir. Render-blocking uyarısındaki her dosyayı otomatik olarak geciktirmek doğru değildir. Uygulama sonrasında görsel bütünlük ve kullanıcı etkileşimleri gerçek cihazlarda test edilmelidir.

WebP ve AVIF görsel formatları, lazy loading ve responsive images sayfa hızını nasıl etkiler?

WebP ve AVIF uygun görsellerde transfer boyutunu azaltabilir. Responsive images mobil kullanıcıya gereksiz büyük masaüstü dosyasının gönderilmesini önler. Lazy loading ilk ekranın dışındaki medya kaynaklarını geciktirerek başlangıç ağ yükünü düşürür. LCP görselinde ise lazy loading kullanılmamalıdır. Bu üç yaklaşım birlikte uygulandığında görsel ağırlığı, LCP ve mobil veri tüketimi açısından güçlü kazanımlar sağlanabilir.

CDN, tarayıcı önbellekleme, dosya sıkıştırma ve minification PageSpeed performansını nasıl iyileştirir?

CDN assetleri kullanıcıya yakın edge noktasından sunarak ağ gecikmesini azaltabilir. Browser cache tekrar ziyaretlerde aynı CSS, JavaScript, font ve görsellerin yeniden indirilmesini önler. Brotli veya GZIP metin tabanlı dosyaların transfer boyutunu küçültür. Minification CSS ve JavaScript içindeki gereksiz biçimlendirme karakterlerini kaldırır. Bu tekniklerin her biri farklı performans katmanını hedeflediği için birlikte kullanıldığında daha güçlü sonuç verir.

PageSpeed ve asset optimizasyonu için yakınımda teknik SEO danışmanlığı nerede bulabilirim?

PageSpeed ve web performans optimizasyonu danışmanlığı yakınımda şeklinde arama yaparken yalnızca bir skor raporu sunan hizmet yerine teknik nedenleri açıklayan çalışma modeline odaklanmanız daha faydalıdır. İyi bir süreç asset envanteri, waterfall analizi, Core Web Vitals incelemesi, JavaScript ve CSS audit, görsel pipeline, cache ve CDN yapılandırmasını birlikte değerlendirmelidir. Kurumsal web sitesi PageSpeed ve Core Web Vitals optimizasyon hizmeti kapsamında uygulama sonrası gerçek kullanıcı verisi de izlenmelidir. Diyarbakır Yazılım Topluluğu hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresini ziyaret edebilirsiniz. Böylece yalnızca teorik tavsiye değil ölçülebilir ve sürdürülebilir performans yaklaşımı hakkında bilgi edinebilirsiniz.

Sonuç

Sayfa Yükleme Hızı (Pagespeed) İçin Varlık (Asset) Optimizasyonu, birkaç dosyayı sıkıştırıp PageSpeed skorunu yükseltmekten çok daha kapsamlı bir performans disiplinidir. Başarılı bir çalışma gereksiz assetleri kaldırır, kritik kaynakların keşfedilme zamanını iyileştirir, görselleri ve fontları doğru biçimde sunar, JavaScript ana thread maliyetini azaltır ve cache ile CDN katmanlarını düzenler. Benim yıllar içinde en çok gördüğüm başarı modeli, her değişikliği ölçen ve performans bütçesini CI/CD sürecine bağlayan ekiplerde ortaya çıkıyor. Sitenizin yalnızca laboratuvar testlerinde değil gerçek kullanıcı koşullarında da hızlı hissettirmesini istiyorsanız LCP, INP, CLS, transfer size ve third-party CPU time değerlerini birlikte izleyin. Teknik performans, SEO ve sürdürülebilir web geliştirme konusunda Diyarbakır Yazılım Topluluğu'na ulaşmak için https://www.diyarbakiryazilim.com.tr adresini kullanabilirsiniz.