Shopify Plus Checkout Sayfasında Performans Sınırları Nelerdir?

Checkout Extensibility'nin mimari sınırı

Shopify Plus'ta checkout özelleştirme, eski script.liquid ve checkout.liquid modellerinden tamamen ayrışan bir yapıya geçti. Bu eski yöntemler artık desteklenmiyor; yeni mağazalar Checkout Extensibility çatısı altında çalışıyor. Bu çatı, UI Extension'lar ve Function'lar aracılığıyla checkout akışına müdahale etmenize olanak tanır: özel form alanları, ek bilgi blokları, indirim mantığı, gönderim filtresi.

Render'ın kendisi Shopify'a aittir. Sayfa iskeletini, asıl ödeme formunu, adres giriş alanlarını ve sipariş özetini Shopify oluşturur. Siz bu iskelet üzerine bileşen ekleyebilir, bazı bölümleri yeniden sıralayabilir ve Function API ile sunucu tarafı mantığını değiştirebilirsiniz. Checkout sayfasının temel HTML'i, CSS'i ve ana JavaScript paketi Shopify'ın CDN'inden gelir; bu dosyaların içeriğine dokunmak mümkün değildir.

Bu mimari bir kısıtlama, ama aynı zamanda bir güvencedir. Shopify'ın global CDN'i ve Anycast yönlendirmesi sayesinde temel sayfa teslimi çoğu durumda sağlıklı TTFB değerleri üretir. Sorun çoğu zaman bu temelden değil, üstüne eklenenlerden çıkar. Checkout Extensibility'yi kullanan bir geliştirici olarak sahip olduğunuz alan, sayfanın göreli olarak küçük bir dilimidir; geri kalanı Shopify'ın pipeline'ında işlenir ve dışarıdan erişilemez.

LCP üzerindeki baskı: hangi kaynaktan geliyor?

Checkout'ta LCP elementi genellikle bir hero görseli değildir. Çoğu durumda ödeme formu bloğu, sipariş özeti veya gönderim seçenekleri paneli LCP olarak ölçülür. Shopify bu bileşenleri kendi render pipeline'ından geçirdiği için sunucu tarafı gecikme minimum düzeyde tutulur. Sorun, LCP elementinin tarayıcıya ne zaman ulaştığından çok, render'ı bloke eden kaynakların ne zaman çözüldüğüne bağlıdır.

UI Extension olarak eklenen bir bileşen, React tabanlı checkout shell yüklenip hydrate olduktan sonra render edilir. Bu hydration süreci LCP elementini doğrudan engellemez, ama main thread üzerindeki yük arttıkça LCP gecikmesi de artar. Üç veya daha fazla UI Extension aktifse bu etkinin belirginleştiği gözlemlenir; tek ya da iki uzantıda fark genellikle marjinaldir.

Checkout sayfasına eklenen üçüncü parti script'ler farklı davranır. Bir loyalty programı SDK'sı veya chat widget'ı senkron script etiketi olarak checkout'a dahil ediliyorsa bu LCP'yi doğrudan bloke edebilir. Checkout Extensibility içinden değil de doğrudan HTML enjeksiyonu yoluyla eklenen kaynaklar bu riski taşır. Marka logosu görsel olarak checkout'ta bulunuyorsa ve fetchpriority="high" ile işaretlenmemişse LCP hesaplamasını olumsuz etkileyebilir; bu kenar durum gibi görünse de mobil cihazlarda fark edilir biçimde öne çıkar.

INP ve etkileşim gecikmesi: gecikme nerede başlıyor?

Checkout sayfasında etkileşim gecikmesi en çok şu anlarda yaşanır: kullanıcı bir adres alanına tıkladığında, gönderim seçeneğini değiştirdiğinde veya kupon kodu uyguladığında. Bu etkileşimlerin her biri hem Shopify'ın kendi mantığını hem de varsa Function API çağrısını tetikler.

INP (Interaction to Next Paint) bu gecikmeleri toplu ölçer. Shopify'ın kendi etkileşim işleyicileri genel olarak optimize edilmiş durumdadır; asıl tehlike eklenen uzantıların kendi event listener'larından gelir. Bir UI Extension, aynı etkileşime bağlı kendi state güncellemesini tetikliyor ve bu güncelleme ağır bir hesaplama ya da büyük DOM değişikliği içeriyorsa INP değeri yükselir. Yüksek INP eşiği 500 milisaniye olarak tanımlanmıştır; checkout sayfalarında bu eşiği aşmak dönüşüm kaybına yol açar.

