Yaz Sonrası Site Performans Denetimi: Sonbahar İçin Kontrol Listesi

Core Web Vitals temel çizgisini yeniden ölçmek

Yaz başında aldığınız ölçümler artık geçerliliğini yitirmiş olabilir. CrUX (Chrome UX Report) verileri son 28 günü kapsar; Ağustos trafiği içinde gerçekleşen yavaşlamalar bu pencerede görünür. Önce güncel alanı ölçün, Mayıs veya Haziran başı anlık görüntüsüyle kıyaslayın.

• CrUX alanını kontrol edin. Google Search Console'daki Core Web Vitals raporunu açın, son 28 günü Mayıs verileriyle karşılaştırın. Hangi sayfalar "Düzeltilmesi gereken" sütununa geçmiş, not alın.
• LCP, CLS ve INP'yi ayrı ayrı inceleyin. Üç metriğin de başarılı sayılabilmesi için tüm eşiklerin karşılanması gerekir: LCP 2,5 saniye altı, CLS 0,1 altı, INP 200 milisaniye altı. Hangisi sorunlu, hangisi sınırda olduğunu belgeleyin.
• Mobil ve masaüstü verilerini ayırın. Yaz kampanyaları mobil trafiği artırmış olabilir. Masaüstünde "İyi" görünen bir sayfa, mobilde "Düzeltilmesi gereken" statüsünde olabilir; iki cihaz tipini ayrı ayrı değerlendirin.
• Alan verisi eksik olan sayfalara dikkat edin. Yeni eklenen kampanya sayfaları CrUX'ta henüz yeterli veri biriktirememiş olabilir. Bu sayfalar için lab ölçümü yapın ve alan verisi beklemeyin.
• Yüzdelik dağılımı kontrol edin. Medyan değer iyi görünse bile 75. yüzdelik dilim kötüyse, kullanıcıların dörtte biri sorun yaşıyordur. Google, Core Web Vitals değerlendirmesinde 75. yüzdelik dilimi esas alır.

Ölçüm tamamlanmadan öncelik sıralaması yapmak, hangi sayfanın en çok kullanıcıyı etkilediğini bilmeden kaynak harcamak anlamına gelir. Bu adım atlanırsa sonraki maddeler verimsizleşir.

Görsel ağırlığını denetlemek: yaz boyunca eklenen dosyalar

Yaz kampanyaları görsel yoğundur. Büyük hero banner'lar, birden fazla ürün kaydırıcısı, animasyonlu GIF'ler, video arka planları; her biri bağımsız bir yavaşlatma faktörüdür. Kampanya bittikten sonra bu dosyaların bir kısmı sayfada kalmaya devam eder ve her yeni ziyaretçiyle birlikte indirilir.

• Haziran'dan bu yana eklenen görselleri listeleyin. CMS'inizde yükleme tarihine göre filtreleyin. Hangileri hâlâ aktif sayfada, hangileri kullanılmıyor? Kullanılmayan görseller hem depolama hem CDN önbellek kirliliği oluşturur.
• LCP elementini doğrulayın. Tarayıcı geliştirici araçlarıyla ya da PageSpeed Insights ile sayfanın LCP elementinin ne olduğunu kontrol edin. Bu element bir görsel ise yüklenme süresini, boyutunu ve formatını not alın.
• LCP görseli yanlışlıkla lazy-load edilmiş mi? loading="lazy" özelliği yanlışlıkla LCP elementine uygulanmışsa LCP ciddi biçimde uzar. Yaz içi hızlı düzenlemelerde bu hata sık karşılaşılır.
• Hero görseli fetchpriority="high" ile işaretli mi? LCP görselini tarayıcıya erken tanıtmak, özellikle mobil bağlantılarda fark yaratır. Özellik eksikse ekleyin; fazla bir maliyeti yoktur.
• Görsel formatlarını kontrol edin. Yaz boyunca yüklenen görseller WebP veya AVIF formatında mı, yoksa ham JPEG ya da PNG mı? Sunucu tarafında format dönüşümü yapılmıyorsa manuel kontrol gerekir.
• Görsellerde width ve height öznitelikleri var mı? Eksik boyut bilgisi, sayfa yüklenirken yerleşim kaymasına yol açar ve CLS'i yükseltir. Yaz boyunca eklenen her görsel için bu öznitelikleri gözden geçirin.
• Artık kullanılmayan sezonluk görselleri kaldırın ya da arşivleyin. Depolama alanındaki gereksiz dosyalar CDN önbelleklerini kirletir ve ileride yanlışlıkla referans alınma riskini artırır.

Cache TTL ve header kontrolü: yaz modunda takılı kalanlar

Yaz kampanyaları sırasında bazı ekipler cache sürelerini kasıtlı olarak kısaltır; içerik sık değiştiğinde bu mantıklıdır. Kampanya bitince bu kısa TTL'ler geri alınmaz ve statik kaynaklar bile gereksiz yere sık sık yeniden indirilir. Kısa önbellekleme süresi, CDN'in işlevini kısmen ortadan kaldırır.

