E-ticaret Sitesinde LCP Neden Yüksek Olur? Gerçek Performans Sorunları ve Çözümleri

E-ticaret sitesinin yavaş olduğunu söylediğimizde çoğu zaman tek bir problemden bahsetmiyoruz.

Sunucu hızlı olabilir ancak hero görseli geç yüklenebilir. HTML hızlı gelebilir ancak JavaScript sayfanın render edilmesini geciktirebilir. Görseller optimize edilmiş olabilir ancak üçüncü parti pazarlama scriptleri tarayıcıyı meşgul edebilir.

Bu nedenle performans optimizasyonuna “sayfayı biraz hızlandıralım” şeklinde yaklaşmak yerine hangi aşamanın kullanıcı deneyimini bozduğunu ölçmek gerekir.

Bu ölçümlerden en önemlilerinden biri Largest Contentful Paint (LCP)'dir.

LCP nedir?

LCP, kullanıcının ekranında görünen ana içeriklerden en büyük olanının ne kadar sürede render edildiğini ölçen Core Web Vitals metriklerinden biridir.

Bir e-ticaret sitesinde LCP elementi çoğu zaman:

• ana sayfadaki hero görseli,
• kategori banner'ı,
• büyük ürün görseli,
• büyük metin alanı

olabilir.

E-ticaret sitelerinde LCP neden özellikle önemlidir?

E-ticaret sayfaları genellikle içerik sitelerinden daha karmaşıktır.

Bir ürün veya kategori sayfasında aynı anda:

• ürün API çağrıları,
• fiyat,
• stok,
• kampanya,
• kişiselleştirme,
• analytics,
• reklam tracking,
• recommendation engine,
• chat widget,
• image CDN,
• review sistemi

çalışabilir.

1. Hero veya ürün görselinin geç yüklenmesi

Ana ekranın büyük bölümünü kaplayan görsel LCP elementi olabilir.

Görsel çok büyük dosya boyutuna sahipse, yanlış formatta servis ediliyorsa, CDN kullanılmıyorsa, gereksiz çözünürlükte gönderiliyorsa veya tarayıcı tarafından geç keşfediliyorsa LCP yükselir.

2. LCP görseline yanlışlıkla lazy-load uygulanması

Lazy loading fold altındaki ürün kartlarında faydalıdır. Ancak ekran açılır açılmaz görünmesi gereken LCP elementini lazy-load etmek ters etki yaratabilir.

3. Server response süresinin yüksek olması

Frontend optimizasyonunun bir sınırı vardır.

Sunucunun ilk HTML veya gerekli veriyi üretmesi uzun sürüyorsa sonraki tüm adımlar gecikir.

Asıl soru: hangi verinin ilk render için gerçekten gerekli olduğudur?

4. Render-blocking CSS ve JavaScript

Özellikle e-ticaret projelerinde zaman içinde birçok script eklenir:

• Meta Pixel,
• Google Tag Manager,
• analytics,
• heatmap,
• live chat,
• popup,
• personalization,
• affiliate tracking,
• review widget,
• recommendation widget.

Her script tek başına küçük görünebilir. Ancak toplam JavaScript maliyeti özellikle düşük segment mobil cihazlarda ciddi olabilir.

5. Client-side rendering'e gereğinden fazla bağımlılık

Bir ürün sayfasında kullanıcı önce boş HTML alıyor, ardından JavaScript yükleniyor, hydration gerçekleşiyor ve daha sonra ürün API'den çekiliyorsa kritik içerik gereksiz yere gecikebilir.

Özellikle ürün adı, fiyat, ana ürün görseli ve temel varyant bilgisi gibi ilk ekranda gerekli olan verilerin mümkün olduğunca erken üretilebilmesi önemlidir.

6. Çok fazla üçüncü parti script

Site ilk geliştirildiğinde hızlı olabilir. Daha sonra ekipler zaman içinde reklam scriptleri, popup araçları, chat, heatmap, A/B testing, affiliate, review ve CRM ekler.

