Hydrogen mı Liquid mi: headless ne zaman kendini amorti eder?

“Headless’a geçmeli miyiz?” konuşmalarının çoğu bir belirtiyle başlar: mağaza yavaş geliyordur, bir tasarımcı temanın yapamadığı bir şey istiyordur ya da bir ajans bunu önermiştir. Faydalı soru daha dardır: Tema tam olarak neyi yapamıyor ve bu, vitrin var olduğu sürece ayrı bir uygulamanın sahibi olmaya değer mi?

Headless’a geçince gerçekte ne değişir?

Liquid temada Shopify her sayfayı, mağaza sahiplerinin tema düzenleyicide değiştirdiği JSON yapılandırma dosyalarıyla birlikte Liquid şablonlarından render eder ve sonucu barındırır. Mağaza sahipleri tema düzenleyicide bölümlerin yerini değiştirir ve ayarları düzenler. Uygulamalar özelliklerini tema uygulama uzantılarıyla ekler; bunların dosyaları Shopify’ın CDN’inden sunulur ve tema kodunu düzenlemezler.

Hydrogen’da vitrin, üzerinde Shopify’ın bileşenleri, yardımcı araçları ve CLI’ı bulunan bir React Router uygulamasıdır. Ürünleri, koleksiyonları ve sepetleri Storefront API’den okur; Shopify’ın Hydrogen barındırma hizmeti Oxygen’da ya da seçtiğiniz başka bir JavaScript çalışma ortamında çalışır. Ana kayıt sistemi yine Shopify’dır; API ile tarayıcı arasındaki her şey ekibinizin sahibi olduğu koda dönüşür.

Headless ne zaman kendini amorti eder?

Headless, vitrinin kendisi ürün olduğunda maliyetini hak eder: yani bir temanın ancak zorla eğilip bükülerek sunabileceği bir şey söz konusuysa. Baktığımız işaretler şunlar:

• Bir temanın temiz biçimde ifade edemeyeceği bir deneyim: bir ürün yapılandırıcı, uygulama hissi veren bir gezinme akışı, yoğun istemci tarafı durum yönetimi ya da süs değil markanın parçası olan hareket.
• Birkaç sistemden gelen içerik ve ticaretin tek bir ön yüzde toplanması; bir temanın her kaynak için geçici çözüm gerektireceği durumlar.
• Birden fazla yüzeyde paylaşılan bir ön yüz; örneğin aynı bileşenleri ya da veri katmanını okuyan web ve native bir uygulama.
• Kalıcı geliştiriciler. Bir Hydrogen vitrini, onu yükseltecek, önbelleğini izleyecek ve bir API sürümü değiştiğinde düzeltecek birine ihtiyaç duyar.

Çalışan bir örnek: Snow / Motion, Shopify’ın örnek ürünleri üzerine geliştirdiğimiz bir Hydrogen vitrin projesidir. Koleksiyonlar ve ürün özellikleri metafield’larla (meta alanlarla) yönetilir, ikincil veriler ilk yanıttan sonra akış (streaming) ile gelir ve hareket yalnızca işe yaradığında yüklenir.

Ne zaman etmez?

• Sorun yalnızca hızsa. Shopify’ın yavaş bir mağaza için kendi önerisi, Horizon ailesi gibi güncel ve optimize edilmiş bir temayla, şablon başına daha az bölümle ve her uygulamanın yükleme süresine mal olduğu kadar değip değmediğini kontrol etmekle başlar. Headless bir yapı hızlı olabilir, ama kendiliğinden olmaz: nasıl kurulduğuna ve önbelleğe alındığına bağlıdır. Önce temadan giden yol için performans ve teknik SEO sayfasına bakın.
• Mağaza temada yaşayan uygulamalara dayanıyorsa. Yorumlar, paketler, sadakat widget’ları ve sayfa oluşturucular genellikle app block olarak gelir. Headless’ta her biri sağlayıcısından bir API ya da headless SDK ve onu entegre edecek bir geliştirici ister.
• Ürün ve kampanya ekibi sayfaları her hafta düzenliyorsa. Tema düzenleyici gerçek bir üründür. Onun yerine bir CMS ya da metaobject tabanlı bölümler koymak iş ister; daha kötü bir düzenleyici de ekibe her gün yansıyan gizli bir maliyettir.
• Yayından sonra kodun sahibi kimse olmayacaksa. Bakımı yapılmayan bir Hydrogen uygulaması framework’ünün ve Storefront API’nin gerisinde kalır. Kendi hâline bırakılan bir tema ise zamanla daha az yıpranır.

Sonradan ortaya çıkan maliyetler

Barındırma nadiren belirleyici maliyettir: Oxygen ücretli Shopify planlarında ek ücret olmadan sunulur (Agentic planlarında sunulmaz). Önemli olan maliyetler insanların zamanıdır:

