Performans, @defer ve SSR

Performans parçaları hattın içine dağılmıştı: bütçeler (1. ders), track (3. ders), lazy rota (7. ders), OnPush ve signals (9. ders). Bu ders parçaları bir teşhis sürecine bağlar: neyi, neyle ölçersin; hangi belirtiye hangi araç? Üstüne iki modern katman ekler: şablon içi tembellik (@defer) ve sunucu tarafı render (SSR + hydration) — "ilk boya neden geç?" sorusunun bugünkü cevapları. Sonda kısa bir ekosistem turu var: Material/CDK, i18n, animasyonlar.

01Ne öğreneceksin

02Tembellik katmanları: doğru araca doğru belirti

Frontend performansının ana ilkesi tektir: kullanıcının şu an görmediği şeyin bedelini şimdi ödeme. Angular'da bu ilkenin üç katmanı vardır ve karıştırılması sık bir mimari hatadır:

Sıralama da budur: önce rota sınırları, sonra sayfa içi bölgeler, en son satır düzeyi. Tersinden başlamak — daha rota bölünmemişken sanal kaydırma kurmak — karmaşıklığı öne, kazancı arkaya koyar.

03@defer: şablon içi tembellik

Lazy rota, sınırı URL'den çizer; @defer sınırı şablonun içinden çizer — bloğun içindeki bileşenler ayrı parçaya (chunk) alınır ve tetikleyici gerçekleşene dek ne kodu iner ne render edilir:

@defer (on viewport; prefetch on idle) {
  <app-maas-grafigi [veriler]="veriler()" />
} @placeholder {
  <div class="grafik-iskelet" aria-hidden="true"></div>
} @loading (minimum 300ms) {
  <p>Grafik yükleniyor…</p>
} @error {
  <p role="alert">Grafik yüklenemedi.</p>
}

Bu altı satırda dersin yarısı var; parçalayalım:

• prefetch ayrı karardır: prefetch on idle — kodu boşta indir ama render'ı tetikleyiciye bırak; viewport'a gelindiğinde bekleme sıfıra iner. "İndirme" ile "çizme"nin ayrışması, bu bloğun en zarif fikridir.
• @placeholder yer tutar: boyutu gerçek içeriğe yakın bir iskelet ver — yoksa içerik gelince sayfa zıplar (8. hattın CLS/düzen kayması bilgisi). @loading (minimum 300ms)'un derdi de titremedir: çok hızlı biten yüklemede göstergenin bir anlığına parlayıp sönmesini engeller.
• Ayrı parça şartı: @defer'ın kod bölmesi, içindeki bileşen yalnız o blokta kullanılıyorsa çalışır — bileşeni aynı dosyada başka yerde de kullanıyorsan zaten ana pakettedir, blok yalnız render'ı geciktirir. "Defer koydum, paket küçülmedi" şaşkınlığının cevabı budur.

04Ölçüm disiplini: tahmin değil, profil

Bu hattın her performans kuralı bir belirtiyle geldi; şimdi belirtiyi ölçme araçlarını sırala. Kural, 2. hattan beri aynı: ölçmeden optimize etme — tahminle yapılan optimizasyon, çoğu zaman yanlış yeri hızlandırır.

• İlk yük yavaşsa → paket analizi: üretim derlemesi çıktısındaki parça boyutlarına bak (ng build tablosu; ayrıntı için source map görselleştiricileri). Soru hep aynıdır: "bu paket neden bu boyda — içinde ne var?" Çoğu şişkinliğin cevabı, ana pakete sızmış bir ağır kütüphanedir; çözüm lazy sınırıdır. 1. dersin bütçeleri bu kontrolü CI'a bağlar: eşik aşılırsa derleme kırılır — gerileme fark edilmeden yayılamaz.
• Etkileşim yavaşsa → Angular DevTools profiler: tarayıcı eklentisi; her değişiklik algılama turunun süresini ve hangi bileşenin ne kadar yediğini gösterir. "Yazarken arayüz takılıyor" şikâyetinde ilk bakılacak yer: turda binlerce kez çalışan bir şablon metot çağrısı ya da saf olmayan pipe (10. ders) burada yakalanır; OnPush/signals kazancı da burada kanıtlanır.
• Kullanıcı gerçeğine bak → Core Web Vitals: 8. hattın DevTools dersindeki Lighthouse/Performance panelleri Angular'da da geçerlidir; LCP (en büyük içerik boyası) SSR kararının, CLS (düzen kayması) placeholder disiplininin ölçüsüdür.

05SSR ve hydration: ilk boyayı öne almak

SPA'nın yapısal zaafını 1. dersten biliyorsun: tarayıcı önce boş bir index.html + JS paketi alır; kullanıcı, paket inip çalışana dek beyaz ekrana bakar. İçerik odaklı ve SEO'nun önemli olduğu sayfalarda bu kabul edilmez — çözüm, ilk HTML'i sunucuda üretmektir (ng new --ssr). Akış üç perdedir:

