E-ticaret Sitesi Hız Optimizasyonu

E-ticaret sitesi hız optimizasyonu, blog ya da kurumsal site hızlandırmaktan yapısal olarak farklıdır ve bu farkı görmeden yapılan her çalışma zaman kaybıdır. Bir tanıtım sitesinde neredeyse her sayfa herkes için aynıdır; bir kez üretip önbelleğe koyarsınız, iş biter. Oysa bir mağazada kullanıcının sepeti, oturumu, gördüğü fiyat, stok durumu ve kampanya uygunluğu kişiye özeldir. Yani "her şeyi cache'le" tavsiyesi mağazanda ya çalışmaz ya da birinin sepetini başka birine gösterir. Ben bu yazıda o ayrımı merkeze alıyorum.

Aşağıda önce yavaşlığın gerçekten nereden geldiğini nasıl ölçeceğini, sonra sırasıyla görseller, veritabanı sorguları, önbellekleme katmanı, üçüncü taraf scriptler ve altyapı tarafında ne yapman gerektiğini anlatacağım. Her bölümde çalışan komutlar ve gerçek eşik değerleri var. Sonda da en sık gördüğüm tuzakları topladım; çünkü mağaza hızlandırma çalışmalarının çoğu yanlış yapılan bir işten değil, doğru yapılıp yanlış yerde yapılan bir işten dolayı sonuç vermiyor.

Mağazada Yavaşlık Ciroya Nasıl Dokunur#

Bir mağazada hız, huninin her adımında ölçülebilir bir kayıp üretir. Ziyaretçi kategori sayfasında bekler ve geri döner; ürün sayfası geç açılır, karşılaştırma yapmaktan vazgeçer; sepete ekleme isteği yanıt vermez, iki kez tıklar ve destek talebi açar. Bu zincirin her halkası ayrı bir sayfa türüdür ve her birinin yavaşlama sebebi farklıdır — bu yüzden "sitem yavaş" cümlesi hiçbir işe yaramaz, "kategori sayfam ilk baytı 1,8 saniyede veriyor" cümlesi doğrudan bir işe yarar.

İkinci nokta, mobil trafiğin ağırlığıdır. Mağazaların büyük kısmında trafiğin yarısından fazlası mobil cihazdan gelir ve bu cihazlar hem daha yavaş işlemcilere hem de daha değişken ağlara sahiptir. Masaüstünde 1,2 saniyede açılan ürün sayfası, orta seviye bir telefonda 4 saniyeye çıkabilir; çünkü JavaScript'i ayrıştırma ve çalıştırma maliyeti CPU'ya bağlıdır. Ölçümlerini masaüstü konsolunda yapıp "hızlı" sonucuna varırsan gerçek kullanıcılarının yaşadığı sayfayı hiç görmemiş olursun. Hız ile arama sıralaması arasındaki bağın nerede başlayıp bittiğini merak ediyorsan site hızı ve SEO ilişkisi yazısı bu eşik mantığını ayrıntılı anlatıyor.

Önce Ölç: Hangi Sayfa Hangi Aşamada Yavaşlıyor#

Optimizasyona başlamadan önce sayfa türlerini ayır ve her biri için ayrı ölçüm al. Bir mağazada en az beş farklı profil vardır: ana sayfa, kategori/liste sayfası, ürün detay sayfası, sepet ve ödeme adımı. Bunların yük profilleri birbirinden tamamen farklıdır. Kategori sayfası genelde veritabanı ağırlıklıdır (filtreleme, sayfalama, stok kontrolü), ürün sayfası görsel ağırlıklıdır, sepet ise oturum ve önbellek dışı istek ağırlıklıdır.

En hızlı ilk teşhis aracı curl ile alınan zaman kırılımıdır. Sunucunun ilk baytı ne kadar sürede verdiğini görmek, sorunun ön uçta mı arka uçta mı olduğunu tek adımda söyler:

# Zaman kırılımını sayfa türü başına ölç
curl -s -o /dev/null -w "dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} toplam:%{time_total}\n" \
  https://firmaniz.com/kategori/ayakkabi

