Web Sitesi Nasıl Hızlandırılır? Core Web Vitals ve Performans Rehberi

Kullanılabilecek araçlar:

• PageSpeed Insights
• Chrome DevTools Lighthouse
• Search Console Core Web Vitals
• Chrome UX Report / field data
• WebPageTest

Lab data: Kontrollü test ortamı.

Field data: Gerçek kullanıcı deneyimi.

İkisini karıştırmayın. Lab testi debug için, field data gerçek kullanıcıları anlamak için değerlidir.

Güncel üç ana metrik:

Bu eşikler genellikle kullanıcı deneyiminin 75. yüzdelik dilimi üzerinden değerlendirilir.

Frontend optimizasyonu yapmadan önce backend yavaş mı kontrol edin. Nedenler:

• Zayıf hosting
• Ağır veritabanı
• Cache yok
• Çok fazla plugin
• API gecikmesi
• Dinamik render maliyeti

WordPress’te full-page cache ciddi fark yaratabilir. Statik sitelerde edge/CDN mimarisi avantaj sağlayabilir.

En sık hız problemi görseldir. Kontrol:

• Gerçek görüntü boyutu
• Dosya boyutu
• WebP/AVIF
• Responsive srcset
• Width/height
• Lazy loading
• Hero preload gereksinimi

300px alanda 4000px JPEG yüklemeyin.

Hero görseli lazy-load edilir mi?

Genellikle LCP öğesi hero ise lazy-load etmek gecikmeye yol açabilir. Kritik görsel önceliklendirilmeli; sayfanın aşağısındaki görseller lazy-load edilebilir.

Ağır JavaScript; parse, compile, main-thread ve hydration maliyeti oluşturabilir. Sorular:

• Bu library gerçekten gerekli mi?
• Tüm sayfada mı yükleniyor?
• Code splitting var mı?
• Üçüncü taraf script geciktirilebilir mi?
• Component hydration azaltılabilir mi?

Animasyon için 100 KB gereken yerde 500 KB framework taşımak gereksiz olabilir.

• Kullanılmayan CSS azaltın.
• Kritik stilleri önceliklendirin.
• Render-blocking kaynakları analiz edin.
• Dev CSS framework çıktısını purge/minify edin.

Ama “her şeyi inline” yapmak da çözüm değildir; cache avantajını kaybedebilirsiniz.

Font problemleri:

• Çok fazla weight
• Çok fazla family
• Harici sunucu gecikmesi
• FOIT/FOUT
• CLS

Çözüm:

• Gerekli weight’leri kullan
• WOFF2
• Subset
• preload yalnız kritik font
• font-display
• fallback metric ayarı

Cache katmanları:

• Browser cache
• CDN cache
• Application cache
• Page cache
• Object cache

Statik asset’lerde uzun cache süresi ve hashed filename verimli olabilir.

Dinamik HTML’de yanlış cache kullanıcıya eski içerik gösterebilir. Strateji kaynak türüne göre yapılmalıdır.

CDN:

• Asset’i yakın noktadan sunabilir.
• Cache sağlayabilir.
• TLS/edge optimizasyonu sağlayabilir.

Ama CDN:

• Şişkin JS’i küçültmez.
• Kötü görseli otomatik düzeltmez.
• Yavaş origin problemini her durumda çözmez.

Cloudflare iyi bir katmandır; optimizasyonun yerine geçmez.

En büyük performans katilleri:

• Çoklu chat widget
• Heatmap
• Reklam
• Sosyal embed
• A/B test
• Eski tracking scriptleri

Her üçüncü taraf için “Bu script iş değeri üretiyor mu?” sorusunu sorun.

Aşırı page builder yapısı div > div > div > div > div şeklinde büyüyebilir.

Büyük DOM:

• Style calculation
• Layout
• Memory

maliyetini artırır. Gereksiz wrapper’ları azaltın.

• Görsellere width/height
• Reklam alanına rezerv
• Geç yüklenen banner için alan
• Font fallback
• Dinamik içeriği mevcut içeriğin üstüne eklememe
• Cookie bar davranışı

Sayfa açılırken butonun yer değiştirmesi kullanıcıyı doğrudan rahatsız eder.

• Uzun main-thread task’leri böl
• Ağır handler’ları azalt
• Gereksiz re-render
• Third-party JS azalt
• Input event’lerinde ağır iş yapma
• Worker değerlendir

INP kullanıcı tıklamasının hissedilen cevabını temsil eder.

LCP öğesini bulun.

Eğer hero image:

• optimize
• doğru size
• preload/fetchpriority
• CDN

Eğer text:

• kritik font
• render-blocking CSS
• server response

Önce LCP öğesinin ne olduğunu tespit edin.

Özel kontrol listesi:

• Güncel PHP
• Kaliteli hosting
• Full-page cache
• Object cache gerekiyorsa
• Görsel optimizasyonu
• Plugin denetimi
• Database cleanup
• Cron
• WooCommerce sorguları
• Tema/page builder yükü

“10 hız eklentisi” yüklemek optimizasyon değildir; bazen birbirleriyle çakışırlar.

Premium etkileşimli sitelerde:

• Model poligon sayısı
• Texture boyutu
• Shader
• Pixel ratio
• Device capability
• Lazy init
• Reduced motion
• Fallback

planlanmalıdır. Her cihazda masaüstü GPU performansını varsaymayın.

Örnek bütçe:

• JS < belirli hedef
• Hero < belirli KB
• Font sayısı
• Third-party sayısı
• LCP hedefi

Bütçe proje başında belirlenirse tasarım kararları daha bilinçli olur.

Hız tek başına sizi ilk sıraya çıkarmaz. Ama:

• Kötü kullanıcı deneyimi
• Mobil sürtünme
• Crawl verimsizliği
• Düşük dönüşüm

yaratabilir. Performansı SEO sisteminin destekleyici bir bileşeni olarak görün.

• Field data kontrol
• LCP öğesi tespit
• INP uzun task analizi
• CLS kaynakları
• Görseller
• JS
• CSS
• Font
• Cache
• CDN
• Third-party
• Mobil test
• Dönüşüm kontrol