Ödeme sağlayıcılarının SDK'ları da bu resmin içindedir. Stripe.js, Braintree ve benzer kütüphaneler kendi iframe'lerini oluştururlar; bu iframe'ler ana sayfanın INP'sini doğrudan etkilemez. Ancak iframe ile ana sayfa arasında postMessage tabanlı iletişim varsa ve bu iletişim senkron state değişikliklerine yol açıyorsa gecikme ana thread'e sızabilir. Bu senaryoyu izole etmek için Chrome DevTools'un Performance panelinde iframe katmanlarını ayrı incelemek gerekir.

Shopify Function'ları INP üzerinde farklı biçimde etki eder. Fonksiyon sunucu tarafında çalıştığı için yerel hesaplama yükü oluşturmaz; ama bir ağ turu gerektirdiği için yüksek gecikme koşullarında etkileşim yanıt süresi uzayabilir. Özellikle gönderim seçeneği değişikliklerinde bu belirgin olur: kullanıcı hızla birden fazla seçenek deniyorsa ve her değişiklik bir Function turu tetikliyorsa istek birikimi yaşanabilir.

Ödeme script'leri ve CLS: ölçülen ama gözden kaçan kayma

CLS (Cumulative Layout Shift) checkout sayfalarında çoğu zaman göz ardı edilir. Sayfa yüklenirken sipariş özeti bloğunun ani büyümesi, ödeme yöntemi ikonlarının geç render edilmesi veya dinamik olarak açılan kupon alanı CLS puanını yukarı çekebilir. CLS eşiğinin iyi kabul edilen üst değeri 0,1'dir; checkout sayfalarında bu eşiği aşmak, mobil cihazlarda özellikle, kullanıcıyı yanlış elemente tıklatma riskini taşır.

Ödeme sağlayıcıları kendi ödeme formu bileşenlerini asenkron yükler. Bu bileşenler tarayıcı tarafından render edildiğinde çevresindeki layout'u kaydırabilir. Kaydırmayı önlemenin yolu o elementler için alan rezervasyonu yapmaktır. Rezerve edilmemiş ödeme bileşenleri sayfaya geldiklerinde shift üretir; bu shift kullanıcı gözünde bir titreme olarak görünür ve CLS metriğine eklenir. Layout kayması geçici bile olsa tarayıcı bunu kaydeder ve puanı etkiler.

Checkout Extensibility içinden eklenen UI Extension'lar da aynı riski taşır. Extension'ın yüksekliği render öncesinde bilinmiyorsa ve layout dinamik olarak genişliyorsa CLS değeri etkilenir. Shopify'ın Extension API'si minHeight ve maxHeight parametrelerine sahiptir; bunları önceden tanımlamak riski azaltır ama tamamen ortadan kaldırmaz. Bileşenin içeriği farklı dil uzunluklarına ya da kullanıcı koşullarına göre değişiyorsa sabit yükseklik tanımlamak yetmeyebilir.

Kontrol edebildikleriniz ve edemeyecekleriniz

Gerçekçi bir sınır haritası için iki sütun gerekir. Hangisinin sizin alanınızda olduğunu görmeden yapılan optimizasyon denemeleri çoğu zaman kontrol edilemeyen katmana çarpıp geri döner.

Elinizde olanlar şunlardır: UI Extension'ların toplam JavaScript yükü ve hydration maliyeti. Üçüncü parti script'lerin eklenme yöntemi - senkron mu, async mı, defer mı. Function API çağrılarının karmaşıklığı ve yürütme süresi - Shopify'ın 5 milisaniyelik Wasm kotası içinde tutulabilir. Ödeme provider seçimi - bazı provider'ların SDK'ları diğerlerine göre çok daha az main thread yükü üretir. CLS'e yol açan dinamik bileşenler için alan rezervasyonu yapılıp yapılmadığı da sizin kararınızdır.