# Örnek çıktı:
# dns:0.021 tcp:0.048 tls:0.112 ttfb:1.842 toplam:1.905

Bu çıktıda ttfb ile tls arasındaki fark, sunucunun sayfayı üretmek için harcadığı süredir. Yukarıdaki örnekte bağlantı 112 ms'de kurulmuş ama ilk bayt 1842 ms'de gelmiş; yani 1,7 saniye tamamen PHP ve veritabanı tarafında geçmiş. Bu tabloda görsel sıkıştırmakla uğraşmak zaman kaybıdır, önce arka ucu düzeltmen gerekir. Tersine ttfb 200 ms ve toplam yükleme 5 saniyeyse sorun ön uçtadır.

Ölçümü tek seferlik yapma; kategori sayfasını hem önbellek soğukken hem sıcakken, hem gündüz hem akşam yoğunluğunda ölç. Performans sorunlarının önemli bir kısmı yalnızca eşzamanlı kullanıcı sayısı arttığında ortaya çıkar.

Ürün Görselleri: En Büyük ve En Kolay Kazanç#

Bir mağaza sayfasının ağırlığının çoğunlukla yüzde 60 ila 80'i görsellerden gelir ve buradaki kazanç hem en büyük hem de en risksizdir. Tipik hata, tedarikçiden gelen 3000 piksel genişliğindeki JPEG'i olduğu gibi yükleyip tarayıcıya 400 piksellik bir kutuda göstermektir. Tarayıcı dosyanın tamamını indirir, sonra küçültür; yani ziyaretçi görmediği piksellerin faturasını öder.

