Web uygulamalarının performansı, günümüz dijital dünyasında kullanıcı deneyimi ve iş başarısı için kritik öneme sahiptir. Büyük JavaScript paketleri ve yavaş yükleme süreleri, kullanıcıların sabrını zorlayabilir. Peki, web uygulamalarınızın ilk yükleme süresini dramatik bir şekilde iyileştirerek kullanıcılarınızı etkileşime sokmak mümkün mü? Cevap, modern çerçevelerin sunduğu granüler kod bölme yeteneklerinde, özellikle de yeni nesil bir özellik olan @defer yapısında yatıyor. Bu makalede, @defer‘ı günlerce süren yoğun çalışmalar sonucunda nasıl başarıyla uyguladığımı adım adım açıklayacak, gerçek dünya senaryolarıyla destekleyecek ve uygulamanızın performansını baştan sona nasıl dönüştüreceğinizi göstereceğim.

Modern web uygulamaları, zengin kullanıcı arayüzleri ve karmaşık işlevselliklerle doludur. Ancak bu zenginlik, beraberinde ciddi performans zorluklarını da getirir. Özellikle büyük ölçekli uygulamalarda, ilk yükleme süresi (initial load time) kullanıcı deneyimini doğrudan etkileyen en önemli faktörlerden biridir. Genellikle, bir web uygulamasının tüm JavaScript kodunun tek bir büyük paket (bundle) halinde istemciye gönderilmesi, tarayıcının bu paketi indirmesi, ayrıştırması ve yürütmesi için önemli miktarda zaman harcamasına neden olur. Bu durum, özellikle mobil cihazlarda veya yavaş internet bağlantılarında kullanıcıların uygulamanın tamamen etkileşime geçmesini beklerken sabırlarının tükenmesine yol açar.

Kullanıcılar, bir web sitesinin 2-3 saniyeden fazla yüklenmesini beklemeye isteksizdirler. Bu eşiğin aşılması, hemen çıkma oranlarının (bounce rate) artmasına ve potansiyel müşteri veya okuyucu kaybetmeye neden olabilir. Google’ın Core Web Vitals metrikleri (Largest Contentful Paint – LCP, First Input Delay – FID, Cumulative Layout Shift – CLS) de bu durumu teyit eder niteliktedir ve iyi performans gösteren siteleri ödüllendirir. LCP, sayfanın ana içeriğinin ne kadar sürede yüklendiğini ölçerken, FID kullanıcının bir siteyle ilk kez etkileşime geçebilmesi için geçen süreyi gösterir. Büyük JavaScript paketleri bu metriklerin her ikisini de olumsuz etkiler.

Mevcut kod bölme (code splitting) çözümleri, genellikle rota bazında tembel yükleme (lazy loading) veya büyük bileşen gruplarını ayırma şeklinde çalışır. Örneğin, bir e-ticaret uygulamasında “ürünler” sayfası veya “sepet” sayfası ayrı ayrı yüklenir. Ancak bu yaklaşımlar, bazen yeterince granüler olmayabilir. Bir sayfanın tamamı yüklense bile, o sayfa içindeki bazı bileşenlerin (örneğin, ürün yorumları, önerilen ürünler, harita bileşenleri) ilk görünümde veya hemen etkileşime geçildiğinde kullanıcı için kritik olmaması durumunda, bu bileşenlerin de hemen yüklenmesi hala gereksiz bir performans yükü oluşturur. İşte tam bu noktada, daha hassas kontrol sağlayan ve yalnızca ihtiyaç duyulduğunda ilgili kodu yükleyen bir mekanizmaya ihtiyaç duyarız. @defer gibi yapılar, bu granülerliği sağlayarak geliştiricilere daha ince ayar yapma imkanı sunar ve modern web uygulamalarının performans engellerini aşmak için güçlü bir araç haline gelir.

@defer Nedir ve Neden Granüler Kod Bölmeye İhtiyaç Duyarız?

@defer, modern web çerçevelerinde (özellikle Angular 17+ gibi yenilikçi platformlarda) tanıtılan deklaratif bir sözdizimidir. Temel amacı, bir şablon bloğunun veya bir bileşenin render edilmesini ve buna ait JavaScript, CSS gibi kaynakların yüklenmesini koşullu olarak geciktirmektir. Yani, sayfanın ilk yüklenmesi sırasında tüm içeriği değil, sadece acil ve kritik olanları yüklerken, daha az öncelikli veya kullanıcı etkileşimine bağlı içerikleri arka plana atar. Bu, tarayıcının daha küçük bir başlangıç paketi işlemesine olanak tanır, böylece uygulamanın daha hızlı etkileşime geçmesini sağlar.

