Uygulama Performansı: Metrikler, Darboğazlar ve İyileştirme

Uygulama performansının yayınlanmış eşikleri vardır; bu yüzden "yavaş hissettiriyor" hiçbir zaman doğru ayrıntı düzeyi değildir. Web'de Core Web Vitals çıtayı belirler: Largest Contentful Paint 2,5 saniyenin, Interaction to Next Paint 200 milisaniyenin, Cumulative Layout Shift 0,1'in altında. Mobilde Google Play, çökme veya ANR oranı kötü davranış eşiklerini aştığında uygulamayı işaretler ve kullanıcılar birkaç saniyeyi aşan soğuk açılışları terk eder.

Bu rehber neyin ölçüleceğini, darboğazların genellikle nerede olduğunu ve izlenim değil rakam üreten bir iyileştirme planının nasıl yürütüleceğini kapsar.

Önemli noktalar

• Ortalamayı değil 75. yüzdelik dilimi ölçün: Ortalamalar, gerçekten kötü olan dörtte birlik oturumu gizler.
• Saha verisi laboratuvar verisinden iyidir: Gerçek cihazlar, gerçek şebekeler; dizüstü bilgisayarınız temsilci bir cihaz değildir.
• Kazanımların çoğu üç yerdedir: Yük boyutu, veritabanı sorguları ve bekleyebilecek işi şimdi yapmak.
• Bir bütçe belirleyip hatta zorlayın: Bir derleme düşmedikçe performans sessizce geriler.

Doğru sayıları ölçün

Bunları 75. yüzdelik dilimde izleyin. 300 ms'lik ortalama yanıt süresi, kullanıcıların dörtte birinin üç saniye beklediğini gizleyebilir ve ayrılanlar onlardır.

Web vitals ayrıca aramayı etkiler: Google'ın sayfa deneyimi sinyallerinin parçasıdır, dolayısıyla bu yalnızca bir kullanılabilirlik sorusu değildir.

Yalnızca laboratuvar değil saha verisi kullanın

Laboratuvar araçları hızlı bir makinede hızlı bir bağlantıda çalışır ve size neyin mümkün olduğunu söyler. Saha verisi ne olduğunu söyler.

Üretimden gerçek kullanıcı izleme verisi toplayın; cihaz sınıfı, bağlantı türü ve coğrafyaya göre bölümlenmiş. Şehirdeki yeni bir telefonda iyi, kırsaldaki üç yıllık bir cihazda kötü çalışan bir ürünün, hiçbir laboratuvar testinin göstermeyeceği bir sorunu vardır, ve çoğu pazarda bu ikinci grup kullanıcıların büyük bölümüdür.

Mobilde mağaza konsolları zaten çökme, ANR ve açılış verisini cihaza göre bölümlenmiş sunar. Hiçbir maliyeti yoktur ve rutin olarak okunmaz.

Optimize etmeden önce darboğazı bulun

Ölçmeden optimize etmek, ekiplerin hiç kısıt olmayan bir şeye iki hafta harcamasının yoludur. Önce profilleyin, en büyük katkıyı düzeltin, sonra tekrar ölçün.

Darboğaz genellikle üç yerden birindedir:

Yük. Sıkıştırılmamış görseller, gereksiz yazı tipleri, tek bir ekranda kullanılan kütüphaneleri içeren JavaScript paketleri. En yaygın web sorunu ve çoğu zaman düzeltmesi en ucuz olanı.

Veritabanı. Eksik indeksler ve elli öğelik bir listenin elli bir sorgu tetiklediği N+1 deseni. En yaygın arka uç sorunu ve tipik olarak en büyük tekil iyileşmeyi üretir.

Bekleyebilecek iş. İstek sırasında hesaplanan ama önceden hesaplanabilecek, önbelleğe alınabilecek veya arka plana taşınabilecek her şey: küçük resim üretimi, rapor toplama, yanıt yolundaki üçüncü taraf çağrıları.

Genellikle önce karşılığını veren düzeltmeler

Web'de üçüncü taraf betikleri özel dikkat hak eder. Analitik, sohbet bileşenleri ve etiket yöneticileri sıklıkla etkileşim gecikmesine en büyük katkıyı yapar ve kimse maliyetini ölçmeden eklenirler.

Bir performans bütçesi belirleyin

Bütçe, performansı ara sıra yapılan bir projeden bir kısıta çevirir. Az sayıda sınır seçin, paket boyutu, LCP, 95. yüzdelikte API yanıtı, ve bir değişiklik bunları aştığında derlemeyi düşürün.

Bu olmadan performans sürüm sürüm bozulur; çünkü hiçbir tekil değişiklik açıkça sorumlu değildir. Her ekleme küçüktür; kullanıcıların hissettiği birikimdir.

Kontrolü sürekli entegrasyonda çalıştırın ki geri bildirim, değişiklik hâlâ yazılırken gelsin.

Algılanan performansı gerçek sayın

Kullanıcılar geçen süreyi değil yanıt verme hissini değerlendirir. Hemen yapı gösterip sonra dolan bir ekran, bekleyip tam görünen bir ekrandan hızlı hissettirir.

İskelet ekranlar, başarıyı varsayıp hatada düzelten iyimser güncellemeler ve muhtemel sonraki ekranı önceden yükleme; tek bir arka uç metriğini değiştirmeden deneyimi iyileştirir. Bunlar sıklıkla eşdeğer gerçek iyileştirmeden ucuzdur ve bazen daha önemlidir.

İstisna, para veya geri alınamaz eylem içeren her şeydir; orada sonradan başarısız olan iyimser bir güncelleme, dürüst bir beklemeden kötüdür.

Bunu birinin işi yapın

Performans, hiçbir şey engellemediği için geriler. Bir sahip atayın, saha metriklerini sabit aralıklarla gözden geçirin ve eşik aşımını tartışma değil kusur olarak değerlendirin.

Yeni işin bitmiş tanımına performansı dahil edin. Sonradan düzeltmek, en baştan gerilememekten her zaman pahalıdır ve kullanıcılara görünür hale geldiğinde genellikle onlarca sürüm boyunca birikmiştir.

İlgili rehberler

• Bunun zeminini kuran yazı şu: Yapay Zeka İş Akışı Otomasyonu: Kullanım Alanları ve Riskler.
• Bu yazının iyi bir tamamlayıcısı şu: Özel Yönetim Panosu Geliştirme: Metrikten Aksiyona.

Uygulama Performansı: Metrikler, Darboğazlar ve İyileştirme eski bir sistemden çıkışın maliyetini hesaplamanızı gerektiriyorsa Modernizasyon Planınızı Konuşalım.