Mücevher Sitesi Core Web Vitals Optimizasyonu

Mücevher sitesinde Core Web Vitals optimizasyonu, ana ürün görselini HTML içinde erken yüklemekle başlar. İlk ekran dışındaki fotoğrafları ertelemek, varyant kodunu hafifletmek ve fiyat alanına sabit yer ayırmak da bu işin parçasıdır. Sorun yüksek kaliteli ürün fotoğrafı kullanmak değil. Sorun, 4 MB’lık yüzük görselini slider içinde saklamak, taksit widget’ını sonradan eklemek ve ilk tıklamada müşteriye gereksiz JavaScript yüklemektir.

Mücevherde görsel, satış mesajının kendisidir. Taş kesimi, metal tonu ve işçilik detayı fotoğrafta görünmelidir. Ancak baskı kalitesindeki kaynak dosyayı her mobil ziyaretçiye göndermek ürünün değerini anlatmaz. Ürünün ekrana geç gelmesine neden olur. Bu yazı, ana sayfa, kategori sayfası ve ürün detay sayfasındaki LCP, INP ve CLS sorunlarını hangi sırayla incelemeniz gerektiğini anlatır.

Key Takeaways

• Mücevher ürün sayfasında LCP çoğunlukla ana ürün görselidir; bu görsel lazy-load edilmemeli ve ilk HTML içinde bulunabilir olmalıdır.
• İyi Core Web Vitals hedefi 75. yüzdelikte LCP için en fazla 2,5 saniye, INP için 200 ms altı ve CLS için 0,1 altıdır.
• Yüzük ölçüsü, taş tipi ve altın ayarı seçimlerinde tüm sayfayı yeniden render etmek hem INP’yi hem CLS’yi bozar.
• Taksit tabloları, kampanya şeritleri ve güven bileşenleri için baştan alan ayrılmazsa fiyat ve “sepete ekle” butonu sayfa yüklenirken kayar.
• PageSpeed puanı teşhis aracıdır; öncelik gerçek kullanıcı verisi ve ürün sayfasından sepete geçiş metriğidir.

Mücevher mağazalarında Core Web Vitals neden daha zor?

Core Web Vitals, sitenin teknik vitrin puanı değildir. Müşterinin ürünü ne kadar erken gördüğünü, seçimlerine ne kadar hızlı yanıt aldığını ve satın alma alanının yerinde kalıp kalmadığını ölçer.

Google, iyi kullanıcı deneyimi için 75. yüzdelikte LCP’nin 2,5 saniye veya altında, INP’nin 200 ms altında ve CLS’nin 0,1 altında olmasını önerir. Bu eşikler, Google Search Central’ın Core Web Vitals dokümantasyonunda açıkça tanımlanır.

Metrik	Hedef	Mücevher mağazasında tipik sorun
LCP	≤2,5 saniye	Ana ürün fotoğrafı, koleksiyon hero görseli veya slider geç yüklenir.
INP	<200 ms	Ölçü, taş, metal ve renk varyantları; mega menü ve üçüncü taraf script’ler etkileşimi geciktirir.
CLS	<0,1	Taksit alanı, indirim mesajı, stok bilgisi ve fontlar sonradan yer değiştirir.

Ürün fotoğrafı kaliteyi taşır, ama LCP’yi de taşır

Mobil sayfaların yaklaşık %73’ünde LCP öğesi bir görseldir. Mücevher mağazasında bu beklenen bir durumdur. İlk ekrandaki en büyük öğe çoğu zaman yüzük, kolye veya bileklik fotoğrafıdır.

Sorun, “görselleri küçültün” denecek kadar basit değildir. Ürünün detayını göstermek için yüksek çözünürlüklü bir kaynak dosya gerekir. Ancak 390 piksel genişliğindeki bir telefon ekranına 4.000–5.000 piksel genişliğinde JPEG göndermek teknik bir tercih değil, gereksiz veri transferidir.

Mücevher ürün görseli için doğru model şudur:

• Arşiv ve zoom için yüksek çözünürlüklü kaynak dosyayı saklayın.
• Ürün kartı, mobil PDP ve masaüstü PDP için ayrı görsel türevleri üretin.
• Tarayıcının uygun dosyayı seçebilmesi için srcset ve sizes kullanın.
• İlk ekran dışındaki galeri fotoğraflarını geciktirin.
• İlk görünen ana görseli erken yükleyin.