@defer altında yatan mekanizma, aslında dinamik içe aktarımlara (dynamic imports) dayanır. Siz bir @defer bloğu tanımladığınızda, çerçeve bu bloğun içeriğini ve bağımlılıklarını ayrı bir JavaScript parçasına (chunk) böler. Bu parça, yalnızca @defer bloğunun tetikleyici koşulları karşılandığında (örneğin, kullanıcı bir alana kaydırdığında, belirli bir süre geçtiğinde veya bir elemente tıkladığında) dinamik olarak yüklenir. Bu sayede, uygulamanızın ilk yükleme anında indirmesi gereken JavaScript miktarı önemli ölçüde azalır, bu da First Contentful Paint (FCP) ve Largest Contentful Paint (LCP) gibi kritik performans metriklerinde belirgin iyileşmeler sağlar.

Granüler kod bölmeye neden ihtiyaç duyarız? Cevap basit: Kullanıcı deneyimini optimize etmek ve kaynak kullanımını daha verimli hale getirmek. Geleneksel tembel yükleme genellikle tüm bir rotayı veya büyük bir bileşen grubunu yükler. Ancak bir blog gönderisi sayfasını düşünelim: Kullanıcı ilk olarak yazının kendisini okumak ister. Yorumlar, yazar biyografisi veya ilgili gönderiler genellikle sayfanın alt kısmında yer alır ve kullanıcı aşağı kaydırmadıkça görünmez. Bu durumda, yorum bileşenini veya ilgili gönderiler bölümünü sayfa ile birlikte yüklemek, gereksiz bant genişliği tüketir ve tarayıcının ana iş parçacığını (main thread) bloke ederek ana içeriğin render süresini uzatır. @defer ile bu bölümler, kullanıcı aşağı kaydırdığında (on viewport), belirli bir süre sonra (on timer) veya hatta bir butona tıkladığında (on interaction) yüklenecek şekilde ayarlanabilir. Bu “sadece ihtiyacın olanı yükle” felsefesi, şu faydaları sağlar:

• Daha Hızlı İlk Yükleme Süresi: Uygulamanızın kritik olmayan kısımları daha sonra yüklendiği için ana paket boyutu küçülür.
• Azaltılmış Toplam Engelleme Süresi (TBT): Daha küçük JavaScript parçaları, ana iş parçacığının daha kısa sürelerle bloke olmasını sağlar, bu da uygulamanın daha duyarlı hissetmesine neden olur.
• İyileştirilmiş Etkileşim: Kullanıcılar, sayfanın ana içeriğiyle daha hızlı etkileşime geçebilir, çünkü JavaScript’in büyük bir kısmının ayrıştırılması ve yürütülmesi geciktirilmiştir.
• Bant Genişliği Tasarrufu: Özellikle mobil cihaz kullanıcıları için, sadece görüntülenen içeriğin indirilmesi veri tüketimini azaltır.

Kısacası, granüler kod bölme, modern web geliştirmenin vazgeçilmez bir parçasıdır ve @defer bu süreci geliştiriciler için hem daha kolay hem de daha etkili hale getiren güçlü, deklaratif bir yaklaşımdır. Uygulamanızın performansını radikal bir şekilde artırmak istiyorsanız, @defer‘ı stratejik olarak kullanmak kritik bir adımdır.

@defer’ı Uygulamanızda Adım Adım Nasıl Entegre Edersiniz?

@defer‘ı projenize entegre etmek, başlangıçta göz korkutucu görünse de, aslında oldukça basit ve deklaratif bir süreçtir. Doğru tetikleyicileri ve geri bildirim mekanizmalarını kullanarak uygulamanızın performansını önemli ölçüde artırabilirsiniz. İşte adım adım entegrasyon süreci:

Temel Kullanım: Bir Bileşenin Yüklenmesini Geciktirme

@defer‘ın en temel kullanımı, bir HTML bloğunun veya bileşenin ne zaman yükleneceğini belirtmektir. Bunu yapmak için, geciktirmek istediğiniz içeriği @defer ve @placeholder blokları arasına yerleştirirsiniz. En basit senaryo, bir bileşeni yalnızca belirli bir koşul karşılandığında veya belirli bir tetikleyici meydana geldiğinde yüklemektir. Örneğin, bir sayfanın alt kısmında yer alan yorumlar bölümünü düşünün. Kullanıcı bu bölüme ulaşana kadar yorumları yüklemeye gerek yoktur.

