Yeni Başlayanlar İçin Web Sitesi Hızı: Yükleme Süresini Gerçekten Ne İyileştirir?

“Web Sitesi Hızı” Gerçekte Ne Anlama Geliyor

İnsanlar “sitem yavaş” dediğinde genellikle iki şeyden birini kasteder:

• Sayfa hiçbir şey göstermeye başlamakta çok geç kalıyor, veya
• Hazır gibi görünüyor ama hâlâ tepkisiz hissediliyor (butonlar gecikiyor, görseller sonra geliyor, sayfa kayıyor).

“Yükleme süresi” tek bir kronometre sayısı değildir. Bir sayfa aşamalar halinde yüklenir: tarayıcınız dosyaları (HTML, görseller, fontlar, scriptler) ister, indirir ve sonra bunları kullanılabilir bir sayfaya çevirir. Bunu bir dükkanı açmaya benzetebilirsiniz: kapıyı açmak, ışıkları yakmak, rafları doldurmak ve nihayet müşterileri ağırlamaya hazır olmak.

Neden hız önemli (sadece “güzel” olmanın ötesinde)

Hız etkiler:

• Kullanıcılar: Yavaş sayfalar mobilde ve zayıf bağlantılarda stresli olur. İnsanlar daha çabuk ayrılır ve siteye daha az güvenir.
• SEO: Google, sayfa deneyiminin bir parçası olarak hızla ilgili sinyalleri (Core Web Vitals dahil) kullanır. Hızlı bir site otomatik olarak #1 yapmaz, ama yavaş bir site sizi geriye çekebilir.
• Dönüşümler: Her ekstra gecikme sürtünme ekler—daha az kayıt, daha az satın alma, daha az form gönderimi.

Beklentiler: çoğu iyileşme birkaç yerden gelir

50 mikro-optimizasyona ihtiyacınız yok. Çoğu yeni başlayan site için en büyük gelişmeler kısa bir listeden gelir: görseller, fazla JavaScript/CSS, üçüncü taraf widget'lar ve sunucu/barındırma yanıt süresi.

Bu rehberin kapsayıp kapsamayacakları

Bu rehber, gerçek dünyada sayfa yükleme süresini iyileştiren pratik, düşük riskli adımlara odaklanır; özellikle mobilde. Uygulama mimarisini baştan yazmak, özel önbellek katmanları oluşturmak veya büyük mühendislik ekipleri için performans bütçelemeye derinlemesine girmeyecektir. Amaç, gerçekten bitirebileceğiniz—ve doğrulayabileceğiniz—değişiklikler yapmanıza yardımcı olmak, siteyi bozmak değil.

Bilmeniz Gereken Temel Hız Metrikleri (Jargonsuz)

İnsanlar “sitem yavaş” dediğinde genellikle üç şeyden birini kasteder: ana içerik geç görünüyor, sayfa etkileşimde gecikiyor veya layout sürekli kayıyor. Google’ın Core Web Vitals bu şikayetlerle güzelce eşleşir.

Üç Core Web Vitals

LCP (Largest Contentful Paint): genellikle bir hero görseli veya başlık bloğu gibi en büyük “ana” şeyin ne kadar sürede göründüğü. LCP yüksekse kullanıcılar çoğunlukla boş bir sayfaya bakar.

INP (Interaction to Next Paint): kullanıcı etkileşiminden (dokunma, tıklama, yazma) sonra sayfanın ne kadar çabuk yanıt verdiği. INP yüksekse site yapışkan hisseder—butonlar geç tepki verir, menüler gecikir.

CLS (Cumulative Layout Shift): yükleme sırasında sayfanın ne kadar kaydığı. Metin kayar ve yanlışlıkla bir butona basarsanız, bu CLS'dir.

TTFB: “ilk yanıt” zamanı

TTFB (Time to First Byte), sunucunuzun (ve aradaki her şeyin) herhangi bir şey göndermeye başlaması için ne kadar sürdüğüdür. Yavaş TTFB her şeyi geciktirir: görseller inemez, fontlar yüklenemez ve genellikle LCP kötüleşir. TTFB sorunları genellikle barındırma, ağır backend işleri veya eksik önbellekleme işaret eder.