• Önbellek sizin işiniz. Hydrogen, Storefront API isteklerini varsayılan olarak önbelleğe alır (her alt istek bir saniye sonra yeniden doğrulanır ve bir güne kadar sunulabilir) ve CacheShort, CacheLong, CacheNone ile özel stratejiler sunar. Kişiye özel veriler asla paylaşılan bir önbelleğe alınmamalıdır; tam sayfaların da kendi başlıkları olmalıdır. Bunu yanlış yaparsanız ya hız kaybedersiniz ya da bir ziyaretçinin verisini başka birine sızdırırsınız.
• Yükseltmeler. Shopify her çeyrekte yeni bir API sürümü çıkarır ve her birini en az 12 ay destekler. Hydrogen bunun üstüne kendi sürümlerini yayınlar. Yükseltme işini bir kez değil, her yıl bütçeleyin.
• Platformun yönü. 30 Haziran 2026’da Vercel ve Shopify, Hydrogen’ı Next.js, Nuxt ve Svelte gibi framework’lerle kullanılabilen, açık kaynak ve çalışma ortamından bağımsız bir proje olarak sıfırdan yeniden yazdıklarını duyurdu. Duyuru, var olan Hydrogen uygulamaları için bir geçiş takvimi vermedi. Bugün başlayan bir proje veri katmanını (sorgular, önbellek, içerik modeli) framework kodundan ayrı tutmalıdır; böylece ileride bir geçiş baştan yazmak değil, taşımak olur.

Adım adım nasıl karar verilir?

1. Bugünkü temanın yapamadığı belirli şeyleri yazın. Liste yalnızca “daha hızlı” ise durun ve önce temayı denetleyin.
2. Her maddeyi özel bölümleri olan modern bir Online Store 2.0 temasıyla karşılaştırın. “Tema sınırlarının” çoğu aslında eski tema sınırlarıdır.
3. Vitrinde varlığı olan her uygulamayı listeleyin ve bir API’si ya da headless desteği olup olmadığını öğrenin.
4. Yayından sonra içeriği kimin, nasıl düzenleyeceğine karar verin. Cevap “tema düzenleyici” ise headless’ın bir yedek plana ihtiyacı vardır.
5. Yıllık sahiplik maliyetini tahmin edin: yükseltmeler, önbellek, izleme ve bunları yapan geliştirici.
6. Headless hâlâ öndeyse tüm mağazaya girişmeden önce en zor şablonun (genellikle ürün ya da koleksiyon) prototipini yapın.

Cevap headless ise sırada iki karar var: vitrinin nerede çalışacağını Hydrogen’ı Oxygen’da mı Workers’ta mı barındırmalı yazısında, arama trafiği kaybetmeden nasıl taşınacağını da Liquid’den Hydrogen’a geçiş kontrol listesinde ele alıyoruz.

Headless’ı önerene sorulacak sorular

Bir ajans ya da geliştirici Hydrogen önerdiyse, bu sorular üzerinde düşünülmüş bir öneriyi varsayılan bir öneriden ayırır:

• Tema tam olarak hangi gereksinimi karşılayamıyor? Cevap “esneklik” ya da “performans” değil, bir özellik ya da şablon adı vermeli.
• Vitrinde kullandığımız her uygulamaya ne olacak? “Çoğu uygulama çalışır” değil, her uygulama için bir entegrasyon planı içeren bir liste bekleyin.
• Yayından sonra ekibimiz ana sayfadaki bir bannerı nasıl değiştirecek? Cevap “bir talep açın” ise bu maliyeti hesaba katın.
• Ne önbelleğe alınıyor, ne kadar süreyle ve ne asla önbelleğe alınmıyor? Net bir cevap, önbelleğin varsayılanlara bırakılmadığını, tasarlandığını gösterir.
• Hydrogen’ı ve Storefront API sürümünü kim, ne sıklıkla yükseltecek? Bu, adı belli bir kişi ya da bir bakım anlaşmasında bir kalem olmalı.
• Bu plan Hydrogen’ın yeniden yazılmasına nasıl dayanır? Haziran 2026 duyurusu düşünüldüğünde dürüst bir cevap belirsizliği kabul eder ve kodun bunu sınırlamak için nasıl yapılandırıldığını açıklar.

Lintel’in yaklaşımı

Lintel varsayılan olarak Liquid üzerine geliştirir ve headless’ı yalnızca yukarıdaki liste karşılığını vereceğini söylediğinde önerir. Hydrogen tarafını birinci elden biliyoruz: bu web sitesi Cloudflare Workers’tan sunulan bir Hydrogen uygulamasıdır; Snow / Motion da örnek veriler üzerindeki Hydrogen vitrin projemizdir. İkisi de bir müşteri vitrini değildir ve bunu açıkça söylüyoruz. Bize kazandırdıkları, headless bir projede temanın sizin yerinize hallettiği kısımları yakından tanımaktır.