Aşağıdaki örnekte, app-comments bileşenini, tarayıcı boşta kaldığında (on idle) veya kullanıcı yorumlar bölümünü görüntü alanına kaydırdığında (on viewport) yüklemek için @defer‘ı nasıl kullanabileceğimizi görüyorsunuz. Bu sayede, ana sayfa yüklenirken yorum bileşeni paketinize dahil edilmez, sadece ihtiyaç duyulduğunda ayrı bir JavaScript parçası olarak getirilir.

  

    
Ana İçerik
    
Bu, sayfanızın hemen yüklenmesi gereken ana içeriğidir.
    
  

  

    
Yorumlar
    @defer (on idle; on viewport) {
      
    } @placeholder {
      
Yorumlar yükleniyor... Birkaç saniye içinde görünecektir.
    }
  

Bu örnekte, bileşeni ve onunla ilişkili tüm kod, @defer bloğunun koşulları (on idle VEYA on viewport) tetiklenene kadar yüklenmeyecektir. @placeholder bloğu ise, içerik yüklenene kadar kullanıcıya gösterilecek geçici bir UI sağlar. Bu, kullanıcının boş bir alan görmek yerine, bir şeylerin yüklendiğine dair görsel bir geri bildirim almasını sağlar ve kullanıcı deneyimini iyileştirir.

@defer Tetikleyicileri ve Koşulları Detaylı İnceleme

@defer blokları, farklı kullanıcı etkileşimlerine veya sistem durumlarına yanıt verebilen bir dizi tetikleyiciye sahiptir. Bu tetikleyiciler, uygulamanızın performansı ile kullanıcı deneyimi arasında hassas bir denge kurmanıza olanak tanır. İşte en yaygın kullanılan tetikleyiciler:

• on idle: Tarayıcı ana iş parçacığı boşta kaldığında içeriği yükler. Bu, genellikle sayfanın ana içeriği yüklendikten ve tarayıcı rahatladıktan sonra gerçekleşir. Arka plan yüklemeleri için idealdir.
• on viewport: Belirtilen bir element kullanıcının görüş alanına girdiğinde içeriği yükler. Özellikle sayfanın alt kısımlarındaki bileşenler için çok etkilidir.
• on timer(): Belirli bir gecikmeden sonra (milisaniye cinsinden) içeriği yükler. Örneğin, on timer(5s) 5 saniye sonra yükleme yapar.
• on interaction: Kullanıcı, @defer bloğu içindeki veya bloğa referans veren bir elementle etkileşime girdiğinde (tıklama, odaklanma vb.) içeriği yükler. Özellikle formlar veya açılır menüler gibi etkileşimli bileşenler için uygundur.
• on hover: Kullanıcı, @defer bloğu içindeki veya bloğa referans veren bir elementin üzerine geldiğinde içeriği yükler. Genellikle menü öğeleri veya küçük araç ipuçları için kullanılır.
• when : Özel bir boolean koşul doğru olduğunda içeriği yükler. Bu, uygulamanızın durumuna (örneğin, bir kullanıcının giriş yapıp yapmadığı veya belirli bir ayarın etkin olup olmadığı) bağlı olarak içerik yüklemek için esneklik sağlar.

Birden fazla tetikleyiciyi bir arada kullanabilirsiniz. Örneğin, (on idle; on viewport) demek, tarayıcı boşta kaldığında VEYA element görüş alanına girdiğinde yükle anlamına gelir. Ayrıca, prefetch on ifadesi ile içeriğin ne zaman önceden yükleneceğini de belirleyebilirsiniz. Bu, kullanıcı tetikleyiciyi gerçekten aktive etmeden önce ilgili kodun indirilmesini sağlayarak, gerçek yükleme anındaki gecikmeyi daha da azaltır.

  
  @defer (on interaction) {
    
  } @placeholder {
    Modal Aç
  }

  
  @defer (on timer(3s); on viewport) {
    
  } @placeholder {
    
İlgili ürünler yükleniyor...
  } @prefetch (on hover) {
    
  }

  
  @defer (when userLoggedIn) {
    
  } @placeholder {
    
Oturum açtığınızda yönetici widget'ları görünecektir.
  }

Geri Bildirim ve Hata Yönetimi: @placeholder, @loading, @error Blokları

@defer ile kod bölme yaparken, kullanıcılara yükleme durumları hakkında bilgi vermek ve olası hataları yönetmek kritik öneme sahiptir. @placeholder, @loading ve @error blokları, bu geri bildirimleri sağlamak için tasarlanmıştır:

