Web Sitesi Hızı ve Core Web Vitals: Tasarım Kararları Hızı Nasıl Belirler?

Web sitesi hızı, çoğu işletmede "kodlama bittikten sonra optimize edilecek" bir konu olarak görülür. Oysa hızın büyük kısmı, tasarım aşamasında verilen kararlarla belirlenir: hangi görsel kullanılacak, kaç yazı tipi yüklenecek, hangi üçüncü taraf araçlar eklenecek. Bu yazı, Google'ın hız ölçütlerini ve bunların tasarım kararlarıyla ilişkisini pratik biçimde ele alıyor.

Core Web Vitals Nedir?

Core Web Vitals, Google'ın bir sayfanın gerçek kullanıcı deneyimini ölçmek için tanımladığı üç temel metriktir. Tanımlar ve eşikler Google'ın web.dev belgelerinde yer alır:

Metrik	Neyi ölçer?	"İyi" eşik
LCP (Largest Contentful Paint)	Sayfadaki en büyük içerik öğesinin yüklenme süresi	2,5 saniye veya altı
INP (Interaction to Next Paint)	Etkileşimlere (tıklama, dokunma, tuş) verilen tepki süresi	200 milisaniye veya altı
CLS (Cumulative Layout Shift)	Sayfanın yüklenirken beklenmedik kayması	0,1 veya altı

Bu eşiklerin sağlanması, sayfa ziyaretlerinin en az yüzde 75'i için aranır. Yani birkaç hızlı deneme yetmez; farklı cihaz ve ağ koşullarındaki gerçek kullanıcıların çoğu için sonuç iyi olmalıdır. INP, Mart 2024'te FID metriğinin yerini aldı ve yalnızca ilk etkileşimi değil, ziyaret boyunca tüm etkileşimleri kapsıyor.

Hız Neden Bir İş Meselesi?

Hızın sıralamaya etkisi gerçek olsa da (Core Web Vitals sayfa deneyimi sinyallerinin parçasıdır), içeriğin alakası ve kalitesi çok daha belirleyicidir. Hızın asıl önemi ziyaretçi davranışındadır: yavaş açılan sayfada insanlar beklemez, kaymayan ve hemen tepki veren sayfada ise eyleme geçer. Bu nedenle hızı yalnızca bir SEO maddesi değil, satış kanalınızın parçası olarak görmek gerekir.

Hızı Tasarım Aşamasında Belirleyen 6 Karar

1. Ana görselin boyutu ve biçimi

LCP çoğu zaman sayfadaki en büyük görseldir. Bu görsel sıkıştırılmamış bir fotoğrafsa, hedeflenen 2,5 saniye eşiği baştan kaçar. Modern biçimler (WebP, AVIF), doğru boyutlandırma ve önceliklendirme (fetchpriority="high") LCP'yi en çok iyileştiren adımlardır. Sayfanın ilk ekranındaki ana görseli tembel yüklememek (lazy loading yapmamak) da önemli bir kuraldır; tembel yükleme yalnızca ekran dışındaki görseller içindir.

2. Yazı tipi sayısı ve ağırlığı

Her yazı tipi ailesi ve her ağırlık ek bir dosya demektir. Pratik hedef, iki aileyi ve gerçekten kullanılan ağırlıkları yüklemektir. Yazı tipini kendi alan adınızdan sunmak, font-display: swap ile metnin beklemeden görünmesini sağlamak ve yalnızca gerekli karakter kümelerini yüklemek yükü azaltır. Türkçe karakterleri (ğ, ş, ı, İ) destekleyen alt kümeyi seçmeyi unutmayın.

3. Animasyon ve etkileşim yükü

Ağır animasyon kütüphaneleri ve sürekli çalışan efektler ana iş parçacığını meşgul eder ve INP'yi kötüleştirir. Animasyonu anlam taşıdığı yerlerde ve düzeni etkilemeyen özelliklerle (dönüşüm ve opaklık) kullanın; "her bölüme kayarak giriş" gibi süsleme efektlerinden kaçının. Kullanıcının "hareketi azalt" tercihine de saygı gösterin.

4. Üçüncü taraf betikler

Canlı destek, izleme pikselleri, harita gömme ve sosyal medya eklentileri çoğu zaman sitenin kendi kodundan daha ağırdır. Her ekleme için "bu betiğin sağladığı fayda, hız maliyetine değer mi?" diye sorun ve mümkünse ilk yüklemeyi kullanıcı etkileşimine kadar erteleyin. Harita için etkileşimli gömme yerine statik bir görsel ve bağlantı çoğu yerel işletme için yeterlidir.

5. Yerleşim kararlılığı