• Statik varlıkların Cache-Control header'larını kontrol edin. CSS, JS ve font dosyalarında max-age değeri en az bir yıl (31536000) olmalı. Daha kısa bir değer görürseniz, yaz döneminde kısaltılıp kısaltılmadığını araştırın.
• Kampanya sayfalarının TTL'sini inceleyin. Artık aktif olmayan açılış sayfaları hâlâ kısa önbellekleme süresiyle sunuluyor olabilir. Bu sayfaları ya devre dışı bırakın ya da kalıcı yönlendirme ekleyin.
• CDN önbellek isabet oranını kontrol edin. CDN panelinizde bu oran Haziran'a göre düşmüşse, kısa TTL veya beklenmedik bir cache invalidation kuralı değişikliği olası nedenlerdir.
• Vary header'larını gözden geçirin. Vary: Cookie veya Vary: User-Agent gibi geniş Vary header'ları CDN önbelleklemeyi etkisiz kılar. Yaz güncellemelerinde bu header'lara istemeden bir şey eklenmiş olabilir.
• ETag ve Last-Modified kontrolü. CDN ya da sunucu yapılandırması değiştiyse bu header'lar beklenmedik şekilde kaybolmuş veya yanlış değer dönüyor olabilir. Tarayıcı önbelleklemesi için her ikisi de önemlidir.

Cache sorunlarının büyük bölümü kayıt defterinde iz bırakmaz. Bir header satırının değişmesi performansı sessizce bozar ve aylarca fark edilmez. TTL denetimine ayırılan yarım saat, yüzlerce günlük CDN maliyetini doğrudan etkiler.

Üçüncü taraf scriptlerin yaz sonrası envanteri

Her kampanya yeni bir entegrasyon getirir: farklı bir analitik piksel, bir A/B test aracı, bir canlı sohbet widget'ı, bir ısı haritası kaydedici. Kampanya sona erdiğinde scriptler genellikle kaldırılmaz. Biriken her script ana iş parçacığında zaman çalar ve INP'yi yukarı çeker.

• Aktif olarak kullanılan scriptleri listeleyin. Tarayıcı geliştirici araçlarındaki ağ sekmesinde üçüncü taraf kaynaklarını filtreleyin. Hangi domainlerden istek geliyor? Her birinin mevcut kampanyayla veya iş süreciyle bağlantısını sorgulayın.
• Kullanılmayan scriptleri kaldırın. Biten kampanyaların piksellerini, devre dışı kalan A/B test araçlarını, deneme amaçlı eklenen widgetları doğrudan silin. Devre dışı bırakmak değil, tamamen kaldırmak gerekir; devre dışı bırakılan script çoğu zaman hâlâ yüklenir.
• Script yükleme stratejilerini gözden geçirin. Kritik olmayan her script async veya defer özelliğiyle yüklenmelidir. Senkron script etiketi, tarayıcının sayfayı ayrıştırmasını durdurur ve FCP ile LCP üzerinde doğrudan etkisi vardır.
• Ana iş parçacığı yükünü ölçün. PageSpeed Insights raporundaki "Üçüncü taraf kodunun etkisini azaltın" bölümünü inceleyin. Hangi scriptler 50 milisaniyenin üzerinde ana iş parçacığı zamanı kullanıyor? Bu değer INP için kritik eşiktir.
• Façade (ön yüz) yaklaşımını değerlendirin. Sohbet widgetı, video oynatıcı veya harita gibi ağır bileşenler için ilk etkileşime kadar gerçek scripti yüklemeyen bir ön yüz (façade) kullanılabilir. Kullanıcı etkileşim göstermeden sayfa bu bileşeni yüklemez.
• Tag manager içindeki tetikleyicileri kontrol edin. Etiket yöneticisi kullanılıyorsa içindeki her etiketin hâlâ geçerli bir tetikleyiciye sahip olduğunu doğrulayın. Tetikleyicisi silinmiş ama etiketi aktif kalan yapılandırmalar sık rastlanan artık yüktür.

JavaScript ve CSS yükündeki birikim

Yaz boyunca eklenen özellikler JavaScript bundle boyutunu büyütür. Yeni bir slider kütüphanesi, bir form doğrulama paketi, bir tarih seçici bileşeni; her biri tek başına makul görünür, ama toplamı hızla birkaç yüz kilobayta ulaşabilir. Asıl sorun, bu scriptlerin büyük bölümünün yüklendikten sonra çalışmayı bekleyen kod kitlesi oluşturmasıdır.