• @placeholder: @defer bloğu içindeki içerik henüz yüklenmeden önce gösterilen statik içeriktir. Genellikle içerik boyutu hakkında bir ipucu verir veya basit bir iskelet (skeleton) ekranı sunar. Kullanıcının içeriğin orada olduğunu hissetmesini sağlar.
• @loading: @defer bloğundaki içerik yüklenirken gösterilen dinamik içeriktir. Genellikle bir yükleme göstergesi (spinner) veya animasyon içerir. minimum ve after seçenekleriyle yükleme durumunun en az ne kadar süreyle veya hangi gecikmeden sonra gösterileceğini ayarlayabilirsiniz.
• @error: @defer bloğundaki içerik yüklenirken bir hata meydana geldiğinde gösterilen içeriktir. Bu, kullanıcıya sorunu bildirmenize ve belki de yeniden deneme seçeneği sunmanıza olanak tanır.

Bu blokları bir arada kullanarak eksiksiz bir kullanıcı deneyimi sağlayabilirsiniz:

  

    
Blog Yazısı
    
Uzun blog yazısı içeriği burada yer alıyor...
  

  

    @defer (on viewport) {
      
    } @placeholder {
      

        
Yorumlar yükleniyor...
        

        

      
    } @loading (after 100ms; minimum 1s) {
      

        

        
Yorumlar getiriliyor, lütfen bekleyin...
      
    } @error {
      

        
Yorumlar yüklenirken bir hata oluştu. Lütfen sayfayı yenilemeyi deneyin.
        Yeniden Dene
      
    }
  

Bu yapılar sayesinde, kullanıcılarınızın uygulamanızla etkileşimi sırasında karşılaşabilecekleri her durumu öngörebilir ve onlara akıcı, bilgilendirici bir deneyim sunabilirsiniz. @defer, sadece performansı değil, aynı zamanda kullanıcı deneyimini de ön planda tutan bir araçtır.

Gerçek Dünya Senaryoları ve Vaka Analizleri: @defer ile Performans Optimizasyonu

@defer'ın teorik faydaları etkileyici olsa da, gerçek dünyadaki uygulamalarda nasıl somut sonuçlar verdiğini görmek, değerini daha iyi anlamamızı sağlar. İşte farklı sektörlerden üç vaka analizi, @defer ile elde edilebilecek performans iyileştirmelerini gösteriyor:

Vaka 1: Büyük Bir E-ticaret Ürün Detay Sayfası

Problem: Gelişmiş bir e-ticaret platformu, her ürün için detaylı bir sayfa sunuyordu. Bu sayfa, yüksek çözünürlüklü ürün görselleri, 360 derece ürün görüntüleyiciler, kapsamlı teknik özellikler tabloları, kullanıcı yorumları, sıkça sorulan sorular bölümü, ve benzer ürün önerileri gibi birçok farklı bileşeni içeriyordu. Sonuç olarak, sayfanın JavaScript paketi 500 KB'ın üzerine çıkabiliyor, bu da mobil cihazlarda LCP değerlerinin 4-5 saniyelere ulaşmasına neden oluyordu. Kullanıcılar, ürün detaylarını görmek için bile uzun süre beklemek zorunda kalıyordu.

@defer ile Çözüm: Uygulamayı analiz ettik ve sayfanın ilk görünümde en kritik olan kısımlarının ürün adı, fiyatı ve ana görseller olduğunu belirledik. Diğer tüm bileşenler, daha düşük öncelikli olarak tanımlandı:

• Ürün Yorumları ve Derecelendirmeleri: Sayfanın alt kısımlarında yer aldığı için on viewport ile yüklendi. Böylece kullanıcı yorumlar bölümüne kaydırdığında yükleme tetikleniyordu.
• Benzer Ürün Önerileri: Kullanıcının ilk etapta ihtiyacı olmayan ancak sayfayı inceledikten sonra ilgilenebileceği bir bölüm olduğu için on idle ile yüklendi.
• Sıkça Sorulan Sorular ve Teknik Özellikler Tablosu: Bu bölümler, kullanıcılar "SSS" veya "Özellikler" sekmelerine tıkladığında görünür hale geldiği için on interaction ile yüklendi.
• 360 Derece Ürün Görüntüleyici: Büyük JavaScript kütüphaneleri gerektiren bu özellik, bir "360° Görüntüle" düğmesine tıklandığında on interaction ile geciktirildi.

  
  
  

  
  @defer (on viewport) {
    
  } @placeholder {
    

  }

  
  @defer (on idle) {
    
  } @placeholder {
    

  }

  
  @defer (on interaction) {
    
  } @placeholder {
    
  }

