1. Sonucu ve sınırı tanımlayın
Bir denetim aracını açmadan önce bir sorumlu belirleyin ve hedeflenen sonucu yazın. Hedef kitleyi, yolculuğu, sayfaları veya rotaları, zaman aralığını ve çalışmanın destekleyeceği kararı belirtin. Faydalı bir hedef, siteyi hızlandırmak gibi belirsiz bir istek yerine, mobilde ürün sayfasından sepete ekleme akışını tamamlama gibi belirli bir görevi tanımlar.
Müzakere edilemezleri listeleyin: çalışan satın alma veya sorgu akışı, hesap erişimi, onay davranışı, erişilebilirlik, arama taranabilirliği ve onaylanmış içerik. Sentetik bir skor artışı, bir form başarısız oluyorsa, içeriğin aramadan gizlenmesine veya klavye kullanımının zorlaşmasına neden oluyorsa zafer değildir.
Başlangıç sayfasını, kullanıcı eylemini ve başarılı bitiş durumunu tek cümlede yazın.
Başarılı gönderim veya yeni bir erişilebilirlik engelleyicisinin olmaması gibi kötüleşmemesi gereken bir sonucu seçin.
2. Karşılaştırılabilir bir başlangıç (baseline) kaydı alın
Kod, içerik, yapılandırma veya etiketleri değiştirmeden önce URL listesini, tarihi, test koşullarını, sürüm bilgisini, raporları veya izleri ve elle yapılan görev sonuçlarını kaydedin. web.dev, değişikliklerden önce site durumunun kaydedilmesini ve birden çok sayfa türünün test edilmesini önerir; tek sayfa uygulamaları (single-page applications) için yalnızca ilk yüklemeyi değil, rotaları, bileşenleri ve akışları da dahil edin.
Birden fazla bakış açısı kullanın. Lighthouse otomatik olarak performans, erişilebilirlik, SEO ve diğer denetimleri sağlar. Temiz depolama veya temiz profil ile ilk yüklemeyi test edin, sonra hedef görevi tamamlayın. Yeterli gerçek kullanıcı verisi varsa, önemli sayfa grupları ve cihaz sınıflarını karşılaştırın. Core Web Vitals alan ölçümlerdir: LCP yüklemeyi, INP etkileşimi ve CLS görsel kararlılığı kapsar.
Alan verisi gerçek ziyaretleri yansıtır; laboratuvar testi sorunu yeniden üretmeyi kolaylaştırır. Mümkünse her ikisini de kullanın.
Simüle edilmiş bir yük INP'yi ölçemez çünkü gerçek kullanıcı girdisi yoktur; lab'deki Total Blocking Time yalnızca bir vekildir.
3. Yolculuğu baştan sona denetleyin
Bulguları yolculuk ve mekanizma bazında gruplayın. Sayfa varlıkları ve üçüncü taraflar için istek boyutu, zamanlaması ve bağımlılıklarını inceleyin. Mobil görünüm alanını, klavye yolunu, görünen odak durumunu, etiketleri, hataları, başlıkları, bağlantı amacını, yakınlaştırmayı ve bir resim, betik veya onay bağımlı hizmet yavaş veya kullanılamazsa ne olduğunu kontrol edin.
Otomatik erişilebilirlik çıktısını triage (ön eleme) olarak değerlendirin. W3C, hiçbir aracın tek başına bir sitenin erişilebilirlik standartlarını karşılayıp karşılamadığını belirleyemeyeceğini söyler; bilgili insan değerlendirmesi gereklidir. Arama için önemli olan render edilmiş kaynakların hem tarayıcılara hem kullanıcılara erişilebilir kalmasını sağlayın. Değişiklik bunları etkiliyorsa yönlendirmeler, canonical'lar, dahili bağlantılar, robots yönergeleri, site haritaları ve yapılandırılmış verileri dahil edin.
Görevin dayandığı etiket yöneticileri, analiz, sohbet, ödeme, fontlar, CDN'ler, API'ler ve onay araçlarını listeleyin.
Ödeme, kimlik doğrulama, kullanıcı verisi, başlıklar veya güvenlik kontrolleri için nitelikli güvenlik ve ödeme incelemesi alın.
4. Sıralanmış bir bekleme listesi (backlog) oluşturun
Her öğe için küçük bir hipotez yazın: bu sayfada veya akışta, kanıt bunun bu soruna neden olduğunu gösterdiği için bu mekanizmayı değiştiriyoruz; beklenen sonucu ölçün ve adlandırılmış koruyucu hatları (guardrails) koruyun. Gözlem ile tanıyı ayrı tutun. Kaydedilmiş bir iz büyük bir resmin içeriği geciktirdiğini gösterebilir, ancak çözüm yine tasarım ve içerik incelemesi gerektirir.
Öğeleri Etki (Impact), Güven (Confidence), Çaba (Effort) ve Risk'e göre sıralayın. Etki öncelikli yolculuktur. Güven laboratuvar, alan ve elle kanıtların uyup uymadığıdır. Çaba yalnızca kod değil, koordinasyonu da içerir. Risk bağımlılıklar, güvenlik, sürüm karmaşıklığı ve geri alınabilirliği içerir. Kritik işlevsel veya güvenlik açığı bu modeli geçebilir ve uzman triyajı gerektirir.
Sahip, kanıt bağlantısı, hipotez, sayfalar, ölçüm, koruyucu hatlar, bağımlılıklar, yayın yöntemi ve geri alma tetikleyicisini tutun.
Güvenlik gerektirmedikçe ilgisiz refaktörleri ölçümlü bir değişikliğe dahil etmeyin.
5. Güvenli yayınlayın ve geri dönüş yolunu koruyun
Yayınlamadan önce neyin değiştiğini, onaylayanı, yayın penceresini, doğrulama sahibini, başarı koşulunu, geri alma tetikleyicisini ve geri yükleme yöntemini kaydedin. Mümkünse, içerik, izinler, entegrasyonlar, yönlendirmeler, onay tercihleri ve yaygın hata yolları dahil olmak üzere temsil edici bir üretim dışı ortamda test edin. Üretim yine de veri, önbellek, yapılandırma ve üçüncü taraflar nedeniyle farklı olabilir.
Platform destekliyorsa küçük bir kademeli dağıtım, özellik bayrağı, versiyonlanmış varlık veya tersine çevrilebilir yapılandırma kullanın. Sonuçları karşılaştırmadan önce önbellek ve CDN davranışını doğrulayın. OWASP, yapılandırma ve dağıtım yönetimini güvenlik testi alanı olarak ele alır; başlıklar, izinler, dosya maruziyeti ve alan veya bulut ayarları tesadüfi optimizasyon değişiklikleri olmamalıdır.
Başarısız ödeme işlemi, kırık gezinim, beklenmedik istemci hatası veya erişilebilirlik regresyonu gibi gözlemlenebilir bir tetikleyici tanımlayın.
Geri alma planı kurtarma süresini azaltabilir ancak tüm riskleri ortadan kaldıramaz; güvenmeden önce geri yüklemeyi test edin.
6. Doğrulayın, karar verin ve tekrarlayın
Yayın sonrası, temel işlevsel kontrolleri ve karşılaştırılabilir laboratuvar testlerini tekrarlayın. İlgili cihazları, tarayıcıları, durumları ve entegrasyonları yeniden kontrol edin. Benzer ile benzeri karşılaştırın: URL, önbellek durumu, cihaz sınıfı, mümkünse bölge ve ölçüm penceresi. Hedef metriğin yanı sıra koruyucu hatları da doğrulayın.
Kanıtların olgunlaşması için zaman tanıyın. Google, arama değişikliklerinin görünür hâle gelmesinin saatlerden aylara kadar sürebileceğini ve işe yarayıp yaramadıklarını değerlendirmenin haftalar alabileceğini belirtir. Gerçek kullanıcı performans verisi toplu kanıttır; anlık bir yayın kararı için tek başına yeterli değildir. Değişikliği koruma, değiştirme, araştırma veya geri alma kararını kaydedin; ardından anlamlı bir şablon, platform, etiket, içerik veya bağımlılık değişikliğinden sonra yeni bir başlangıç ölçümü alın.
Beklenen yolculuk sonucu iyileşir ve kararlaştırılmış koruyucu hatlar sağlam kalır.
Alan verisi veya görev kanıtı laboratuvar sonucu ile çelişiyorsa veya kritik bir koruyucu hat gerilerse harekete geçin.