• Bundle boyutunu karşılaştırın. Derleme aracınız bir analiz çıktısı üretiyorsa Haziran başı ile bugünü kıyaslayın. Hangi paket boyut artışının büyük bölümünden sorumlu?
• Kullanılmayan CSS'i tespit edin. Tarayıcı geliştirici araçlarının Coverage sekmesi, sayfada çalıştırılmayan CSS ve JS satırlarını gösterir. Yüksek oranda kullanılmayan CSS genellikle kaldırılan bir bileşenin stillerinin temizlenmemiş olduğuna işaret eder.
• Render-blocking kaynakları kontrol edin. <head> içindeki her <link rel="stylesheet"> ve senkron <script>, ilk boyamayı geciktirir. Kritik olmayan stil dosyaları media özelliğiyle veya JavaScript ile yüklenebilir.
• Kullanılmayan kütüphaneleri kaldırın. Yaz kampanyası için eklenen ama artık aktif olmayan slider, lightbox veya animasyon kütüphanelerini bağımlılıktan çıkarın. Bir kütüphane sayfada referans almıyor olsa bile bundle'a dahilse yüklenir.
• Font yükleme stratejisini gözden geçirin. Yaz döneminde eklenen yeni bir yazı tipi ailesi, ek font ağırlıkları veya Google Fonts bağlantısı FCP'yi geciktirebilir. font-display: swap ve <link rel="preconnect"> kullanımını kontrol edin.
• Preload yanlışlıklarını tespit edin. <link rel="preload"> yanlış kaynağa yönlendirilmişse tarayıcı kaynak indirip kullanmaz ve konsolda uyarı verir. Yaz boyunca eklenen preload etiketlerini doğrulayın.

Küçük paketler bazen büyük paketlerden daha yavaş yüklenebilir. Asıl darboğaz boyut değil, sıralamadir: kritik olmayan büyük bir script, kritik içeriğin önüne geçiyor mu?

TTFB ve sunucu yanıt süresi: yaz yükünün izleri

Yaz trafiği sunucuyu zorlar. Veritabanı sorguları optimizasyonu yapılmadan kalmış, önbelleksiz dinamik sayfalar artmış, kaynak limitlerine yaklaşılmış olabilir. Yüksek TTFB her şeyin gerisini ötelediğinden, 800 milisaniyenin üzerinde bir sunucu yanıt süresi diğer tüm optimizasyonları gölgeler.

• TTFB'yi ölçün, ana sayfayla sınırlı kalmayın. Kampanya açılış sayfaları, ürün listeleme sayfaları ve sepet gibi dinamik sayfaları ayrı ayrı ölçün. Hangi sayfa tipi en uzun sunucu yanıt süresine sahip?
• Sunucu tarafı önbellekleme aktif mi? Yaz döneminde bir güncelleme sırasında sayfa önbellekleme devre dışı bırakılmış veya yanlış yapılandırılmış olabilir. Önbelleklenmiş ve önbelleklenmemiş sayfa arasındaki TTFB farkını ölçün.
• Veritabanı sorgu sürelerini inceleyin. Yaz içinde eklenen yeni filtreler, sıralama seçenekleri veya öneri motorları beklenmedik sorgu yükleri yaratmış olabilir. Yavaş sorgu günlüğünü kontrol edin.
• Kaynak kullanımını izleyin. CPU ve bellek kullanımı yaz dönemindeki zirve trafikten sonra normal seviyeye düşmüş mü? Bazı süreçler zirve sonrasında da yüksek kaynak tüketmeye devam eder.
• CDN'in HTML'yi önbelleğe alıp almadığını doğrulayın. CDN yalnızca statik varlıkları değil, HTML yanıtlarını da önbelleğe alabilir. Oturum açmış kullanıcılar için önbellek bypass doğru yapılandırılmışsa bu büyük bir TTFB kazancı sağlar.

Yaz sonrası yönlendirme ve bağlantı temizliği

Sezonluk sayfalar genellikle geçici URL'lerle yayınlanır ve sezon bitince ya kaldırılır ya 404 verir. Bu durum hem kullanıcı deneyimini hem de sayfa yükleme süresini olumsuz etkiler; her 301 zinciri ek bir ağ gidiş-dönüşü anlamına gelir.

• Aktif olmayan kampanya URL'lerini kontrol edin. Yaz boyunca yayınlanan açılış sayfası URL'lerinin hangi HTTP yanıt kodu döndürdüğünü kontrol edin. 404 veren URL'lere bir 301 yönlendirmesi ekleyin veya içeriği arşivleyin.
• Yönlendirme zincirlerini kısaltın. A URL'si B'ye, B URL'si C'ye yönlendiriliyorsa A'yı doğrudan C'ye yönlendirin. Her zincirleme adım TTFB'ye eklenir ve tarayıcı önbelleği yalnızca son hedefi önbellekler.
• İçerideki bağlantıları güncelleyin. Sitenizdeki başka sayfalar artık mevcut olmayan bir kampanya sayfasına bağlantı veriyor olabilir. Kırık iç bağlantılar hem kullanıcı deneyimini bozar hem de gereksiz yönlendirme yükü oluşturur.
• Sitemap'i güncelleyin. Kaldırılan sayfalar XML sitemap'te hâlâ listeleniyorsa güncelleyin. Arama motorunun kaldırılmış sayfaları taraması hem kaynak israfıdır hem de indeks temizliğini geciktirir.
• Canonical etiketleri doğrulayın. Yaz kampanyası için oluşturulan UTM parametreli varyantlar ya da A/B test URL'leri canonical olmayan bir sayfaya işaret eden canonical etiketi bırakmış olabilir.