2 Saniyenin Altında Yüklemek İçin 14 Web Sitesi Hız Optimizasyon Tekniği

2 saniyenin altında yüklenen bir web sitesi, 4 saniye süren bir siteden ölçülebilir şekilde daha iyi dönüşüm sağlar. Bu bir teori değil. Google'ın kendi verileri mobilde bir saniyelik gecikmenin dönüşümleri %20 azaltabildiğini gösteriyor. Portent araştırması ise her ek saniye için %4.42'lik bir düşüş olduğunu ortaya koyuyor.

Çoğu web sitesi hız optimizasyonu rehberinin sorunu "neden hız önemlidir" noktasında kalması. Zaten önemli olduğunu biliyorsunuz. İhtiyacınız olan şey, neyin hangi sırayla düzeltileceğine dair adım adım bir liste.

Bu rehber, sitenizi 2 saniyenin altında yüklemek için 14 spesifik tekniği kapsıyor. Her biri somut adımlar, gerektiğinde kod örnekleri ve beklenen iş etkisi içeriyor. Yeni bir site yapıyor olsanız da mevcut bir siteyi optimize ediyor olsanız da, bunlar Vezert'te her projede web sitesi performansını artırmak için kullandığımız aynı adımlar.

Hız ve dönüşümler yakından bağlantılı, veriler net:

• Amazon, her 100ms gecikmenin satışları %1 kaybettirdiğini tespit etti.
• Walmart, her 1 saniyelik yükleme süresi iyileştirmesi için %2 dönüşüm artışı gördü.
• Portent çalışması 20 sektörde her ek saniye için ortalama %4.42 dönüşüm düşüşü ölçtü.

Hız aynı zamanda SEO'yu doğrudan etkiler. Google Core Web Vitals (LCP, CLS, INP) değerlerini sıralama sinyali olarak kullanıyor. Yavaş bir site sadece ziyaretçi kaybetmiyor, arama görünürlüğünü de kaybediyor. SEO ve web sitesi geliştirme artık ayrı konuşmalar değil.

Sonuç: sayfa yükleme süresi ve dönüşüm oranı birlikte hareket eder. Bu rehberdeki her teknik sadece teknik performans değil, iş için ne yaptığı açısından değerlendirilir.

Herhangi bir şeyi optimize etmeden önce bir temel değere ihtiyacınız var. İşte en net resmi veren araçlar:

Google PageSpeed Insights (pagespeed.web.dev) gerçek kullanıcılardan (saha verisi) ve laboratuvar testlerinden Core Web Vitals verisi sağlar. Bu, sıralama için Google'ın gerçekten ne ölçtüğünü gösterdiği için en önemli araçtır.

