Angular uygulaması nasıl hızlanır? Ölçümden iyileştirmeye pratik bir yol

Önce ne yavaş, onu ölçün

Performans çalışması tahminle değil ölçümle başlar. Angular yavaşlığı farklı yerlerde yaşanır: sayfa ilk açılırken (yükleme performansı) ve kullanıcı etkileşirken (çalışma zamanı performansı). Yükleme yavaşsa sorun genellikle indirilen kod miktarı, görseller ve sunucu yanıtıdır; etkileşim yavaşsa sorun çoğunlukla değişiklik algılamanın çok sık ya da gereksiz yere çalışması veya ağır hesaplardır.

Resmî belge ölçüm için Angular DevTools'u ve Chrome DevTools profilleyicisini anar. Pratik yöntem: yavaş hissettiğiniz akışı belirleyin (örneğin büyük bir tablo ekranı), tarayıcı profilleyicisiyle kaydedin, zamanın nerede harcandığına bakın. Optimizasyondan önce ve sonra aynı senaryoyu ölçmezseniz iyileşmenin gerçek olup olmadığını bilemezsiniz.

Değişiklik algılama: ne zaman, nerede çalışır?

Değişiklik algılama, Angular'ın uygulama durumunun değişip değişmediğini ve DOM'un güncellenmesi gerekip gerekmediğini kontrol ettiği süreçtir. Belgeye göre çok sık çalıştırılırsa yavaşlatabilir. Varsayılan modda bir olay oluştuğunda bileşen ağacının büyük bölümü kontrol edilir; ağaç büyüdükçe bu kontrol pahalılaşır.

Bunun tipik nedenleri şunlardır: büyük ve derin bileşen ağaçları, şablonda çağrılan ağır fonksiyonlar ve sık tetiklenen asenkron olaylar (zamanlayıcılar, kaydırma ve fare hareketi dinleyicileri). Belge ayrıca "zone pollution" olarak adlandırılan durumu anar: Angular bölgesi içinde çalışan ve değişiklik algılamayı gereksiz yere tetikleyen asenkron işler. Çözüm, bu işi Angular dışında çalıştırmak ya da gereksiz tetiklemeyi azaltmaktır.

OnPush ile bileşen alt ağaçlarını atlamak

OnPush stratejisi, bir bileşen alt ağacını yalnızca gerektiğinde kontrol ettirir. Belgeye göre kontrol şu durumlarda yapılır: alt ağacın kök bileşeni, şablon bağlamasıyla yeni bir girdi aldığında ya da alt ağacın kök bileşeninde veya herhangi bir çocuğunda bir olay işlendiğinde. Girdi karşılaştırması Object.is ile yapılır; yani nesne içeriğini yerinde değiştirirseniz değişim fark edilmez.

Kullanım: bileşen dekoratöründe changeDetection: ChangeDetectionStrategy.OnPush yazılır. Bunun pratik koşulu, durumu değişmez şekilde güncellemektir: listeye eleman eklemek yerine yeni bir liste üretip girdiye vermek gibi. Bu disiplini sinyallerle birlikte kullanmak da kolaylaşır; sinyal okuyan bileşenler değerler değiştiğinde güncellenir. Büyük tabloların satır bileşenleri, kartlar ve liste öğeleri OnPush için ilk adaylardır.

Yükleme performansı: tembel rota ve @defer

Kullanıcı ilk sayfayı görmek için tüm uygulamayı indirmek zorunda olmamalıdır. Belge yükleme performansı için şu araçları sıralar: tembel yüklenen rotalar, @defer ile şablon parçalarının ertelenmesi, servislerin tembel yüklenmesi, görsel optimizasyonu ve sunucu tarafı render (SSR).

Tembel rota, yalnızca kullanıcı o sayfaya gidince indirilen koddur:

{ path: 'raporlar', loadComponent: () => import('./raporlar/raporlar').then(m => m.Raporlar) }

