Headless Commerce için Beden Önerisi

Geleneksel bir Shopify veya Magento teması, bir script etiketi ve bir <div> ile beden widget'ini kolayca ekleyebilir. Next.js, Hydrogen veya özel bir React/Vue frontend üzerine kurulu headless bir mağazada böyle bir kısayol yoktur — üçüncü taraf her özellik bir API çağrısı, bir bileşen ve bir render kararı olarak kablolanmalıdır. Mimariyi yanlış kurarsanız beden önerisi sayfadaki en yavaş şey haline gelir.

Composable commerce artık frontend'ini yeniden kuran orta ölçekli ve kurumsal moda markaları için varsayılan yaklaşım haline geldi ve beden rehberi genellikle taşınan son özelliklerden biri oluyor çünkü ürün verisi, oturum durumu ve render stratejisine aynı anda dokunuyor. Bu yazı bu geçişi yapan mühendisler için: beden önerisi mantığı nerede yaşamalı, SSR altında nasıl hızlı tutulur ve kişiselleştirilmiş beden verisinin kullanıcılar arasında sızmasına veya bayatlamasına neden olan önbellekleme hatalarından nasıl kaçınılır.

Headless Entegrasyon Modelini Neden Değiştirir

Monolitik bir mağazada, beden widget'i tedarikçisi genellikle DOM'u doğrudan değiştiren, ürün verisini window globallerinden okuyan ve kendi durumunu yöneten bir script enjekte eder. Bu desen headless kurulumlarda basit bir nedenle bozulur: paylaşılan bir çalışma zamanı yoktur. Next.js veya Remix frontend'iniz, headless CMS'iniz ve commerce backend'iniz (Shopify Hydrogen, commercetools, BigCommerce, Salesforce Commerce Cloud) API'ler üzerinden konuşan ayrı servislerdir ve render'ı tedarikçi değil frontend ekibi kontrol eder.

Bu daha kötü değil, daha iyi bir entegrasyon modelini zorunlu kılar. Kara kutu bir script yerine, beden önerisi katmanı şunları sunmalıdır:

• Ürün tanımlayıcılarını (SKU, beden tablosu ID) kabul edip bir öneri payload'u döndüren bir REST veya GraphQL endpoint'i
• Herhangi bir framework'ün bileşen ağacına eklenebilecek hafif bir istemci bileşeni
• Üçüncü taraf bir alan adının ayarladığı çerezlere bağımlı olmadan kullanıcı ölçüm/profil verisini iletme yolu

Beden önerisini "sadece başka bir API çağrısı" olarak ele alan ekipler bunu günler içinde entegre eder. Eski script-etiketi desenini headless bir frontend'e taşımaya çalışan ekipler ise genellikle haftalarca hydration uyumsuzlukları ve CORS hatalarıyla boğuşur.

Nerede Render Edilmeli: Global Enjeksiyon Değil, PDP Bileşeni

Somut yerleşim sorusu: beden önerisi Ürün Detay Sayfası (PDP) bileşen ağacının içinde mi yaşıyor, yoksa bir analitik etiketi gibi global mi enjekte ediliyor? Headless yapılar için bu her zaman kapsamlı bir PDP bileşeni olmalı, ideal olarak beden seçici arayüzünün kendisiyle aynı yerde konumlandırılmalı.

İki neden var. Birincisi, öneri yalnızca belirli bir ürünün beden tablosu bağlamında anlamlıdır — bileşen PDP'nin bir alt öğesi olduğunda bu bağlamı geçirmek basittir, DOM kazıma yoluyla sayfa bağlamını tahmin eden global bir katman olduğunda ise garip olur. İkincisi, aynı yerde konumlandırmak mevcut kod bölme sürecinize dahil olması demektir: her rotada değil, PDP paketiyle birlikte yüklenir.

React tabanlı headless frontend'lerde yaygın bir yapı:

<ProductDetailPage>
  <ProductGallery />
  <ProductInfo>
    <SizeSelector>
      <SizeRecommendationWidget productId={sku} sizeChartId={chartId} />
    </SizeSelector>
    <AddToCartButton />
  </ProductInfo>
</ProductDetailPage>

Önerinin kendisini sunucu tarafında render etmek için özel bir nedeniniz olmadıkça widget'in kendi ağ çağrılarını istemci tarafında ve tembel yüklenen (next/dynamic ile ssr: false veya framework'ünüzdeki eşdeğeri) halde tutun — ki bu bizi bir sonraki konuya getiriyor.

