Optimize Etmeden Önce Ölçün: Paul Irish'in Hız Çalışma Akışı

Neden önce optimize etmek genellikle zaman kaybettirir

Performansla uğraşmak, düzeltmelerle başlarsanız rastgele hissedilir. Bir gün dosyaları küçültürsünüz, ertesi gün önbelleği ayarlarsınız, sonra bir kütüphaneyi kaldırırsınız. Bazen işe yarar. Bazen hiçbir şey değişmez ve nedenini bilmezsiniz.

En büyük risk yanlış şeyi optimize etmektir. Sayfa JavaScript yüzünden ana iş parçacığı tarafından engelleniyorsa, saatlerce resimleri sıkıştırmak pek bir etkisi olmayabilir. Ya da kullanıcıların fark etmediği bir şeyi hızlandırırken gerçek gecikme uzun bir API çağrısı, sürekli yeniden hesaplanan bir layout veya tek bir engelleyici script olabilir.

Ayrıca "hissediliyor daha hızlı" tuzağı var. "Daha hızlı hissetmek" bir yükleniyor göstergesinden kaynaklanan plasebo etkisi olabilir ya da farklı bir ağda, cihazda veya saatte test ettiğiniz için olabilir. "Daha hızlı" demek, aynı eylemin aynı koşullar altında daha iyi sayılar ürettiği anlamına gelir.

Bunun çoğunu düzelten basit bir söz var: optimize etmeden önce ölçün, sonra karar verin. Performansı bir ölçüm problemi olarak gördüğünüzde tahmin etmeyi bırakırsınız, öğrenmeye başlarsınız.

Pratik bir döngü şöyle görünür: iyileştirmek istediğiniz tek bir kullanıcı eylemini seçin, tekrarlanabilir koşullarda bir temel değer kaydedin, açıklayabileceğiniz tek bir değişiklik yapın, sonra yeniden ölçün ve sayılar iyileşirse değişikliği tutun.

Paul Irish ve önce ölçme alışkanlığı

Paul Irish web performansının en bilinen seslerinden biridir. Tarayıcı araçları ve performans rehberliği üzerindeki çalışmalarıyla basit bir fikri popülerleştirdi: ilk işiniz yavaş olanı tahmin etmek değil, onu kanıtlamaktır.

Bu zihniyet ekip dinamiklerini değiştirir. "Resimler her zaman sorun" veya "kesin çatı (framework) yüzünden" gibi alışkanlıklardan tartışmak yerine, kanıtla başlamış olursunuz. Bir zaman çizelgesine, yavaş bir sorguya veya uzun bir göreve işaret edebildiğinizde, konuşma suçlamadan çözümlere kayar.

"Optimize etmeden önce ölçün" ayrıca performans tartışmalarını soğutur çünkü ortak kurallar oluşturur: neyi ölçtüğünüzde anlaşın, "daha iyi"nin ne anlama geldiğinde anlaşın ve sayılar hareket ettiğinde kutlayın.

Bu küçük sitelerde de büyük uygulamalarda da işe yarar. Tek bir başlangıç ölçümü bir pazarlama sayfasındaki rastgele mikro-optimizasyonları durdurabilir. Büyük bir üründe ise tutarlı ölçümler performansın bitmek bilmeyen bir yapılacaklar listesine dönüşmesini engeller.

Bunu gerçeğe dönüştürmenin basit bir yolu performansı bir hata raporu gibi ele almaktır: yeniden üretme adımları, gördüğünüz metrik ve tek bir değişiklik ile tek bir sonuç. İki kişi anlaşamazsa, ölçümü yeniden çalıştırın ve verilerin karar vermesine izin verin.

Performansı önce enstrümantasyon problemi olarak görmek

Önce performansı bir enstrümantasyon problemi olarak ele alın: kullanıcıların gerçekten ne deneyimlediğini gözlemlemenizi sağlayacak yollar ekleyin. Görmüyorsanız, fikirlerden değil kanıttan tartışırsınız. Bu, önce ölçmenin gerçek anlamıdır.

Enstrümantasyon karmaşık olmak zorunda değil. Tutarlı olarak ve aynı yerlerde birkaç sinyal toplamak, temel soruları cevaplamanızı sağlar:

• Ne yavaş hissediliyor?
• Zaman nereye gidiyor?
• Değişikliğimiz yardımcı oldu mu?

Genellikle iki tür veri istersiniz.

Lab verisi kontrollü bir kurulumda yakalanır: belirli bir dizüstü/cihaz, sabit bir ağ profili, her koşu aynı adımlar. Tekrar üretilebilir olduğu için hata ayıklama için iyidir.

