Bu sayfada
Bir beden önerisi widget'ı düşünen her mağaza sahibi, doğruluk konusunu sormadan önce sessizce aynı soruyu sorar: bu, mağazamı yavaşlatır mı? Haklı bir endişe. Largest Contentful Paint'i geciktiren ya da layout shift tetikleyen bir beden aracı, sağlaması gereken dönüşüm artışını sessizce silebilir. İyi haber şu: doğru kurulduğunda hız ile beden zekası birbirine karşıt değil.
Beden widget sayfa hızı neden düşündüğünüzden daha önemli
Sayfa hızı artık bir gösteriş metriği değil — doğrudan gelire ve Google'ın ürün sayfalarınızı nasıl sıraladığına bağlı. Google'ın e-ticaret siteleri üzerine yaptığı araştırma, sayfa yükleme süresi 1 saniyeden 3 saniyeye çıktığında sıçrama olasılığının belirgin biçimde arttığını, her ek 100 milisaniyelik gecikmenin dönüşüm oranını aşındırdığını gösteriyor. Ürün sayfalarına ücretli trafik gönderen bir moda mağazası için yavaş bir üçüncü taraf script'i teknik bir dipnot değil, para ödeyerek doldurduğunuz hunide bir sızıntıdır.
Bu, beden araçları için özellikle önemli çünkü genelde mağazanın ana teması zaten optimize edildikten sonra eklenirler. Bir beden önerisi widget'ı tipik olarak kendi JavaScript paketini, fontlarını, bazen de 3D ya da görsel tabanlı bir önizlemeyi yükler. Dikkatsizce eklenirse — senkron, head içinde, render'ı bloke ederek — tek bir deploy'da aylar süren Core Web Vitals çalışmasını geri alabilir. Moda mağazanızı hızlandırarak dönüşümü artırma konusunda çalışma yaptıysanız, kötü entegre edilmiş bir beden uygulaması bunu bir gecede boşa çıkarabilir.
Bir beden widget'ının bozabileceği üç vital
- LCP (Largest Contentful Paint): widget katlanma çizgisinin üstünde bir görsel, iframe ya da ağır bir DOM bloğu enjekte ederse, LCP elemanı haline gelebilir ya da onu geciktirebilir.
- CLS (Cumulative Layout Shift): sayfa yerleştikten sonra beliren bir "Bedenimi bul" butonu, satın al butonunu aşağı iter — klasik ve önlenebilir bir CLS cezası.
- INP (Interaction to Next Paint): kendi başlatma sürecinde ana thread'i ele geçiren bir widget, kullanıcı yakınlarda herhangi bir yere tıkladığında tüm sayfayı tepkisiz hissettirebilir.
Asenkron yükleme: vazgeçilmez ilk adım
En yüksek etkili karar, widget'ın script etiketinin nasıl yüklendiğidir. Kurulmaya değer her beden uygulaması, JavaScript'inin sayfanın geri kalanıyla paralel indirildiği ve HTML parse işlemini bloke etmediği asenkron ya da defer yüklemeyi desteklemelidir.
| Yükleme yöntemi | Render'ı bloke eder mi? | Beden widget'ları için önerilir mi? |
|---|---|---|
head içinde senkron <script> | Evet | Hayır |
defer özniteliği | Hayır, parse'dan sonra çalışır | Evet, çoğu durumda |
async özniteliği | Hayır, hazır olunca çalışır | Evet, script'in DOM bağımlılığı yoksa |
| Etkileşimde dinamik enjekte edilen | Hayır | Katlanma altı ya da yalnız modal araçlar için en iyisi |
Çoğu moda mağazası için doğru desen şudur: widget'ın çekirdek script'ini defer ile yükleyin, 3D beden modeli gibi daha ağır her şeyi yalnızca müşteri beden panelini gerçekten açtığında yükleyin. Bazen tembel hidrasyon (lazy hydration) denen bu ikinci adım, hızlı bir entegrasyonu yavaş olandan ayıran şeydir ve mobilde hızlı yüklenen 3D beden önizlemesi yazısında ele alınan ilkeyle aynıdır.
Tembel başlatma: müşterinin istemediğine ödeme yapmayın
Ürün sayfasındaki bir beden önerisi butonunun sayfa yüklendiği anda tam öneri motoruna, model varlıklarına ya da beden tablosu verisine ihtiyacı yoktur. İhtiyacı olan:
- Tema ile birlikte gelen CSS ile stillenmiş küçük bir tetikleyici buton (uzaktan bir stil sayfası değil).
- Bir tıklama ya da intersection-observer dinleyicisi.
- Yalnızca müşteri etkileştiğinde yüklenen ağır mantık — ölçüm formları, 3D önizlemeler, ML çıkarım çağrıları.
Bu, tembel başlatmadır (lazy initialization) ve sayfa yüklemesine 40 milisaniye ekleyen bir widget ile 2 saniye ekleyen bir widget arasındaki farktır. Beden aracını hiç açmayan müşteriler onun performans maliyetini asla ödememelidir. Açanlarsa kısa, beklenen bir yükleme anını kabul eder çünkü onu kendileri tetiklemiştir — beklenen gecikme, beklenmedik gecikmeye göre çok daha iyi tolere edilir.
CLS'yi ortadan kaldırmak için layout alanı ayırmak
Beden widget'larından kaynaklanan CLS cezaları neredeyse her zaman tek bir hatadan gelir: buton ya da rozet, sayfa zaten render edildikten sonra, ayrılmış bir alan olmadan DOM'a enjekte edilir. Çözüm basit ve sıklıkla atlanıyor.
- Widget'ın script'i çalışmadan önce bile, temanın kendi HTML/CSS'inde beden butonu için sabit yükseklikli bir konteyner ayırın.
- Herhangi bir modal ya da panele
position: fixedya da overlay davranışı verin ki çevresindeki içeriği asla itmesin. - Widget sayfada satır içi bir beden tablosu render ediyorsa, konteynerine nihai render edilmiş yüksekliğe eşit bir
min-heightverin.
Shopify üzerinden entegrasyon yapan mağaza sahipleri, Shopify'a beden önerisi widget'ı ekleme yazısında anlatılan aynı içerme yaklaşımını izlemeli — buradaki yerleştirme deseni özellikle widget düşünülmeden inşa edilmiş tema bölümlerinde layout shift'ten kaçınmak için tasarlandı.
Beden aracı için gerçek bir performans bütçesi belirlemek
"Yeterince hızlı" bir strateji değildir — bir sayıya ihtiyacı var. Herhangi bir beden aracı kurmadan önce, entegrasyonu sahiplenen kişiyle — ister şirket içi geliştirici ister uygulama sağlayıcının destek ekibi — bir performans bütçesi üzerinde anlaşın.
| Bütçe kalemi | Hedef |
|---|---|
| İlk sayfa yüklemesinde eklenen JS | 15 KB gzip altı (yalnızca buton + tetikleyici) |
| Eklenen LCP gecikmesi | 0 ms (widget asla LCP elemanı olmamalı) |
| Eklenen CLS | 0.01 altı |
| Tıklama sonrası widget'ın etkileşilebilir olma süresi | 4G'de 1 saniye altı |
| İlk yüklemede üçüncü taraf istekleri | 0-1 (geri kalanı erteleyin) |
Bu bütçeye, bir tema geliştiricisini tutacağınız gibi tedarikçiyi de tutun. Saygın bir beden uygulaması, talep üzerine Lighthouse ya da WebPageTest sayılarını memnuniyetle verir; YourSizer dahil çoğu modern entegrasyon, tam olarak ertelenmiş yükleme etrafında inşa edilmiştir, böylece müşteri katılana kadar mağazanın çekirdek deneyimi el değmemiş kalır.
Yayına almadan önce test etmek
Yalnızca tedarikçinin pazarlama rakamlarına güvenmeyin. Kendi öncesi/sonrası karşılaştırmanızı yapın:
- Herhangi bir şey kurmadan önce üç temsili ürün sayfasında Lighthouse ya da PageSpeed Insights skoru alın.
- Widget'ı staging temasında ya da bir tema kopyasında kurun, asla doğrudan canlı temada değil.
- Aynı üç sayfayı tekrar çalıştırıp LCP, CLS ve Total Blocking Time farklarını karşılaştırın.
- Fark bütçenizin içindeyse ancak o zaman canlıya alın.
Bu kademeli devreye alma sizi ikinci, daha az belirgin bir riskten de korur: bazı beden uygulamaları tema CSS'iyle çakışan global bir stil sayfası yükler ve ilgisiz elemanlarda stilsiz içerik yanıp sönmesine (flash-of-unstyled-content) neden olur. Staging'de test etmek, bunu müşteriler görmeden yakalar.
Pratikte iyi entegrasyonlar nasıl görünür
En hızlı beden aracı entegrasyonları ortak bir biçimi paylaşır: küçük, temaya özgü bir tetikleyici buton, ertelenmiş bir script etiketi ve müşteri kullanmayı taahhüt ettiğinde ancak o zaman beden tablosu verisi, giysi ölçüleri ya da 3D varlıkları çeken tembel yüklenen bir panel. Bu deseni izleyen perakendeciler tipik olarak ölçülebilir LCP etkisi görmezken, CLS skorları Google'ın "iyi" bandında kalır ve yine de iadeleri azaltan beden güvenini sağlarlar.
Herhangi bir eklenti script'ini — beden, yorum, sohbet, yukarı satış — değerlendiren mağaza sahipleri için daha geniş ders aynıdır: performans ve işlevsellik karşıt hedefler değildir. Bir sıralama sorunudur. Tetikleyiciyi hızlı yükleyin, özü talep üzerine yükleyin.
Sıkça Sorulan Sorular
Beden widget'ı eklemek her zaman sayfa hızını mı bozar?
Hayır. İyi kurulmuş bir widget, müşteri tıklayana kadar yükleme süresine etkin olarak hiçbir etkisi olmayan küçük, ertelenmiş bir tetikleyici script ekler. Performans riski özellikle senkron yüklemeden, ayrılmamış layout alanından ya da 3D modeller gibi ağır varlıkların etkileşim üzerine tembel yüklenmesi yerine ilk sayfa yüklemesine paketlenmesinden gelir.
Bir beden aracı kurduktan sonra ürün sayfalarım ne kadar yavaşlar?
Widget asenkron ya da defer yükleme ve tembel başlatma ile entegre edildiyse, Core Web Vitals'daki ölçülebilir fark sıfıra yakın olmalıdır. Buna karşılık kötü entegre edilmiş widget'lar LCP'ye yüzlerce milisaniye ve ölçülebilir CLS ekleyebilir, bu yüzden yayına almadan önce staging'de test etmek gereklidir.
Bir beden widget'ı için özellikle hangi Core Web Vitals'ı kontrol etmeliyim?
Widget'ın asla sayfanızın en büyük içerik elemanı olmadığını ya da onu geciktirmediğini doğrulamak için LCP'ye, tetikleyici buton ya da panel belirdiğinde herhangi bir layout shift olmadığını doğrulamak için CLS'ye ve beden butonuna tıklamanın sayfanın geri kalanını dondurmadığını doğrulamak için INP'ye odaklanın. Bu kontrolleri hem mobilde hem masaüstünde çalıştırın çünkü mobil bağlantılar eklenen script ağırlığına çok daha duyarlıdır.
Widget'ı canlıya almadan önce staging'de test etmeli miyim?
Evet, her zaman. Bir kopya ya da staging temasında kurun, birkaç temsili ürün sayfasında öncesi/sonrası Lighthouse ya da PageSpeed Insights çalıştırın ve skor farkı önceden anlaştığınız performans bütçesine uyduğunda ancak o zaman canlı temanıza yükseltin. Bu ayrıca widget'ın kendisiyle ilgisiz, flash-of-unstyled-content sorunlarına neden olabilecek CSS çakışmalarını da yakalar.