Altı ay sonra frontend'in önemli bir bölümü markanın kendi kodundan değil, üçüncü parti JavaScript'ten oluşabilir.

7. Fontların yanlış yüklenmesi

Çok fazla font weight veya büyük font dosyaları ilk render'ı etkileyebilir.

8. Cache stratejisinin olmaması

Doğru durumda CDN cache, edge cache, server cache, application cache, incremental/static generation ve stale-while-revalidate gibi yöntemlerle response süreleri azaltılabilir.

Ancak fiyat ve stok gibi dinamik verilerin güncelliği dikkate alınmalıdır.

Lighthouse skoru ile gerçek kullanıcı performansı aynı şey mi?

Hayır.

Lighthouse kontrollü laboratuvar ortamında test yapar. Gerçek kullanıcıların cihazları, internet bağlantıları ve lokasyonları farklıdır.

E-ticaret performansını nasıl analiz ediyoruz?

1. Gerçek kullanıcı verisi

Önce problemi yaşayan kullanıcıların kim olduğu anlaşılmalıdır: mobil mi, desktop mı, belirli ülke mi, belirli route mu?

2. LCP elementini tespit et

Gerçekte hangi DOM elementi LCP oluyor?

3. Network waterfall'u incele

LCP resource ne zaman keşfediliyor ve indirilmeye başlanıyor?

4. Backend süresini ayır

Problem server mı, network mü, frontend mi, resource priority mi?

5. JavaScript maliyetini çıkar

Main thread'i en çok hangi scriptler kullanıyor?

6. Route bazlı analiz yap

Homepage hızlı olsa bile category, search, product detail ve cart ayrı ayrı incelenmelidir.

LCP optimizasyon checklist

• LCP elementinin ne olduğunu ölç
• LCP görselinde lazy-load kullanma
• Uygun image dimensions kullan
• Modern image formatlarını değerlendir
• CDN kullan
• Kritik resource'ları erken keşfedilebilir hale getir
• TTFB'yi ölç
• Gereksiz blocking API çağrılarını kaldır
• JavaScript bundle'ını analiz et
• Üçüncü parti scriptleri audit et
• Kullanılmayan CSS'i azalt
• Font dosyalarını optimize et
• Kritik içeriği mümkün olduğunca server tarafında üret
• Cache stratejisini route/veri tipine göre tasarla
• Gerçek kullanıcı verisini takip et

LCP'yi dört parçaya ayırmadan optimizasyon yapmayın

Modern performans analizinde LCP'yi tek bir sayı olarak görmek yerine oluşum süresini parçalamak daha faydalıdır:

1. TTFB: İlk dokümanın gelmesi.
2. Resource load delay: LCP kaynağının tarayıcı tarafından ne kadar geç keşfedildiği.
3. Resource load duration: Kaynağın indirilme süresi.
4. Element render delay: Kaynak hazır olduktan sonra elementin ne kadar geç boyandığı.

Bu ayrım çok önemlidir. Örneğin 3,8 saniyelik LCP'nin sebebi görsel dosyasının 2 MB olması değil, görselin ancak hydration sonrasında keşfedilmesi olabilir.

Örnek waterfall teşhisi

0 ms    HTML request
450 ms  HTML response
900 ms  JS bundle
1400 ms hydration
1650 ms product API
1900 ms image URL discovered
3100 ms hero image loaded
3450 ms LCP rendered

Burada image compression fayda sağlar ama kök neden resource discovery'nin 1,9 saniyeye kadar gecikmesidir.

Daha doğru çözüm:

• kritik ürün verisini server render etmek,
• LCP görsel URL'sini HTML içinde erken sunmak,
• gerekirse preload/fetch priority kullanmak,
• hydration'a bağımlılığı kaldırmak.

TTFB yüksekse neyi ölçmeliyiz?

TTFB tek başına “backend yavaş” anlamına gelmez.