SSR, Hydration ve Beden Verisinin Neden Nadiren Sunucuda Olması Gerektiği

Öneriyi sunucu tarafında render etmek algılanan performans için cazip görünür, ancak gerçek bir sorun getirir: öneri, kullanıcıya özel duruma bağlıdır (kayıtlı ölçümler, bir fit profili, oturum geçmişi) ve bu genellikle ek altyapı olmadan edge'de veya SSR istek bağlamınızda mevcut değildir. Sunucu tarafında genel, kişiselleştirilmemiş bir yer tutucu render etmek ve kişiselleştirilmiş sürümü istemci tarafında hidratlamak genellikle daha güvenilir bir yoldur.

Pratikte bu şu anlama gelir:

• Beden seçici arayüz kabuğunu (S–XL bedenler, stok durumları) sunucu tarafında render edin, böylece hemen görünür ve indekslenebilir olur
• Hidrasyondan sonra kişiselleştirilmiş öneriyi istemci tarafında, giriş yapmış veya oturumla tanımlanmış alışverişçiye bağlı olarak getirin
• Öneri çağrısı çözülene kadar bir iskelet veya sade beden tablosu gösterin, böylece düzen kayması ve Largest Contentful Paint'in engellenmesi olmaz

Framework'ünüz akış SSR'ı destekliyorsa (örneğin Suspense sınırlarıyla React Server Components), öneri paneli bir Suspense sınırı için ders kitabı adayıdır — bu, PDP'nin geri kalanının hemen boyanmasını sağlarken beden verisinin bir an sonra akmasına izin verir.

Kişiselleştirmeyi Sızdırmadan Önbellekleme

Headless entegrasyonların en sık yanlış gittiği yer burasıdır. CDN ve edge önbellekleme headless performansının çekirdeğindedir — ancak bir beden önerisi yanıtı kişiselleştirilmiştir ve kişiselleştirilmiş bir API yanıtını paylaşılan bir edge düğümünde önbelleğe almak, A alışverişçisinin B alışverişçisinin beden verisini almasına yol açabilir.

Çözüm, önbellek katmanlarının temiz bir şekilde ayrılmasıdır:

Kullanıcı başına öneri yanıtının paylaşılan bir önbellek anahtarının arkasında oturmasına asla izin vermeyin. Performans için öneri çağrısı hakkında bir şeyi önbelleğe almanız gerekiyorsa, altta yatan beden modelini veya beden tablosu eşlemesini (ürün kapsamlı, kullanıcı kapsamlı değil) önbelleğe alın ve nihai kişiselleştirilmiş yanıtı isteğin yukarısında değil, edge'inde hesaplayın.

Ayrıştırılmış Bir Frontend'de Widget'i Hızlı Tutmak

Headless frontend'ler Core Web Vitals açısından eski temalardan daha agresif değerlendirilir, kısmen headless'a geçmenin tüm satış noktası performans olduğu için. Time to Interactive'e 300ms ekleyen bir beden önerisi entegrasyonu bu satış noktasını baltalar. Üç pratik kaldıraç:

1. Öneri mantığını tembel yükleyin, beden seçici kabuğunu değil — kabuk anında görünür olmalı, "önerilen: M" rozeti bir an sonra doldurulabilir.
2. API çağrısını mount'tan sonra ayrı bir gidiş-dönüş yapmak yerine mümkün olduğunda diğer PDP veri getirmeleriyle toplu hale getirin (örneğin, envanter ve fiyatlandırmayı yükleyen aynı GraphQL sorgusu içinde).
3. İstemci tarafı şelalelerden kaçının — iki tanesi paylaşılan bir ürün ID'siyle paralel çalışabiliyorsa, ürün veri getirmesi tamamen çözülmeden beden isteğini başlatmayı bekletmeyin.

