Kod değiştirmeden önce bir müşteri yolculuğunu profilleyin
Önemli bir rota ve etkileşimi seçin; örneğin navigasyon açmak, sonuçları filtrelemek veya bir form göndermek. Bunu Chrome DevTools’un Performance panelinde temiz bir tarayıcı durumunda kaydedin. Eylemi tekrarlayın ve hem CPU sınırlı (throttled) bir çalışmayı hem de geliştirme makinesi çalışmasını yakalayın; masaüstü izleri, düşük güçlü bir telefonda rahatsızlık yaratan işleri gizleyebilir.
İzlemeyi (trace) bir bileşeni paket raporundan suçlamak için değil, dar bir hipotezi test etmek için kullanın. Main flame chart’ta daha geniş çubuklar daha uzun süren işleri, üst üste binen çubuklar ise çağrı yığını gösterir. Bir Task üzerindeki kırmızı üçgen potansiyel bir long task’i işaretler; onu seçin ve başlatan kod bağlantısını izleyin. Anlamlı değişiklikler için önce-sonra izlerini saklayın.
Eylemden hemen önce kayıt başlatın ve görünür sonuç sonrası durdurun.
Rota, hesap durumu ve eylem sırasını tutarlı tutun.
Her en yüksek maliyeti değiştirebilecek ekip veya tedarikçiye atayın.
İzlemeyi bir iş kuyruğu olarak okuyun
Uzun bir görev araştırma eşiğidir; tam bir tanı değildir. W3C Long Tasks spesifikasyonu 50 milisaniye veya daha uzun süren görevleri raporlar. Bir görevin altında JavaScript değerlendirme, olay işleyici, stil yeniden hesaplama, layout veya paint görünebilir. Çağrı yığını nereden başlanacağını gösterir; zamanlama sorunun kod mu, render mı yoksa üçüncü taraf bir frame mi olduğunu gösterir.
Değerli bir etkileşim sırasında tekrarlanan maliyeti önceliklendirin. Kısa bir handler, layout tetiklediğinde veya önceki işlerin arkasında beklediğinde yine de yavaş hissettirebilir. İzleme bir laboratuvar ölçümüdür; bu yüzden düzeltmeyi temsil eden cihazlarda ve mümkünse gizlilik-dostu saha telemetrisi ile doğrulayın.
Başlangıç ayrıştırması (startup parsing) bir dokunma sonrası handler’dan farklı bir çözüm gerektirir.
Refaktör etmeden önce tekrarlayan stil-yazma ve layout-okuma desenlerini bulun.
İzleme, senaryo ve en yüksek maliyetleri iş öğesine ekleyin.
Önemli olduğu anda daha az kod gönderin
Rotalara ve amaçlara göre script’leri envanterleyin. Kullanılmayan paketleri, kopyaları, emekliye ayrılmış deneyleri ve sona eren özelliklerin kodunu kaldırın. Ardından rota-özel veya nadiren kullanılan özellikleri, başlangıç akışında yüklenmek yerine gerektiğinde yüklenecek şekilde ayırın. Dinamik yükleme başlangıç işini azaltabilir, ancak kullanıcı özelliğe hemen ihtiyaç duyduğunda görünür gecikme yaratabilir.
Bir bileşenin tam bir istemci tarafı framework’e (client-side framework) gerçekten ihtiyacı olup olmadığını, bir yardımcı programın (utility) mevcut yeteneği kopyalayıp kopyalamadığını ve statik HTML artı küçük bir iyileştirmenin yeterli olup olmadığını sorun. Gecikmeli modülün yedek durumunu test edin. Sayfa, isteğe bağlı bir yeteneği ölü bir kontrol göstermek yerine kibarca ertelemelidir.
Bir rotada hangi script’lerin neden izinli olduğunu belgeleyin.
Bunun isteğe bağlı düzenleyiciler, haritalar, oynatıcılar veya raporlama görünümleri için düşünülebileceğini değerlendirin.
Kimlik doğrulama, erişilebilirlik, ödeme ve form tamamlamayı test edin; kontroller etkilendiğinde nitelikli inceleme isteyin.
Tarayıcının yanıt verebilmesi için işi parçalayın
Küçük fonksiyonlara ad vermek, senkron çalıştıklarında onları ayrı tarayıcı görevlerine dönüştürmez. Uzun bir döngüde işi partilere ayırın, kullanıcıya hemen görünen durumu güncelleyin ve devam etmeden önce tarayıcının kontrolü geri almasına izin verin. Böylece tarayıcı, partiler arasında kullanıcı girdisini işleyebilir ve ekranı güncelleyebilir.
Destekleniyorsa scheduler.yield() ana iş parçacığına yield eder ve daha sonra işi sürdürür; bunu feature-detect edin ve desteklenmeyen tarayıcılar için bir geri dönüş (fallback) kullanın. Her küçük işlemden sonra yield etmeyin: bunun bir yükü vardır ve tamamlanma süresini artırabilir. Ölçümlere göre sınırlar seçin, iptali koruyun ve eski sonuçların yeni durumu değiştirmesini önleyin.
Görünür olmayan takip işlerinden önce kabul veya ilerleme göstermek.
Öğe başına değil, ölçülen iş uzunluğu uzun hale gelmeden önce yield edin.
Mevcut web.dev rehberi isInputPending() temelli yeni bir stratejiyi önermemektedir.
Hesaplamayı, arayüzü değil, bir worker’a taşıyın
Bir Web Worker, ana yürütme iş parçacığından ayrı bir arka plan iş parçacığında bir script çalıştırır. Ağır ayrıştırma, veri dönüşümü, arama indeksleme ve doğrudan arayüz erişimi gerektirmeyen diğer maliyetli hesaplamalar için uygundur. Tanımlanmış bir girdi gönderin, tanımlanmış bir sonuç döndürün ve render ile görünür durum değişikliklerini ana iş parçacığında tutun.
Worker'lar evrensel bir çözüm değildir. DOM'u doğrudan değiştiremezler veya Window nesnesini kullanamazlar; mesajlaşma yoluyla iletişimde veriler kopyalanır. Worker oluşturma, veri taşıma ve hata koordinasyonunun getirdiği ek yük, küçük bir hesaplamanın sağlayacağı faydayı aşabilir. Tüm etkileşimi ölçün, gereksiz worker'ları sonlandırın ve worker işi başarısız olduğunda bir geri dönüş tasarlayın.
Girdisi ve çıktısı serileştirilebilir ve test edilebilir bir hesaplamayla başlayın.
Eski bir filtre, rota veya işlem için oluşturulmuş sonuçları atın.
Normal arayüz yoluyla anlamlı ilerleme bildirin.
Üçüncü taraf JavaScript’i üretim bağımlılığı olarak yönetin
Analitik, reklam, deneyler, sosyal gömme içerikler, video oynatıcılar ve destek widget’ları istek, JavaScript değerlendirmesi, iframe’ler ve bağımlılıklar ekleyebilir. Bir sağlayıcı script’i gerekli olabilir, ancak uygulama ekibinin doğrudan kontrolü dışında kalır ve performans, gizlilik, güvenlik ve süreklilik üzerinde etkili olabilir. Amacını, rotalarını, yükleme koşulunu, onaylayıcısını, izin gereksinimini ve kaldırma sahibini envanterleyin.
Koşullar ve sözleşmeler izin verdiğinde, temsilî bir sayfayı belirli bir üçüncü taraf kaynağı etkin ve devre dışıyken karşılaştırın. Performans araçları maliyetli değerlendirmeyi, yükleri ve uzun görevlere ilişkin kaynak atfını gösterebilir. Belgelendirilmiş değeri, ölçülen maliyetini haklı çıkarıyorsa hafif veya gecikmeli bir entegrasyonu koruyun. İsteğe bağlı bir bağımlılık yavaş veya kullanılamaz olduğunda temel içeriğin ve ana işlemin çalıştığını doğrulayın.
Bir etiketi yalnızca ihtiyaç duyan rotalar ve koşullar için yükleyin.
Tag-manager değişikliklerini performans, gizlilik, güvenlik ve geri alma incelemesine dahil edin.
Kritik olmayan entegrasyonu devre dışı bırakma prosedürünü belgeleyin ve test edin.
Yanıt verebilirliği bir sürüm emniyeti (release safeguard) yapın
Başarılı sonucu gösteren performans kaydını, önemli yolculuk için küçük bir regresyon kontrolüne dönüştürün. Kapsanan etkileşimleri, cihaz veya CPU kısıtını, beklenen yanıtı ve inceleyiciyi tanımlayın. Bunu paket ve üçüncü taraf envanteri incelemesiyle birlikte kullanın; böylece yeni bir paket veya etiket ana iş parçacığı yükünü fark edilmeden yeniden getiremez.
Status Is UP bu kanıtı proaktif optimizasyon ve güvenli düzeltme için kullanır; bu yaklaşım canlı kullanılabilirlik izlemenin yerine geçmez. Yüksek riskli bir değişiklikten önce geri alma hazırlayın ve sürüm sonrasında kritik akışı doğrulayın. Sonuçlar cihaz, ağ, tarayıcı, içerik ve hesap durumuna göre değişir; eşik değerlerini garanti değil, koruyucu hatlar olarak ele alın.
Paylaşılan gezinme, ödeme, arama veya büyük paketler için önce-sonra izleri şart koşun.
Bilinen iyi davranışı geri getiren özellik bayrağı, etiket ayarı veya dağıtım sürümünü bilin.
Büyük sürümler, sağlayıcı değişiklikleri veya cihaz-karışımı kaymaları sonrası tekrar profilleyin.