Ayrıştırın:

• CDN/edge latency,
• app server processing,
• database query,
• upstream commerce API,
• authentication/session,
• cold start,
• cache miss.

Özellikle headless storefront'ta upstream commerce API 700 ms sürüyorsa frontend framework değiştirmek problemi çözmez.

Image optimization'da dosya boyutundan fazlası var

Bir LCP görseli için:

• doğru intrinsic size,
• responsive srcset,
• modern format,
• CDN,
• compression,
• cache headers,
• early discovery,
• priority

birlikte düşünülmelidir.

JavaScript LCP'yi nasıl geciktirir?

LCP resource indirilmiş olsa bile main thread meşgulse browser element'i zamanında paint edemez.

Örnek kaynaklar:

• ağır hydration,
• client-side data transformations,
• tag manager container,
• personalization script,
• synchronous third-party SDK.

Bu nedenle Chrome Performance trace içinde long task'ler ve main-thread utilization incelenmelidir.

RUM neden laboratuvar testinden daha değerlidir?

Segmentleyin:

• route,
• device class,
• country,
• network type,
• logged-in/logged-out,
• experiment variant.

Örneğin p75 genel LCP 2,4 s iken kategori sayfası Android low-end cihazlarda 4,9 s olabilir. Ortalama değer problemi gizler.

Performance budget tanımlayın

Sayılar marka ve route'a göre belirlenmelidir; önemli olan performansın “sonradan bakılan skor” olmaktan çıkıp release contract haline gelmesidir.

Üçüncü parti script governance

Her script için owner ve iş değeri belirlenebilir:

• script adı
• takım sahibi
• ticari amaç
• load strategy
• CPU cost
• network cost
• consent requirement
• kaldırma kriteri

Performans optimizasyonu nasıl önceliklendirilir?

Her bulgu için üç boyut:

Impact × Reach × Effort

Homepage hero 300 ms iyileşirken trafiğin %10'unu etkileyebilir. PDP LCP 700 ms iyileşmesi trafiğin %55'ini etkiliyorsa ikinci çalışma daha değerlidir.

Performans ve conversion birlikte nasıl izlenir?

Session cohort'ları:

• LCP <2.5s
• 2.5–4s

• 4s

olarak ayrılıp add-to-cart ve conversion rate kıyaslanabilir. Bu korelasyon nedensellik kanıtı değildir; ancak performans yatırımını önceliklendirmeye yardımcı olur.

Bir performans incident'ı nasıl ele alınır?

Örneğin yeni kampanya sonrası mobil PDP LCP 2,2 saniyeden 4,6 saniyeye çıktı.

Sıra:

1. Release diff kontrol edilir.
2. RUM route/device segmenti doğrulanır.
3. LCP element değişmiş mi bakılır.
4. Network waterfall karşılaştırılır.
5. Third-party script veya hero asset değişimi ayrıştırılır.
6. Fix sonrası yalnız Lighthouse değil gerçek kullanıcı p75 trendi izlenir.

Bu disiplin, performans sorununu “frontend biraz yavaşladı” seviyesinden çıkarıp production incident olarak yönetir.

En kritik anti-pattern

Birçok ekip performans sorununda doğrudan image compression'a gider. Oysa LCP'nin kaynak keşfi 1,5 saniye geçse 100 KB daha küçük görsel yalnız semptomu azaltır. Önce fazı ölçmek, sonra çözüm seçmek gerekir.

Sonuç

E-ticaret sitesinde yüksek LCP çoğu zaman tek bir dosyadan kaynaklanmaz.

Sorun:

backend → network → resource discovery → render → JavaScript

zincirinin herhangi bir noktasında olabilir.

Reliefers olarak e-ticaret projelerinde performansı yalnızca Lighthouse skoruyla değerlendirmek yerine storefront mimarisi, server response, image delivery, caching, JavaScript ve üçüncü parti entegrasyonları birlikte inceliyoruz.