Shopify Performansınızı %50 Artırmanın Kritik Kontrol Listesi

Shopify mağazanızı hayata geçirdiniz. Tasarım estetik, ürün fotoğrafları profesyonel ve içerikler akıcı. Peki ya müşteri, sayfalarınızı açmak için saniyelerce bekliyorsa? Google PageSpeed Insights’ın mobil puanınız 41 çıkıyorsa, sorun tek bir bileşende değil — performansınızın altında yatan birden fazla katman var.

Bu katmanlardan bazıları Shopify tarafından yönetilirken, diğerleri sizin kontrolünüzde. Sunucu yanıt süresinden görüntü optimizasyonuna, üçüncü parti uygulamalardan Liquid şablonlarına kadar her detay, müşteri deneyimini doğrudan etkiliyor. Doğru adımları atmadan önce, hangi katmanın soruna yol açtığını belirlemek kritik önem taşıyor. İşte Shopify performansınızı kökten iyileştirecek, adım adım ilerleyen bir kontrol listesi.

Shopify’in Kontrolünde Olanlar ve Olmayanlar

Shopify, hosting, Fastly üzerinden CDN dağıtımı, HTTP/2 protokolü ve otomatik kaynak sıkıştırma gibi temel performans unsurlarını yönetiyor. Bu altyapı, toplam yükleme süresinin yaklaşık %30’unu oluşturuyor ve doğrudan değiştirmeniz mümkün değil. Bu nedenle, zamanınızı burada harcamak yerine, kalan %70’lik kısmı optimize etmek çok daha verimli.

Kontrol edebileceğiniz alanlar ise tarayıcıda çalışan ve sunucu yanıtından önce işlenen tüm unsurlar: görüntüler, JavaScript dosyaları, üçüncü parti uygulama betikleri, Liquid render mantığı ve temanın kritik render yolu yönetimi. Bu %70’lik kısım, hız kazanımlarının neredeyse tamamının yer aldığı yer.

Liquid Rendering: DevTools’ta Görünmeyen Maliyet

Liquid, sunucu tarafında çalıştığı için DevTools’un Ağ sekmesinde görünmez. Bunun yerine, İlk Bayt Süresi (TTFB) olarak karşımıza çıkar. Yavaş TTFB değerlerine sahip mağazaların çoğunda, Liquid şablonlarında gereğinden fazla işlem yapıldığı görülüyor: büyük koleksiyonlar üzerinde çalışan iç içe for döngüleri, tekrarlanan meta alan çağırmaları veya aynı snippet’in bir sayfa yüklemesi sırasında defalarca render edilmesi.

Liquid performansını iyileştirmek için dikkat edilmesi gerekenler:

• Veri yapısı izin verdiğinde, iç içe döngüleri düzleştir
• Maliyetli Liquid hesaplamalarını her render sırasında yeniden yapmak yerine, capture blokları kullanarak önbelleğe al
• Koleksiyon sayfa boyutlarını makul seviyede sınırla; tek bir şablon geçişinde 50’den fazla ürün yüklemek, TTFB’yi sürekli olarak olumsuz etkiler
• theme.liquid içinde, hangi şablonun aktif olduğuna bakılmaksızın her sayfa yüklemesinde çalışan mantık bloklarını denetle

Shopify tarafından yayınlanan ve ücretsiz olan Shopify Theme Inspector for Chrome eklentisi, Liquid etiketlerine göre render süresini ayrıntılı olarak gösteriyor. İlk olarak ürün ve koleksiyon sayfalarında bu aracı kullanmak, kurtarılabilir zamanı belirlemek açısından en etkili yaklaşım.

Görüntü Teslimi: Genellikle Atlanan En Hızlı Kazanç

Tipik bir Shopify mağazasında, toplam sayfa ağırlığının %50 ila %80’ini görüntüler oluşturuyor. Shopify’nin görüntü CDN’i, resimleri yeniden boyutlandırma ve format dönüştürme konusunda oldukça başarılı; ancak girdi olarak kullanılan kaynak dosyalar uygun değilse, bu avantaj tam olarak değerlendirilemiyor.

Yapılan denetimlerde sıkça karşılaşılan görüntü optimizasyon hataları:

• Temanın 600 piksel olarak render edildiği durumlarda, 3.000 ila 4.000 piksel genişliğinde kaynak dosyalar yüklemek — Shopify otomatik olarak yeniden boyutlandırıyor ancak tam boyutlu dosyalar üzerinde işlem yapmaya devam ediyor
• Şablonlarda img_url: 'master' kullanmak yerine, hedef boyut belirtilmiş olması gereken img_url: '1200x' gibi ifadelerin tercih edilmesi
• En büyük içerikli öğenin (LCP) genellikle kahraman görüntü veya ilk ürün fotoğrafı olduğu durumlarda, fetchpriority="high" özniteliğinin eklenmemesi
• Görünüm alanına girmeyen öğelerde loading="lazy" özniteliğinin kullanılmaması