Google’ın LCP rehberi de ana görselin JavaScript ile sonradan eklenmemesini, ilk HTML yanıtında keşfedilebilir olmasını ve gerekli durumda fetchpriority="high" veya preload ile önceliklendirilmesini önerir. LCP optimizasyonu rehberi, kötü LCP’nin yalnızca dosya boyutundan değil, görselin geç keşfedilmesinden de kaynaklandığını vurgular.

Varyantlar ve kişiselleştirme INP’yi bozar

Mücevher ürün sayfası sıradan bir katalog ekranı değildir. Kullanıcı yüzük ölçüsünü seçer, altın ayarını değiştirir, taş tipi ekler veya zincir boyunu uzatır. Bazı ürünlerde kişiselleştirme notu da girer.

Bu seçimlerin her birinde tüm ürün sayfası yeniden hesaplanıyorsa müşteri butona basar, arayüz geç yanıt verir. Bu bir INP sorunudur. Fiyat alanı iki kez değişiyor ya da “sepete ekle” butonu aşağı kayıyorsa aynı akış CLS de üretir.

9 Mayıs sabahı bir yüzük koleksiyonunu inceleyen Elif’i düşünün. 14 ayar altın seçeneğinden 18 ayara geçtiğinde fiyat güncellendi, ancak ürün sayfası kısa süreliğine yeniden yüklendi. Ardından taksit kutusu genişledi ve “sepete ekle” butonu parmağının altından kaydı. Elif ikinci tıklamada yanlışlıkla ürün açıklamasını açtı. Sorun ürünün fiyatı değildi. Sayfa müşteriye net bir sonraki adım veremiyordu.

Taksit, indirim ve güven rozetleri CLS üretir

Mücevher alışverişinde güven unsurları gerekir. Taksit bilgisi, sertifika açıklaması, sigortalı kargo, iade koşulu ve stok durumu satın alma kararının parçasıdır. Ancak bu bileşenler sonradan sayfaya eklenirse güven vermek yerine arayüzü oynatır.

CLS’nin yaygın kaynakları şunlardır:

• Genişlik ve yüksekliği belirtilmemiş ürün görselleri
• Geç gelen banka taksit modülleri
• Sonradan açılan indirim veya geri sayım şeritleri
• “Son 2 ürün” gibi dinamik stok mesajları
• Cookie banner ve canlı destek balonu
• Yüklendikten sonra metin ölçüsünü değiştiren web fontları
• Varyant değişince genişleyen fiyat alanı
• Sayfaya geç eklenen sticky “sepete ekle” çubuğu

Fiyat, teslimat bilgisi ve satın alma butonu aynı anda görünmelidir. Müşteri bunları okuyabilmek için sayfanın sakinleşmesini beklememelidir.

Önce hangi sayfaları ölçmelisiniz?

E-ticaret hız optimizasyonu, ana sayfada tek bir Lighthouse testi çalıştırmak değildir. Geliri etkileyen şablonları ayrı ayrı ölçmek gerekir.

Önceliği şu dört sayfaya verin:

1. Ana sayfa: Hero görseli, kampanya banner’ı, koleksiyon bağlantıları ve slider davranışı.
2. Kategori sayfası: İlk ürün kartları, filtre açılışı, sıralama ve sonsuz kaydırma davranışı.
3. Ürün detay sayfası: Ana görsel, fiyat, varyant seçici, taksit alanı ve “sepete ekle” akışı.
4. Sepet ve checkout: Kargo hesaplama, ödeme sağlayıcısı, kupon alanı ve üçüncü taraf script’ler.

Ana sayfa ve kategori sayfası satış yolunun başlangıcıdır

Ana sayfadaki her kampanya bileşeninin ilk render’da bulunması gerekmez. Özellikle otomatik kayan hero slider’lar, birden fazla büyük görseli ve ek JavaScript’i ilk yüklemeye dahil eder. Çoğu mağazada tek, açık bir koleksiyon mesajı dört slaytlık slider’dan hem daha hızlı hem daha anlaşılırdır.

Kategori sayfasında ilk ürün kartı önemlidir. Ziyaretçi koleksiyona girdiğinde ürünleri hızlı görmeli, filtreyi açtığında arayüz yanıt vermelidir. Sayfanın altındaki 48 ürünün görselini ilk anda indirmek gerekmez.