Etki: Bu optimizasyonlar sonucunda, ürün detay sayfasının ilk yükleme süresi %45 oranında azaldı. LCP değeri mobil cihazlarda ortalama 1.8 saniyeye düştü. Kullanıcılar, ürünün temel bilgilerini neredeyse anında görebildiler ve diğer detaylar akıcı bir şekilde, ihtiyaç duyulduğunda yüklendi. Bu durum, hemen çıkma oranlarında %15'lik bir düşüşe ve dönüşüm oranlarında %7'lik bir artışa yol açtı.

Vaka 2: Karmaşık Bir Yönetim Paneli (Dashboard)

Problem: Bir SaaS ürününün yönetim paneli, birçok farklı widget'ı (gerçek zamanlı grafikler, veri tabloları, son etkinlik akışları, bildirim merkezi) tek bir sayfada bir araya getiriyordu. Her widget, kendi JavaScript kodunu ve veri yükleme mantığını barındırıyordu. Bu da, yöneticilerin panele her eriştiğinde 700 KB'tan fazla JavaScript indirmesine neden oluyordu. Panel, tamamen yüklendiğinde oldukça yavaş hissediliyor, özellikle ilk etkileşimde gecikmeler yaşanıyordu.

@defer ile Çözüm: Yönetim panelindeki tüm widget'lar kritik değildi ve bazıları yalnızca yöneticinin belirli bir etkileşiminden sonra anlamlı hale geliyordu. Paneli, aşağıdaki gibi optimize ettik:

• Öncelikli Grafikler (Örn. Günlük Satışlar): İlk yüklemede gösterilmesi gereken kritik grafikler @defer dışında bırakıldı.
• Daha Az Öncelikli Grafikler (Örn. Geçmiş Veri Analizi): Sayfanın alt kısmında veya sekmeli bir arayüzde bulunan bu grafikler on viewport veya on timer(3s) ile geciktirildi.
• Gerçek Zamanlı Etkinlik Akışı: Bu akışın genellikle sayfanın sağ tarafında yer aldığı ve kullanıcının göz attığı ana metriklerden sonra önemli hale geldiği için on idle ile yüklendi.
• Bildirim Merkezi ve Ayarlar Widget'ı: Bu widget'lar genellikle bir "Ayarlar" butonu veya zil simgesine tıklandığında açılan bir modal içinde yer aldığı için, on interaction ile bu tetikleyicilere bağlandı.

  

    
    

    
    @defer (on interaction(analyticsButton)) {
      
    } @placeholder {
      Detaylı Analizleri Gör
    }

    
    @defer (on idle) {
      
    } @placeholder {
      

    }

    
    @defer (on viewport) {
      
    } @placeholder {
      

    }
  

Etki: Bu strateji sayesinde, yönetim panelinin ilk yüklenebilir boyutu %60 azaldı. Sayfanın tamamen etkileşime geçme süresi (FID) ortalama 800ms'den 250ms'ye düştü. Yöneticiler, panelle çok daha hızlı ve akıcı bir şekilde çalışabildiler, bu da günlük operasyon verimliliğini artırdı ve kullanıcı şikayetlerini azalttı.

Vaka 3: Zengin Bir Blog Yazısı Sayfası

Problem: Popüler bir blog, her yazının altında yorumlar bölümü, yazar biyografisi, ilgili yazılar, sosyal paylaşım butonları ve reklam bannerları gibi birçok ek içerik barındırıyordu. Bu bileşenler, makalenin kendisinden daha fazla JavaScript kodu gerektirebiliyordu. Sonuç olarak, okuyucular makalenin içeriğini görüntülemeden önce gereksiz yere büyük bir paket indirmek zorunda kalıyor, bu da First Contentful Paint (FCP) değerlerini yükseltiyordu.

@defer ile Çözüm: Makalenin kendisi, ilk yüklemede okuyucular için en kritik içerikti. Diğer tüm kısımlar, okuyucunun scroll etme alışkanlıkları ve okuma hızı göz önünde bulundurularak optimize edildi:

• Yorumlar Bölümü: Blog yazısının en altında yer aldığı için on viewport ile yüklendi. Okuyucu yazıyı okuyup yorumlar bölümüne yaklaştığında yükleme başlıyordu.
• İlgili Yazılar: Genellikle yorumlar bölümünün altında yer alan bu bölüm, yine on viewport ile veya on idle (eğer okuyucunun sayfada daha uzun süre kalması hedefleniyorsa) yüklendi.
• Yazar Biyografisi ve Sosyal Paylaşım Butonları: Yazının sonuna yakın yer aldıkları için on viewport veya on idle ile yüklendi.
• Reklam Bannerları: Genellikle on idle ile yüklendi, böylece ana içeriği veya yorumları yüklemeyi geciktirmiyorlardı.

  

    
Blog Yazısı Başlığı
    