1. Sunucu render eder: Node üzerinde uygulama çalıştırılır, rota çizilir, dolu HTML döner. Kullanıcı içeriği hemen görür; arama motoru dolu sayfa okur.
2. İstemci paketi iner ve Angular, sunucunun ürettiği DOM'u hydrate eder: sıfırdan çizmek yerine var olan DOM'u sahiplenir, dinleyicileri bağlar. (Hydration olmadan SSR, sayfayı ikinci kez baştan çizerdi — ekran titrer, kazanç yarıya inerdi.) Hydration tamamlanana dek biriken tıklamalar da kaydedilip sırasıyla işlenir — event replay.
3. Uygulama SPA olarak devam eder: sonraki geçişler yine router'ındır (7. ders) — SSR yalnız ilk yükleme hikâyesidir.

İki üretim tuzağını bilmek, "SSR açtım, patladı" gününde seni kurtarır:

• window sunucuda yoktur: Node'da window, document, localStorage tanımsızdır — bunlara sınıf gövdesinden/kurucudan dokunan her kod sunucu render'ını düşürür. Bu hattın temalarında bu yüzden hep tarayıcıya dokunan işler afterNextRender'a kondu (10. ders): o blok yalnız tarayıcıda çalışır. İnce ayrım gerekiyorsa platform kontrolü vardır (isPlatformBrowser); ama ilk refleks "DOM işi render sonrasına" olmalı.
• Çift istek tuzağı ve TransferState: sunucu render ederken API'den veriyi çekti; istemci hydrate olurken aynı isteği bir daha atarsa emek boşa gider (ve ekran bir anlığına titreyebilir). Angular'ın HttpClient'ı SSR'da bunu kendiliğinden çözer: sunucuda çekilen cevaplar HTML'in içine gömülür (TransferState), istemci ilk hydration'da isteği ağa çıkmadan oradan okur. Mekanizmayı bilmek önemli çünkü kapsamı sınırlı: yalnız GET ve ilk yükleme — "neden bazı istekler hiç atılmıyor?" sorusunun cevabı da budur.

Karar ölçüsü: giriş yapılmış, içerik herkese kapalı bir yönetim paneli SSR'dan neredeyse hiç kazanmaz; pazarlama sayfaları, ilan listeleri gibi ilk boyanın ve SEO'nun para ettiği yüzeyler kazanır. SSR bir sunucu işletmek demektir (12. hat Node bilgisi) — bedava değildir, gerekçesiyle açılır.

06Ekosistem turu: Material, CDK, i18n, animasyon

Bu tablo bilinç haritasıdır, müfredat değil: hangi sorunun hangi kutuda çözüldüğünü bil; derinleşme işe girince ihtiyaçla gelir.

07Üretim pratiği: performans bir süreçtir

• Sıra: ölç → en pahalı tekil sebebi bul → düzelt → yeniden ölç. Tek seferde beş optimizasyon yapan, hangisinin işe yaradığını asla öğrenemez (2. hattın deney disiplini).
• Bütçeyi gerilemeden önce kur: angular.json bütçeleri + CI'da üretim derlemesi — paket şişmesi kod incelemesinde değil, derleme kırılınca yakalanır.
• Placeholder'sız defer, gösterge titreten loading bırakma: @defer her zaman boyutlu bir @placeholder ve minimum'lu bir @loading ile gelir — performans kazancı, düzen kaymasıyla geri ödenmesin.
• SSR'ı sonradan açmak pahalıdır: baştan SSR düşünülen kodda "DOM'a yalnız afterNextRender'da dokun" kuralı doğal alışkanlıktır; sonradan açılan projede yüzlerce window erişimi tek tek ayıklanır. Yeni projede kararı 1. günde ver.

08Mini alıştırma — Defer ve profil deneyleri

09Kendini sına

Angular'da tembellik katmanlarını say; her birinin doğru belirtisi nedir?

Üç katman var ve sıralama önemli. (1) Rota düzeyi — loadComponent/loadChildren: ilk paket büyükse ve kullanıcının belki hiç girmeyeceği bölgeler (yönetim, raporlar) ana pakete gömülüyse; kod, rotaya ilk girişte iner. (2) Şablon bölgesi — @defer: sayfa açık ama içindeki bir parça pahalıysa — sayfa altındaki grafik, yorumlar, ağır üçüncü parti bileşen; bloğun kodu ayrı parçaya alınır, tetikleyiciye dek ne iner ne çizilir. (3) Satır düzeyi — sanal kaydırma (CDK): binlerce satırlık listede DOM'da yalnız görünen pencereyi tutmak; track ve OnPush artık yetmediğinde. Doğru sıra da budur: önce rota sınırları, sonra sayfa içi bölgeler, en son satır düzeyi — tersinden başlamak, karmaşıklığı öne kazancı arkaya koyar. Hepsinin ortak ilkesi: kullanıcının şu an görmediği şeyin bedelini şimdi ödeme; ve hepsinin kanıtı ölçümdür — paket tablosu, Network'te inen parça, profiler.