Laboratuvar testleri vs. gerçek kullanıcı verisi

Laboratuvar testleri (Lighthouse gibi) belirli koşullar altında bir sayfa yüklemesini simüle eder. Hata ayıklama ve öncesi/sonrası karşılaştırmalar için harikadır.

Gerçek kullanıcı verisi (genellikle alan verisi olarak anılır, ör. PageSpeed Insights içindeki CrUX), ziyaretçilerin cihazları ve ağları üzerinde gerçekte ne deneyimlediğini yansıtır. “Gerçek insanlar için hızlı mı?” sorusu açısından bu daha önemlidir.

Yeni başlayanlar için “yeterince iyi” hedefler

• LCP: hedef ≤ 2.5s (4.0s'e kadar iyileştirme gerekir)
• INP: hedef ≤ 200ms (500ms'e kadar iyileştirme gerekir)
• CLS: hedef ≤ 0.10 (0.25 üstü sorun)
• TTFB: hedef ≤ 0.8s (1.8s üstü genellikle fark edilir derecede yavaş)

Değiştirmeden Önce Sitenizi Nasıl Ölçersiniz

Bir temel almadan “optimize etmeye” başlarsanız zaman kaybetmek veya yanlışlıkla siteyi daha da yavaşlatmak kolaydır. Önce 20 dakika ölçüm yapın, sonra hangi değişikliklerin işe yaradığını bilirsiniz.

Hızlı gerçeklik kontrolü için PageSpeed Insights kullanın

PageSpeed Insights gibi araçları kullanın: PageSpeed Insights size hızlı bir anlık görüntü verir. Hem alan verisi (kullanıcı deneyimi) hem de laboratuvar verisi (simüle test) raporlar. Dikkat edin:

• Mobil vs. masaüstü sonuçları (mobil genellikle sorundur)
• “Fırsatlar” listesi (iyi fikirler, kati bir yapılacak listesi değil)
• Testin URL için gerçek kullanıcı verisi olup olmadığı

Daha derin laboratuvar testi için Chrome'da Lighthouse çalıştırın:

1. DevTools'u açın → Lighthouse
2. Mobile ve Performance seçin
3. 2–3 kez çalıştırın ve orta sonucu alın (testler değişkenlik gösterir)

“Waterfall” için WebPageTest kullanın

Hangi şeyin sayfayı geciktirdiğini görmek gerektiğinde, WebPageTest en net araçlardan biridir. Waterfall görünümü her dosyanın yüklenmesini sırayla gösterir—HTML, görseller, fontlar, scriptler ve üçüncü taraf etiketler—ve tarayıcının nerede beklediğini gösterir.

Bir ana sayfayla başlayın (ana sayfa veya öne çıkan açılış sayfası) ve test edin:

• First View (soğuk önbellek) ve Repeat View (önbellekli)
• Mümkünse bir mobil cihaz profiliyle

Test koşullarınızı kaydedin (sonuçların anlamlı olması için)

Her test için şunları not alın:

• Cihaz (dizüstü, orta seviye telefon vb.)
• Ağ (Wi‑Fi, 4G, kısıtlanmış ayarlar)
• Konum (WebPageTest'teki test bölgesi)
• Tam URL (parametreler dahil)

Basit bir ön/son kontrol listesi oluşturun

Küçük bir günlük oluşturun (bir tablo yeterli): tarih, kullanılan araç, URL, sonuçlar ve yapılan değişiklik. Her seferinde bir veya iki şey değiştirin, sonra aynı koşullarda yeniden test edin.

Bir uygulama üzerinde iterasyon yapıyorsanız (sadece statik site değilse), performans deneylerini göndermek ve geri almak için güvenli bir yol olması yardımcı olur. Örneğin Koder.ai gibi platformlar (sohbet iş akışından React/Go uygulamaları oluşturup barındırabilir) burada kullanışlıdır çünkü anlık görüntüler (snapshots) alabilir, değişiklikleri test edebilir ve bir “hız düzeltmesi” UX'i bozar ise hızlıca geri alabilirsiniz.

Sayfaların Yavaş Yüklenmesinin En Yaygın Nedenleri

Yavaş sayfalar genellikle tek bir gizemli sorundan kaynaklanmaz. Mobilde üst üste binen birkaç yaygın “ağırlık ve gecikme” sorununun sonucudur.

1) Gereğinden büyük görseller

Görseller genellikle sayfanın en ağır kısmıdır. Yanlış boyutta dışa aktarılmış tek bir hero görseli megabaytlar ve saniyeler ekleyebilir.

Yaygın sebepler:

• Site 1200px gösterirken 4000px genişliğinde fotoğraf yüklenmesi
• Fotoğraflar için PNG kullanılması yerine modern formatların (WebP/AVIF) tercih edilmemesi
• Aynı büyük görselin masaüstü ve mobil için aynı şekilde sunulması

2) Çok fazla JavaScript (ve eklenti)

JavaScript, bir sayfanın kullanılabilir hale gelmesini geciktirebilir. Sayfa “görünse” bile scriptler yüklenip çalışırken site yavaş hissedebilir.

Üçüncü taraf scriptler sık sık suçludur: sohbet widget'ları, açılır pencereler, ısı haritaları, A/B test araçları, reklam etiketleri ve sosyal gömüler. Her biri ekstra ağ çağrısı ekleyebilir ve tarayıcının kritik işleri yapmasını geciktirebilir.

3) Yavaş barındırma veya ağır sunucu işi

