Site Hızı Optimizasyonu Kontrol Listesi
Önceliklendirme, görseller, JS ve önbellekleme ile site hızını ölçülebilir iyileştirin; önce/sonra kanıtı olmadan “hız yaptık” demeyin.
Site hızı optimizasyonu, Lighthouse’ta yeşil rozet toplama yarışı değildir. Amaç: kullanıcıya anlamlı içeriği daha çabuk göstermek ve bunu önce/sonra kanıtıyla yönetmek. Sıralama vaadi yok — ölçülebilir UX ve Core Web Vitals field iyileştirmesi var.
Metrik çerçevesi: web.dev Core Web Vitals. SEO bağlamında okuma: CWV kontrol listesi, rapor: CWV raporu.
Bölüm 11) Önceliklendirme
- URL’leri trafik × dönüşüm × CWV “Kötü/İyileştirme gerekli” ile sıralayın
- Şablon bazında gruplayın (PDP, kategori, blog) — tek URL avı yapmayın
- LCP öğesini DevTools Performance / PSI’da işaretleyin
- En ucuz kazanım: LCP görseli + kritik CSS; en pahalı: mimari yeniden yazım
- Aynı sprintte 10 mikro uyarı yerine 1–2 şablon kök nedeni
E-ticaret şablonları için ek katman: e-ticaret hız optimizasyonu.
Bölüm 22) Ölç → değiştir → ölç (önce/sonra)
Adım 1
Analiz
Arama niyeti
Adım 2
Strateji
Öncelik planı
Adım 3
Büyüme
Organik trafik
- Önce: GSC CWV (field) + PSI/Lighthouse (lab) + gerçek cihaz spot check
- Baseline kaydı: tarih, URL/şablon, LCP/INP/CLS p75, lab LCP öğesi
- Tek değişiklik paketi deploy (mümkünse); karışık release’i ayırın
- Sonra: lab anında; field için CrUX penceresinin dolmasını bekleyin
- Rapor: “lab +12 puan” değil; field p75 ve iş metriği (CVR, bounce)
Araçlar: site hız testi, CWV testi. Field gecikmesi normaldir; lab’ı zafer ilanı sanmayın.
Bölüm 33) Görseller
- LCP adayı: doğru boyut, modern format (AVIF/WebP), compression
- Hero’da lazy-load yok; `fetchpriority="high"` / preload bilinçli
- width/height veya aspect-ratio ile CLS rezervi
- srcset/sizes gerçek viewport’lara uyuyor
- CMS’in orijinal 4000px PNG’yi olduğu gibi basması engelli
Lazy-load yanlış yerde LCP’yi bozar. Kurallar: lazy loading SEO.
Bölüm 44) JavaScript
Performans görünümü
Trafik, görünürlük ve dönüşüm birlikte okunur.
Q1
Q2
Q3
Q4
- Kritik yol dışı script’ler defer/async; üçüncü parti envanteri var
- Kullanılmayan polyfill / çift analytics etiketı yok
- Hydration maliyeti ölçülüyor (özellikle SSR/SPA)
- INP: tıklamada uzun task (>50ms) Performance panelinde işaretli
- A/B ve chat widget’ları ilk boyamada şart değilse ertelenmiş
JS’yi “minify ettik” diye kapatmayın; hangi paketin LCP/INP’ye değdiğini flame chart ile gösterin.
Bölüm 55) Caching ve kenar
- Statik varlıklar uzun cache + fingerprint; HTML politika net
- CDN: cache hit oranı ve origin offload izleniyor
- HTML’de yanlış Cache-Control yüzünden stale noindex/canonical riski yok
- 5xx/404 sayfaları uzun TTL ile edge’de kilitli değil
- API/HTML için stale-while-revalidate bilinçli kullanılıyor
CDN SEO sınırları: CDN SEO rehberi. Hosting tek başına hız stratejisi değildir.
Bölüm 6Kontrol listesi — sprint kapanışı
- Baseline ve after ölçümleri aynı yöntemle kaydedildi
- Değişiklik tek şablona izlenebilir commit/PR ile bağlı
- Regresyon: kritik sayfa lab LCP kötüleşmedi
- GSC CWV’de ilgili grup izleme listesinde
- İş metriği panosu (hız slaytından ayrı) güncellendi
Bölüm 7Kritik render yolu ve CSS
- Above-the-fold için gereken CSS ayrılmış veya inline kritik; geri kalan ertelenmiş
- Render-blocking CSS/JS sayısı biliniyor ve gerekçeli
- Font dosyaları subset / display stratejisi ile yükleniyor
- Ana CSS’te kullanılmayan mega framework kalıntısı düzenli temizleniyor
‘Purge CSS yaptık’ iddiasını lab waterfall ile doğrulayın. Yanlış purge tasarımı bozar; doğru kritik yol LCP’yi görünür şekilde çeker. CSS işi görsel işi kadar ‘içerik’ kararıdır — tasarım sistemi ile birlikte yürür.
Bölüm 8Sunucu ve TTFB gerçekçiliği
- HTML TTFB hedef aralığı şablon bazında yazılı (vaat değil, iç SLA)
- Origin CPU/DB yavaş sorguları APM’de görünür
- Edge cache HTML için bilinçli (kişiselleştirme vs anonim)
- TTFB’yi tek başına SEO skoru sanmayın; LCP zincirinin ilk halkasıdır
Hosting yükseltmek bazen TTFB’yi iyileştirir; şişmiş sepet widget’ı ve 3 MB slider’ı iyileştirmez. Hız checklist’inde altyapı satırı vardır ama ‘sunucu değişti sıralarız’ cümlesi yoktur.
Bölüm 9Üçüncü parti ve etiket yönetimi
- Tag manager konteynerinde tetikleyici envanteri güncel
- Marketing pikselleri consent ve sayfa tipine göre koşullu
- Canlı destek / heatmap yalnızca gerekli şablonlarda
- Her yeni etiket için performans bütçesi (KB + main-thread ms)
Etiket eklemek ürün kararıdır; SEO ekibi veto değil, bütçe ve ölçüm ister. INP ve LCP regresyonunda ilk şüpheli çoğu zaman ‘geçen sprint eklenen script’tir.
Bölüm 10E-ticaret özel notlar
- PDP galeri: ilk görsel LCP, diğerleri lazy
- Varyant değişimi layout shift üretmiyor
- Filtre AJAX sonrası scroll/URL politikası performans + SEO ile uyumlu
- Checkout hızı SEO metriği değil ama dönüşüm KPI’sı — ayrı izlenir
Mağaza şablonları için ayrı derinlik: e-ticaret hız. Bu genel listede PDP/kategori önceliğini kaybetmeyin; blog’u ilk optimize etmek sık görülen kaynak israfıdır.
Bölüm 11Medya dışında kalan LCP adayları
LCP her zaman görsel değildir. Büyük heading bloğu veya background video poster da LCP olabilir. Checklist:
- Performance panelinde LCP öğesi işaretli ve dokümante
- Web font LCP metnini geciktirmiyorsa font stratejisi gözden geçirildi
- CSS’te gecikmeli görünen hero (opacity/animation) LCP’yi şişirmiyor
Yanlış varsayım (‘mutlaka image optimize et’) zaman kaybettirir. Önce öğeyi bulun, sonra optimize edin. Bu disiplin lab ile field arasındaki boşluğu da küçültür.
Bölüm 12Performans bütçesi
- Şablon başına JS KB ve istek sayısı üst sınırı yazılı
- CI’da bütçe aşımı uyarı / fail politikası net
- Yeni bağımlılık PR şablonunda performans etkisi soruluyor
Bütçe yoksa hız işi sonsuz ‘bir ticket daha’ya döner. Bütçe, tasarım ve pazarlama ile paylaşılan kısıttır; SEO tek başına dayatmaz ama ölçümü taşır. Önce/sonra kayıtları bütçe ihlallerinin maliyetini gösterir.
Bölüm 13Regresyon ve sürümleme
Hız bir kez düzelip tema veya bağımlılık güncellemesiyle geri gelebilir. Checklist’e sürümleme ekleyin: her major front-end release öncesi aynı URL setinde lab LCP/INP, release sonrası field izleme. “Geçen çeyrek düzelttik” yeterli değildir; performans da ürün gibi regress olabilir. Ölçüm kaydı commit hash veya release notuna bağlansın ki hangi değişikliğin bozduğu tartışılabilsin.
- Release öncesi lab baseline kaydı zorunlu
- Release sonrası 7–28 gün field penceresi takip listesinde
- Regresyonda rollback veya feature flag planı yazılı
Son kontrol: hız işini ‘biten proje’ değil ‘sürekli hijyen’ olarak takvime yazın. Aylık field özeti, çeyreklik bütçe gözden geçirmesi ve major release kapısı olmadan kazanımlar erir. Bu ritmi product backlog’a bağladığınızda SEO ile geliştirme aynı dilde kalır.
Bölüm 14Sık hatalar
- “PageSpeed 90 = SEO kazandık” iddiası
- Field kötü iken yalnızca lab ile raporlamak
- Hero’yu lazy-load edip LCP’yi kendi eliyle bozmak
- Üçüncü parti script’i dokunulmaz saymak
- Ölçmeden tema/CDN değiştirmek
Özet: Önceliklendirin, görsel ve JS kök nedenine inin, cache’i doğru kurun, her paketi önce/sonra ile kanıtlayın. Hız hijyendir; sıralama sihri değil. Genel teknik tarama için SEO analiz yanına performans araçlarını koyun.
Sık Sorulan Sorular
Site hızı artınca sıralama garanti mi?
Hayır. Performans sayfa deneyiminin parçasıdır; içerik niteliği ve niyet uyumu belirleyici kalır. Hızı dönüşüm, bounce ve CWV field metrikleriyle raporlayın — “X ms = Y sıra” iddiası kurmayın.
Önce neyi optimize etmeliyim?
Trafik ve gelir yüksek şablonlarda LCP’yi bozan görsel/hero ve gereksiz JS. Tek blog yazısı yerine ortak layout’u hedeflemek genelde daha ucuz kazanım verir.
Lab mı field mı karar verir?
Karar ve “geçti/kaldı” için field (CrUX / GSC CWV). Lab (Lighthouse, WebPageTest) teşhis ve regresyon içindir. İkisini aynı slaytta karıştırmayın. Kaynak: web.dev CWV.
CDN tek başına yeter mi?
Hayır. CDN TTFB ve statik varlık dağıtımına yardım eder; şişmiş JS, optimize edilmemiş LCP görseli veya sunucu render gecikmesini sihirle çözmez. Bakın: CDN SEO.
İlgili Rehberler
Aynı konuda devam etmek için seçilmiş yazılar
Sonraki adım
Site Hız Testi
Sayfa yükleme performansı
Ücretsiz kontrolden sonra uzman incelemesi mi lazım? SEO Hizmetlerini İncele