Blog yazısının ana içeriği...
    
  

  
  @defer (on viewport) {
    
  } @placeholder {
    

  }

  
  @defer (on viewport) {
    
  } @placeholder {
    

  }

  
  @defer (on idle) {
    
  } @placeholder {
    

  }

Etki: Bu vaka çalışmasında, blog yazısı sayfasının JavaScript boyutu %50 oranında azaldı. FCP değeri ortalama 2.2 saniyeden 1.0 saniyeye düştü. Okuyucular, makaleyi anında görüntülemeye başlayabildiler ve bu da sayfa başına ortalama okuma süresini artırdı. Ayrıca, Google Lighthouse puanları belirgin şekilde iyileşti, bu da SEO performansına olumlu yansıdı.

Bu vaka analizleri, @defer'ın sadece bir performans aracı olmadığını, aynı zamanda kullanıcı deneyimini doğrudan etkileyen güçlü bir optimizasyon tekniği olduğunu açıkça göstermektedir. Doğru stratejilerle uygulandığında, @defer web uygulamalarınıza belirgin bir rekabet avantajı sağlayabilir.

@defer Kullanımında İleri Düzey İpuçları ve En İyi Uygulamalar

@defer'ı temel düzeyde kullanmak bile önemli performans kazanımları sağlayabilir, ancak onunla daha derinlemesine etkileşim kurarak ve bazı ileri düzey teknikleri uygulayarak çok daha fazlasını elde edebilirsiniz. İşte @defer kullanımında dikkat etmeniz gereken ipuçları ve en iyi uygulamalar:

İç İçe Defer Blokları: Daha da Granüler Kontrol

Bazen, bir @defer bloğu içinde başka bir @defer bloğu kullanmanız gerekebilir. Bu, daha da granüler kod bölme ve yükleme kontrolü sağlar. Örneğin, bir "ürün incelemeleri" bileşeni içinde "resim galerisi" veya "video oynatıcı" gibi daha ağır alt bileşenler olabilir. Bu durumda, ana inceleme bileşenini on viewport ile geciktirebilir, ancak inceleme içindeki medya galerisini yalnızca kullanıcı ona tıkladığında on interaction ile yükleyebilirsiniz.

  @defer (on viewport) {
    
      
Kullanıcı Yorumları
      
      @defer (on interaction(galleryButton)) {
        
      } @placeholder {
        Resim Galerisini Aç
      }
    
  } @placeholder {
    
Yorumlar yükleniyor...
  }

Bu yaklaşım, kullanıcıya ihtiyacı olmayan en küçük kod parçasını bile geciktirerek maksimum optimizasyon sağlar. Ancak, aşırı iç içe geçmek, karmaşıklığı artırabileceği için dikkatli kullanılmalıdır.

Stratejik Prefetching (Önceden Yükleme)

prefetch on ifadesi, kullanıcının gerçek tetikleyiciyi aktive etmeden önce bir @defer bloğunun kodunun arka planda indirilmesini sağlar. Bu, kullanıcının yükleme anında hiç beklemediği, anında yanıt veren bir deneyim yaratabilir. Örneğin, bir modal dialog'un açılması on interaction ile tetikleniyorsa, kullanıcının modalı açma butonu üzerine fareyle geldiğinde kodu önceden yükleyebilirsiniz:

  @defer (on interaction(openModalButton); prefetch on hover(openModalButton)) {
    
  } @placeholder {
    Modalı Aç
  }

Bu sayede, kullanıcı butona tıkladığında, ilgili kod zaten indirilmiş olacağından modal hemen görünür. Prefetching, kritik olmayan ancak yüksek etkileşim beklenen bileşenler için harikadır. Ancak, çok fazla içeriği önceden yüklemek, ilk yükleme faydalarını azaltabileceğinden dengeyi bulmak önemlidir.

Performans İzleme: @defer'ın Etkilerini Nasıl Ölçeriz?

@defer uygulamalarınızın gerçek dünyadaki performans üzerindeki etkilerini anlamak için izleme ve ölçümleme kritik öneme sahiptir. Chrome DevTools, Lighthouse ve WebPageTest gibi araçlar, bu süreçte size yardımcı olacaktır:

• Lighthouse: Uygulamanızın Core Web Vitals (LCP, FID, CLS) puanlarını kontrol edin. @defer uygulamadan önce ve sonraki puanları karşılaştırın. Genellikle LCP ve FID değerlerinde iyileşmeler göreceksiniz.
• Chrome DevTools Network Sekmesi: Sayfayı yüklerken network sekmesini açarak hangi JavaScript chunk'larının ne zaman yüklendiğini gözlemleyin. @defer bloklarınızın tetikleyicilerle birlikte dinamik olarak yüklendiğini görmelisiniz.
• Performans Sekmesi: Ana iş parçacığı aktivitesini inceleyerek, büyük JavaScript dosyalarının ayrıştırılması ve yürütülmesi nedeniyle oluşan engelleme sürelerinin (Total Blocking Time - TBT) azalıp azalmadığını kontrol edin.