Ürün sayfası para sayfasıdır

Ürün detay sayfasında ilk ekran karar alanıdır. Ana görsel, fiyat, materyal, ölçü, teslimat bilgisi ve CTA burada birlikte çalışmalıdır.

Mert’in mağazasında bir ürün sayfası masaüstünde kabul edilebilir görünüyordu. Mobilde ise ana görselin arkasında çalışan slider kodu, review uygulaması ve canlı destek script’i ilk etkileşimlere geç yanıt verilmesine neden oluyordu. Ölçü seçildikten sonra fiyat alanı yeniden oluşuyor, taksit tablosu da bunun altına ekleniyordu. Teknik düzeltme yalnızca görsel sıkıştırma değildi. Ürün sayfasının ilk ekran mimarisi yeniden düzenlendi.

Mücevher sayfasında hız sorunu görsel sayısı değildir. Sorun, ilk tıklamada hangi öğenin gerçekten gerekli olduğunu ayıramamaktır.

LCP’yi düşürün: ana ürün görselini erken ve doğru yükleyin

LCP çalışmasında ilk soru şudur: Tarayıcı ana ürün görselinin URL’sini ne zaman görüyor?

Görsel data-src niteliği arkasında bekliyorsa, JavaScript çalışmadan oluşmuyorsa veya slider bileşeni tarafından sonradan ekleniyorsa tarayıcı indirmeye geç başlar. Bazı kötü LCP sayfalarında bu gecikme, gerçek kullanıcıların 75. yüzdelik deneyiminde 1.290 ms’ye ulaşabiliyor.

LCP görselini ilk HTML’de bulunabilir yapın

Ana ürün görseli HTML içinde doğrudan src veya srcset ile yer almalıdır. JavaScript’in görseli oluşturmasını beklemeyin.

Teknik uygulama listesi:

• PDP ana görselini sunucu tarafında üretilen HTML’de gösterin.
• İlk görünür görsel için loading="eager" kullanın.
• Görselin gerçekten LCP olduğu doğrulandıysa fetchpriority="high" değerlendirin.
• Kritik görseli CSS arka planına saklamak yerine mümkünse <img> öğesi olarak sunun.
• Slider kullanılıyorsa yalnızca ilk görünür görsele yüksek öncelik verin.

Ana görselde lazy-load kullanmak sık yapılan, ancak yanlış bir “optimizasyondur”. Lazy-load ekran dışında kalan öğeler içindir. Müşterinin ilk gördüğü ürünü bekletmek LCP’yi düşürmez, kötüleştirir.

WebP veya AVIF kullanın, ama ürün detayını öldürmeyin

WebP ve AVIF doğru kullanıldığında dosya boyutunu azaltır. Ancak otomatik görsel eklentisinin her fotoğrafa aynı kalite ayarını uygulaması, taşın parlaklığını, metal geçişlerini veya ince işçiliği bozabilir.

Bu nedenle kalite kontrolünü ürün türüne göre yapın. Pırlanta yakın planı ile düz fondaki altın küpe fotoğrafı aynı sıkıştırma sonucunu vermez. Dosya boyutunu azaltırken satış için gerekli ürün detayını kaybetmeyin.

Google Merchant Center da ürün görselleri için kalite standardı ister. 31 Ocak 2027’den itibaren ana ürün görsellerinde en az 500×500 piksel gereksinimi uygulanacak. Merchant Center ürün görseli gereksinimleri nedeniyle çözüm, tek görseli küçültmek değil; farklı ekranlar için doğru türevleri üretmektir.

CDN ve doğru boyutlandırma byte israfını keser

CDN, görseli kullanıcıya daha yakın bir noktadan sunabilir. Ancak CDN tek başına yanlış görsel stratejisini düzeltemez. 4 MB’lık dosyayı daha hızlı dağıtmak, 120 KB’lık uygun boyutlu bir dosya göndermek kadar etkili olmayabilir.

Önce şunları kontrol edin:

• Görselin ekranda gösterildiği gerçek genişlik
• Gönderilen dosyanın piksel genişliği
• Mobil ve masaüstü için farklı srcset türevleri
• Görsel formatı ve sıkıştırma ayarı
• Görselin ilk HTML içinde keşfedilip keşfedilmediği