Elinizde olmayanlar: checkout sayfasının temel HTML'i ve CSS'i, Shopify'ın checkout shell JavaScript paketi ve versiyonlama politikası, ödeme formu iframe'lerinin iç yapısı, Shopify CDN'inin önbellek süreleri, checkout'un sunucu tarafı render sıralaması. Bu katmanlarda Shopify'ın yaptığı iyileştirmeler otomatik olarak size yansır; siz bu katmanlara müdahale edemezsiniz.

"Checkout LCP sorununu çöz" biçiminde genel bir görev tanımı, hangi katmanın bozulduğunu netleştirmeden başlatılırsa çalışma süresi büyük ölçüde boşa gider. Özellikle üçüncü parti araçların ürettiği raporlardaki "checkout sayfanızı hızlandırın" tavsiyeleri, sizin alanınızda olmayan değişkenleri hedef alıyor olabilir.

Checkout sayfasında performans bütçesi

Performans bütçesi, checkout sayfasına ekleyeceğiniz her kaynağın taşıması gereken bir tavan değeridir. Shopify Plus platformu checkout sayfasının temelini sağlar; siz üstüne yazdığınız her satır bu bütçeden pay alır.

JavaScript tarafında UI Extension'ların toplam boyutu izlenmelidir. Her extension kendi bundle'ıyla gelir; bu bundle'lar checkout shell yüklendikten sonra ek ağ isteği ve parse maliyeti üretir. Toplam extension JavaScript yükü sıkıştırılmış 100-150 KB'ın üzerine çıktığında hydration maliyeti ölçülebilir biçimde artmaya başlar; bu eşiğin üzerinde extension eklemek, ciddi bir gerekçe olmadan yapılmamalıdır.

Ağ isteği sayısı da bir bütçe kalemi olarak ele alınmalıdır. Checkout'ta her ek üçüncü parti bağlantı, tarayıcının yeni bir TLS el sıkışması kurmasına yol açar. Beş farklı origin'den kaynak yükleyen bir checkout sayfası, iki origin'den yükleyen bir sayfaya göre belirgin biçimde daha fazla bağlantı kurulum süresi harcar. Bu özellikle düşük bant genişlikli mobil bağlantılarda fark yaratır.

Function API yanıt süresini takip etmek başka bir bütçe boyutudur. Shopify, Function yürütme süresini 5 milisaniye ile sınırlar. Bu sınırın içinde kalmak gerekli ama yeterli değildir; Function'ın tetiklediği toplam ağ turunun süresi de hesaba katılmalıdır. Kullanıcı hızla birden fazla gönderim seçeneği deniyorsa ve her değişiklik bir Function turu tetikliyorsa, istek birikimi yaşanabilir ve bu birikimin görünür bir şekilde yavaş bir etkileşim olarak yansıması kuvvetle muhtemeldir.

Checkout'ta Core Web Vitals nasıl izlenir?

CrUX (Chrome UX Report) verileri checkout URL'lerini çoğu zaman yeterli hacimde toplamaz. Checkout oturum gerektiren bir URL'de yer alır ve bu URL'lerin gerçek kullanıcı verisi dışarıya çıkması kısıtlanmış olabilir. Saha verisi izlemenin birincil yolu platformun kendi analitiği veya özelleştirilmiş bir RUM (Real User Monitoring) kurulumudur.

Shopify Analytics checkout dönüşüm hızını izler ama Core Web Vitals doğrudan burada görünmez. Web Vitals kütüphanesini bir UI Extension içinden yükleyip event'leri kendi analitik endpoint'inize göndermek mümkündür. Bu yöntem checkout sayfasına özgü LCP, INP ve CLS verisi üretir; ancak ölçüm kodunun kendisi de checkout'a eklenen bir yük olduğu için bütçeden pay alır. Küçük tutulmuş bir RUM uygulaması genellikle 5-10 KB sıkıştırılmış JavaScript ile karşılanabilir.

Lab ortamında test etmek için oturum açık bir tarayıcı profili kullanmak gerekir. Anonim modda checkout'a doğrudan erişim her zaman mümkün değildir. Bu durum checkout performans testlerini otomasyona direnç gösteren bir alan yapar; testler çoğunlukla elle yapılan tarayıcı testine dayanır. Alternatif olarak, Puppeteer veya Playwright ile oturum cookie'si aktarımını içeren bir otomasyon zinciri kurulabilir; bu yöntem karmaşık ama tekrar edilebilirdir ve CI sürecine entegre edilebilir.