@defer bloğunu anlat: tetikleyiciler, alt bloklar, prefetch. Lazy rotadan farkı nedir; "defer koydum, paket küçülmedi" nasıl olur?

@defer, şablonun bir bölgesini hem kod hem render olarak erteler: içindeki bileşenler ayrı parçaya derlenir ve tetikleyici gerçekleşene dek yüklenmez. Tetikleyiciler: on viewport (görünür alana girince — sayfa altı bölgelerin standardı), on idle (varsayılan; tarayıcı boşta), on interaction/hover, on timer, when kosul. Alt bloklar durum tasarımıdır: @placeholder yüklemeden önce yer tutar — boyutlu bir iskelet verilmezse içerik gelince sayfa zıplar (CLS); @loading (minimum 300ms) gösterge titremesini engeller; @error yükleme başarısızlığını çizer. prefetch indirme ile çizmeyi ayırır: prefetch on idle; on viewport — kod boşta iner, render görünürlüğü bekler; kullanıcı geldiğinde bekleme sıfırdır. Lazy rotadan farkı sınırın yeri: rota URL'den böler, defer şablon içinden. Paketin küçülmemesinin klasik sebebi: defer içindeki bileşen başka yerde de (eager) kullanılıyordur — o zaman kod zaten ana pakettedir, defer yalnız render'ı geciktirir; kod bölmesi, bileşenin yalnız defer bloklarında kullanılmasını ister.

SSR ve hydration nasıl çalışır? window tuzağını ve TransferState'i anlat; SSR'ı hangi projede açarsın?

SSR'da ilk HTML sunucuda üretilir: Node üzerinde uygulama çalıştırılır, rota render edilir, dolu HTML döner — kullanıcı beyaz ekran yerine içeriği hemen görür, arama motoru dolu sayfa okur. İstemci paketi inince Angular DOM'u sıfırdan çizmez, hydrate eder: sunucunun ürettiği DOM'u sahiplenir ve dinleyicileri bağlar (hydration'sız SSR sayfayı ikinci kez çizer, ekran titrer); bu sırada biriken tıklamalar event replay ile işlenir. Sonrası normal SPA'dır — SSR yalnız ilk yükleme hikâyesidir. Birinci tuzak: Node'da window, document, localStorage yoktur — kurucudan bunlara dokunan kod sunucuda çöker; DOM'a dokunan işler afterNextRender'a (yalnız tarayıcıda çalışır) alınır, gerekirse isPlatformBrowser ile dallanılır. İkinci tuzak çift istektir: sunucu veriyi çekti, istemci hydration'da aynı isteği tekrar atarsa emek boşa gider; HttpClient sunucuda çekilen GET cevaplarını HTML'e gömer (TransferState), istemci ilk yüklemede ağa çıkmadan oradan okur. Karar: SEO ve ilk boyanın para ettiği yüzeylerde (ilan listeleri, içerik sayfaları) açılır; girişli yönetim paneli neredeyse hiç kazanmaz — SSR bir sunucu işletmektir, gerekçesiz açılmaz.

Performans şikâyeti geldi: "uygulama yavaş." Teşhis sürecini ve araçlarını anlat.

İlk iş şikâyeti ayrıştırmaktır — "yavaş"ın en az üç ayrı hastalığı vardır ve araçları farklıdır. (1) İlk açılış yavaşsa paket sorunudur: üretim derlemesinin parça tablosuna ve source map analizine bakarım — "bu paket neden bu boyda, içinde ne var?"; çözüm tipik olarak lazy sınırı ya da ana pakete sızmış ağır bir bağımlılığı defer/lazy arkasına almaktır; angular.json bütçeleri bu sınıfı CI'da kilitler. (2) Etkileşim yavaşsa (yazarken takılma, tıklamada gecikme) değişiklik algılama sorunudur: Angular DevTools profiler ile turların süresini ve pahalı bileşeni bulurum; klasik failler şablonda metot çağrısı, saf olmayan pipe, track'siz büyük liste, OnPush'suz geniş ağaç — düzeltmenin kanıtı yine profiler'dır. (3) Kullanıcı algısı kötüyse Core Web Vitals'a bakarım: LCP kötüyse SSR/defer/görsel önceliklendirme; CLS kötüyse boyutsuz placeholder ve zıplayan düzen. Süreç hep aynıdır: ölç → tek sebep bul → düzelt → yeniden ölç; tek seferde beş optimizasyon yapan hangisinin işe yaradığını öğrenemez. Kıdem cümlesi: optimizasyon kanıtla başlar, kanıtla biter.

10Sınav köşesi