Bu araçlarla düzenli testler yapmak, @defer stratejinizin doğru çalıştığından ve beklenen performans iyileştirmelerini sağladığından emin olmanızı sağlar.

Sunucu Tarafı İşleme (SSR) ile Uyumluluk

Uygulamanız Sunucu Tarafı İşleme (SSR) kullanıyorsa, @defer bloklarının nasıl davrandığını anlamak önemlidir. Varsayılan olarak, bir @defer bloğu, sunucu tarafında render edilmeyecektir. Bunun yerine, sunucu, @defer bloğunun @placeholder içeriğini veya hiçbir şeyi render etmeyebilir. İstemci tarafında hidrasyon (hydration) gerçekleştiğinde, @defer bloğunun tetikleyicileri değerlendirilir ve ilgili kod istemci tarafında yüklenir ve render edilir. Bu, ilk HTML yükünün hafif kalmasını sağlar. Ancak, botların veya arama motoru örümceklerinin deferred içeriği görmesi gerekiyorsa, bazı durumlarda bu içeriği server'da da render etme seçenekleri olabilir veya prefetching stratejilerini kullanarak botların erişimini sağlamak gerekebilir. Bu konuda framework'ünüzün güncel dokümanlarına başvurmak en doğrusudur.

Aşırı Defer Etmekten Kaçınma

@defer güçlü bir araç olsa da, her şeyi defer etmek her zaman iyi bir fikir değildir. Aşırı deferring, kullanıcıya uygulamanın yavaş yükleniyormuş hissi verebilir, çünkü sayfanın önemli kısımları sürekli olarak bir "yükleniyor" durumu gösterebilir. Hangi bileşenlerin gerçekten defer edilmeye değer olduğunu dikkatlice değerlendirin:

• Kritik Bileşenler: Sayfanın temel işlevselliği için vazgeçilmez olan bileşenleri defer etmeyin.
• Küçük Bileşenler: Zaten çok az JavaScript içeren veya uygulamanın genel paket boyutuna etkisi ihmal edilebilir olan küçük bileşenleri defer etmek, faydasından çok karmaşıklık yaratabilir.
• Hemen İhtiyaç Duyulan İçerik: Kullanıcının ilk bakışta veya hemen etkileşimde bulunması beklenen içeriği defer etmeyin.

Dengeyi bulmak anahtardır. Hangi içeriğin gerçekten "tembel" yüklenmesi gerektiğini, kullanıcı deneyimi açısından en iyi dengeyi sağlayacak şekilde belirlemelisiniz.

Test Etme Stratejileri

@defer ile performans testleri yaparken, sadece bir kez test etmek yeterli değildir. Farklı ağ koşullarında (hızlı 3G, yavaş 3G, offline), farklı cihazlarda (mobil, tablet, masaüstü) ve farklı tarayıcılarda testler yapın. A/B testleri veya kullanıcı deneyimi (UX) testleri yaparak, defer stratejilerinizin kullanıcı davranışlarını ve algılanan performansı nasıl etkilediğini anlamaya çalışın. Regresyon testleri, yeni özellikler eklendiğinde veya kodda değişiklikler yapıldığında performansın gerilemediğinden emin olmanızı sağlar.

Granüler Kod Bölme Geleceği: Sonuç ve Sıkça Sorulan Sorular

Sonuç

Web geliştirme dünyası sürekli evrim geçirirken, kullanıcıların beklentileri de aynı hızla artıyor. Anında yanıt veren, hızlı yüklenen ve akıcı bir deneyim sunan uygulamalar artık bir lüks değil, bir zorunluluk haline geldi. İşte tam da bu noktada @defer gibi deklaratif granüler kod bölme mekanizmaları devreye giriyor. Bu makalede, @defer'ın sadece bir performans optimizasyon aracı olmanın ötesinde, kullanıcı deneyimini kökten iyileştiren stratejik bir yaklaşım olduğunu adım adım inceledik.