Composable mağazalarda gördüğümüz entegrasyon desenlerine dayanarak, iyi tasarlanmış ile kötü tasarlanmış bir beden önerisi çağrısı arasındaki fark genellikle bir ekstra sıralı ağ gidiş-dönüşüdür — tek başına küçük, ama aynı şeyi yapan her diğer ayrıştırılmış özellikle (yorumlar, kişiselleştirme, sadakat widget'leri) birleşir.

Mevcut bir mağazayı taşıyan ekipler bu yazıyı genellikle API ile beden önerisi nasıl eklenir rehberindeki uç nokta ayrıntılarıyla ve Shopify Hydrogen için sanal deneme yazısındaki adım adım anlatımla birlikte okuyor.

YourSizer Nerede Devreye Giriyor

YourSizer'ın beden önerisi API-first olarak inşa edildi, özellikle entegrasyon hacmimizin büyük bir kısmı artık klasik tema kurulumlarından değil headless ve composable yapılardan geldiği için. Çekirdek öneri endpoint'i ürün ve beden tablosu tanımlayıcılarını kabul eder ve yapılandırılmış bir JSON payload'u döndürür, böylece bir Next.js sunucu eyleminden, bir React istemci bileşeninden, bir Vue composable'ından veya bir mobil uygulamadan çağrılabilir — belirli bir şablon motoruna veya DOM yapısına bağımlılık yoktur.

Yukarıda anlatılan deseni öneriyoruz: beden seçici kabuğunu hemen render edin, kişiselleştirilmiş öneriyi istemci tarafında getirin ve global olarak enjekte etmek yerine PDP bileşenine kapsamlı tutun. React Server Components kullanan ekipler için widget, sayfanın geri kalanını engellemeyecek şekilde bir Suspense sınırının içine temiz bir şekilde oturacak şekilde tasarlanmıştır. Composable bir yapıya geçişin ortasındaysanız, entegrasyon dokümanlarımız belirli bir frontend framework'ü gerektirmek yerine doğrudan istek/yanıt şeklini kapsar.

Sıkça Sorulan Sorular

Beden önerisinin kendi backend servisine mi ihtiyacı var, yoksa serverless bir fonksiyon olabilir mi?

İkisi de işe yarar ve seçim çoğunlukla headless yapınızın geri kalanının nasıl organize edildiğine bağlıdır. Serverless bir fonksiyon (Vercel Edge Function, Cloudflare Worker, AWS Lambda), sadece beden önerisi API'sine yapılan bir çağrıyı proxy'liyor ve hafifçe dönüştürüyorsa doğal bir uyumdur, çünkü düşük gecikmeli, durumsuz bir çağrı için kalıcı bir servis çalıştırmaktan kaçınır. Zaten diğer ürün verilerini toplayan bir BFF (backend-for-frontend) katmanı çalıştırıyorsanız, ayrı bir fonksiyon kurmak yerine beden çağrısını bu mevcut katmana katmak genellikle daha basittir.

Frontend durumsuzsa ölçüm veya fit-profil verisi nasıl geçirilmeli?

En temiz yaklaşım, fit profilini sepet veya oturum durumunu ele aldığınız gibi ele almaktır: bunu sunucu tarafında bir oturum veya hesap ID'sine karşı saklayın ve frontend'in yalnızca bu tanımlayıcıyı öneri API'sine geçirmesini sağlayın, API gerçek ölçümleri dahili olarak çözer. Bu, frontend'i durumsuz tutar ve ham vücut ölçümlerini istemci tarafı kod veya URL parametreleri üzerinden geçirmekten kaçınır, ki bu hem bir gizlilik endişesi hem de her istekte gereksiz bir payload artışıdır.

Bir beden önerisi API çağrısı eklemek headless bir kurulumda PDP yükleme sürelerine zarar verir mi?

Beden seçici bileşenine kapsamlı, engellemeyen, tembel yüklenen bir çağrı olarak uygulanırsa hayır — bu headless entegrasyonlar için standart desendir. Beden tablosu ve satın alma kutusu, öneri çözülmüş olsun ya da olmasın hemen render edilmelidir; önerinin kendisi düzeni kaydırmadan bir an sonra dolmalıdır. Bir beden entegrasyonundan performans gerilemesi gören ekipler neredeyse her zaman çağrıyı senkron olarak engelliyor veya diğer PDP verilerinden önce getiriyordur, ikisi de özelliğin doğasında olan sınırlamalar değil, uygulama tercihleridir.

Sonuç

Headless commerce beden önerisi eklemeyi zorlaştırmaz — entegrasyon kararlarını daha görünür hale getirir, çünkü kötü bir mimari kararı bir script etiketinin arkasında saklayan bir framework sihri yoktur. Öneriyi global bir enjeksiyon yerine kapsamlı, tembel yüklenen, oturum farkında bir API çağrısı olarak ele alın, kişiselleştirilmiş yanıtları paylaşılan önbelleklerin dışında tutun, ve özellik kurduğunuz composable yapıya ne olursa olsun eklenti gibi değil, doğal hissettirir. 2026'da daha fazla moda markası headless geçişlerini tamamladıkça, ayakta kalacak entegrasyonlar bir tema-çağı script'inden uyarlanan değil, baştan API-first olarak tasarlananlar olacak.