Core Web Vitals: Sitenizi Yavaşlatan 5 Gerçek Sebep

Site yavaş olduğunda ilk suçlanan hosting olur. Bazen haklıdır ama benim baktığım sitelerin çoğunda sunucuyu yükseltmek hiçbir şeyi değiştirmedi — çünkü sorun sunucunun cevap verme hızında değil, tarayıcının o cevabı ekrana boyamasındaydı.

Önce üç metriği tek cümleyle netleştirelim:

• LCP — Sayfadaki en büyük görsel öğe ne zaman göründü? Hedef: 2,5 saniyenin altı.
• CLS — İçerik yüklenirken sayfa ne kadar zıpladı? Hedef: 0,1'in altı.
• INP — Kullanıcı tıkladığında sayfa ne kadar sürede tepki verdi? Hedef: 200 ms'nin altı.

1. Optimize edilmemiş hero görseli

LCP'yi bozan bir numaralı sebep budur ve tespiti kolaydır: sayfanın en üstündeki büyük görsel, çoğu zaman 2-4 MB'lık, 4000 piksel genişliğinde, telefonda 380 piksele sıkıştırılan bir JPEG'dir.

Çözüm sırası:

1. Görseli gerçekten görüntüleneceği boyuta indirin. 1600 pikselden geniş hero görseline neredeyse hiç gerek yoktur.
2. WebP veya AVIF formatına geçin — aynı kalitede %30-60 daha küçük.
3. srcset ile telefona küçük, masaüstüne büyük sürüm gönderin.
4. Hero görseline fetchpriority="high" verin, lazy-load vermeyin. Ekranda ilk görünen görseli geciktirmek tam ters etki yapar.

2. Render'ı bloklayan yazı tipleri

Google Fonts'tan çekilen üç ayrı aile, altı ağırlık. Tarayıcı bu dosyaları indirene kadar metni ya gizler ya da sonradan zıplatır — birincisi LCP'yi, ikincisi CLS'yi bozar.

Çözüm: Yazı tipi sayısını ikiye indirin, sadece kullandığınız ağırlıkları yükleyin, dosyaları kendi sunucunuzdan servis edin ve mutlaka font-display: swap kullanın. Bu sitede sistem yazı tipi tercih ettim; hiç indirme yok, hiç zıplama yok.

3. Boyutu belirtilmemiş görseller ve gömülü içerik

CLS'nin klasik sebebi. <img> etiketine width ve height yazmazsanız tarayıcı görselin ne kadar yer kaplayacağını bilemez; görsel gelince altındaki her şeyi aşağı iter. Kullanıcı tam okuduğu yeri kaybeder.

Aynı sorun YouTube gömüleri, harita iframe'leri ve reklam alanları için de geçerli. Hepsine sabit bir yükseklik veya aspect-ratio tanımlayın — içerik gelmeden yeri ayrılmış olsun.

4. Üçüncü taraf script yığını

Analytics, pixel, canlı destek widget'ı, ısı haritası, çerez bandı, A/B test aracı… Her biri tek başına masum görünür. Ama bunlar ana iş parçacığını meşgul eder ve INP'yi doğrudan öldürür: kullanıcı tıklar, tarayıcı meşguldür, tepki gecikir.

Yapılacaklar:

• Envanter çıkarın. Sitede çalışan her script'in bir sahibi ve bir gerekçesi olsun. Sahipsizleri silin.
• Kritik olmayanları defer ile veya kullanıcı etkileşiminden sonra yükleyin. Canlı destek widget'ının sayfa açılışında yüklenmesi gerekmez.
• Chrome DevTools → Performance sekmesinde uzun görevleri (long tasks) izleyin; hangi script'in ne kadar süre bloklandığını orada görürsünüz.

5. Sunucunun ilk cevap süresi (TTFB)

Sıralamada beşinci ama sebep olduğunda diğer her şeyi geçersiz kılar. Tarayıcı ilk baytı 1,5 saniyede alıyorsa, önyüzde ne yaparsanız yapın LCP hedefini tutturamazsınız.

Bakılacak yerler, en sık rastladığım sıraya göre:

• N+1 sorgu: Listede 50 kayıt varsa ve her biri için ayrı sorgu atılıyorsa, 51 sorgu döner. En yaygın ve en kolay düzelen sorun.
• Eksik veritabanı indeksi: WHERE ve ORDER BY'da kullandığınız kolonlarda indeks yoksa tablo baştan sona taranır.
• Her istekte yapılan dış API çağrısı: Döviz kuru, kargo sorgusu, hava durumu — bunları önbelleğe alın.
• Eski PHP sürümü: PHP 7'den 8.3'e geçiş, tek satır kod değiştirmeden ciddi kazanç verebiliyor.

Bu maddelerin hepsini denediğiniz halde TTFB inatla yüksek kalıyorsa, sorun tekil bir ayarda değil altyapıda olabilir. Otuz eklentinin her istekte yüklendiği bir kurulumda optimizasyonun bir tavanı vardır; o noktada özel bir çözüme geçmenin ne zaman mantıklı olduğunu ayrıca ele aldım.

Nasıl ölçmeli

Kritik nokta: laboratuvar verisiyle saha verisini karıştırmayın. Lighthouse kendi makinenizde simülasyon yapar — geliştirirken faydalıdır, karar vermek için yeterli değildir. Gerçek kullanıcılarınızın deneyimi Search Console'daki Core Web Vitals raporunda ve PageSpeed Insights'ın üst bölümündeki saha verisindedir.

Sıralama açısından Google'ın baktığı da budur. Lighthouse'ta 100 alıp sahada kırmızı görmek son derece mümkün; tersi de öyle.

Performans, siteyi yayına almadan önce doğrulanması gereken maddelerden yalnızca biri. Geri kalanını 20 maddelik teknik SEO kontrol listesinde topladım.

Sıra

Bir siteyi hızlandırmaya oturduğumda takip ettiğim sıra şu: önce TTFB'yi ölçerim, sorun ordaysa önyüze hiç dokunmam. Değilse hero görselini hallederim — genelde tek başına en büyük kazanç budur. Sonra yazı tipleri, sonra layout kaymaları, en son script envanteri. Bu sırayla gidildiğinde çoğu site iki günlük işle yeşile geçiyor.