“Sitemiz neden yavaş açılıyor?” sorusunun cevabı neredeyse hiçbir zaman tek bir sebep değildir. Ama iyi haber şu: hız, fikir değil ölçü meselesi. Üç sayı var ve bu üç sayı sitenin gerçekte ne durumda olduğunu söylüyor.
Core Web Vitals nedir, eşikleri kaç?
Google 2020’den beri sayfa deneyimini üç ölçüyle takip ediyor. 2024 Mart’ında bunlardan biri (FID) emekliye ayrıldı ve yerine INP geldi. 2026 itibarıyla geçerli tablo şu:
| Ölçü | Ne ölçüyor | İyi | Geliştirilmeli | Kötü |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | En büyük içerik öğesinin ekrana gelme süresi | 2,5 sn ve altı | 2,5 ile 4,0 sn arası | 4,0 sn üstü |
| INP (Interaction to Next Paint) | Tıklamaya sitenin cevap verme süresi | 200 ms ve altı | 200 ile 500 ms arası | 500 ms üstü |
| CLS (Cumulative Layout Shift) | Sayfa yüklenirken içeriğin zıplaması | 0,1 ve altı | 0,1 ile 0,25 arası | 0,25 üstü |
Kritik ayrıntı: bu değerler ortalama değil, 75. yüzdelik üzerinden hesaplanıyor. Yani ziyaretçilerinizin dörtte üçü eşiğin altında kalmalı. Ortalamanız iyi görünse bile mobil kullanıcılarınızın çeyreği kötü deneyim yaşıyorsa test kırmızı yanar.
Laboratuvar verisi mi alan verisi mi doğruyu söyler?
Bu ayrım, hız konuşmalarındaki en büyük yanlış anlamanın kaynağı.
- Laboratuvar verisi (lab data): Lighthouse veya PageSpeed Insights’ın simülasyonu. Sabit bir cihaz ve bağlantı varsayar. Sorunu bulmak için iyidir.
- Alan verisi (field data): Chrome kullanıcılarının gerçek tarayıcılarından toplanan CrUX verisi. Google sıralamada bunu kullanır.
PageSpeed Insights’ı açtığınızda üstte “Gerçek Kullanıcı Deneyimi”, altta “Performansı Teşhis Et” görürsünüz. Üstteki gerçektir, alttaki tahmindir. Yeni bir sitede üst bölüm boş çıkar çünkü henüz yeterli ziyaretçi verisi yoktur. Bu bir hata değil, sadece zaman ister.
Bir web sitesini asıl ne yavaşlatır?
Aşağıdaki sıralama, bu sorunların ne kadar yaygın görüldüğüne göre yapıldı.
1. Sıkıştırılmamış görseller
Çoğu sitede birinci sebep. Telefonla çekilip doğrudan yüklenen bir fotoğraf birkaç MB olabilir; aynı görsel doğru sıkıştırıldığında yüzlerce KB’a iner ve ekranda belirgin bir fark görünmez. Yapılması gereken:
- Modern format: WebP veya AVIF. JPEG’e göre aynı kalitede belirgin biçimde küçüktür.
- Doğru ölçü: 4000 piksel genişliğindeki bir görseli 600 piksellik bir alanda göstermeyin. Tarayıcı dosyanın tamamını indirir, sonra küçültür.
widthveheightverin: bu, CLS’i doğrudan düzeltir. Ölçü verilmezse tarayıcı görselin yerini bilemez, görsel gelince altındaki her şey aşağı kayar.- Ekranda görünmeyene
loading="lazy": sayfanın altındaki görseller kullanıcı oraya gelene kadar inmesin.
2. Sayfayı bloklayan üçüncü taraf kodlar
Chat widget’ı, ısı haritası, üç ayrı analitik, sosyal medya beslemesi, çerez bandı, yazı tipi servisi: her biri ayrı bir alan adına bağlanır ve her bağlantı DNS + TLS el sıkışması demektir. Bunlar sizin sunucunuzun hızını değil, kullanıcının bekleme süresini uzatır.
Sert ama işe yarayan kural: her üçüncü taraf script’in bir sahibi ve bir gerekçesi olmalı. Gerekçesini kimse hatırlamıyorsa kaldırın.
3. Yazı tipi yükleme düzeni
Özel yazı tipleri iki şekilde zarar verir: dosya büyükse geç gelir, font-display ayarı yanlışsa metin görünmez bekler (FOIT). Doğrusu:
- Yazı tipini kendi sunucunuzdan verin, üçüncü taraf CDN’den değil.
- Yalnızca kullandığınız alfabeyi yükleyin. Rusça içerik yoksa Kiril alt kümesini indirmeyin.
font-display: swapkullanın: yazı tipi gelene kadar sistem fontuyla göster, sonra değiştir.
4. Sunucu yanıt süresi (TTFB)
Tarayıcının ilk baytı alma süresi. Google’ın web.dev rehberi 0,8 saniyenin altını iyi sayıyor; Lighthouse denetimi daha sıkı davranıp 600 milisaniyenin üstünü işaretliyor. Yaygın sebepleri: paylaşımlı hostingde aşırı yoğunluk, önbelleksiz veritabanı sorguları, sunucunun ziyaretçiden coğrafi olarak çok uzak olması.
Alanya’daki bir işletmenin sitesi ABD’deki bir sunucuda duruyorsa, her istek Atlantik’i geçer. Hedef kitleniz Türkiye ve Avrupa ise sunucu da orada olmalı. Rus ve Alman ziyaretçisi olan bir sitede statik dosyaları ziyaretçiye yakın sunan bir CDN de aynı işe yarar.
5. Gereğinden fazla JavaScript
Bir tanıtım sitesinin ağır bir JavaScript çatısına ihtiyacı yoktur. İçerik statik olarak üretilebiliyorsa, tarayıcıya iş bırakmayın. Bu hem hızı hem de yapay zekâ aramalarında görünürlüğü etkiler: OpenAI, Anthropic ve Perplexity tarayıcıları JavaScript’i büyük ölçüde çalıştırmıyor, Google ise çalıştırıyor ama gecikmeli işliyor.
6. Yönlendirme zincirleri
http://site.com → https://site.com → https://www.site.com → https://www.site.com/tr/ şeklinde uzayan zincir, her adımda bir tur ekler. Tek bir yönlendirmeye indirin.
7. Önbellek başlıkları
Logo, yazı tipi ve CSS her ziyarette yeniden inmemeli. Değişmeyen dosyalara uzun süreli Cache-Control verin, dosya adına sürüm damgası koyun.
INP nasıl düzeltilir?
INP, sitenin tıklamaya ne kadar çabuk cevap verdiğini ölçer; yavaşsa sebep neredeyse her zaman ana iş parçacığını meşgul eden JavaScript’tir. Sırayla bakılacaklar:
- Üçüncü taraf script’leri azaltın. Chat, takip ve reklam kodları tıklamayı geciktiren en sık sebeptir.
- Uzun görevleri bölün. Tek parçada yüzlerce milisaniye çalışan kod, tıklamanın beklemesine yol açar.
- Ağır olay işleyicilerini hafifletin. Tıklamada çalışan koddan yalnızca ekranı güncelleyen kısım hemen çalışmalı.
- Sayfa kurucu ve gereksiz kütüphaneleri çıkarın. Gönderilen JavaScript azaldıkça INP genellikle iyileşir.
Hangi etkileşimin yavaş olduğunu Chrome DevTools’un Performans paneli ve Search Console’un Core Web Vitals raporu gösterir. Ayrıntılı yöntem web.dev’in INP iyileştirme rehberinde.
Site hızı nasıl ölçülür?
Sırayla, ücretsiz araçlarla:
- PageSpeed Insights: hem alan hem laboratuvar verisi. Mobil sekmesine bakın.
- Search Console › Core Web Vitals: sitenin tamamının alan verisi, URL grupları hâlinde. Asıl takip edilecek yer burasıdır.
- WebPageTest: istek istek şelale görünümü. Hangi dosyanın neyi beklettiğini gösterir.
- Chrome DevTools › Lighthouse: geliştirme sırasında hızlı kontrol.
Ölçerken üç kural: her zaman mobil test edin, önbelleği boş sayfa ile test edin, aynı sayfayı üç kez ölçüp ortancayı alın.
Site hızı neden ticari bir mesele?
Hız, teknik bir gurur meselesi değil. Yavaş açılan sayfa üç yerden zarar verir: ziyaretçi beklemeden çıkar, Google eşit rakipler arasında hızlıyı öne alır, ve reklam veriyorsanız aynı tıklama için daha fazla ödersiniz. Yavaş açılan sayfa dönüşüm oranını düşürür.
Kurumsal web sitesi projelerinde hızı sonradan eklenen bir iyileştirme olarak değil, baştan bir kısıt olarak ele alıyoruz: sayfalar statik üretiliyor, görseller otomatik olarak modern formata çevriliyor, yazı tipleri kendi sunucumuzdan ve yalnızca gereken alfabeyle geliyor. turuncsoft.com de aynı şekilde yapıldı; kendi adresimizi PageSpeed Insights’a girip bakabilirsiniz. SEO optimizasyonu çalışmalarında da ilk bakılan yer teknik performanstır; içerik iyileştirmesi yavaş bir altyapının üstüne konduğunda beklenen sonucu vermiyor.
Yayına almadan önce neler kontrol edilmeli?
- Mobil PageSpeed Insights’ta LCP 2,5 saniyenin altında mı?
- Bütün görseller WebP/AVIF ve gösterildikleri ölçüde mi?
- Her
<img>etiketindewidthveheightvar mı? - Ekranın altındaki görsellerde
loading="lazy"var mı? - Sunucu yanıt süresi 0,8 saniyenin altında mı?
- Yazı tipleri kendi sunucunuzda ve
font-display: swapile mi? - Sayfada gerekçesi olmayan üçüncü taraf script var mı?
- Yönlendirme zinciri tek adıma mı iniyor?
Kaynaklar
Bu rehberdeki teknik eşikler ve kural tanımları aşağıdaki birincil kaynaklara dayanıyor.