Yapman gereken üç şey var: her görsel için gerçekten kullanılacak boyutlarda türevler üret, modern format sun (WebP tipik olarak JPEG'e göre yüzde 25-35 daha küçük dosya üretir) ve ekran dışındaki görselleri geciktir.

# ImageMagick ile toplu türev üretimi (400, 800, 1200 piksel)
for f in urunler/*.jpg; do
  base=$(basename "$f" .jpg)
  for w in 400 800 1200; do
    convert "$f" -resize "${w}x" -quality 82 -strip "cikti/${base}-${w}.jpg"
    cwebp -q 80 -resize "$w" 0 "$f" -o "cikti/${base}-${w}.webp"
  done
done

HTML tarafında ise tek bir sabit görsel yerine tarayıcıya seçenek sunmalısın: srcset özniteliğiyle farklı genişlikteki dosyaları listeler, sizes ile kutunun gerçek genişliğini bildirirsin. Tarayıcı cihazın piksel yoğunluğuna bakıp en uygun dosyayı indirir; liste sayfalarında bu tek değişiklik çoğu mağazada sayfa ağırlığını yarıya indirir.

Geciktirmeli yükleme (lazy loading) konusunda kritik bir istisna var: ilk ekranda görünen ana ürün görselini asla geciktirme. O görsel büyük ihtimalle LCP elemanındır ve geciktirdiğinde metriği doğrudan bozarsın (LCP nasıl iyileştirilir). Bir de görselleri geciktirirken yer tutucu boyut vermezsen sayfa yüklenirken içerik zıplar ve düzen kayması metriğin bozulur; genişlik ve yükseklik oranını mutlaka bildir (CLS düzen kayması nasıl düzeltilir).

Katalog Sorgularını ve Veritabanını Hafifletme#

Kategori sayfası yavaşsa suçlu neredeyse her zaman veritabanıdır. Tipik bir mağazada bir liste sayfası ürünleri çeker, her ürünün varyantlarını çeker, stok durumunu kontrol eder, kampanya kurallarını uygular ve fiyatı hesaplar. Kötü yazılmış bir eklenti bunu her ürün için ayrı sorgu açarak yapar; 48 ürünlük bir sayfa 300 sorguya çıkar. Bu klasik N+1 problemidir ve tek başına bir sayfayı saniyelerce bekletir.

İlk iş, yavaş sorguları görünür kılmaktır. MySQL veya MariaDB'de yavaş sorgu günlüğünü geçici olarak açman yeterlidir:

-- Yavaş sorgu günlüğünü aç, 0.5 saniyeden uzun olanları yakala
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

-- Şu an çalışan sorguları anlık görmek için
SHOW FULL PROCESSLIST;

Birkaç saat trafik topladıktan sonra günlüğü incele. Aynı sorgunun yüzlerce kez tekrar ettiğini görüyorsan bu bir N+1 belirtisidir; tek ve uzun süren bir sorgu görüyorsan indeks eksikliği olasıdır. İndeks kontrolü için sorgunun planına bak:

-- Sorgu planını incele: type=ALL ise tam tablo taraması var demektir
EXPLAIN SELECT p.id, p.name, s.quantity
FROM products p
JOIN stock s ON s.product_id = p.id
WHERE p.category_id = 42 AND p.status = 'publish'
ORDER BY p.created_at DESC
LIMIT 48;

-- Eksikse bileşik indeks ekle
CREATE INDEX idx_products_cat_status_date ON products (category_id, status, created_at);

EXPLAIN çıktısında type sütunu ALL görünüyorsa ve rows sayısı yüz binlerdeyse, veritabanı her istekte tüm tabloyu tarıyor demektir. Doğru bileşik indeks bu süreyi milisaniyelere indirir. İndeks eklerken sıralamaya dikkat et: filtrede kullandığın sütunlar önce, sıralamada kullandığın sütun sonra gelmelidir. Ayrıca uzun süredir çalışan mağazalarda oturum, geçici veri ve günlük tabloları yüz binlerce satıra ulaşır; düzenli temizlik yapmıyorsan her sorgu bu şişkinliğin bedelini öder.

Önbellekleme: Neyi Cache'leyebilirsin Neyi Cache'leyemezsin#

Mağaza önbelleklemesinin tamamı tek bir ayrım üzerine kuruludur: anonim ziyaretçiye gösterilen sayfa ile oturumu olan ziyaretçiye gösterilen sayfa. Birincisi tam sayfa önbelleğe alınabilir ve alınmalıdır; ikincisi alınamaz, çünkü sepet içeriği ve kişiye özel fiyat sızar. Bu ayrımı yapmayan bir yapılandırma ya hiçbir şeyi cache'ler (yavaş kalırsın) ya da her şeyi cache'ler (veri sızdırırsın).

Pratikte kural şudur: sepet çerezi ya da oturum çerezi taşıyan istekleri önbellekten muaf tut, kalan her şeyi önbellekten servis et. Nginx tarafında bu, çerez varlığına bakan basit bir atlama kuralıdır:

# Sepeti dolu veya oturumu olan kullanıcıyı önbelleğe alma
set $atla_cache 0;

if ($http_cookie ~* "sepet_dolu|oturum_id|wordpress_logged_in") {
    set $atla_cache 1;
}

# Sepet, ödeme ve hesap yollarını hiçbir koşulda önbellekleme
if ($request_uri ~* "^/(sepet|odeme|hesabim)") {
    set $atla_cache 1;
}

location ~ \.php$ {
    fastcgi_cache MAGAZA;
    fastcgi_cache_bypass $atla_cache;
    fastcgi_no_cache    $atla_cache;
    fastcgi_cache_valid 200 301 302 10m;
    add_header X-Cache-Status $upstream_cache_status;
}

X-Cache-Status başlığı burada çok işine yarar; yanıt başlıklarına bakarak isteğin HIT mi MISS mi BYPASS mı olduğunu anında görürsün. Yapılandırmayı kurduktan sonra ilk yapman gereken iş, anonim bir tarayıcıyla kategori sayfasını iki kez açıp ikincisinde HIT gördüğünü doğrulamaktır. Ayrıntılı yapılandırma için Nginx FastCGI cache yapılandırma yazısına bakabilirsin; LiteSpeed kullanıyorsan LiteSpeed Cache tarafında aynı mantık hazır kurallarla gelir.

İkinci önbellek katmanı nesne önbelleğidir (object cache). Tam sayfa önbelleği anonim ziyaretçiyi kurtarır ama oturumu olan kullanıcı hâlâ her istekte veritabanına gider; Redis ya da Memcached ile sorgu sonuçlarını, ayar değerlerini ve hesaplanmış fiyatları bellekte tutarsan bu kullanıcıların sayfası da belirgin biçimde hızlanır (Memcached nedir). Önbellek geçersiz kılma tarafını da atlama: stok değiştiğinde, fiyat güncellendiğinde ya da ürün yayından kalktığında ilgili sayfaların önbelleği temizlenmelidir — aksi halde stokta olmayan ürünü satmaya devam edersin ve bu, yavaş siteden daha pahalı bir sorundur.

Üçüncü Taraf Scriptler ve Ölçüm Etiketleri#

Mağazalarda en sinsi yavaşlık kaynağı, kendi kodun değil, yıllar içinde eklenmiş üçüncü taraf scriptlerdir. Analitik, reklam pikselleri, canlı destek, yorum widget'ı, kargo takip, A/B test aracı, ısı haritası... Her biri ayrı ayrı "çok hafif" görünür ama toplamda ana iş parçacığını dakikalarca meşgul eden bir yığın oluşturur. Bu scriptler senin sunucundan gelmediği için CDN'in, önbelleğin ve sıkıştırman onlara hiçbir fayda sağlamaz.

İlk adım envanter çıkarmaktır. Tarayıcının ağ sekmesinde isteği üçüncü taraf alan adına göre grupla ve her birinin indirme boyutu ile çalışma süresini not al. Sonra tek tek şu soruyu sor: bu script kaldırılırsa hangi ölçülebilir iş kaybolur? Cevabı olmayan her script gider. Cevabı olanlar için ise şu üç kural geçerlidir:

1. Kritik olmayan her script'i geciktirerek yükle; sayfanın ilk çizimini bloklamasın.
2. Mümkün olanları etiket yöneticisi yerine doğrudan ve tek seferde yükle; iç içe etiket yöneticileri zincir gecikmesi üretir.
3. Canlı destek gibi ağır widget'ları ilk kullanıcı etkileşimine kadar hiç yükleme.

Üçüncü madde küçük görünür ama etkisi büyüktür: canlı destek widget'ları tipik olarak birkaç yüz kilobayt JavaScript indirir ve ziyaretçilerin ezici çoğunluğu ona hiç dokunmaz. İlk kaydırma, dokunma veya tuş vuruşunda yüklemek, davranışı değiştirmeden ilk yükleme maliyetini sıfırlar.

Altyapı Tarafı: Hosting, PHP ve TTFB#

Yukarıdaki her şeyi yapıp hâlâ TTFB'nin yüksek kaldığını görüyorsan sorun uygulamada değil, altındaki katmandadır. Burada bakman gereken üç şey var: PHP sürümü ve opcode önbelleği, işlem havuzu boyutu ve disk hızı.

PHP tarafında opcode önbelleğinin açık ve yeterli boyutta olduğunu doğrula. Kapalı bir OPcache, her istekte tüm PHP dosyalarının yeniden derlenmesi demektir ve bu tek başına TTFB'yi ikiye katlayabilir:

; php.ini - üretim için makul bir başlangıç
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
realpath_cache_size=4096k
realpath_cache_ttl=600

max_accelerated_files değeri, projendeki PHP dosya sayısından büyük olmalıdır; küçükse önbellek sürekli taşar ve hiç işe yaramaz. Mevcut kullanımı opcache_get_status() ile ya da sunucu panelinden kontrol edebilirsin.

İkinci konu işlem havuzudur. PHP-FPM'de pm.max_children değeri, aynı anda kaç isteği işleyebileceğini belirler. Bu sayı çok düşükse istekler kuyrukta bekler ve trafik arttığında TTFB tavan yapar; çok yüksekse bellek biter ve sunucu takas alanına düşer. Doğru sayı, mevcut belleği bir PHP işleminin ortalama bellek kullanımına bölerek bulunur. Bu konunun ayrıntısı RAM yetersizliği ve swap etkisi yazısında.

Üçüncüsü disktir. Mağazalar çok sayıda küçük dosya okur ve veritabanı yoğun rastgele erişim yapar; bu profilde disk gecikmesi doğrudan sayfa süresine yansır. NVMe ile SATA SSD arasındaki farkın gerçekte ne kadar olduğunu NVMe ve SATA SSD hız farkı yazısında ölçümlerle anlattım. Paylaşımlı bir pakette kaynak sınırlarına takılıyorsan paylaşımlı hostingde hız limitleri yazısı nerede durduğunu görmeni sağlar; büyüyen bir mağaza için e-ticaret hosting veya kendi kaynaklarını ayırdığın bir VDS çoğu zaman doğru adımdır.

Sık Yapılan Hatalar#

En sık gördüğüm hata, ölçmeden optimize etmek. Birisi ön uç eklentisi kurar, kritik CSS üretir, JavaScript'i böler ve haftalar harcar; oysa sorun 1,9 saniyelik TTFB'dedir ve tüm bu çalışma o süreyi hiç azaltmaz. Her zaman curl zaman kırılımıyla başla, sorunun hangi katmanda olduğunu tespit et, sonra o katmana yüklen.

İkincisi, sepet ve ödeme sayfalarını yanlışlıkla önbelleğe almak. Bunun sonucu yavaş site değil, veri sızıntısıdır: bir kullanıcı başkasının sepetini görür. Önbellek kurallarını yazdıktan sonra mutlaka iki farklı tarayıcıda, ikisinde de farklı ürünler sepette olacak şekilde test et.

Üçüncüsü, eklenti biriktirmek. Her yeni özellik bir eklentiyle çözülür, hiçbiri kaldırılmaz ve iki yıl sonra 60 eklentili bir mağaza ortaya çıkar; bunların önemli bir kısmı her sayfada kendi CSS ve JavaScript dosyasını ekler. Ayrıntısı tema ve eklenti seçiminin hıza etkisi yazısında.

Dördüncüsü, filtre sayfalarını sınırsız bırakmak. Filtre kombinasyonları sonsuz sayıda benzersiz URL üretir; her biri önbellek dışıdır, her biri ağır bir sorgu çalıştırır ve bir tarayıcı botu bu alanı gezmeye başladığında sunucu diz çöker. Filtre sayfalarını taramaya kapat. Beşincisi ise testleri boş saatte yapmaktır: kaynak sınırlarına takılan bir mağaza gece yarısı her zaman hızlıdır, gerçek performansını akşam yoğunluğunda ölç.

Sıkça Sorulan Sorular#

E-ticaret sitesi hız optimizasyonu ne kadar sürer#

Doğru sıralamayla ilerlersen ilk belirgin kazanç genellikle bir gün içinde gelir: görsel türevleri üretmek, tam sayfa önbelleğini kurmak ve gereksiz üçüncü taraf scriptleri kaldırmak birkaç saatlik iştir ve çoğu mağazada yükleme süresini yarıya indirir. Veritabanı indeksleri ve sorgu düzeltmeleri gibi derin işler ise ölçüm, test ve doğrulama gerektirdiği için birkaç güne yayılır. Toplamda tipik bir mağaza için bir haftalık odaklı çalışma gerçekçi bir plandır.

Hız için CDN kullanmam şart mı#

Şart değil ama ziyaretçilerinin coğrafi dağılımı genişse fark yaratır. CDN esas olarak statik dosyaları (görsel, CSS, JavaScript) kullanıcıya yakın bir noktadan servis ederek ağ gecikmesini düşürür; sunucundaki PHP ve veritabanı yavaşlığını düzeltmez. Ziyaretçilerinin neredeyse tamamı Türkiye'den geliyorsa ve sunucun da Türkiye'deyse kazanç sınırlı kalır. Karşılaştırma için CDN mi daha iyi hosting mi yazısına bakabilirsin.

Ürün görsellerini hangi formatta yüklemeliyim#

Kaynak dosyayı yüksek kaliteli JPEG ya da PNG olarak sakla, ziyaretçiye ise WebP sun; WebP tipik olarak aynı görsel kalitede JPEG'e göre belirgin biçimde küçüktür ve tüm güncel tarayıcılar destekler. Fotoğraf ağırlıklı ürün görsellerinde kalite değerini 78-85 aralığında tutmak gözle fark edilmeyen bir kayıpla büyük tasarruf sağlar. Şeffaflık gerekmiyorsa PNG kullanma; PNG fotoğraflarda çok verimsizdir.

Eklentileri kaldırmak siteyi bozar mı#

Bozabilir, bu yüzden sırayla ve ölçerek ilerlemelisin. Önce bir test kopyasında dene, eklentiyi devre dışı bırak, sitenin kritik akışlarını (ürün görüntüleme, sepete ekleme, ödeme adımı) elle test et ve ancak sonra canlıya al. Kaldırmadan önce eklentinin veritabanında bıraktığı tabloları da not et; bazı eklentiler kaldırıldığında veriyi temizlemez ve şişkinlik kalır.

TTFB süremi nasıl düşürürüm#

Önce ölç: TTFB yüksekse sorun sunucu tarafındadır. Sırasıyla şunlara bak: tam sayfa önbelleği çalışıyor mu (yanıt başlığında HIT görüyor musun), OPcache açık ve yeterli mi, yavaş sorgu günlüğünde uzun süren sorgular var mı, PHP işlem havuzu istekleri kuyruğa alıyor mu. Bu dördünü düzelttiğinde çoğu mağazada TTFB 200 milisaniyenin altına iner. Hâlâ inmiyorsa kaynak yetersizliği vardır ve paket yükseltmesi gerekir.

Mobil hızım masaüstünden neden çok daha kötü#

İki sebebi var. Birincisi ağ: mobil bağlantılar daha yüksek gecikmeye sahiptir, bu yüzden çok sayıda küçük istek yapan sayfalar orantısız biçimde yavaşlar. İkincisi ve daha önemlisi işlemci: JavaScript'i ayrıştırmak ve çalıştırmak CPU işidir ve orta seviye bir telefonun işlemcisi masaüstünden kat kat yavaştır. Yani mobil hızını düzeltmenin en etkili yolu JavaScript miktarını azaltmaktır, görsel sıkıştırmak ikinci sırada gelir.

Kapanış#

E-ticaret sitesi hız optimizasyonunda akılda tutman gereken dört alışkanlık var. Birincisi, her zaman ölçerek başla ve sorunun sunucuda mı tarayıcıda mı olduğunu curl zaman kırılımıyla ilk adımda ayır. İkincisi, sayfa türlerini birbirinden ayrı ele al; kategori sayfasının derdiyle sepet sayfasının derdi aynı değildir. Üçüncüsü, önbelleklemede anonim ve oturumlu ziyaretçi ayrımını asla bulanıklaştırma. Dördüncüsü, üçüncü taraf script envanterini yılda en az bir kez gözden geçir ve karşılığı olmayanları kaldır.

Bu işlerin bir kısmını altyapı seviyesinde çözmek istersen Clou.TR tarafında hazır seçenekler var. Yoğun katalog ve eşzamanlı sepet trafiği olan mağazalar için e-ticaret hosting paketleri NVMe disk ve ayrılmış kaynakla gelir; tam kontrol istiyorsan VDS sunucu üzerinde kendi önbellek ve PHP yapılandırmanı kurabilirsin. Sunucu tarafını hiç dert etmek istemiyorsan sunucu yönetimi hizmetimiz önbellek, PHP ayarları ve izleme kurulumunu üstlenir; mevcut mağazanı taşırken kesinti yaşamamak içinse site taşıma hizmetinden yararlanabilirsin.