Vaka Çalışması: Web Sitemi 6.1s'den 2.2s'ye İndirdim — Core Web Vitals Optimizasyonu

Vaka Çalışması: LCP 6.1s → 2.2s Arasında Bir Web Sitesi

Eylül 2026'nın başında kendi web sitem olan yunusgungor.com'un arama motoru görünürlüğünü artırmak için teknik denetim yaptığımda beklenmedik bir tabloyla karşılaştım: Google'ın sıralama sinyali olarak kullandığı Core Web Vitals metriklerinden LCP (en büyük içerik boyama süresi) 6.1 saniyeydi. Google'ın "iyi" eşiği 2.5 saniye. Yani sitem mobilde "başarısız" kategorisindeydi ve bu, ne kadar iyi içerik üretirsem üreteyim sıralama şansımı kısıtlıyordu.

Bu yazı, o optimizasyonun uçtan uca kaydı: ne ölçtüm, hangi temelleri buldum, hangi değişiklikleri yaptım ve sonuç ne oldu. Tüm adımlar yeniden uygulanabilir.

1. Ölçüm: Sorunun Kaynağını Bulmak

Önce üretim sitesini Lighthouse ile ölçtüm (mobil strateji, performans kategorisi). İlk rapor net bir resim çizdi:

| Metrik | İlk Ölçüm | Google Eşiği | Durum | |---|---|---|---| | LCP | 6.1s | ≤ 2.5s | ❌ FAIL | | CLS | ~0.5 | ≤ 0.1 | ❌ FAIL | | TBT | ~300ms | ≤ 200ms | ❌ FAIL | | Performans skoru | ~60 | — | ⚠️ Orta |

Üç metrik birden başarısızdı; ama LCP 6.1s en kritik olanıydı çünkü mobil kullanıcının ilk gördüğü şeyin ne kadar geç geldiğini ölçüyordu.

2. Kök Neden Analizi: Üç Temel Suçlu

Raporlardan sonra LCP yol haritasını çıkardım. Üç şey net olarak öne çıktı:

1. 176KB'lık Analytics script'i LCP yolundaydı

Site, Google Analytics 4'i senkron şekilde yüklüyordu. gtag.js ~176KB büyüklüğündeydi ve render-blocking'di — yani tarayıcı ana içeriği çizmeden önce bu scripti indirip işlemek zorundaydı. Bu tek başına LCP'nin en büyük tetikleyicisiydi.

2. Google Fonts render-blocking yükleniyordu

Font dosyaları <link> ile senkron geliyordu; özellikle yazı tipi CSS'i ana içeriği bekletiyordu.

3. Görsel optimizasyonu eksikti

Ana görsellerin boyut bilgisi ve önceliklendirmesi yetersizdi; bu da hem LCP'yi hem CLS'yi (şablon kayması) tetikliyordu.

3. Uygulama: Yapılan Değişiklikler

Sorunlar netleşince değişiklikleri tek commit'te uyguladım (repo commit feedfde):

1. GA4'ü requestIdleCallback ile erteledim — Analytics script'i artık ana içerik çizildikten ve tarayıcı boşta kaldıktan sonra yükleniyor. 176KB'lık dosya LCP yolundan tamamen çıktı. Analitik verisi kaybolmuyor; sadece kullanıcı deneyimini bozmadan yükleniyor.
2. Google Fonts'u async yükledim — media="print" + swap tekniğiyle fontlar önce yazım yüzü olarak yükleniyor, içerik font için asla beklemiyor.
3. rol yüklemelerini optimize ettim — Teknoloji yığınımda (Vite + React) kritik olmayan JS chunk'larını erteleyerek ilk çizimi hızlandırdım.

Ayrıca Lighthouse CI yapılandırmasına INP ≤ 200ms eşiğini ekledim — böylece gelecekteki her pull request bu metrikteki gerilemeyi otomatik yakalayacak. Bu, "bir kere düzelttim, unuttum" tuzağına düşmeyi engelleyen süreç hamlesiydi.

4. Sonuç: Ölçülen İyileşme

Optimizasyon sonrası aynı Lighthouse/PageSpeed ile tekrar ölçtüm:

| Metrik | Öncesi | Sonrası | Değişim | |---|---|---|---| | LCP | 6.1s | 2.2s | ⚡ -64% | | CLS | ~0.5 | 0 | ✅ mükemmel | | TBT | ~300ms | 140ms | ✅ eşik altı | | Performans skoru | ~60 | 94/100 | 📈 +34 puan | | Testler | — | 445/445 geçti | ✅ regresyon yok |

LCP neredeyse 3 kat, TBT eşiğin altına, CLS sıfıra indi. Bütün bu iyileşmeler üç dosya değişikliğiyle geldi: <head>'de script ertelenmesi, font async, görsel önceliği. Site işlevselliği bozulmadı — 445 otomasyon testimin tamamı yeşil kaldı.

5. Çıkarımlar ve Tekrar Kullanılabilir Dersler

1. Önce ölç, sonra düzelt: "Site yavaş" hissi yanıltıcıdır. Lighthouse/PageSpeed'i çalıştırıp LCP/CLS/TBT'yi tek tek görmek, kaynağa odaklanmayı sağlıyor.
2. Analytics ve reklam script'leri en büyük gizli maliyettir: 176KB'lık tek bir IDLE-defer değişikliği LCP'yi 3 kata kadar etkiliyor. Analytics verileri aynen kalıyor, sadece sırası değişiyor.
3. CWV süreç değil güncel proje: Eşikleri CI'ye yazdığınızda (INP ≤ 200ms assertion) geri düşmeler otomatik yakalanır. Tek seferlik düzeltme, zamanla bozulur.
4. Eşikler Google'ın "iyi" sınırları: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1. Bu eşiklere inmek yalnızca kullanıcı deneyimi için değil; Google sıralama sinyali için de önemli.

6. Doğrulama: Kendiniz Kontrol Edin

Bu sonuçlar üretim sitesi üzerinde alındı ve herkes tarafından tekrar ölçülebilir. İki yol öneririm:

1. PageSpeed Insights: https://pagespeed.web.dev/ adresine https://yunusgungor.com yazın (strateji: Mobil). Performans skoru ve CWV metriklerini aynen göreceksiniz.
2. Lighthouse (Chrome DevTools): Sitede sağ tık → İncele → Lighthouse sekmesi → "Performance" → Generate. Aynı metrikler gösterilir.

Ölçümler açık ve tekrarlanabilir — bu yazının savunduğu şey de bu: hız optimizasyonu sihir değil, ölçülebilir mühendisliktir.

Alakalı: AI Ajanı Nedir? Nasıl Çalışır? · KOBİ Yapay Zeka Adaptasyonu Yol Haritası · Türkiye'de Yapay Zeka Kullanımı — TÜİK