Bu liste eksiksiz bir rehber değil; en sık gözden kaçan ve en yüksek etkiyi yaratan kontrol noktalarının derlemesidir. Her madde için kısa bir doğrulama yöntemi de yer alıyor. Amaç kontrolleri hafızaya yüklemek değil, her seferinde aynı soruların sorulmasını sağlamak ve bunu bir alışkanlığa dönüştürmektir.

Ağ katmanı: sıkıştırma, önbellekleme ve protokol

Sunucudan gelen yanıtların sıkıştırılıp sıkıştırılmadığı, DevTools Network sekmesinde yanıt başlıklarındaki Content-Encoding: br veya Content-Encoding: gzip değeriyle doğrulanır. Brotli destekleniyorsa tercih edilmeli; desteklenmiyorsa Gzip minimum gereksinimdir. Metin tabanlı tüm kaynaklar — HTML, CSS, JS, SVG, JSON — sıkıştırılmış olmalıdır.

Önbellekleme yapılandırması, statik varlıklar için Cache-Control: public, max-age=31536000, immutable ve HTML için Cache-Control: no-cache şeklinde kontrol edilir. Content hash ile versiyonlanmış CSS ve JS dosyaları uzun cache süresiyle servis edilebilir; HTML'in her zaman taze olması gerektiğinden cache'lenmemelidir. Network sekmesinde bir kaynağı tekrar yükleyip yanıt 304 Not Modified veya (from cache) döndürüyorsa, önbellekleme çalışıyor demektir.

Protokol kontrolü için DevTools Network sekmesinin Protocol sütunu açılır. Tüm kaynakların h2 veya h3 üzerinden yüklendiği doğrulanmalıdır. http/1.1 görünen kaynaklar varsa, sunucu veya CDN yapılandırması gözden geçirilmelidir. HTTP/2 multiplexing'den yararlanmak için alan adı başına bağlantı sayısını azaltmak — yani mümkün olduğunca az kaynaktan varlık yüklemek — tüm protokol avantajını gerçekleştirir.

Görseller: format, boyut ve yükleme önceliği

Tüm görsellerin WebP veya AVIF formatında sunulduğu, Network sekmesinde Content-Type başlığıyla doğrulanır. JPEG ve PNG kullanımı varsa bunların dönüştürülmesi veya <picture> etiketiyle modern format alternatifleri sunulması gerekir. Görsel boyutları için PageSpeed Insights'ın "Properly size images" uyarısı kontrol edilir; ekranda gösterilenden belirgin biçimde büyük görseller bant genişliğini boşa harcar.

LCP görseli için özel kontrol zorunludur: bu görsel loading="eager" ve fetchpriority="high" nitelikleriyle işaretlenmiş olmalıdır. Sayfa boyunca lazy loading uygulanmışsa, ekranın ilk görünür alanındaki (above the fold) görsellerin loading="lazy" almadığından emin olunmalıdır. DevTools'ta bir görselin LCP öğesi olup olmadığı Performance sekmesindeki LCP işaretçisiyle teyit edilir.

Responsive görsel yapılandırması da kontrol kapsamındadır. srcset ve sizes nitelikleri olmayan görseller, mobil ekranlarda desktop boyutunda görsel indirir. Bu yapılandırmanın doğruluğunu test etmek için DevTools'ta cihaz simülatörü açılır ve Network sekmesinde hangi görsel boyutunun gerçekten indirildiği gözlemlenir.

JavaScript: bundle boyutu ve üçüncü parti yük

Başlangıç JavaScript yükü için bir hedef belirlenmiş olmalıdır. Çoğu proje için 200 KB altında sıkıştırılmış JS, makul bir başlangıç noktasıdır; ancak bu eşik uygulamanın türüne göre değişir. Bundle analizi aracı — webpack-bundle-analyzer veya rollup-plugin-visualizer — son deploy öncesinde çalıştırılarak beklenmedik büyük bağımlılıklar kontrol edilir. Bir önceki deploy'dan bu yana anormal boyut artışı varsa nedenini anlamadan yayına çıkmak risklidir.