Bazen tarayıcı sayfanın yüklenmesine başlamadan önce sunucunuzu bekler. Bu genellikle yavaş ilk yanıt (TTFB) olarak hissedilir. Sebepler: yetersiz barındırma, yoğun veritabanı, optimize edilmemiş tema/eklentiler veya her ziyaret için dinamik olarak oluşturulan sayfalar.

4) Önbellek yok + çok fazla istek

Site her ziyareti sıfırdan başlatıyorsa, tekrar gelen ziyaretçiler cezalandırılır. Önbellek yoksa sunucu sayfaları tekrar tekrar yeniden oluşturur ve tarayıcı nadiren değişen dosyaları yeniden indirir.

Ayrıca çok sayıda küçük dosya (fontlar, scriptler, stiller, izleyiciler) “istek yükü” yaratır. Her dosya küçük olsa bile birleşik bekleme süresi toplanır.

İyi haber: bu nedenler düzeltilebilir—ve genellikle en büyük kazançları bu sırayla alırsınız.

Görseller: En Hızlı, En Güvenilir Kazanç

Tek bir performans iyileştirmesi yapacaksanız, görseller olsun. Birçok yeni başlayan sitede görseller sayfanın indirilen “ağırlığının” çoğunu oluşturur—özellikle mobilde. İyi haber: görsel düzeltmeleri genellikle güvenlidir, hızlıdır ve tasarımınızı değiştirmenizi gerektirmez.

1) Görselleri gösterildikleri boyuta göre yeniden boyutlandırın

Yaygın hata, devasa bir fotoğraf (ör. 4000px genişlik) yükleyip bunu 800px olarak göstermektir. Tarayıcı hâlâ büyük dosyayı indirmek zorunda kalır.

Görselleri sitenizde gerçek maksimum görünecek boyuta yakın dışa aktarın. Örneğin, blog içerik alanınız 800px ise 3000–4000px görseller yüklemeyin “ihtimal” için.

2) Mümkünse modern formatlar kullanın (WebP/AVIF)

JPEG ve PNG hâlâ çalışır, ancak modern formatlar aynı görsel kalitede çok daha küçük dosya sunar.

• WebP geniş desteklidir ve iyi bir varsayılandır.
• AVIF daha da küçük olabilir, ama kodlama daha yavaş olabilir ve destek daha sınırlıdır.