Kampanya veya koleksiyon landing page’leri mağazadan bağımsız, hafif bir yapıda kurulacaksa Astro web geliştirme yaklaşımı yalnızca ihtiyaç duyulan kodu yükleyen ayrı bir seçenek olabilir.

INP’yi düşürün: müşteriyi bekleten JavaScript’i azaltın

INP, müşterinin tıklaması ile ekranın anlamlı biçimde yanıt vermesi arasındaki süreyi ölçer. Mücevher PDP’sinde bu metrik; ölçü seçici, taş seçimi ve “sepete ekle” akışında doğrudan hissedilir.

Varyant değişiminde yalnızca gerekli alanları güncelleyin

Kullanıcı yüzük ölçüsünü değiştirdiğinde tüm ürün detay sayfasının yeniden render edilmesi gerekmez. Fiyat, stok, SKU, teslimat süresi ve seçili varyant görseli güncellenebilir. Açıklama, yorumlar, footer ve diğer galeri öğeleri bu işlemden etkilenmemelidir.

Şu sorular teknik denetim için iyi bir başlangıç noktasıdır:

• Varyant değişince bütün DOM ağacı yeniden mi oluşturuluyor?
• Fiyat alanı geçici olarak boşalıp yeniden mi geliyor?
• Stok ve teslimat mesajları iki ayrı script tarafından mı yazılıyor?
• Varyant bilgisi için birden fazla ağ isteği mi atılıyor?
• Seçim sırasında zorlayıcı layout hesaplamaları oluşuyor mu?

Uygama ve eklenti listesini iş sonucuyla denetleyin

Shopify uygulamaları veya WooCommerce eklentileri tek tek küçük görünebilir. Ancak toplam etkileri küçük değildir. Review, bundle, upsell, kişiselleştirme, canlı destek, heatmap, piksel, pop-up ve taksit araçları aynı PDP’de JavaScript çalıştırabilir.

Her araç için şu üç soruyu sorun:

1. Bu araç hangi iş sonucunu üretiyor?
2. Aynı işi yapan başka bir araç var mı?
3. Ürün sayfasında ilk yüklemede çalışmak zorunda mı?

WooCommerce tarafında sorun çoğu zaman eklenti sayısı değildir. Eklentilerin birbirinin işini tekrar etmesi daha büyük bir sorundur. Page builder, slider, pop-up, cache ve görsel eklentileri aynı sorunu farklı yöntemlerle çözmeye çalıştığında ilk render ağırlaşır.

Mücevher mağazasında varyant, ödeme ve performans birbirinden bağımsız değildir. Bu altyapı kararlarını baştan doğru kurmak isteyen işletmeler için WooCommerce e-ticaret geliştirme, ürün akışını page builder yükü olmadan planlama imkânı verir.

CLS’yi düşürün: fiyat ve CTA yer değiştirmesin

Sayfa kayması küçük bir teknik ayrıntı gibi görünebilir. Ancak müşteri fiyatı okurken taksit kutusu açılır ya da butona basarken banner eklenirse deneyim güvensiz görünür.

Alanı sonradan açmayın, baştan ayırın

Ürün görselleri, banner’lar ve gömülü widget’lar için genişlik-yükseklik bilgisi veya CSS aspect-ratio tanımlayın. Tarayıcı ne kadar alan ayıracağını ilk render’da bilmelidir.

Taksit tablosu, stok uyarısı veya kargo mesajı dinamikse yüklenmeden önce bile yaklaşık alanını ayırın. Boş alan görmek, butonun müşterinin parmağının altından kaymasından daha iyidir.

Font ve kampanya bileşenlerini kontrol edin

Web fontu yüklendiğinde metnin genişliği değişebilir. Bu durum özellikle fiyat, uzun ürün adı ve taksit metninde belirgindir. Font dosyalarını doğru önceliklendirin. Yedek font metriklerini de mümkün olduğunca yakın seçin.

Sticky “sepete ekle” çubuğu da dikkat ister. Bu alan sonradan sayfayı iterek eklenirse içerik kayar. Başlangıçtan itibaren sabit konumda planlanmalı ya da kullanıcı belirli bir kaydırma noktasına geldiğinde mevcut alanı bozmadan görünmelidir.