Code splitting yapılandırması, kullanıcının ilk açtığı sayfada ihtiyaç duymadığı bileşenlerin ayrı chunk'larda olduğunu güvence altına alır. Rota bazlı bölme uygulanmışsa, her rota için chunk boyutu gözden geçirilir. Çok büyük bir chunk varsa içinde ne olduğu araştırılmalıdır.

Üçüncü parti scriptler özel dikkat gerektirir. DevTools'ta Coverage sekmesi açılır ve sayfadaki tüm script'lerin ne kadarının gerçekten kullanıldığı incelenir. %30'un altında kullanım oranına sahip büyük bir üçüncü parti script, performans üzerinde orantısız bir yük oluşturabilir. Bu script'ler için gecikmeli yükleme veya facade pattern değerlendirilmelidir.

CSS ve kritik yol kontrolü

Render engelleyen CSS miktarı, DevTools Performance sekmesindeki kaynak yükleme zaman çizelgesinde görülür. Ana CSS dosyası büyükse ve <head>'de bloke edici biçimde yükleniyorsa, critical CSS ayrıştırılarak inline edilmeli; geri kalan stiller asenkron yüklenmelidir. Bu yaklaşım özellikle LCP süresini belirgin biçimde iyileştirir.

Kullanılmayan CSS kontrolü için DevTools Coverage aracı açılır ve stil dosyasının ne kadarının gerçekten kullanıldığı ölçülür. %60'ın altında kullanım oranı, PurgeCSS veya benzeri bir araçla kullanılmayan CSS'in temizlenmesini işaret eder. Özellikle büyük framework stilleri veya icon font CSS'leri bu kontrolde sıkça sorun olarak çıkar.

Font yükleme yapılandırması da kritik yol üzerindedir. Sayfada kullanılan fontlar için <link rel="preload"> direktifi veya font-display: swap ayarının etkin olduğu doğrulanmalıdır. Render tamamlanmadan önce font beklentisi varsa — FOIT durumu — kullanıcı boş bir sayfa görür. DevTools Network sekmesinde font dosyalarının yükleme zamanlaması incelenerek bu durum teyit edilir.

Core Web Vitals ve etkileşim kalitesi

Core Web Vitals kontrolü yayın öncesinde Lighthouse veya PageSpeed Insights ile yapılır. LCP için hedef 2,5 saniyenin altı, CLS için 0,1'in altı ve INP için 200 ms'nin altıdır. Bu değerlerin lab ortamında tutturulması sahada da iyi performans gösterileceğini garanti etmez; ancak ciddi sorunların varlığına işaret eder. Hızlı bir alternatif ölçüm için bir site analiz aracı üzerinden sayfayı taramak, Lighthouse verisiyle birlikte değerlendirmeye ek bir perspektif sunar.

CLS kontrolü için sayfa yükleme sırasında ve font'lar yüklendikten sonra herhangi bir düzen kayması olup olmadığı DevTools Performance sekmesindeki Layout Shift işaretçileriyle izlenir. Reklam alanları, dinamik yüklenen içerik ve boyutlandırılmamış görseller yaygın CLS kaynaklarıdır. Her resim ve video öğesinin width ve height nitelikleri veya CSS aspect-ratio değeri olduğu doğrulanmalıdır.

INP için test, kullanıcı etkileşimlerini simüle ederek yapılır: butonlara tıklamak, form doldurmak, menüyü açıp kapatmak. Her etkileşim DevTools Performance sekmesinde uzun görev oluşturuyor mu? 50 ms'yi aşan etkileşim görevleri INP'yi kötüleştirir ve incelenmelidir. Özellikle form submit, arama filtreleme ve sonsuz kaydırma etkileşimleri bu açıdan test edilmelidir.