fetchpriority özniteliği, görece yeni olduğu için sıkça atlanıyor. Bu öznitelik, tarayıcıya ilgili görüntüyü diğer kaynaklarla bant genişliği rekabetine girmeden önce yüklemesini söylüyor. Ürün sayfalarında kahraman görüntü LCP öğesiyse, bu tek öznitelik gerçek dünya LCP puanlarını 200 ila 400 milisaniye arasında azaltabiliyor.

Hiç Kimsenin Yapmak İstemediği Uygulama Denetimi (Ama Her Zaman İşe Yarıyor)

Üçüncü parti uygulamalar, olgunlaşmış Shopify mağazalarında performans regresyonunun en büyük nedenlerinden biri. Uygulamaların kendisi kötü kodlanmış olduğu için değil, her uygulama varsayılan olarak tüm sayfalara kendi JavaScript ve CSS dosyalarını enjekte ediyor — sayfanın uygulama işlevselliğiyle ilgili olmasa bile.

Örneğin, bir inceleme widget’ı FAQ sayfasında çalışıyor ya da bir sadakat programı blog gönderilerinde tetikleniyor. Bu durumda, ne uygulama ne de kullanıcı açısından bir fayda sağlanmıyor; yalnızca sayfa ağırlığı artıyor.

Uygulama denetimi oldukça basit bir süreç:

• Chrome DevTools’u aç, Kapsam sekmesini bul (Shift+Ctrl+P, "Coverage" yaz)
• Sayfayı yeniden yükle
• JavaScript dosyalarını %80-100 oranında kullanılmayan olarak işaretlenmiş olanları belirle
• Bu dosyaları uygulama listesine eşleştirerek sahiplerini tespit et
• Her uygulamanın ayarlarında sayfa türüne özel yükleme seçeneklerini kontrol et; çok sayıda uygulama bu özelliği destekliyor ancak varsayılan olarak devre dışı

Eğer bir uygulama sayfa türüne özel yüklemeyi desteklemiyorsa, ilgili işlevselliğin yerel olarak (örneğin, metafields veya metaobjects kullanılarak) gerçekleştirilip gerçekleştirilemeyeceğini değerlendir. Online Store 2.0 bölümleri de, daha önce sayfa oluşturucu uygulamaları tarafından karşılanan görüntüleme mantığını yerel olarak yönetebilir. Daha az JavaScript yüklenmesi, herhangi bir miktarda ertelenmiş veya asenkron yüklemeden daha hızlı sonuç verir.

Sıralamaları Doğrudan Etkileyen Üç Web Vitesi Metriği

Google’ın sayfa deneyimi sinyalleri, laboratuvar testleri yerine gerçek kullanıcı verilerinden (CrUX) elde ediliyor. Bu fark, çoğu kişi tarafından olduğundan daha önemli. Örneğin, hızlı bir dizüstü bilgisayarda Lighthouse’tan 85 puan alan bir mağaza, orta seviye Android cihazlarda değişken bağlantı hızlarına sahip gerçek kullanıcılar tarafından yükleniyorsa, zayıf alan puanlarına sahip olabilir.

Üç temel metrik: En Büyük İçerikli Boyama (LCP), Etkileşimden Sonraki Boyama (INP, 2024 yılında İlk Girdi Gecikmesi’nin yerini aldı) ve Kümülatif Düzen Kayması (CLS). Her bir metriğin farklı bir kök nedeni var.

• LCP genellikle görüntüler veya render engelleyici kaynaklardan kaynaklanır
• INP senkron JavaScript ile ilişkilidir
• CLS geç yüklenen fontlar veya içeriği yukarıdaki öğelerin üzerine enjekte eden uygulama bloklarından kaynaklanır

Tek bir PageSpeed puanını kovalamak yerine, her metriği ayrı ayrı iyileştirmek pratik bir başlangıç noktasıdır. Özellikle CLS üzerinde durulması gerekiyor; çünkü düzen kayması, kullanıcı deneyimini doğrudan bozan ve müşteri güvenini zedeleyen bir faktör.

Performans optimizasyonu, tek seferlik bir çalışma değil. Mağazanızın büyümesiyle birlikte, yeni uygulamalar, temalar ve içeriklerle birlikte performans profili de değişecek. Bu kontrol listesini periyodik olarak gözden geçirmek, uzun vadede hem hızınızı hem de arama motoru sıralamalarınızı korumanın anahtarı olacak.