CLS, görsellere ve reklam ya da başlık alanlarına önceden yer ayrılmadığında yükselir. Görsellerin genişlik ve yükseklik değerlerini belirtin, sonradan enjekte edilen afiş ve çerez bildirimleri için alan ayırın, yazı tipi yüklenirken oluşan kaymayı yedek yazı tipi ölçüleriyle azaltın.

6. Sunucu ve teknoloji seçimi

Sunucu yanıt süresi (TTFB), tüm ölçütlerin başlangıcıdır. Önceden üretilmiş (statik) veya sunucu tarafında verimli oluşturulan sayfalar, içerik dağıtım ağı (CDN) ve etkili önbellekleme bu süreyi düşürür. Teknoloji tercihinin hız üzerindeki etkisini WordPress ve Next.js karşılaştırmamızda ele aldık; özel geliştirmede gereksiz eklenti yükü olmadığı için kontrol daha kolaydır.

Metriklere Göre Sık Neden ve Çözüm

Sorun	Sık neden	Çözüm
Yüksek LCP	Büyük hero görseli, yavaş sunucu, render'ı engelleyen CSS/JS	Görseli optimize edin ve öncelendirin, sunucu yanıtını iyileştirin, kritik CSS'i öne alın
Yüksek INP	Ağır JavaScript, üçüncü taraf betikler, uzun görevler	Kodu bölün, gereksiz betiği kaldırın, ağır işleri erteleyin
Yüksek CLS	Boyutsuz görsel, geç yüklenen afiş, yazı tipi değişimi	Boyut belirtin, alan ayırın, yedek yazı tipini eşleştirin

Kendi Sitenizin Hızını Nasıl Ölçersiniz?

1. PageSpeed Insights'ta ana sayfanızı ve bir hizmet sayfanızı test edin. Ana sayfa genellikle en iyi optimize edilen sayfadır; iç sayfalar gerçeği gösterir.
2. "Gerçek kullanıcı deneyimi" bölümüne bakın. Yeterli trafik varsa Chrome kullanıcı verisinden gelen gerçek değerler burada görünür; bunlar laboratuvar puanından daha güvenilirdir.
3. Laboratuvar önerilerini okuyun. "Fırsatlar" listesi en çok süre kazandıran maddeleri sıralar.
4. Search Console'daki Core Web Vitals raporunu inceleyin. Sorunlu sayfa gruplarını ve hangi metriğin başarısız olduğunu gösterir.
5. Değişiklikten sonra yeniden ölçün. Tek seferlik puana değil, zaman içindeki eğilime bakın.

Önemli bir uyarı: laboratuvar puanı (0-100 arası skor) ile Core Web Vitals değerlendirmesi aynı şey değildir. Puanı yüksek bir sayfa gerçek kullanıcılarda yavaş olabilir; karar verirken gerçek kullanıcı verisine öncelik verin.

Performans Bütçesi Belirleyin

Hızı korumanın en etkili yolu, tasarım aşamasında bir performans bütçesi koymaktır. Bütçe, sayfanın aşmaması gereken sınırlardır. Aşağıdakiler standart değil, uygulamada kullanabileceğiniz hedeflerdir:

• Ana görsel için makul bir dosya boyutu hedefi belirleyin ve bu hedefi aşan görseli yayına almayın.
• Yüklenen yazı tipi ailesi sayısını iki ile sınırlayın.
• Yeni bir üçüncü taraf betik eklerken önce mevcut biri çıkarılabilir mi diye sorun.
• Her yeni özellikten sonra Core Web Vitals değerlerini yeniden ölçün.

Görsel Optimizasyonu: Adım Adım

Görseller çoğu sitede sayfa ağırlığının en büyük kısmıdır; en yüksek kazanç da genellikle burada bulunur. Sıra şöyle olmalı:

1. Doğru boyutu belirleyin: Ekranda 600 piksel genişlikte görünen bir görseli 3000 piksel olarak yüklemeyin.
2. Modern biçim kullanın: WebP veya AVIF, aynı görsel kalitesinde JPEG ve PNG'den belirgin biçimde küçük dosya üretir.
3. Cihaza uygun boyutlar sunun: srcset ve sizes ile tarayıcının en uygun dosyayı seçmesini sağlayın.
4. Genişlik ve yüksekliği belirtin: Tarayıcı yükleme öncesi yer ayırır, böylece CLS oluşmaz.
5. Ekran dışındakileri tembel yükleyin: loading="lazy" yalnızca ilk ekranın altındaki görseller içindir.
6. İlk ekrandaki ana görseli önceliklendirin: fetchpriority="high" ile LCP görselinin hızlı yüklenmesini sağlayın; bu görseli asla tembel yüklemeyin.

