Bu mobil-odaklı vitrin performans kontrol listesiyle Core Web Vitals’a öncelik verin, görselleri optimize edin, SSR vs CSR tercihi yapın ve sıkı bir bütçeyle önbellekleme düzeni kurun.
Hızlı bir mobil vitrin mükemmel laboratuvar puanlarıyla ilgili değil. Gerçek bir telefonda, sinyal zayıfken ve tek bir başparmakla kullanıldığında nasıl hissettirdiği önemlidir. Kullanışlı bir şey hızla görünür, görseller yüklenirken sayfa yer değiştirmez ve her dokunuşa net bir yanıt gelir.
Hız önemlidir çünkü alışveriş yapanlar hızlı karar verir. İlk görünüm yavaş veya dağınıksa insanlar siteyi terk eder. Site takılıyor gibi hissedilirse güven düşer. Sepet veya ödeme gecikirse tamamlanma oranları düşer. Mobilde küçük bir gecikme bile daha büyük hissedilir çünkü ekranlar küçük ve dikkat dağıtıcı şeyler bir kaydırma uzağındadır.
Bütçe kısıtlıysa amaç tam bir yeniden yapı değil. "Büyük kazançlar önce" diye düşünün: deneyimi en çok etkileyenleri düzeltin ve haftalarca sürecek ama milisaniyeler kazandıracak değişiklikleri atlayın. Çoğu mağaza, birkaç pratik düzeltmeyle faydanın çoğunu elde eder.
Bu hedefleri aklınızda tutun:
Yaygın bir hata: kahraman görsel geç yüklenir, “Sepete ekle” butonu aşağı kayar ve kullanıcılar yanlış yere dokunur veya vazgeçer. Görsel boyutlarını belirlemek ve ana görselin daha erken yüklenmesini sağlamak genellikle framework değiştirmekten daha fazla iyileştirme getirir.
Koder.ai ile inşa ediyorsanız aynı öncelikler geçerlidir: en küçük, en hızlı ilk görünümü yayınlayın, sonra sayfayı ağırlaştırmadan özellik ekleyin.
Bütçeyle yapılan performans çalışmaları, kapsamı küçük ve ölçülebilir tuttuğunuzda daha başarılı olur. Geliri ve güveni en çok etkileyen 1–2 sayfayla başlayın ve her seferinde aynı şekilde ölçün.
Mobil kullanıcıların kaldığı veya ayrıldığı sayfaları seçin. Birçok mağaza için bu ürün sayfası ve ya ana sayfa (ilk izlenim) ya da bir kategori sayfasıdır (göz atma). Ödeme en büyük terk noktasıysa onu ekleyin, ama başlangıç kapsamını dar tutun.
Sonra o sayfalarda kullanıcıların gerçekte yaptığı eylemleri listeleyin. Özellikler değil dokunuşlar düşünün: arama, filtre uygulama, ürün açma, varyant değiştirme, sepete ekleme. Bu, laboratuvar testlerinin kaçırdığı yavaş filtre güncellemeleri veya gecikmeli sepete ekleme geri bildirimleri gibi sorunları yakalamanıza yardımcı olur.
Tutarlı olmak için iki gerçek cihaz kullanın: bir orta seviye Android (sorunların hızlı çıktığı yer) ve ortalama bir iPhone. Aynı Wi‑Fi noktasından veya aynı mobil hotspot’tan test edin ki sonuçlar karşılaştırılabilir olsun.
Her hedef sayfa için basit bir başlangıç kaydı alın:
Örneğin ürün sayfanızın LCP’si orta seviye Android’de 5.2s ve LCP öğesi ana ürün görseliyse, yüksek ROI’li çalışmanın muhtemel yerini zaten biliyorsunuz demektir.
Core Web Vitals, bir sayfanın telefonda ne kadar hızlı hissettirdiğiyle yakından ilişkili üç sinyaldir:
Pratik bir işlem sırası: önce büyük LCP problemlerini düzeltin, sonra INP ile ilgilenin, ardından CLS’i cilalayın. Ana içerik 5 saniyede görünüyorsa, dokunuşlar hızlı olsa bile sayfa yine de yavaş hissedilir. LCP makul seviyeye geldiğinde giriş gecikmeleri ve düzen kaymaları çok daha belirgin olur.
Mağaza yaygın sorunları her metriğe net şekilde denk gelir:
Mobil kullanıcılar için faydalı hedefler:
Hedefleri site-genel değil sayfa türüne göre belirleyin. Ürün detay ve ödeme sayfaları daha sıkı olmalı çünkü satın alım burada gerçekleşir. Ana sayfalar LCP konusunda biraz daha gevşek olabilir, ama CLS sıkı tutun ki sayfa stabil hissetsin.
Bütçeli bir vitrinde tek bir şeyi düzeltecekseniz, görselleri düzeltin. Mobilde görseller indirme boyutunun çoğunu oluşturur, LCP’yi geciktirir ve boyutlar belirtilmemişse düzen kaymalarına neden olur.
Çoğu mağazayı kapsayan görsel kontrol listesi:
sizes değeri ile srcset kullanın.Büyük bir kural: her görsel için daima width ve height (veya CSS aspect-ratio) ayarlayın. Bu kolay bir CLS kazanımı sağlar.
Tipik bir sonuç: 2 MB’lık bir kategori grid’i, grid görsellerini WebP’ye çevirmek, mobilde maksimum 640px sunmak ve kaliteyi biraz düşürmekle genellikle 400 KB altına inebilir. Çoğu alıcı fark etmez, ama yükleme süresi düşer.
İlk ekranın çizilmesi ucuz olmalı. Mobilde her ekstra font, CSS kuralı ve script aynı küçük CPU ve ağ bütçesi için yarışır.
Özel fontlar sessiz bir gecikme kaynağıdır. Marka izin veriyorsa, önce sistem fontlarıyla başlayın ve sonra bir özel font ekleyin.
Sıkı tutun: bir aile, bir veya iki ağırlık (örneğin 400 ve 600) ve sadece gereken karakter setleri. Üstte görünen tek font dosyasını preload edin ve metnin hemen render olduğundan emin olun (font yüklenirken boş başlık olmasın).
UI kütüphaneleri ve tekrar eden bileşenlerle CSS hızla büyür. Üstte görünen CSS’i küçük tutun, sonra geri kalanını ilk görünüm göründükten sonra yükleyin. Kullanılmayan stilleri düzenli kaldırın.
Scriptler için kural basit: kullanıcı içeriği görüp okumaya başlayana kadar kritik olmayan hiçbir şey çalışmasın. Ağır analytics paketleri, chat widget’ları, A/B testleri ve slider’lar bekleyebilir.
Ana sayfa ve ürün sayfaları için hızlı kontroller:
Vitrininiz React ise (Koder.ai’den dışa aktarılmış kod dahil), ürün galerisini ve yorumları ayrı parçalara ayırmayı düşünün. Başlığı, fiyatı ve birincil görseli önce yükleyin, sonra sayfa kullanılabilirken geri kalanı hydrate edin.
Bütçe mağazasında amaç, düşük seviye telefonda bile giriş sayfalarının anlık hissettirilmesi. Render stratejisi neredeyse diğer tüm optimizasyonları etkiler.
Pratik bir başparmak kuralı:
Pratik bir hibrit iyi çalışır: sayfa kabuğunu ve kritik içeriği SSR ile verin (başlık, fiyat, ana görsel, satın al butonu, ilk yorumlar), sonra ağır widget’ları daha sonra hydrate edin.
Mobilde performansı sıkan noktalar:
Örnek: 12 öğeli kategori grid’ini SSR ile verin ama filtreleri (beden, renk) ilk paint’ten sonra yükleyin. Alışveriş yapanlar hemen kaydırabilir, filtre UI bir an sonra gelir ve düzeni kaydırmaz.
Önbellekleme para ve saniye kazandırır, ama müşterileri eski fiyatlarda, hatalı JS’te veya eksik görsellerde sıkıştırabilir. Nadiren değişenleri uzun süre cacheleyin ve güncellediğiniz şeylerin hızlıca değiştirilebilir olduğundan emin olun.
Statik varlıklarla başlayın: görseller, CSS ve JS paketleri. Bunlara uzun önbellek yaşam süreleri verin ki tekrar ziyaretler hızlı olsun, özellikle mobil veride.
Uzun önbellekleme ancak dosya adları içerik değiştiğinde değişiyorsa işe yarar. Dosya sürümlendirmesi (hash’ler) kullanın ki yeni build’ler yeni dosyalar olarak gelsin.
Kullanıcı başına değişmeyen, sık okunan şeyleri cacheleyin (ana sayfa kabuğu, kategori sayfaları, ürün listeleri, arama önerileri). Sepet, checkout, hesap gibi her zaman taze olması gerekenleri cachelemeyin.
Pratik bir kontrol listesi:
Koder.ai üzerinden AWS’e deploy ediyorsanız, önbellekleme işlemlerini sürümlere bağlayın: varlıkları versiyonlayın, HTML tazeliğini kısa tutun ve geri dönüşü sürümle ilişkilendirerek öngörülebilir hale getirin.
INP, bir dokunuştan sonra ne olduğunu ölçer. Mobilde gecikmeler göze çarpar. Bir buton 200–500ms “ölü” hissediyorsa satış kaybedebilirsiniz, hatta sayfa hızlı yüklenmiş olsa bile.
Mümkünse gerçek düşük seviye bir telefonda test edin, sadece dizüstü ile yetinmeyin. Dört görev deneyin: bir ürün sayfası açın, bir varyant değiştirin, sepete ekleyin, sonra sepeti açın. Herhangi bir dokunuş yavaş veya sayfa kayar ve takılıyorsa, INP ile ilgili işiniz var demektir.
Büyük yeniden yazımlar gerektirmeden genelde işe yarayan düzeltmeler:
Sepet çağrınız yavaşsa (1–2s), sayfayı bloke etmeyin. Basılı durumu gösterin, öğeyi iyimserce ekleyin ve sadece istek başarısız olursa akışı kesintiye uğratın.
Önce tek bir yüksek trafikli sayfada hız geçişi yapın (genelde ana sayfa veya popüler bir ürün). Mümkünse gerçek telefon kullanın ya da Chrome DevTools ile orta seviye Android profili kullanarak throttle edin.
Bir sayfa seçin ve LCP öğesini belirleyin. Sayfayı bir kez yükleyin ve LCP’nin ne olduğunu not edin (kahraman görseli, ürün görseli, büyük başlık). LCP süresini yazın.
Görsel boyutlandırmasını düzeltin ve LCP kaynağını preload edin. LCP görselinin doğru width/height (veya aspect-ratio) değerlerine sahip olduğundan, mobil için daha küçük bir versiyon sunduğunuzdan, modern format kullandığınızdan ve sadece o tek görseli preload ettiğinizden emin olun.
Kritik olmayan scriptleri ilk görünümden erteleyin. Sohbet widget’ları, heatmap’ler, A/B testleri ve ağır yorum paketleri sayfa kullanılabilir olana kadar beklesin.
Düzen kaymalarını durdurun. Banner, carousel, cookie bar ve yorum yıldızları için alan ayırın. Yüklemeden sonra üstte içerik eklemekten kaçının.
Aynı koşullarda yeniden test edin. LCP ve CLS’yi karşılaştırın. LCP hareket etmediyse sunucu yanıt süresine veya render’ı engelleyen CSS’ye bakın.
Koder.ai gibi sohbet tabanlı bir araçla inşa ediyorsanız, bunu tekrarlanabilir bir rutin yapın: öncesi/sonrası anlık görüntüsü alın ki bir değişiklik sayfayı yavaşlatırsa hızla geri alabilesiniz.
Çoğu yavaşlama kendi yarattığınız şeylerden gelir: bir eklenti daha, bir slider daha, bir etiket daha. Yararlı bir kural: gerçek içeriği hızlı gösterin, sonra zenginleştirin.
Sürekli görülen hatalar:
Tipik bir örnek: ürün sayfası büyük bir carousel kütüphanesi ve birden çok takipçi çekiyor; "Sepete ekle" butonu geç etkin hale geliyor. Alışveriş yapanlar bir dokunuşun gecikmesini önemsemezse, gösterişli hareketler satışı kurtaramaz.
Hızlı düzeltmeler:
Koder.ai kullanıyorsanız, performansı bir özellik gibi ele alın: orta seviye bir telefonda önizleyin, sonra yavaşlayan değişiklikleri anlık görüntülerle geri alın.
Küçük bir yayın kontrolü, büyük bir performans projesinden üstündür. Bunu bir kapı gibi ele alın: sayfa ucuz bir telefonda yavaşsa yayınlamadan önce düzeltin.
Önemli sayfaları (ana, kategori, ürün, ödeme başlangıcı) gerçek bir orta seviye Android cihazda veya kısıtlanmış bir profilde test edin:
Bir şey yanlış görünüyorsa en belirgin sorunu önce düzeltin. Tek büyük görsel veya erken bir script bir yayını mahvedebilir.
Önbellekleme ve render seçimleri, giriş sayfalarını hızlı hissettirmeli ama eski fiyat veya kırık checkout sunmamalı:
Koder.ai ile inşa ediyorsanız, yayınlardan önce basit bir "performans anlık görüntüsü" tutmak, karşılaştırma, geri alma ve yeniden test etmeyi kolaylaştırır.
Küçük bir vitrin yaklaşık 200 ürün satıyor. Çoğu ziyaretçi mobilden sosyal reklamlardan geliyor, kategori sayfasına iniyor, sonra ürün açıyor. Ekip sınırlı geliştirici zamanına sahip, bu yüzden plan basit: ilk iki sayfayı hızlı ve stabil yapın, sonra etkileşim hızını artırın.
Onlar birkaç ana sayfa (popüler kategori, popüler ürün, sepet) izliyor ve LCP (ana içerik hızı), CLS (düzen stabilitesi) ve INP (dokunuş duyarlılığı) üzerine odaklanıyorlar.
Kategori ve ürün sayfalarında en büyük kazançlardan başladılar: doğru boyutlandırılmış görseller (360px ekranda 2000px görsel yok), modern formatlar (WebP/AVIF), gridler için agresif sıkıştırma ve düzen kaymalarını önlemek için açık boyutlar. Ürün sayfasında tek kahraman görseli preload ettiler, geri kalanları lazy-load yaptılar.
Sonuç: kaydırırken daha az sıçrama ve sayfalar daha hızlı hissedildi, derin çalışmalara başlamadan önce bile.
Sonra ana iş parçacığı işini azalttılar:
Sonuç: INP gelişti. Dokunuşlar hızlı kaydedildi, filtreler kaydırma sırasında donmayı bıraktı.
Giriş sayfaları (ana, popüler kategori, ürün) için SSR eklediler, böylece yavaş bağlantılarda içerik daha çabuk görünür oldu. Hesap sayfaları ve sipariş geçmişi için CSR’de kaldılar.
Her değişikliğin tutulup tutulmayacağına karar vermek için:
Koder.ai üzerinde inşa ediyorsanız, snapshot ve rollback desteği render, script veya sayfa yapısı değişiklikleri denerken daha güvenli deneyler yapmanızı sağlar.
Bir kontrol listesi ancak alışkanlığa dönüştüğünde işe yarar. Basit tutun: ölçün, bir şey değiştirin, tekrar ölçün. Bir değişiklik sayfayı yavaşlatıyorsa çabuk geri alın ve ilerleyin.
1–2 para sayfa seçin (çoğunlukla ana, kategori, ürün, ödeme başlangıcı) ve küçük bir rutin kullanın:
Bu rastgele optimizasyondan uzak durmanızı sağlar ve kullanıcıların gerçekten neyi hissettiğine odaklar.
Bütçeler yavaşçanın sızmasını önler. İnceleme süreçlerinde uygulanacak kadar küçük tutun:
Bütçeler mükemmellik değil, mobil deneyimi koruyan sınırlar sağlar.
Performansı bir özellik gibi görün: hızlı geri alma planınız olmalı. Platformunuz snapshot ve rollback destekliyorsa, yayınlardan önce bunları kullanın ki yavaş bir değişikliği dakikalar içinde geri alabilesiniz.
Hız ve performans üzerinde hızlı denemeler yapmak istiyorsanız, Koder.ai (koder.ai) prototipleme ve değişiklikleri kaynak kodu dışa aktarımıyla gönderme aşamasında faydalı olabilir. Yine de asıl önemli olan alışkanlıktır: küçük değişiklikler, sık kontroller ve performans düşerse hızlı geri dönüş.
Hızlı bir mağaza gerçekten şöyle hissettirmelidir: ana içerik erken görünür, düzen sıçramaz ve dokunuşlara anında geri bildirim gelir.
Önceliği algılanan hız olmalı: ürün resmi/adı/fiyatı ve net bir satın alma yolu hızlıca gösterilsin, ekstralar sonra yüklensin.
1–2 tane gelir getiren sayfayla başlayın; mobil kullanıcıların kalıp kalmayacağına karar verdiği sayfalar genellikle şunlardır:
En büyük çıkış noktası ödeme süreciyse checkout ekleyin, ama ilk kapsamı küçük tutun ki değişiklikleri net ölçebilesiniz.
Hedef sayfa başına şu temel verileri izleyin:
Aynı testi tutarlı şekilde tekrarlamak, mükemmel araçlardan daha önemlidir.
Sıralama şöyle olmalı:
Ana içerik geç görünüyorsa diğer her şey yine de yavaş hissedilir—önce LCP'yi düzeltin.
Öncelikle şunları yapın:
İlk görünümü hafif tutun:
Amaç: telefonun ilk saniyeleri içeriği çizmek için harcansın, ekstralara değil.
Genel bir kural:
Ancak aşırı JavaScript ilk yükte INP'yi kötüleştirebilir; hydration gecikmelerine dikkat edin.
Güvenli bir yaklaşım:
Böylece tekrar ziyaretler hızlı olur ama kullanıcılar eski fiyat/ürün bilgisine takılmaz.
Dokunuş sonrası his önemlidir:
Ağ yavaşsa bile sayfa “donmuş” hissettirmemeli—önce anlık geri bildirim verin.
Tek sayfada hızlı bir kontrolden geçirin:
Koder.ai ile çalışıyorsanız, değişiklikten önce/sonra anlık görüntüler alarak geri alma işlemini kolaylaştırın.
Çoğu yavaşlama kendi yarattığınız eklere veya özelliklere dayanır: bir plugin, bir slider, bir tag daha. Kural: önce gerçek içeriği hızlı gösterin, sonra iyileştirmeleri ekleyin.
Hızlı çözümler:
Basit bir geçiş rutini:
Bu, gelişigüzel optimizasyonu engeller ve kullanıcıların gerçekten neyi fark ettiğine odaklanmanızı sağlar.
width/height veya aspect-ratio ayarlayın ki düzen kaymaları olmasınDoğru boyutlandırılmış tek bir ön yüklü ana görsel, haftalar sürecek derin değişikliklerden daha etkili olabilir.
Koder.ai kullanıyorsanız performansı bir özellik gibi yönetin: orta seviye bir telefonda önizleyin ve yavaşlatan yeni widget’ları bulmak için anlık görüntüleri kullanın.