Ürün sayfanızda taksit ve kampanya bileşenlerinin ne kadar yük oluşturduğunu bilmiyor musunuz? Önce gerçek kullanıcı verisini, uygulama listesini ve PDP akışını birlikte inceleyin. Sorun tek bir eklenti olmayabilir. Aynı anda çalışan beş aracın toplamı olabilir.

Mücevher sitesi için 30 günlük Core Web Vitals planı

Core Web Vitals iyileştirmesi, tek gecelik cache kurulumu değildir. Yeni bir kampanya, uygulama ya da ürün fotoğrafı düzeniyle metrikler yeniden bozulabilir. Bu yüzden işi ölçüm, düzeltme ve regresyon kontrolü olarak planlayın.

İlk 7 gün: field veri ve para sayfaları

Önce Google Search Console, Chrome UX Report veya RUM verisinden sorunlu URL gruplarını bulun. Ana sayfayı, kategori sayfasını, PDP’yi ve checkout’u ayrı değerlendirin.

Ardından PageSpeed Insights ve Lighthouse ile teknik teşhis yapın. LCP öğesini, render-blocking kaynakları, büyük JavaScript paketlerini ve uzun görevleri kaydedin.

8–14 gün: ana görsel, font ve CLS kaynakları

Bu aşamada en büyük görseli doğru boyutlandırın. Ana görselin eager yüklenmesini, galeri görsellerinin lazy-load davranışını ve srcset yapısını test edin.

Sonra ürün görseli, taksit bileşeni, kampanya şeridi ve sticky CTA için ayrılmış alanları kontrol edin. Mobil ekranı gerçek cihazda test edin. Masaüstü tarayıcıda sakin görünen bir kayma telefonda çok daha belirgin olabilir.

15–21 gün: script, uygulama ve varyant etkileşimi

Üçüncü taraf kodlarını satış, ölçüm, destek ve deney kategorilerine ayırın. Her birinin PDP’ye ne kattığını ve ne kadar yük getirdiğini görün.

Varyant seçimini ve “sepete ekle” tıklamasını Chrome DevTools performans kaydıyla inceleyin. Tüm sayfayı güncelleyen işlemleri ayırın. Ağır script’leri erteleyin, koşullu yükleyin veya tamamen kaldırın.

22–30 gün: yayın sonrası ölçüm ve regresyon kontrolü

Yayına alınan değişiklikler laboratuvar testinde iyi görünebilir. Asıl kontrol gerçek kullanıcı verisinde yapılır. Search Console verisinin anlamlı biçimde güncellenmesi zaman alır. Kısa vadede yönü RUM ve iş metrikleriyle bulun.

Aylin’in mağazasında ana görsel optimize edildikten sonra Lighthouse puanı yükseldi. Asıl kazanım, mobil PDP’den sepete ekleme oranını varyant bazında izlemeye başladıktan sonra ortaya çıktı. Bazı ürünlerde hız iyileşmişti, ancak uzun kişiselleştirme formu müşteriyi hâlâ bekletiyordu. Teknik iş skor yükselince bitmedi. Sürtünmenin kaldığı noktaya geçti.

PageSpeed 100 hedefi neden yanlış hedef?

PageSpeed 100 kolay anlatılan, ancak zayıf bir iş hedefidir. Laboratuvar testi kontrollü bir ortamda yapılır. Müşteri ise mağazaya farklı telefon, ağ hızı, tarayıcı ve uygulama kombinasyonlarıyla girer.

Field veri, lab veri ve iş verisini birlikte okuyun

Üç veri kaynağının görevi farklıdır:

Veri türü	Araç	Ne için kullanılır?
Field veri	Search Console, Chrome UX Report, RUM	Gerçek kullanıcıların hangi şablonda sorun yaşadığını görmek
Lab veri	PageSpeed Insights, Lighthouse, DevTools	LCP öğesini, uzun görevleri ve bloklayan kaynakları teşhis etmek
İş verisi	GA4 ve e-ticaret analitiği	Ürün görüntüleme, sepete ekleme, checkout ve satın alma etkisini izlemek

İyi bir laboratuvar skoru, gerçek kullanıcı deneyiminin kanıtı değildir. Düşük skor da tek başına satış kaybının miktarını göstermez. Bu yüzden değişiklikleri şablon bazında ve iş metrikleriyle birlikte değerlendirin.