@defer ise bir şablon parçasını (örneğin sayfanın altındaki ağır bir grafik) görünür olduğunda ya da bir tetikleyiciden sonra yüklemeyi sağlar. Mantık şudur: ilk ekranda gerekmeyen her şey ertelenebilir. Yönetim paneli gibi çok sayfalı kurumsal uygulamalarda her özellik alanı kendi tembel paketinde olursa ilk açılış belirgin biçimde hafifler.

Şablon ve hesap maliyeti

Şablonda ifade olarak çağrılan bir fonksiyon, değişiklik algılamanın her turunda yeniden çalışır. Ağır bir filtreleme, sıralama ya da biçimlendirme fonksiyonunu şablondan çağırmak, ekranı yavaşlatan klasik bir hatadır. Çözümler: sonucu bir kez hesaplayıp alanda saklamak, hesaplamayı sinyal tabanlı computed içine taşımak (girdiler değişmedikçe yeniden hesaplanmaz) ya da saf bir pipe kullanmak.

Listelerde @for kullanırken track ifadesini anlamlı seçin; kayıtların benzersiz kimliğini verirseniz Angular listeyi güncellerken yalnızca değişen öğelere dokunur, tüm satırları yeniden çizmez. Çok uzun listelerde yalnızca ekranda görünen satırları çizen sanal kaydırma gibi tekniklere ihtiyaç duyabilirsiniz. Belge bu başlıkta yavaş hesaplamaların azaltılmasını ayrıca ele alır.

Örneğin müşteri listesi ekranında her satırda toplam bakiyeyi şablondan çağırılan bir fonksiyonla hesaplıyorsanız, ekrandaki küçük bir olay bile tüm satırların yeniden hesaplanmasına yol açar. Bakiyeyi veri geldiğinde bir kez hesaplayıp satır nesnesinde saklamak ya da computed ile türetmek aynı işi çok daha ucuza yapar. Bu tür bir değişiklik, kod karmaşıklığını artırmadan en görünür kazancı sağlayan müdahalelerden biridir.

Zonesuz çalışma, görseller ve sunucu tarafı render

Belge, zone tabanlı tetiklemeden bağımsız çalışan zoneless modunu da ayrı bir kılavuz olarak sunar. Bu mod, değişiklik algılamanın yalnızca gerçekten ilgili durumda tetiklenmesini hedefler ve sinyal tabanlı bir uygulamayla doğal biçimde uyumludur. Geçmeden önce kullandığınız kütüphanelerin ve sürümünüzün buna uygun olup olmadığını resmî belgeden kontrol edin.

Görseller çoğu sayfada en büyük indirme kalemidir. Boyutu ekranda gösterilecek alana uygun, doğru biçimde sıkıştırılmış ve gerektiğinde tembel yüklenen görseller ilk açılışı hızlandırır; belge görsel optimizasyonunu ayrı bir başlık olarak anar. SSR ise sayfanın ilk halini sunucuda üretip tarayıcıya hazır göndererek algılanan hızı ve arama motoru görünürlüğünü destekleyebilir; ancak sunucu maliyeti ve kurulum karmaşıklığı getirir, bu yüzden gerçekten ihtiyaç duyulan sayfalar için değerlendirilmelidir.

Sıralı kontrol listesi ve Mindset bağlamı

Bir performans iyileştirme turu için kullanışlı sıra:

• Yavaş senaryoyu seçin ve profilleyiciyle ölçün.
• Yükleme mi çalışma zamanı mı yavaş, bunu ayırın.
• Yükleme yavaşsa: tembel rotalar, @defer, görseller, paket içeriği.
• Çalışma zamanı yavaşsa: şablondaki fonksiyonlar, OnPush, @for track, zone pollution.
• Her değişiklikten sonra aynı senaryoyu yeniden ölçün; iyileşme yoksa değişikliği geri alın.

Mindset'in Angular ile Kurumsal Web Uygulamaları programındaki "Performans, Test ve Dağıtım" modülü bu çalışmayı testle ve dağıtımla birlikte ele alır. Veri yoğun yönetim ekranları geliştiren ve uygulamanın büyümesiyle yavaşlama yaşayan ekipler için uygundur; çünkü performans, sonradan eklenen bir iyileştirme olmaktan çok mimari kararların sonucudur.