Yayın öncesi performans kontrolünün asıl değeri, tek seferlik sorun tespitinden değil, ekip içinde sürdürülebilir bir alışkanlık oluşturmaktan gelir. Her ekip üyesinin aynı kontrol noktalarını gözden geçirdiği, herhangi bir deployment'ta aynı soruları sorduğu bir kültür, performansı kod kalitesiyle aynı statüye taşır. Bu liste bir güvence değil, bir başlangıç noktasıdır; zamanla proje ve ekiple birlikte şekillenir.

TTFB kontrolü, sunucu yanıt süresinin doğrudan ölçümüdür. DevTools Network sekmesinde ana HTML belgesinin Timing sekmesi açılır ve "Waiting for server response" süresi incelenir. 200 ms'nin altındaki TTFB iyi kabul edilir; 500 ms'yi aşıyorsa sunucu tarafında veya CDN yapılandırmasında sorun aranmalıdır. Aynı sayfayı farklı coğrafyalardan test etmek için WebPageTest gibi araçlar kullanılabilir; ülkeye ve ISS'e göre önemli farklar ortaya çıkabilir.

Güvenli bağlantı ve yönlendirme kontrolü de genellikle gözden kaçar. HTTP'den HTTPS'e yönlendirme tek adımda gerçekleşmeli; zincirleme yönlendirmeler her biri ekstra bir RTT maliyeti taşır. www ile non-www arasında doğrudan yönlendirme olup olmadığı da kontrol edilmelidir; iki aşamalı yönlendirme zinciri hem gecikme hem de tarayıcı önbellekleme açısından gereksiz yük oluşturur. Bu kontrol Network sekmesinde başlangıç URL'sini inceleyerek yapılır: kaç tane 301 veya 302 yanıtı göründüğü sayılır.

Performans bütçesi, bu kontrol listesinin üzerine oturacağı zemini sağlar. Hangi metrik için hangi eşiğin kabul edilebilir olduğu önceden kararlaştırılmışsa, her kontrol maddesinin geçti/kaldı kararı nesnel bir ölçüte dayanır. Bütçe belirlenmemişse kontrol sonuçlarını yorumlamak her seferinde yeniden tartışma gerektirir. Kısa bir belge — LCP için 2,5 sn, toplam JS için 250 KB, TTFB için 300 ms gibi — bu tartışmayı ortadan kaldırır ve ekip içinde ortak bir referans noktası oluşturur.

Bu listedeki maddelerin tamamını her deployment'ta tek başına kontrol etmek pratik olmayabilir. Bazı kontroller CI pipeline'ına otomatik testler olarak eklenir — Lighthouse CI, size-limit, bundle boyutu karşılaştırması — böylece insan müdahalesi gerektirmez. Otomatikleştirilemeyen kontroller — görsel kalite, üçüncü parti davranışı, gerçek cihazda etkileşim testi — daha kritik yayınlar öncesinde manuel olarak yapılır. İkisini birleştiren bir yaklaşım, en az çabayla en fazla güvenceyi sağlar.

Erişilebilirlik ve performans kesişim noktaları da bu süreçte gözden geçirilmelidir. alt niteliği eksik görseller hem erişilebilirlik hem de SEO açısından sorun yaratırken, width ve height eksikliği CLS'e katkıda bulunur. Lighthouse'un Accessibility ve Best Practices kategorileri bu tür sorunları otomatik olarak işaretler ve tek bir araçla birden fazla kontrol kategorisini kapsama alır. Ayrıca sayfada console.error veya JavaScript exception olup olmadığını DevTools Console sekmesinde kontrol etmek, yükleme sırasında sessizce başarısız olan özellik veya kaynak hatalarını ortaya çıkarır. Hata içeren bir sayfa, görünürde çalışıyor olsa bile ölçülemeyen bir yük taşıyabilir.