CMS veya görsel eklentiniz otomatik olarak WebP/AVIF sunabiliyorsa fallback (yedek) ile bu idealdir.

3) Görselleri sıkıştırın ve gereksiz metadata'yı kaldırın

Sıkıştırma çoğu hemen elde edilen kazancın olduğu yerdir. Görselin “görsel olarak aynı” kalmasını sağlayarak genellikle %30–70 boyut azaltımı mümkündür.

Ayrıca gereksiz metadata'yı (kamera bilgisi, konum verisi) kaldırın. Görselin görünüşünü değiştirmez ama byte ekler.

Pratik kural: kalite belirgin düşene kadar sıkıştırın, sonra bir adım geri gidin.

4) Mobil vs masaüstü için responsive görseller (srcset) kullanın

Mobil kullanıcılar masaüstü boyutlu görselleri indirmemeli. Responsive görseller tarayıcının ekran genişliğine göre uygun boyutu seçmesini sağlar.

Siteniz birden fazla görsel boyutu otomatik üretiyorsa, temanızın bunları doğru kullandığından emin olun. Aradığınız şey HTML'de tek bir devasa dosya yerine srcset gibi bir şey olsun.

Hızlı kontrol listesi

Kodu küçültme gibi daha ileri ayarlamalara geçmeden önce yalnızca en büyük görsellerinizi denetleyin:

• Bulundukları yerde uygun boyutta mı?

• Mümkünse WebP/AVIF olarak sunuluyor mu?

• Makul şekilde sıkıştırılmışlar mı?

• Mobil cihazlar daha küçük sürümler alıyor mu?

Bu dört şeyi tutarlı şekilde yapın; web sitesi hızınız ve sayfa yükleme süreniz genellikle hemen iyileşir—çoğu zaman Core Web Vitals'ı olumlu etkiler.

Lazy Loading ve Üst Ekran Öncelikleri

Lazy loading, sayfanızın bazı görselleri (ve bazen iframe'leri) ekranına yakın olana kadar indirmeyi geciktirmesi anlamına gelir. Bu, özellikle uzun içerikli sayfalarda başlangıçta tarayıcının her şeyi aynı anda almaması nedeniyle ilk yüklemeyi kısaltır.

Lazy loading ne zaman yardımcı olur

Lazy loading en çok şu durumlarda faydalıdır:

• Ürün ızgaraları, blog yazıları ve ilk ekrandan sonra çok içerik olan açılış sayfaları
• Hemen gerekli olmayan gömülü videolar/haritalar
• Yavaş bağlantıda mobil ziyaretçiler

Doğru kullanıldığında “önceki yükleme işi” azalır ve sayfa daha hızlı hissedilir.

Hero'yu lazy-load yapmayın (LCP'yi koruyun)

En büyük üst ekran görseli genellikle hero görselidir. Eğer bunu lazy-load yaparsanız, tarayıcı onu istemekte gecikebilir ve bu Largest Contentful Paint (LCP)'i olumsuz etkileyebilir.

Kural: ana hero görselini veya ilk ekranda kritik olan öğeleri asla lazy-load yapmayın (başlık görseli, birincil ürün fotoğrafı, üst afiş).

Yerleşim kaymalarını prevent etmek için genişlik/yükseklik ayırın

Lazy loading, görseller görünürken “atlama”ya neden olabilir. Layout shift (CLS)'yi önlemek için alan ayırın:

• Görsellere width ve height verin, veya
• Sabit bir en-boy oranı kullanan CSS kullanın

Böylece görseller yüklenirken sayfa düzeni stabil kalır.

Gerçekten önemli olanları preload edin

Eğer üst ekranda çok önemli bir görsel veya font varsa, tarayıcının onu erken alması için preload düşünün. Bunu tutarlı şekilde kullanın—çok fazla preload bant genişliği için yarışarak geri tepme yapabilir.

Kontrol listesi yaklaşımını isterseniz, bunu ölçüm adımınızla eşleştirin ve blog/how-to-measure-site-speed-before-you-change-anything adlı referansı not alın.