Gerçek kullanıcı verisi (RUM) ise kullanıcıların vahşi doğada deneyimledikleridir: farklı cihazlar, konumlar ve bağlantı kalitesi. Gerçek kullanıcı verisi önceliklendirme için iyidir çünkü sadece bir test koşusunu değil gerçek kullanıcıya zarar verenleri gösterir.

Uzman olmasanız bile sayfa yükleme kilometre taşlarını (ör. ilk içerik gösterimi), uzun görevleri ve ana iş parçacığı blokajlarını, yavaş ağ isteklerini, pahalı render işini (layout, style, paint) ve sunucu yanıt süresini ölçebilirsiniz.

Bu sinyaller genellikle birkaç yerde bulunur: lab profilleme için tarayıcı geliştirici araçları (DevTools), backend zamanlaması için sunucu günlükleri ve izleri, gerçek kullanıcı verisi için analytics veya RUM panoları. Örneğin ödeme adımı yavaş hissediliyorsa, DevTools büyük bir sepet UI'sı render ederken tarayıcının meşgul olduğunu gösterirken sunucu günlükleri API'nin hızlı olduğunu gösterebilir. Enstrümantasyon yoksa backend'i optimize edersiniz ve gerçek problemi hiç çözemezsiniz.

Adım 1: Tekrarlanabilir bir başlangıç ölçümü (baseline) belirleyin

Optimize etmeden önce ölçmek için güvenebileceğiniz bir başlangıç noktasına ihtiyacınız var. Bir başlangıç ölçümü aynı eylem, aynı şekilde, aynı koşullar altında ölçülmüş olandır.

Bir gerçek kullanıcı yolculuğuyla başlayın, "tüm site" ile değil. Bir cümleyle tanımlayabileceğiniz bir şey seçin: "ana sayfayı açıp ilk ürün ızgarasına kaydır" veya "giriş yapıp panoya ulaş" gibi. Dar tutmak sayıları daha dengeli ve sonraki adımları daha net yapar.

Sonra yolculuğa uyan 1–3 metrik seçin. Bir sayfa görüntüleme için yaygın bir çift LCP (ana içerik ne kadar hızlı görünüyor) ve TTFB (sunucu ne kadar hızlı yanıt veriyor). Bir akış için (ör. checkout), adım 1 tamamlama süresi artı ödeme çağrısı için API yanıt süresini izleyebilirsiniz. Çok fazla metrik seçmek, istastistikleri seçme eğilimini artırır.

Test kurulumunu bir başkasının tekrar üretebilmesi için yazın. Küçük farklar sonuçları değiştirebilir:

• Cihaz ve tarayıcı (sürüm dahil)
• Ağ (wifi vs 4G, throttling açık/kapalı)
• Önbellek durumu (soğuk vs sıcak)
• Konum ve test verisi (bölge, hesap tipi, sepet büyüklüğü)
• Koşu sayısı (örneğin 5 koşu ve medyanı kullan)

Son olarak, hedef kitleniz için "yeterince iyi"nin ne olduğunu tanımlayın. Örneğin: "Orta seviye bir telefonda 4G üzerinde LCP 2.5s altında." Eğer Koder.ai kullanıyorsanız, testten önce bir snapshot almak başlangıç ölçümünüzü bilinen bir sürüme bağlamaya yardımcı olur.

Adım 2: Yavaşlamayı kasıtlı olarak yeniden üretin

Herhangi bir şeyi profillemeden önce, sorunun tekrar oluşmasını sağlayın. Tekrar edemiyorsanız sonuca güvenemezsiniz.

İnsanların hissettiği yerden başlayın, varsaydığınız yerden değil. İlk render mı yavaş? Bir tıklama bekleme mi yaratıyor? Bir form gönderildikten sonra uzun bir bekleme mi var? Kullanıcıların şikayet ettiği anı seçin ve oraya odaklanın.

Küçük bir koşu yaparak yavaşlamanın gerçek ve tekrarlanabilir olduğunu doğrulayın. Diğer her şeyi aynı tutun: aynı sayfa, aynı cihaz, mümkünse aynı ağ. Sonra tetikleyiciyi ve tam olarak hangi anın yavaş hissettirdiğini yazın: "Pay'a tıkladıktan sonra buton bir saniye donuyor" veya "ürün listesi göründüğünde kaydırma takılıyor" gibi.

Tekrarlanabilir tutmanın basit bir yolu minik bir betik yapmaktır: sayfayı temiz bir sekmeden aç, yavaş eylemi yap, tam olarak nerede yavaşladığını not et, sonra bir kez daha tekrarla.

Bir veya iki temel kayıt yakalayın, onlarca değil. Yeterli kanıt olmalı: "Evet, yavaşlama oluyor ve tam olarak burada oluyor."