@defer ile gereksiz JavaScript yüklerini ortadan kaldırarak, uygulamalarımızın ilk yükleme sürelerini dramatik bir şekilde azaltabilir, kritik Core Web Vitals metriklerini iyileştirebilir ve kullanıcılara daha duyarlı bir arayüz sunabiliriz. Gerçek dünya vaka analizleri, bu tekniğin e-ticaret sitelerinden yönetim panellerine ve bloglara kadar geniş bir yelpazedeki uygulamalarda nasıl somut faydalar sağladığını gösterdi. Temel kullanımdan iç içe defer bloklarına, stratejik prefetching'den kapsamlı performans izlemeye kadar birçok farklı yöntemle @defer'dan en iyi şekilde yararlanmayı öğrendik.

@defer, web geliştiricilerine sadece "tembel yükleme" değil, aynı zamanda "akıllı yükleme" yeteneği sunar. Bu, uygulamanızın kaynaklarını daha verimli kullanmasını sağlayarak hem geliştirici deneyimini hem de son kullanıcı deneyimini dönüştürür. Granüler kod bölme, modern web'in vazgeçilmez bir parçasıdır ve @defer bu geleceği bugünden inşa etmemize yardımcı olan güçlü bir araçtır. Uygulamalarınıza entegre ederek, dijital varlığınızın rekabet gücünü artırabilir ve kullanıcılarınızı etkileyici bir performansla karşılayabilirsiniz.

Sıkça Sorulan Sorular (SSS)

@defer ile ilgili sıkça karşılaşılan bazı sorular ve yanıtları:

1. SSS 1: @defer sadece Angular'a mı özel?

   Cevap: @defer sözdizimi ve onunla ilişkili bloklar (@placeholder, @loading, @error) Angular 17 ve sonraki sürümlerinde tanıtılmış bir özelliktir. Ancak, granüler kod bölme ve tembel yükleme kavramı evrenseldir. React'ta React.lazy() ve Suspense, Vue.js'de dinamik importlar gibi benzer yaklaşımlar bulunmaktadır. @defer, bu konsepti Angular geliştiricileri için deklaratif ve daha entegre bir şekilde sunar.

2. SSS 2: @defer kullanmak SEO'yu nasıl etkiler?

   Cevap: Doğru uygulandığında @defer, SEO üzerinde genellikle olumlu etkiler yaratır. Daha hızlı yüklenen sayfalar, iyileştirilmiş Core Web Vitals (özellikle LCP ve FID) metrikleri, arama motorları tarafından sıralama sinyali olarak kabul edilir. Bu, sitenizin arama sonuçlarında daha üst sıralarda yer almasına yardımcı olabilir. Modern arama motoru botları (özellikle Google botları) JavaScript'i çalıştırabildiği için deferred içeriği de görebilir. Ancak, çok kritik ve ilk anda görünmesi gereken içeriği defer etmekten kaçınmak önemlidir.

3. SSS 3: Her bileşeni @defer içine almalı mıyım?

   Cevap: Hayır, kesinlikle almamalısınız. Her bileşeni @defer içine almak, uygulamanızda aşırı karmaşıklığa ve yönetim yüküne yol açabilir. Ayrıca, çok küçük veya zaten hızlı yüklenen bileşenler için @defer kullanmak, kod bölmenin getirdiği ek ağ istekleri ve dosya yönetimi overhead'i nedeniyle performansı olumsuz etkileyebilir. @defer'ı yalnızca başlangıçta kritik olmayan, boyutça büyük veya kullanıcı etkileşimi sonrası ihtiyaç duyulan bileşenler için stratejik olarak kullanmalısınız.

4. SSS 4: @defer ile hangi performans metrikleri en çok iyileşir?

   Cevap: @defer kullanımıyla en çok iyileşmesi beklenen performans metrikleri şunlardır:

   • FCP (First Contentful Paint): İlk anlamlı içeriğin görünme süresi.
   • LCP (Largest Contentful Paint): Sayfadaki en büyük içerikli öğenin yüklenme süresi.
   • TBT (Total Blocking Time): Ana iş parçacığının engellendiği toplam süre.
   • FID (First Input Delay): Kullanıcının sayfayla ilk etkileşimine kadar geçen gecikme.

   Bu metrikler, uygulamanızın "algılanan hızı" ve "etkileşimliliği" için kritik öneme sahiptir.

5. SSS 5: @defer block içindeki CSS nasıl ele alınır?

   Cevap: @defer block içindeki bileşenlerle ilişkili CSS (genellikle bileşenlerin kendi stilleri veya modül stil dosyaları) de ilgili JavaScript paketiyle birlikte tembel yüklenir. Bu, ilk yüklenen CSS miktarını azaltmaya yardımcı olur, böylece sayfanın render-blocking kaynakları azalır. Ancak, sayfanın genel görünümünü ve hissini etkileyen kritik CSS (global stiller, tema değişkenleri) genellikle ilk pakete dahil edilmelidir.