<img
  src="hero-800.webp"
  srcset="hero-480.webp 480w, hero-800.webp 800w, hero-1200.webp 1200w"
  sizes="(min-width: 1024px) 50vw, 100vw"
  width="1200" height="800"
  fetchpriority="high"
  alt="Ekibimiz bir web projesinin tasarımını inceliyor">

Görselin ayrıca anlamlı bir alternatif metni olması hem erişilebilirlik hem arama için önemlidir. Bu ayarlara hâkim çerçeveler (Next.js gibi) görsel bileşenleriyle bunları otomatikleştirir; özel geliştirmede bu kontrol elinizdedir.

Yazı Tipi Yükleme: Örnek Ayar

Yazı tipi dosyaları ağırdır ve yüklenirken metnin görünmemesine (veya yer değiştirmesine) yol açabilir. Aşağıdaki desen, yaygın ve güvenli bir başlangıçtır:

<link rel="preload" href="/fonts/marka.woff2" as="font" type="font/woff2" crossorigin>

@font-face {
  font-family: "Marka";
  src: url("/fonts/marka.woff2") format("woff2");
  font-weight: 400 700;      /* değişken yazı tipi */
  font-display: swap;        /* metin beklemeden görünür */
}

Üç ilke: yazı tipini kendi alan adınızdan sunun, yalnızca gerçekten kullandığınız ağırlıkları yükleyin ve Türkçe karakterleri (ğ, ş, ı, İ) içeren alt kümeyi seçin. Değişken yazı tipleri birden çok ağırlığı tek dosyada toplayarak istek sayısını azaltabilir.

Üçüncü Taraf Betik Envanteri

Siteye zaman içinde eklenen betikler çoğu zaman unutulur ve hızı sessizce düşürür. Yılda en az bir kez envanter çıkarın ve her betiğe "hâlâ gerekli mi, değerine karşılık ne kadar yük getiriyor?" diye sorun:

Betik türü	Tipik etki	Alternatif veya erteleme
Analiz ve izleme	Ana iş parçacığı ve ağ yükü	Yalnızca gerekli olayları toplayın; sayfa yüklendikten sonra başlatın
Canlı destek penceresi	Ağır ve sürekli çalışır	Kullanıcı etkileşimine kadar yüklemeyi erteleyin
Gömülü harita	Çok sayıda ek istek	Statik görsel ve "Yol tarifi al" bağlantısı
Gömülü video (YouTube gibi)	Büyük betik ve çerez yükü	Kapak görseli, tıklayınca yükleme
Sosyal medya eklentileri	Yavaş ve izleme yükü	Basit bağlantı simgeleri
Kullanılmayan eski etiketler	Boşuna yük	Kaldırın

Çerez ve izleme yükümlülükleri konusunda KVKK uyumlu web sitesi yazımıza bakın; izleme betikleri hem hızı hem yasal uyumu ilgilendirir.

Önbellekleme ve CDN: Basitçe

Önbellekleme, aynı dosyanın her ziyarette baştan indirilmesini önler. İki temel katman vardır. Tarayıcı önbelleği: yazı tipi, görsel, CSS ve JavaScript gibi değişmeyen dosyalara uzun süreli önbellek başlığı verilir; dosya değiştiğinde adı da değişir (versiyonlama), böylece kullanıcı her zaman doğru sürümü alır. İçerik dağıtım ağı (CDN): dosyaların kullanıcıya coğrafi olarak yakın sunuculardan verilmesini sağlar ve sunucu yanıt süresini (TTFB) kısaltır. Sayfaların kendisi de önceden üretilip önbelleğe alınabiliyorsa (statik veya artımlı üretim), sunucu her ziyarette yeniden hesap yapmaz. Bu, özellikle içeriği sık değişmeyen kurumsal siteler için hız açısından çok verimli bir yaklaşımdır.

Sık Duyulan Hız Yanılgıları

• "Puanım 100 olmalı." Laboratuvar puanı bir rehberdir; hedef, gerçek kullanıcı verisinde Core Web Vitals eşiklerini sağlamaktır. 100 puan peşinde özelliklerden vazgeçmek çoğu zaman gereksizdir.
• "Hız yalnızca sunucu meselesi." Sunucu önemlidir ama görsel, yazı tipi ve betik kararları, çoğu sitede daha büyük etki yaratır.
• "Hız eklentisi kurarsam sorun çözülür." Eklenti, kötü kararları düzeltmez; bazen ek yük bile getirir. Asıl çözüm, gereksiz olanı kaldırmaktır.
• "Her şeyi tembel yükleyeyim." İlk ekrandaki içeriği tembel yüklemek LCP'yi kötüleştirir. Tembel yükleme yalnızca ekran dışı içerik içindir.
• "Masaüstü hızlıysa mobil de hızlıdır." Telefonlar daha yavaş işlemci ve değişken ağda çalışır; ölçümü mobil koşullarda yapın.