Lighthouse (Chrome DevTools'a yerleşik, Audits sekmesi altında) spesifik önerilerle detaylı performans denetimleri yapar. DevTools'u açın, Lighthouse paneline gidin ve mobil performans testi çalıştırın.

WebPageTest (webpagetest.org) sayfa yüklemesi sırasında zamanın tam olarak nerede harcandığını gösteren waterfall grafikleri oluşturur. Spesifik darboğazları teşhis etmek için kullanışlıdır.

GTmetrix (gtmetrix.com) Lighthouse verilerini görsel bir zaman çizelgesi ve geçmiş takibi ile birleştirir.

İzlenecek Temel Metrikler

• LCP (Largest Contentful Paint): Ana içeriğin ne zaman görünür hale geldiği. Hedef: 2.5 saniyenin altında.
• CLS (Cumulative Layout Shift): Sayfanın yüklenme sırasında ne kadar kaydığı. Hedef: 0.1'in altında.
• INP (Interaction to Next Paint): Sayfanın tıklamalara ne kadar hızlı yanıt verdiği. Hedef: 200ms altında.
• TTFB (Time to First Byte): Sunucunun ne kadar hızlı yanıt verdiği. Hedef: 800ms altında.

Bu testleri hem mobil hem masaüstünde çalıştırın. Mobil, Google'ın sıralama için öncelikli olarak kullandığı alandır ve çoğu hız problemi burada ortaya çıkar.

İşte rakamlarınızın ulaşması gereken yerler. Herhangi bir metrik "Zayıf" sütununa düşerse, bu en yüksek öncelikli düzeltmenizdir.

Bu teknikler kabaca etkiye göre sıralanmıştır. En üstten başlayarak ilerleyin. Her biri ne yapılacağını, nasıl yapılacağını ve alt satırınız için ne anlama geldiğini içerir.

Görseller genellikle sayfa ağırlığının en büyük parçasıdır. Ortalama bir web sayfasında, HTTP Archive verilerine göre toplam baytın %40'ından fazlasını oluştururlar.

Çözüm basit:

• Görselleri WebP veya AVIF formatına dönüştürün; aynı kalitede JPEG/Png'den %25-50 daha küçüktür.
• Mobil kullanıcıların masaüstü boyutlarındaki dosyaları indirmemesi için srcset kullanarak responsive görseller sunun.
• Düzen kaymalarını önlemek (CLS'yi iyileştirmek) için açık width ve height özellikleri belirleyin.
• Agresif sıkıştırma yapın. Çoğu görsel görünür fark olmadan %40-60 dosya boyutu kaybedebilir.

<img
  src="/hero.webp"
  srcset="/hero-480.webp 480w, /hero-800.webp 800w, /hero-1200.webp 1200w"
  sizes="(max-width: 800px) 100vw, 1200px"
  width="1200" height="630"
  alt="Ürün ekran görüntüsü"
  loading="lazy"
/>

İş etkisi: Görsel optimizasyonu tek başına tipik olarak sayfa ağırlığını %30-50 azaltır; bu doğrudan LCP ve toplam yükleme süresini iyileştirir. Hero görselinin LCP elementi olduğu landing sayfaları için bu genellikle tek en büyük kazançtır.

Dönen bir ziyaretçi sitenizi yüklediğinde, tarayıcı önbelleği varlıkların yeniden indirilip indirilmeyeceğini belirler. Doğru cache header'ları olmadan, her ziyaret ilk ziyaret gibidir.

Statik varlıklarda Cache-Control header'larını ayarlayın:

# Statik varlıklar (görseller, fontlar, JS, CSS)
Cache-Control: public, max-age=31536000, immutable

# HTML sayfaları
Cache-Control: public, max-age=0, must-revalidate

immutable flag'i tarayıcılara sürümlü dosyalarda güncelleme kontrolü bile yapmamasını söyler. HTML için, kullanıcıların her zaman taze içerik alması için must-revalidate kullanın; varlıklar önbellekte kalırken.

Vezert'te kullandığımız Next.js gibi bir framework kullanıyorsanız, statik varlıklar varsayılan olarak içerik-hash dosya adları alır; bu da uzun önbellek sürelerini güvenli kılar.

İş etkisi: Tarayıcı önbelleği, tekrar sayfa yüklemelerini %80 daha hızlı yapabilir. Kullanıcıların oturum başına birden fazla sayfa ziyaret ettiği kurumsal web siteleri veya web portalları için bu, farkedilir şekilde daha akıcı bir deneyime dönüşür.

Bir içerik dağıtım ağı, sitenizi dünya çapındaki sunucularda önbelleğe alır; böylece kullanıcılar en yakın konumdan sunulur. CDN olmadan, Tokyo'daki bir ziyaretçi her istek için Virginia'daki sunucuya gidiş-dönüş yapar.

Popüler seçenekler:

• Vercel Edge Network (Next.js deployment'larıyla yerleşik)
• Cloudflare (ücretsiz katmanı çoğu siteyi kapsar)
• AWS CloudFront (özel altyapı için)

Bir CDN, kaynak sunucunuzdan uzak kullanıcılar için gecikmeyi %50-70 azaltır. Ayrıca web host'unuzdan trafiği alır; bu da yük altında daha iyi performans demektir.

Birden fazla bölgede kullanıcısı olan uluslararası siteler için CDN opsiyonel değildir. Küresel bir kitle için 2 saniyenin altında tutarlı web sitesi yükleme hızı elde etmenin tek yoludur.

İş etkisi: CDN deployment'ı uzak kullanıcılar için TTFB'yi tipik olarak 100-300ms azaltır. Siteniz birden fazla ülkeye hizmet veriyorsa, bu genellikle "İyi" ve "Geliştirilmeli" TTFB skoru arasındaki farktır.

Minifikasyon, CSS ve JavaScript dosyalarınızdan boşluk, yorum ve gereksiz karakterleri temizler. Kodun ne yaptığını değiştirmez, sadece dosyaları daha küçük yapar.

Modern build araçları bunu otomatik olarak halleder:

• Next.js / Webpack / Vite: üretim build'lerinde minifikasyon varsayılan olarak açıktır.
• Bağımsız CSS: cssnano veya lightningcss kullanın.
• Bağımsız JS: terser veya esbuild.

Build aracı kullanmıyorsanız, Minifier.org gibi online araçlar tek seferlik dosyalar için çalışır.

İş etkisi: Minifikasyon tipik olarak dosya boyutlarını %10-20 azaltır. Tek başına mütevazı geliyor, ama sıkıştırmayla (teknik 8) birleşince etki çoğalır. Her kilobyte mobil bağlantılarda önemlidir.

Render-blocking CSS ve JavaScript, tarayıcının indirmeyi ve çalıştırmayı bitirene kadar herhangi bir şey çizmesini engeller. Bu, yüksek LCP skorunun en yaygın nedenlerinden biridir.

Çözümler:

• Kritik CSS'i doğrudan <head> içine inline yapın; böylece ilk boyama harici bir stylesheet için beklemez.
• Kritik olmayan CSS'i media="print" onload="this.media='all'" kullanarak erteleyin.
• Script tag'lerine async veya defer ekleyin; böylece JavaScript rendering'i engellemez.

<!-- Kritik olmayan CSS'i ertele -->
<link rel="stylesheet" href="/non-critical.css" media="print" onload="this.media='all'">

<!-- JavaScript'i ertele -->
<script src="/analytics.js" defer></script>

Lighthouse render-blocking kaynakları spesifik olarak işaretler. Denetiminizi açın, "Eliminate render-blocking resources" fırsatına bakın ve listelenen dosyalarda çalışın.

İş etkisi: Render-blocking kaynakları kaldırmak First Contentful Paint'i 1-3 saniye iyileştirebilir; bu, kullanıcıların anlamlı içeriği ne kadar hızlı gördüğünü doğrudan hızlandırır. Bu, güçlü ilk izlenim bırakması gereken kaliteli web siteleri için kritiktir.

Lazy loading, katlanın altındaki görselleri ve videoları kullanıcı onlara kaydırana kadar erteler. Bu, tarayıcının sadece hemen görünür olanı indirmesi anlamına gelir; ilk sayfa ağırlığını önemli ölçüde keser.

En basit yaklaşım yerel loading="lazy" özelliğidir:

<img src="/team-photo.webp" loading="lazy" width="800" height="600" alt="Takım fotoğrafı" />

Hero görselini veya katlanın üstündeki herhangi bir içeriği lazy-load ETMEYİN. Bunlar genellikle LCP elementi olduğu için hemen yüklenmelidir (loading="eager" kullanın veya özelliği atlayın).

Daha fazla kontrol için, elementler görünür alana girdiğinde yükleme tetiklemek üzere Intersection Observer API kullanın.

İş etkisi: Lazy loading tipik olarak ilk sayfa ağırlığını %30-40 azaltır. Bloglar veya portfolyo sayfaları gibi içerik ağırlıklı sayfalar için tasarruf daha da büyüktür çünkü çoğu görsel katlanın altındadır.

TTFB (Time to First Byte), sunucunun yanıt vermeye başlamasının ne kadar sürdüğünü ölçer. Diğer her şey, rendering, görseller, scriptler buna bağlıdır. TTFB yavaşsa, başka hiçbir şey telafi edemez.

Yaygın nedenler ve çözümler:

• Yavaş web host: Ucuz paylaşımlı hosting genellikle 1 saniyenin üzerinde TTFB'ye sahiptir. Yönetilen bir sağlayıcıya veya edge deployment'a (Vercel, Netlify, Cloudflare Pages) geçin.
• Optimize edilmemiş veritabanı sorguları: Yavaş sorguları profilleyin, indeksler ekleyin, sık okunanları önbelleğe alın.
• Sunucu tarafı önbellek yok: Dinamik içerik için Redis veya Memcached ekleyin. Statik siteler için build zamanında önceden render edin.
• CDN eksikliği: Teknik 3'e bakın.

web.dev verilerine göre, 800ms altında TTFB hedeftir. 200ms altı statik hosting veya edge fonksiyonlarıyla elde edilir.

İş etkisi: TTFB her tek sayfa yüklemesini etkiler. Bunu 1.5s'den 300ms'ye düşürmek diğer her şey için 1 saniyeden fazla boşluk sağlar; bu genellikle 2 saniyenin altında yüklenmekle yüklenmemek arasındaki farktır.

Metin tabanlı dosyalar (HTML, CSS, JavaScript, JSON, SVG) çok iyi sıkıştırılır. Gzip boyutlarını %60-80 azaltır. Brotli, daha yeni alternatif, Gzip'ten %15-20 daha iyi sıkıştırır.

Çoğu hosting sağlayıcısı ve CDN Gzip'i varsayılan olarak etkinleştirir. Brotli HTTPS gerektirir ve özel sunucularda açık yapılandırma gerektirebilir.

Doğrulamak için: Chrome DevTools'u açın, Network sekmesine gidin ve yanıtlarınızdaki Content-Encoding header'ını kontrol edin. br (Brotli) veya gzip görmelisiniz.

İş etkisi: Sıkıştırma etkin değilse, gerekenden 3-5 kat daha büyük dosyalar sunuyorsunuz. Bu, özellikle JavaScript-ağır siteler için en kolay düzeltmelerden biri ve en yüksek getirisi olandır.

Tarayıcının indirmesi gereken her dosya, her CSS sayfası, her script, her görsel bir HTTP isteğidir. Daha fazla istek daha fazla gidiş-dönüş, daha fazla gecikme ve sayfanın kullanılabilir olması için daha uzun süre demektir.

İstekleri azaltmak için adımlar:

• Mümkünse CSS dosyalarını birleştirin (çoğu bundler bunu yapar).
• Kritik CSS'i HTML <head> içine inline yaparak bir gidiş-dönüşü ortadan kaldırın.
• CSS spriteları veya inline SVG'ler kullanın; küçük ikonlar için ayrı görsel dosyaları yerine.
• Kullanılmayan CSS ve JavaScript'i kaldırın. Chrome DevTools Coverage sekmesi tam olarak hangi kodun çalıştığını ve hangisinin çalışmadığını gösterir.

İş etkisi: 80 HTTP isteğinden 40'a düşmek, yavaş bağlantılarda yükleme süresinden 500ms-1s kesebilir. Bu mobil kullanıcılar için en önemli olanıdır; onlar hala web trafiğinin çoğunluğunu oluşturur.

Özel fontlar görünmez metin (FOIT) veya düzen kaymaları (FOUT) için yaygın bir kaynaktır. Font dosyası 2 saniye indirmek için zaman alırsa, kullanıcılar hiçbir şey göremez veya yedek metin flash'ı görür.

Bunu şununla düzeltin:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2');
  font-display: swap;
  unicode-range: U+0000-00FF;
}

• font-display: swap hemen yedek metni gösterir, sonra font yüklendiğinde değiştirir.
• Fontlarınızı alt kümeye ayırın sadece gerçekten kullandığınız karakterleri içerecek şekilde (unicode-range).
• Mümkünse değişken fontlar kullanın. Bir dosya 4-6 ağırlık/stil varyantının yerini alır.
• Google Fonts yerine fontları kendi sunucunuzda barındırın; böylece ekstra DNS lookup'dan kaçınırsınız.

İş etkisi: Font optimizasyonu yükleme sırasında görünmez metni önler ve CLS'yi azaltır. Bu, ilk izlenimi düzgün tutar, takıntılı göstermek yerine.

Tarayıcı kaynakları HTML'i parse ederken keşfeder; bu, derinlemesine iç içe geçmiş dosyaların (CSS'te referans verilen fontlar, CSS background'larındaki görseller) geç keşfedildiği anlamına gelir. Preloading tarayıcıya bunları daha erken getirmeye başlamasını söyler.

<!-- Hero görselini (LCP elementi) önceden yükle -->
<link rel="preload" as="image" href="/hero.webp" type="image/webp">

<!-- Kritik fontu önceden yükle -->
<link rel="preload" as="font" href="/fonts/inter-var.woff2" type="font/woff2" crossorigin>

<!-- Üçüncü taraf kaynaklara önceden bağlan -->
<link rel="preconnect" href="https://fonts.googleapis.com">

Seçici olun. Çok fazla kaynağı önceden yüklemek amacı bozar çünkü her şey bant genişliği için yarışır. Sadece LCP görselini, birincil fontu ve herhangi bir kritik üçüncü taraf bağlantısını önceden yükleyin.

İş etkisi: LCP görselini önceden yüklemek tek başına Largest Contentful Paint'i 200-500ms iyileştirebilir. Üçüncü taraf kaynaklara önceden bağlanmakla birleşince, bu düşük çaba, yüksek getiri demektir.

Tek bir devasa JavaScript paketi sunmak, her kullanıcının hiç ziyaret etmeyeceği sayfaların kodunu indirmesi anlamına gelir. Code splitting bu paketi talep üzerine yüklenen daha küçük parçalara böler.

Next.js ve React gibi framework'lerde:

// Dinamik import - sadece ihtiyaç duyulduğunda yüklenir
const HeavyComponent = dynamic(() => import('./HeavyComponent'), {
  loading: () => <Skeleton />,
});

Tree-shaking build zamanında kullanılmayan export'leri paketinizden kaldırır. Modern bundler'lar (Webpack 5, Vite, Turbopack) bunu ES modülleri için otomatik olarak yapar, ancak CommonJS require() sözdizimiyle bozulur.

Paket boyutunuzu @next/bundle-analyzer veya source-map-explorer gibi araçlarla kontrol edin; en büyük suçluları bulmak için.

İş etkisi: İyi bölünmüş bir uygulama ilk JavaScript yükünü %40-60 azaltabilir. Daha az JavaScript daha hızlı Time to Interactive demektir; bu, kullanıcıların sitenizle ne kadar hızlı etkileşime girebildiğini doğrudan etkiler.

Analytics, chat widget'ları, reklam scriptleri, sosyal embed'ler: üçüncü taraf scriptler genellikle bir sayfadaki en ağır öğelerdir ve üzerinde en az kontrol sizdedir.

Onları yönetmek için adımlar:

• Her şeyi denetleyin. Chrome DevTools'u açın, Network sekmesine gidin, "third-party" ile filtreleyin ve her scriptin boyut ve zaman açısından ne kadara mal olduğunu kontrol edin.
• Kritik olmayan scriptleri erteleyin. Analytics ve chat widget'ları sayfa kullanılabilir olmadan önce yüklenmek zorunda değil.
• Embed'ler için loading="lazy" kullanın (YouTube, haritalar, sosyal feed'ler).
• Ağır widget'ları daha hafif alternatiflerle değiştirin. 300KB'lık bir chat widget'ının 30KB'lık bir alternatifi olabilir.
• Bir script bütçesi belirleyin. Bir üçüncü taraf script yükleme süresine 50ms'den fazla ekliyorsa, yerini hak edip etmediğini sorgulayın.

İş etkisi: Üçüncü taraf scriptlerin toplam JavaScript'in %60+'sını oluşturduğu siteler gördük. Bunları temizlemek yükleme süresinden saniyeler kesebilir ve INP'yi (etkileşim yanıt hızı) dramatik şekilde iyileştirebilir.

Hız optimizasyonu tek seferlik bir proje değildir. Yeni özellikler, içerik güncellemeleri ve bağımlılık yükseltmeleri kimse izlemiyorsa sessizce performansı düşürebilir.

Sürekli izleme kurun:

• Google Search Console gerçek kullanıcı Core Web Vitals değerlerini zaman içinde izler. "Core Web Vitals" raporunu aylık kontrol edin.
• Lighthouse CI (veya benzeri) deployment pipeline'ınızda performans testleri çalıştırır; böylece regresyonlar kullanıcılara ulaşmadan yakalanır.
• Real User Monitoring (RUM) araçları Vercel Analytics veya web-vitals kütüphanesi gibi, ziyaretçilerinizden gerçek saha verisi yakalar.

Bir performans bütçesi oluşturun: aşıldığında uyarı tetikleyen sayfa ağırlığı, JavaScript boyutu ve LCP için maksimum değerler tanımlayın.

İş etkisi: Performansı izleyen ekipler, üç ayda bir denetim yapanlara göre regresyonları 10 kat daha hızlı yakalar. Lansman sonrası optimizasyon sadece neyin ne zaman değiştiğini görmek için veriye sahipseniz işe yarar.

Bunu siteniz için hızlı bir geçti/kaldı kontrolü olarak kullanın. Bunlardan birkaçı eksikse, Core Web Vitals'i etkileyenlerle başlayın.

Sunucu ve Altyapı

• TTFB tüm bölgelerde 800ms altında
• İçerik dağıtım ağı (CDN) statik varlıkları sunuyor
• Sunucu yanıt süresi trafik spike'ları altında stabil
• Gzip veya Brotli sıkıştırma metin tabanlı dosyalar için etkin

Görseller ve Medya

• Tüm görseller WebP veya AVIF formatında
• Responsive görseller farklı ekran boyutları için srcset kullanıyor
• Katlanın altındaki görseller loading="lazy" kullanıyor
• Tüm görseller açık width ve height özelliklerine sahip

CSS ve JavaScript

• CSS ve JS üretimde minify edilmiş
• Kritik CSS <head> içine inline
• JavaScript paketleri route'a göre code-split edilmiş
• Kullanılmayan CSS ve JS kaldırılmış (Coverage sekmesiyle kontrol edin)
• Render-blocking scriptler async veya defer kullanıyor

Fontlar

• Web fontları font-display: swap kullanıyor
• Fontlar gerekli karakter aralıklarına alt kümeye ayrılmış
• Birincil font <link rel="preload"> ile önceden yüklenmiş

İzleme

• Core Web Vitals Google Search Console'da izleniyor
• Performans testleri CI/CD pipeline'ında çalışıyor
• Üçüncü taraf scriptler üç ayda bir denetleniyor
• Sayfa ağırlığı bütçesi tanımlanmış ve uygulanmış

Bu kontrol listesi tam web sitesi denetimi ile aynı zemini kapsar. Siteniz bunların hepsinden geçiyorsa, web sitesi performansınız iyi durumdadır.

Web sitesi hız optimizasyonu tek büyük bir düzeltme değil. Birikerek 2 saniyenin altına indiren 14 daha küçük düzeltmedir. Görseller, önbellek, CDN, sıkıştırma, render-blocking kaynaklar, fontlar, lazy loading, sunucu yanıtı, code splitting ve izleme; her biri zamandan kazarır ve birlikte 2 saniyenin altına getirir.

PageSpeed Insights skorunuzla başlayın. İşaret ettiği şeyleri önce düzeltin. Bu listede teknik 1'den 14'e kadar çalışın, her değişiklikten sonra ölçüm yapın. Her şeyi bir kerede yapmanıza gerek yok, ama bunları yapmanız gerek.

İş durumu basit: daha hızlı siteler daha iyi dönüşür, daha yüksek sıralanır ve sunmak için daha az maliyetlidir. Yükleme süresinden kestiğiniz her saniye paradır.

Yardım isterseniz, Vezert hızı her projeye başlangıçtan itibaren dahil eder. Burada listelenen aynı teknikleri web sitesi geliştirme sürecimizde kullanıyoruz ve sonuçları portfolyomuzda görebilirsiniz. Hız sonra düzelteceğimiz bir şey değil. Yaptığımız şey budur.