Hız iyileşmesini satış metriğiyle dürüstçe ölçün

Bir değişiklikten sonra şu metrikleri takip edin:

• Ürün sayfası görüntüleme → sepete ekleme oranı
• Sepete ekleme → checkout başlangıcı
• Mobil ve masaüstü farkı
• Varyant seçimi yapılan ürünlerde terk oranı
• Kampanya dönemleri ile normal dönemler arasındaki fark
• Yeni uygulama veya tema değişikliği sonrası performans gerilemesi

Core Web Vitals iyileşince Google sıralaması veya satış artışı garanti edilmez. Ancak müşterinin ürünü daha erken görmesi, seçeneğe daha hızlı yanıt alması ve butonun yerinde kalması satın alma akışındaki gereksiz sürtünmeyi azaltır. Ölçülebilecek etki budur.

Mücevher sitesi Core Web Vitals optimizasyonu hakkında sık sorulan sorular

Mücevher ürün görsellerini lazy-load yapmak doğru mu?

İlk ekranda görünen ana ürün görseline lazy-load uygulanmamalıdır. Bu görsel LCP adayıdır ve tarayıcının indirmeye mümkün olduğunca erken başlaması gerekir. İlk ekran dışındaki galeri kareleri, önerilen ürünler ve kategori altı görseller lazy-load edilebilir.

Shopify mağazasında Core Web Vitals iyileştirilebilir mi?

Evet. Shopify mağazasında tema yapısı, uygulama sayısı, ürün medya stratejisi ve üçüncü taraf script’ler performansı belirler. Shopify platformu tek başına sorunun veya çözümün tamamı değildir; özellikle PDP’de çalışan uygulamalar ve tema kodu denetlenmelidir. Mağaza altyapısı, tema ve büyüme ihtiyaçlarını birlikte değerlendirmek için Shopify kurulumu sayfasındaki yaklaşım incelenebilir.

WooCommerce mağazasında en sık hız sorunu nedir?

Sık görülen sorun, page builder ve eklenti yığınının aynı sayfada fazla CSS ve JavaScript çalıştırmasıdır. Ağır ürün görselleri, gereksiz slider’lar ve birden fazla pop-up veya analiz aracı bu yükü artırır. Önce hangi eklentinin hangi iş sonucunu ürettiğini belirlemek gerekir.

Taksit widget’ı Core Web Vitals’ı bozar mı?

Taksit widget’ı geç yükleniyorsa, ağır JavaScript çalıştırıyorsa veya fiyat ile CTA alanını aşağı itiyorsa LCP, INP ya da CLS’yi olumsuz etkileyebilir. Taksit bilgisini kaldırmak zorunda değilsiniz. Bileşen için alan ayırın, kodu geç yükleyin ve ilk ekranı bozmadan sunun.

Core Web Vitals iyileşince Google sıralaması garanti edilir mi?

Hayır. Core Web Vitals, Google’ın değerlendirdiği kullanıcı deneyimi sinyallerinden biridir. Tek başına sıralama garantisi vermez. İçerik, ürün verisi, teknik taranabilirlik, rekabet ve kullanıcı niyeti de sonucu etkiler.

Ana ürün görseli için ideal dosya boyutu kaç olmalı?

Tek bir ideal sayı yoktur. Görselin ekrandaki boyutu, ürünün detay ihtiyacı, formatı ve kullanıcının cihazı belirleyicidir. Hedef, dosyayı rastgele küçültmek değil; aynı görselin farklı ekranlar için uygun türevlerini üretmek ve gereksiz piksel göndermemektir.

Ürün sayfasını hızlandırmak, ürünü sadeleştirmek değildir

Mücevher sitesinde performans, ürün fotoğrafından, taksit bilgisinden veya güven unsurundan vazgeçmek değildir. Bunları doğru boyutta, doğru yükleme sırasıyla ve sayfanın stabilitesini bozmadan göstermektir.

Önce ana ürün görselini tarayıcının erken keşfedebileceği hale getirin. Ardından varyant seçimindeki ağır JavaScript’i, sonradan eklenen taksit alanlarını ve iş sonucu üretmeyen uygulamaları denetleyin. Son olarak gerçek kullanıcı verisinde ürün sayfasından sepete uzanan akışı izleyin.