Yüksek LCP'yi Teşhis Etme Sırası

LCP yüksek çıktığında ilk refleks görseli küçültmek olur; ancak sorun her zaman görselde değildir. web.dev, LCP süresini dört parçaya ayırır ve hangi parçanın uzun olduğuna bakmayı önerir:

Parça	Ne anlatır?	Uzunsa ne yapılır?
Sunucu yanıt süresi (TTFB)	Sunucunun ilk cevabı verme süresi	Önbellekleme, CDN, sunucu iyileştirmesi, statik üretim
Kaynak yükleme gecikmesi	Tarayıcının LCP görselini bulup istemeye başlama süresi	Görseli HTML'de erken görünür yapın, önceliklendirin
Kaynak yükleme süresi	Görselin indirilme süresi	Boyut ve biçim optimizasyonu, doğru boyut sunma
Öğe çizim gecikmesi	Görselin ekrana çizilmesindeki bekleme	Çizimi engelleyen CSS ve betiği azaltın

Bu sıra, tahmini optimizasyon yerine sistemli teşhis sağlar: önce en uzun parçayı bulun, sonra yalnızca onu iyileştirin. Örneğin TTFB uzunsa görseli sıkıştırmak sonucu değiştirmez. Aynı mantık INP ve CLS için de geçerlidir: önce ölçün, sonra en büyük katkıyı yapan nedene odaklanın.

Ölçümlerde tarayıcı geliştirici araçlarının performans paneli ve PageSpeed Insights'ın ayrıntı bölümleri size hangi öğenin LCP olduğunu ve zamanın nerede harcandığını gösterir. Bu bilgiyi tasarım ve yazılım ekibine iletmek, tartışmayı "yavaş" gibi belirsiz bir şikâyetten somut bir düzeltme listesine dönüştürür.

Özet Notlar: Hız İçin 5 Cümle

• Eşikler: LCP 2,5 saniye veya altı, INP 200 milisaniye veya altı, CLS 0,1 veya altı; ziyaretlerin en az yüzde 75'inde.
• Hızın büyük kısmı kodlamadan önce, görsel, yazı tipi, animasyon ve üçüncü taraf betik kararlarıyla belirlenir.
• Önce ölçün, sonra en uzun parçayı iyileştirin; gerçek kullanıcı verisini laboratuvar puanına tercih edin.
• İlk ekrandaki ana görseli önceliklendirin, ekran dışındakileri tembel yükleyin.
• Hızı korumak için bir performans bütçesi koyun ve yılda en az bir kez betik envanteri çıkarın.

Hız İşi Kimin Sorumluluğunda?

Hız yalnızca yazılımcının sorunu değildir: tasarımcı görsel ve yazı tipi kararlarını, içerik ekibi görsel boyutlarını, pazarlama ekibi izleme betiklerini yönetir. Bu yüzden hedef, süreç başında ortak bir performans beklentisi koymaktır. Projenin tamamında hızın nerede ele alınacağını tasarım süreci yazımızda görebilirsiniz. Hız kalitenin bir ölçütü olarak profesyonel web sitesi tasarımı kontrol listesinde de yer alır. Daha kapsamlı bir teknik inceleme için web sitesi teknik SEO denetimi rehberimize göz atabilirsiniz.

Mevcut sitenizin hız durumunu birlikte değerlendirmek veya yeni bir siteyi hız hedefiyle tasarlamak isterseniz web site geliştirme hizmetimizi inceleyin ya da bizimle iletişime geçin.

Web Sitesi Tasarımı Rehber Serisindeki Diğer Yazılar

Bu yazı, işletmeler için web sitesi tasarımını farklı açılardan ele alan bir serinin parçası. İlgilendiğiniz konuya doğrudan geçebilirsiniz:

• İşletmeler için web sitesi tasarımı rehberi
• Profesyonel web sitesi tasarımının 12 ölçütü
• Kurumsal web sitesi sayfa yapısı ve bilgi mimarisi
• Web sitesi tasarım süreci: adım adım
• Mobil uyumlu web sitesi tasarımı
• SEO uyumlu web sitesi tasarımı
• Yapay zekâ aramaları için web sitesi tasarımı
• Dönüşümü düşüren web sitesi tasarım hataları
• Yerel işletmeler için web sitesi tasarımı