Web Sitesi Performansı Neden Önemli?
Web Sitesi Performansı: Hızın Sessiz Gücü
Sitenin 3 saniyeden uzun yükleniyor mu? O zaman ziyaretçilerinin yarısından fazlasını hiç görmeden kaybediyorsun.
Bu dramatik bir iddia değil — Google'ın kendi araştırması. Mobil sayfa yüklenme süresi 1 saniyeden 3 saniyeye çıktığında, hemen çıkma olasılığı %32 artıyor. 5 saniyeye çıktığında %90. 6 saniyede %106. 10 saniyede %123 (Google/SOASTA, Think with Google). Amazon ise ölçtü: her 100 milisaniye ek yüklenme süresi, gelirde %1 düşüş anlamına geliyor (Greg Linden, Amazon).
Bu rakamlar tesadüf değil. Performans bir teknik detay değil — ilk izlenim, kullanıcı deneyimi, SEO sıralaması ve dönüşüm oranının hepsini etkileyen altyapısal bir karar.
Bu yazıda web performansını bir mühendis gözüyle ele alıyorum: neden yavaşlıyorsun, nasıl ölçeceksin, ve adım adım nasıl düzelteceksin.
Performans Neden Düşüyor? Teknik Anatomi
Yavaş bir siteye baktığında genellikle aynı suçluları buluyorsun. Bunları sistematik olarak ele alalım.
1. Optimize Edilmemiş Görseller
En yaygın sorun. Bir fotoğrafçının portfolyo sitesini denetlediğimde ana sayfada toplam 47 MB görsel yükleniyordu. Mobilde bu, 4G bağlantıda 12 saniye demek.
Boyutlar:
- Ortalama bir web sayfasının toplam ağırlığı: 2.5 MB (HTTP Archive, 2025)
- Bu ağırlığın %50'den fazlası görsellerden geliyor
- JPEG yerine WebP formatı: %25-34 daha küçük dosya boyutu (aynı kalitede)
- WebP yerine AVIF formatı: %20 daha küçük (ama tarayıcı desteği henüz %92)
2. Gereksiz Plugin ve Script Yükü
WordPress sitelerde ortalama 20-30 plugin kurulu. Her plugin, kendi CSS ve JavaScript dosyasını yüklüyor. Kullanılmayan plugin'ler bile arka planda kaynak tüketiyor.
Tipik sorunlar:
- Slider plugin'leri: 200-400 KB ek yük (çoğu zaman dönüşüme katkısı sıfır)
- Sosyal medya paylaşım butonları: 100-300 KB (3. parti scriptler)
- Analitik araçları üst üste: Google Analytics + Facebook Pixel + Hotjar + Clarity = her biri 30-80 KB JavaScript
- Font dosyaları: Google Fonts'tan 4-5 font ailesi = 200-500 KB
3. Kötü Hosting Altyapısı
Türkiye'deki KOBİ'lerin büyük çoğunluğu shared hosting kullanıyor. Bu, 200 web sitesinin aynı sunucuyu paylaşması demek. Birinin trafiği artınca herkes yavaşlıyor.
| Hosting Türü | Ortalama TTFB | Aylık Maliyet | Kime Uygun |
|---|---|---|---|
| Shared Hosting | 800-2000 ms | 50-200 TL | Hiçbir ciddi işletmeye |
| VPS | 200-500 ms | 300-800 TL | Orta trafik siteleri |
| Managed WordPress | 100-300 ms | 500-2000 TL | İçerik ağırlıklı siteler |
| Cloud (AWS/GCP) | 50-200 ms | 500-5000 TL | Ölçeklenebilirlik gereken siteler |
| Cloudflare Pages/Vercel | 20-80 ms | 0-500 TL | Statik/JAMstack siteler |
TTFB (Time to First Byte): Sunucunun ilk yanıtı gönderme süresi. 200 ms altı ideal, 600 ms üstü sorunlu.
4. Render-Blocking Kaynaklar
Tarayıcı sayfayı çizerken CSS ve JavaScript dosyalarına takılıyor. "Render-blocking" kaynaklar, sayfanın görsel olarak hazır olma süresini uzatıyor.
Tipik senaryo:
<head> <link rel="stylesheet" href="theme.css"> <!-- 150 KB --> <link rel="stylesheet" href="plugins.css"> <!-- 200 KB --> <link rel="stylesheet" href="font-awesome.css"> <!-- 80 KB --> <script src="jquery.js"></script> <!-- 90 KB --> <script src="slider.js"></script> <!-- 120 KB --> </head>Bu durumda tarayıcı, 640 KB dosya indirilip işlenene kadar sayfayı çizmeye başlayamıyor. Mobilde bu 2-4 saniye demek.
Core Web Vitals: Google'ın Performans Karnesi (2025-2026 Güncel)
Google, 2021'de Core Web Vitals'ı sıralama faktörü olarak devreye aldı. 2024'te önemli bir güncelleme geldi: FID (First Input Delay) yerini INP'ye (Interaction to Next Paint) bıraktı.
Güncel Core Web Vitals Metrikleri
| Metrik | Ne Ölçüyor | İyi | İyileştirme Gerekli | Kötü |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Ana içeriğin yüklenme süresi | ≤2.5 s | 2.5-4.0 s | >4.0 s |
| INP (Interaction to Next Paint) | Etkileşime yanıt süresi | ≤200 ms | 200-500 ms | >500 ms |
| CLS (Cumulative Layout Shift) | Görsel kayma/zıplama | ≤0.1 | 0.1-0.25 | >0.25 |
FID'den INP'ye Geçiş: Ne Değişti?
FID sadece ilk etkileşimi ölçüyordu. INP ise sayfadaki tüm etkileşimlerin (tıklama, dokunma, klavye) yanıt süresini ölçüyor ve en kötüsünü raporluyor.
Bu ne demek? Sayfa ilk tıklamada hızlı yanıt verse bile, beşinci tıklamada yavaşlıyorsa INP bunu yakalıyor. Özellikle JavaScript ağırlıklı SPA'lar (React, Vue, Angular) için kritik.
Chrome UX Report verilerine göre (2025): Türkiye'deki sitelerin sadece %38'i üç Core Web Vitals metriğinin hepsinde "iyi" notuna sahip. Global ortalama %48. Yani Türk sitelerin performans açığı var — bu da düzeltirsen öne çıkacağın anlamına gelir.
Performance Budget: Hız İçin Bütçe Belirle
Yazılım mühendisliğinde "performance budget" kavramı var: sistemin performans limitleri önceden belirlenir ve her yeni özellik bu bütçe dahilinde kalmalıdır.
Aynı yaklaşımı web sitene uygula:
Örnek Performance Budget
| Parametre | Bütçe | Neden |
|---|---|---|
| Toplam sayfa ağırlığı | ≤1.5 MB | 3G'de 3 saniye altı yüklenme |
| JavaScript boyutu | ≤300 KB (sıkıştırılmış) | Main thread blokajını önlemek |
| CSS boyutu | ≤100 KB (sıkıştırılmış) | Render-blocking süresini minimize etmek |
| Görsel başına boyut | ≤200 KB | Bant genişliği tasarrufu |
| HTTP istek sayısı | ≤50 | Connection overhead'i azaltmak |
| Web font dosyası | ≤100 KB | FOUT/FOIT önlemek |
| LCP | ≤2.0 s | Google "iyi" eşiğinin altında |
| INP | ≤150 ms | Kullanıcı deneyimi için |
| CLS | ≤0.05 | Görsel kararlılık |
Nasıl kullanacaksın: Her yeni plugin, her yeni görsel, her yeni özellik eklemeden önce performance budget'a bak. Bütçeyi aşıyorsa, ya vazgeç ya mevcut bir şeyi optimize et. "Bu özelliğin maliyeti 50 KB JavaScript — bütçemde yeri var mı?" diye sor.
Gerçek Dünya Vakası: Bir Türk KOBİ Sitesinin Performans Dönüşümü
Geçen yıl İstanbul'da bir e-ticaret KOBİ'sinin sitesini denetledim. Hikaye tanıdık gelecek.
Başlangıç Durumu
- Platform: WooCommerce (WordPress)
- Hosting: Shared hosting, Türkiye lokasyonu
- PageSpeed skoru: Mobil 23/100, Desktop 48/100
- LCP: 8.2 saniye (mobil)
- CLS: 0.38
- Toplam sayfa ağırlığı: 6.8 MB
- HTTP istek sayısı: 142
- Aktif plugin: 34
Adım Adım Düzeltme
Adım 1: Görsel optimizasyon (1 gün)
- Tüm görseller WebP formatına dönüştürüldü (ShortPixel)
- Lazy loading eklendi (sadece viewport'taki görseller yükleniyor)
- Responsive srcset eklendi (cihaza göre farklı boyut)
- Sonuç: Sayfa ağırlığı 6.8 MB → 2.9 MB
Adım 2: Plugin temizliği (yarım gün)
- 34 plugin → 18 plugin (16 tanesi ya gereksiz ya alternatifi vardı)
- Kalan plugin'lerin asset'leri sadece kullanıldıkları sayfalarda yükleniyor (Asset CleanUp)
- Sonuç: JavaScript boyutu %45 azaldı
Adım 3: Hosting değişikliği (1 gün)
- Shared hosting → Cloudways (DigitalOcean, İstanbul sunucusu)
- TTFB: 1.400 ms → 180 ms
Adım 4: CDN ve önbellekleme (yarım gün)
- Cloudflare Free plan aktifleştirildi
- Statik dosyalar CDN'den sunuluyor
- Tarayıcı önbelleği yapılandırıldı (statik dosyalar için 1 yıl, HTML için 1 saat)
- Sayfa önbelleği aktifleştirildi (WP Rocket)
Adım 5: Render-blocking temizliği (1 gün)
- Kritik CSS inline edildi (above-the-fold)
- Geri kalan CSS dosyaları async yükleniyor
- JavaScript dosyaları defer/async ile yükleniyor
- Kullanılmayan CSS kaldırıldı (PurgeCSS)
Sonuç
| Metrik | Önce | Sonra | İyileşme |
|---|---|---|---|
| PageSpeed (Mobil) | 23 | 84 | +265% |
| PageSpeed (Desktop) | 48 | 96 | +100% |
| LCP | 8.2 s | 1.8 s | -78% |
| INP | 380 ms | 120 ms | -68% |
| CLS | 0.38 | 0.04 | -89% |
| Sayfa ağırlığı | 6.8 MB | 1.1 MB | -84% |
| HTTP istekleri | 142 | 38 | -73% |
| TTFB | 1.400 ms | 95 ms | -93% |
İş etkisi (3 ay sonra):
- Hemen çıkma oranı: %67 → %41 (-%39)
- Ortalama oturum süresi: 1:20 → 2:45 (+106%)
- Mobil dönüşüm oranı: %0.8 → %1.9 (+138%)
- Aylık organik trafik: +%22 (Core Web Vitals iyileşmesinin SEO etkisi)
Toplam çalışma süresi: 4 gün. Hosting maliyeti artışı: aylık +350 TL. Bu yatırımın geri dönüş süresi: 2 hafta.
Görsel Optimizasyon: Derinlemesine Rehber
Görseller sayfa ağırlığının yarısından fazlasını oluşturduğu için burayı derinleştirmek şart.
Format Seçimi
| Format | Sıkıştırma | Şeffaflık | Animasyon | Tarayıcı Desteği | Ne Zaman Kullan |
|---|---|---|---|---|---|
| JPEG | Kayıplı | Yok | Yok | %100 | Fotoğraflar |
| PNG | Kayıpsız | Var | Yok | %100 | Logolar, ikonlar, şeffaf görseller |
| WebP | Kayıplı+Kayıpsız | Var | Var | %97 | Her şey (varsayılan olarak) |
| AVIF | Kayıplı+Kayıpsız | Var | Var | %92 | Maksimum sıkıştırma gerektiğinde |
| SVG | Vektör | Var | CSS/JS ile | %100 | İkonlar, logolar, basit grafikler |
Responsive Images: srcset Kullanımı
Tek bir 2400px genişliğinde görsel yüklemek yerine, cihaza uygun boyutu sun:
<img src="urun-800.webp" srcset=" urun-400.webp 400w, urun-800.webp 800w, urun-1200.webp 1200w, urun-1600.webp 1600w " sizes=" (max-width: 600px) 400px, (max-width: 900px) 800px, 1200px " alt="Ürün açıklaması" loading="lazy" decoding="async" width="1200" height="800" >Önemli noktalar:
loading="lazy": Ekranda görünene kadar yüklemez (bant genişliği tasarrufu)decoding="async": Görsel decode işlemi ana thread'i bloklamazwidthveheightattributes: CLS'yi önler (tarayıcı yer ayırır)- Above-the-fold görsellerde
loading="lazy"kullanma — LCP'yi kötüleştirir
Otomatik Optimizasyon Araçları
- ShortPixel / Imagify: WordPress plugin olarak otomatik sıkıştırma + WebP dönüşümü
- Cloudflare Polish: CDN seviyesinde otomatik optimizasyon
- Squoosh (squoosh.app): Google'ın ücretsiz online aracı, manuel optimizasyon için
- Sharp (Node.js): Programatik optimizasyon, build sürecine entegre edilebilir
Cloudflare + CDN: Türkiye İçin Pratik Kurulum
Türkiye'de sitelerin büyük çoğunluğu CDN kullanmıyor. Bu büyük bir fırsat — ve kurulumu sanıldığından çok daha kolay.
CDN Nedir ve Neden Gerekli?
CDN (Content Delivery Network), statik dosyalarını (görseller, CSS, JS, fontlar) dünya genelindeki sunuculara dağıtır. Kullanıcı en yakın sunucudan dosyayı alır.
Türkiye'deki etki: Hosting'in Almanya'daysa, İstanbul'dan gelen istek Almanya'ya gidip dönüyor (~80 ms). CDN ile İstanbul'daki edge sunucudan dönüyor (~15 ms). Her dosya için bu fark, toplamda 1-3 saniye iyileşme anlamına gelebilir.
Cloudflare Kurulumu (Ücretsiz Plan)
- Cloudflare'e kayıt ol ve domain'ini ekle
- DNS kayıtlarını Cloudflare'e yönlendir (nameserver değişikliği)
- SSL: Full (Strict) seç — uçtan uca şifreleme
- Caching Rules: Statik dosyalar için "Cache Everything" kuralı oluştur
- Speed > Optimization bölümünde:
- Auto Minify: HTML, CSS, JS hepsini aç
- Brotli sıkıştırma: Aç
- Early Hints: Aç
- Rocket Loader: Dikkatli ol, bazı scriptleri bozabilir — test et
Ücretsiz planda bile gelen özellikler:
- Global CDN
- DDoS koruması
- SSL sertifikası
- Temel web güvenlik duvarı (WAF)
- HTTP/2 ve HTTP/3 desteği
İleri Seviye: Cloudflare Workers ile Edge Computing
Daha ileri gitmek isteyenler için: Cloudflare Workers ile HTML sayfalarını da edge'de önbelleğe alabilirsin. WordPress gibi dinamik sitelerde bile TTFB'yi 50 ms altına çekebilirsin.
Performans Ölçüm Araçları: Sonuçları Nasıl Okuyacaksın?
Araçları listelemek yetmez — sonuçları yorumlamayı bilmen lazım.
Google PageSpeed Insights
URL: pagespeed.web.dev
- Lab Data: Kontrollü ortamda yapılan test. "Potansiyel" performansı gösterir.
- Field Data (CrUX): Gerçek kullanıcılardan toplanan veri. Asıl önemli olan bu. Google sıralamada bunu kullanıyor.
- Lab ve Field Data uyuşmuyorsa: Lab iyi ama Field kötüyse, gerçek kullanıcılarının cihazları/bağlantıları düşük demektir. Lab kötü ama Field iyiyse, kullanıcıların çoğu hızlı bağlantıda demektir.
Dikkat: Puan takıntısına düşme. 100/100 almak hedef değil. Hedef: Core Web Vitals'ın üçünde de "iyi" (yeşil) olmak.
Google Search Console — Core Web Vitals Raporu
Neden önemli: Tüm sayfaların performansını toplu olarak gösterir. Tek tek URL test etmek yerine, hangi sayfa gruplarının sorunlu olduğunu görürsün.
- İyi / İyileştirme Gerekli / Kötü kategorileri ile sayfaları gruplar
- Mobil ve desktop ayrı ayrı raporlanır
- Trend çizgisi ile iyileşme/kötüleşmeyi izlersin
Chrome DevTools — Performance Tab
Derinlemesine analiz için. Sayfanın yüklenme sürecini milisaniye milisaniye gösterir:
- Hangi dosya ne zaman yükleniyor?
- Main thread ne zaman meşgul?
- Layout shift'ler tam olarak nerede oluşuyor?
- Long task'ler (50 ms üzeri) hangileri?
WebPageTest (webpagetest.org)
En detaylı test aracı. Farklı lokasyonlardan, farklı cihaz ve bağlantı hızlarıyla test edebilirsin. Film strip görünümü ile sayfanın saniye saniye nasıl yüklendiğini görürsün.
İstanbul lokasyonundan test yap — gerçek kullanıcı deneyimini simüle etmek için.
Sistem Mimarı Perspektifi: Performans Altyapısal Bir Karardır
Çoğu işletme performansı "sitenin yavaş olduğu fark edilince" düşünür. Bu, yangın söndürme yaklaşımı. Sistem mimarı yaklaşımı ise farklıdır: performans, sistem tasarımının bir parçasıdır — sonradan eklenen bir yama değil.
Performans Piramidi
┌─────────┐ │ Ölçüm │ ← Sürekli izle ─┤& İzleme ├─ ┌─┴─────────┴─┐ │ Optimizasyon │ ← Düzenli iyileştir ─┤ ├─ ┌─┴──────────────┴─┐ │ Mimari Kararlar │ ← Baştan doğru tasarla └──────────────────┘
Taban: Mimari kararlar. Hosting seçimi, framework seçimi, veritabanı yapısı, CDN kullanımı — bunlar sonradan değiştirmesi en zor ve en pahalı kararlar. Baştan doğru yap.
Orta: Optimizasyon. Görsel sıkıştırma, cache yapılandırması, script yönetimi — bunlar düzenli bakım gerektiren süreçler.
Tepe: Ölçüm. Core Web Vitals izleme, performans budget kontrolü, regression testi — sürekli yapılmalı.
Kritik prensip: Piramidi yukarıdan aşağıya düzeltmeye çalışma. Kötü bir hosting üzerinde ne kadar optimize edersen et, temelden yavaş kalırsın. Önce tabanı sağlamlaştır.
Performans Kontrol Listesi
Bu listeyi sitenin performans denetimi için kullan:
Altyapı
- TTFB ≤200 ms
- HTTP/2 veya HTTP/3 aktif
- CDN kullanılıyor (Cloudflare veya alternatifi)
- SSL/TLS aktif (HTTPS)
- Gzip veya Brotli sıkıştırma aktif
Core Web Vitals
- LCP ≤2.5 s (hedef: ≤2.0 s)
- INP ≤200 ms (hedef: ≤150 ms)
- CLS ≤0.1 (hedef: ≤0.05)
Görseller
- WebP veya AVIF formatında
- Lazy loading aktif (above-the-fold hariç)
- srcset ile responsive boyutlar
- width/height attributes tanımlı
- Tek görsel ≤200 KB
JavaScript & CSS
- Render-blocking script yok (defer/async)
- Kritik CSS inline edilmiş
- Kullanılmayan CSS kaldırılmış
- Toplam JS ≤300 KB (sıkıştırılmış)
- Toplam CSS ≤100 KB (sıkıştırılmış)
Genel
- Toplam sayfa ağırlığı ≤1.5 MB
- HTTP istek sayısı ≤50
- Font dosyaları ≤100 KB
- Tarayıcı önbelleği yapılandırılmış
- Performance budget tanımlanmış ve izleniyor
Harekete Geç: Bu Hafta Yapabileceğin 3 Şey
- Sitenin mevcut durumunu ölç. PageSpeed Insights'a gir, ana sayfanı ve en çok trafik alan 3 sayfanı test et. Sonuçları bir tabloya yaz. Bu, iyileşmeyi takip etmek için başlangıç noktası.
- Görselleri optimize et. ShortPixel veya Imagify kur, tüm görselleri WebP'ye dönüştür, lazy loading ekle. Tek başına bu adım, sayfa ağırlığını %30-50 azaltabilir.
- Cloudflare kur. Ücretsiz plan, 20 dakikada kurulur. DNS yayılımı için 24 saat bekle. Sonra tekrar test et — TTFB ve genel yüklenme süresinde ciddi iyileşme göreceksin.
Sonuç: Hız Bir Özellik Değil, Bir İlkedir
Performans konusunda en sık duyduğum cümle: "Siteyi bitirdik, şimdi hızlandıralım." Bu, bir binayı yapıp sonra temelini güçlendirmeye çalışmak gibi. Mümkün — ama pahalı, zahmetli ve hiçbir zaman baştan doğru yapmak kadar etkili değil.
Web performansı bir "özellik" değil. Bir mimari ilke. Her teknik karar — hangi hosting, hangi framework, hangi plugin, hangi görsel formatı — performans bütçesi içinde değerlendirilmeli.
Google'ın verisi net: kullanıcılar 3 saniye beklemez. Amazon'un verisi net: 100 milisaniye bile önemli. Ve Türkiye'deki sitelerin %62'si Core Web Vitals'ta "iyi" notunu alamıyor — bu da performansı ciddiye alan her sitenin rekabet avantajı kazanacağı anlamına gelir.
Hız sessiz bir güçtür. Kimse "bu site ne kadar hızlıydı" demez. Ama yavaş bir siteden "bu site ne kadar yavaştı" diye kaçar. İyi performans fark edilmez — kötü performans asla unutulmaz.
Bugün sitenin PageSpeed skoruna bak. Eğer mobilde 70'in altındaysa, bu yazıdaki kontrol listesini aç ve çalışmaya başla. Her optimizasyon adımı, görmediğin ama kaybettiğin müşterileri geri kazandırıyor.
Pazarlamacı gibi düşün, mühendis gibi çöz.
Ömer Faruk Gürler — Dijital Pazarlama Uzmanı & Sistem Mimarı omerfarukgurler.com
Bir projeniz mi var?
Konuşalım