PrestaShop Hosting: PHP, MySQL, Önbellek ve CDN Ayarları

PrestaShop Hostinginde Hız Neden Bu Kadar Kritik?

PrestaShop ile e-ticaret mağazası kurarken tema seçimi, ödeme altyapısı veya ürün girişleri kadar önemli bir konu daha var: hosting ve sunucu ayarları. Aynı temayı kullanan iki mağazanın hız farkı yalnızca hostingden kaynaklanmaz; modüller, sorgular, görseller ve PHP, MySQL, önbellek ve CDN yapılandırması birlikte değerlendirilmelidir. Yoğun kampanya trafiği için doğru boyutlandırılmış bir VPS veya dedicated sunucu seçenekler arasındadır; seçim, ölçülen kaynak ihtiyacına dayanmalıdır.

Bu rehber; PrestaShop hosting seçiminden PHP-FPM, MySQL, Smarty ve CDN ayarlarına kadar ölçüme dayalı bir yapılandırma planı sunar. Kod örnekleri PrestaShop 9.0 ile uyumlu PHP 8.4 ve MySQL 8.4 LTS temel alınarak hazırlanmıştır; kurulu alt sürümünüz, tema ve modülleriniz ayrıca doğrulanmalıdır. DCHost üzerindeki paylaşımlı hosting, VPS veya dedicated sunucu seçeneklerini değerlendirirken bu gereksinimleri ve yönetim sorumluluklarını birlikte kontrol edin.

PrestaShop İçin Doğru Hosting Mimarisi Nasıl Seçilir?

Teknik ayarlara inmeden önce, PrestaShop çalıştıracağınız altyapının kabaca neye benzemesi gerektiğini netleştirmek önemli. Çünkü yanlış mimari üzerine kurulmuş bir mağazayı sadece php.ini ayarlarıyla kurtarmak genellikle mümkün olmuyor.

Paylaşımlı Hosting mi, VPS mi, Dedicated mi?

PrestaShop, basit bir blogdan farklı olarak yoğun veritabanı ve disk erişimi yapan bir uygulama. Özellikle ürün sayısı, filtreler, kombinasyonlar ve sepet işlemleri arttıkça CPU ve disk IO’ya yük bindiriyor.

• Paylaşımlı hosting: Uyumlu ve güvenlik desteği alan PHP/veritabanı sürümleri, yeterli kaynak sınırları ve gerekli zamanlanmış görev desteği varsa uygun olabilir. Ürün sayısı tek başına yeterlilik ölçütü değildir.
• VPS: FPM ve veritabanı ayarlarına erişim veya daha fazla kapasite gerektiğinde değerlendirin. vCPU, RAM, disk I/O ve paylaşım koşulları pakete bağlıdır. CPU, RAM ve trafik hesaplama rehberindeki kapasite planlama yaklaşımı bu ölçümleri düzenlemeye yardımcı olur.
• Dedicated sunucu: Ölçülen iş yükü, donanım kontrolü veya ayrıştırılmış hizmetler gerektirdiğinde seçilebilir. Daha fazla donanım; ağır modülleri, hatalı sorguları veya eksik yedekleme planını kendiliğinden düzeltmez.

Aşağıdaki ortak örnek, 4 vCPU ve 8 GiB RAM bulunan tek bir Linux sunucuda Nginx/Apache, PHP-FPM ve MySQL çalıştığını varsayar. Bu bir mağaza kapasitesi garantisi değildir. Redis ancak uyumlu entegrasyon ve ölçülen fayda varsa eklenir; yapılandırmalar mevcut hizmet ayarlarına birleştirilir.

Temel Kaynak Planlama: CPU, RAM ve Disk

PrestaShop performansını etkileyen ana kaynaklar:

• CPU: PHP-FPM süreçleri ve MySQL sorguları için kritik. Kampanya dönemlerinde anlık CPU patlamaları görebilirsiniz.
• RAM: PHP memory_limit, MySQL InnoDB buffer pool ve Redis/Memcached için yeterli alan ayırabilmek adına önemli.
• Disk (özellikle NVMe): Ürün resimleri, cache klasörleri ve veritabanı dosyaları için yüksek IOPS ve düşük latency sağlıyor. NVMe disklerin hız farkını detaylı anlattığımız rehberdeki kazanımların PrestaShop mağazanıza ne ölçüde yansıyacağı, disk darboğazına ve iş yüküne bağlıdır.

Ürün ve günlük ziyaret sayısını doğrudan sunucu paketine çevirmek yerine, kampanya sırasındaki eşzamanlı PHP isteklerini, ağır filtreleri ve entegrasyon işlerini ölçün. Örnek 8 GiB sunucunun bellek bütçesini şöyle sınırlandırabilirsiniz:

• PHP-FPM: 3 GiB bütçe. Yoğun iş yükünde süreç başına yaklaşık 300 MiB ölçüldüğü varsayılırsa 8 çalışan yaklaşık 2,4 GiB kullanır; kalan pay dalgalanmalar içindir. Bu ölçüm varsayımı sizin mağazanızda doğrulanmalıdır.
• MySQL: toplam 3 GiB bütçe. Bunun 2 GiB kısmı InnoDB buffer pool için ayrılır; kalan bölüm bağlantılar, geçici tablolar ve diğer MySQL belleğini karşılamalıdır.
• Diğer hizmetler: 2 GiB bütçe. İşletim sistemi, web sunucusu, ortak OPcache alanı, izleme ve varsa Redis burada hesaba katılır. Bu pay yetmiyorsa FPM/DB bütçelerini azaltın veya kapasiteyi artırın; CPU ve I/O sınırlarını da yük altında ölçün.

PrestaShop İçin PHP Sürümü ve PHP-FPM Ayarları

PHP sürümü ve FPM sınırları, sayfa üretim süresini ve aynı anda işlenebilen istek sayısını etkiler. Sonucu TTFB, hata oranı, FPM kuyruğu ve toplam bellek tüketimiyle ölçün; tek bir ayar her mağazada hız artışı sağlamaz.

Hangi PHP Sürümünü Kullanmalıyım?

PHP seçimini PrestaShop sürüm uyumluluk tablosu ile PHP güvenlik desteği takvimini birlikte değerlendirerek yapın:

• Bu rehberin örneği: PrestaShop 9.0 için PHP 8.4 kullanılır; resmi tabloda 9.0 dalı PHP 8.1–8.4 ile uyumludur. Bu aralıktaki her PHP sürümünün hâlâ güvenlik desteği aldığı sonucu çıkarılmamalıdır.
• PrestaShop 9.1: Resmi tablo PHP 8.1–8.5 uyumluluğunu gösterir ve PHP 8.5 önerir. Tam mağaza sürümüyle birlikte ödeme, tema ve entegrasyon modüllerini de test edin.
• Eski 1.6, 1.7 ve 8.x mağazalar: 9.x ayarlarını ve PHP aralığını doğrudan uygulamayın. Kendi alt sürümünüzün gereksinimlerini kontrol edip desteklenen sürümlere geçişi planlayın.

Kurulumdan önce mutlaka PrestaShop sürümünüzün resmi gereksinim listesine bakın. PHP 8.x geçişlerinde yaşanabilecek uyumluluk sorunlarını azaltmak için PHP 8.x yükseltme kontrol listesinde anlattığımız yaklaşımı PrestaShop tarafında da uygulayabilirsiniz: staging ortamda test, eklenti uyumluluğunun kontrolü, hata loglarının yakından izlenmesi gibi.

Gerekli PHP Eklentileri (Extensions)

PrestaShop 9 gereksinim listesi ve 9.0.0 çekirdeğinin paket tanımı şu uzantıları içerir. Hosting panelinde bazıları PHP içine derlenmiş olduğundan ayrı bir anahtar olarak görünmeyebilir:

• PDO ve pdo_mysql: veritabanı bağlantısı.
• curl, dom, fileinfo, iconv, intl, json, mbstring, openssl, simplexml ve zip.
• gd gereklidir: Ürün görsellerinin küçük sürümlerini üretir. Imagick kurmak bu gereksinimin yerine geçmez; bir modül ayrıca Imagick isteyebilir.
• Modül gereksinimleri: SOAP gibi ek uzantıları yalnızca kullandığınız entegrasyonun şartlarına göre etkinleştirin. Gereksinimlerdeki allow_url_fopen=On ayarını da doğrulayın.

Kontrolü mağazanın çalıştığı web PHP sürümünde yapın; komut satırındaki PHP farklı olabilir. Kurulum gereksinim ekranını ve modül belgelerini birlikte inceleyin. Panelde sunulmayan uzantılar için paketin desteklediği seçenekleri sağlayıcıyla doğrulayın.

php.ini Temel Performans Ayarları

Aşağıdaki PHP 8.4 örneğinde memory_limit=512M, PrestaShop 9 belgelerindeki öneriyle uyumludur; her çalışana baştan 512 MiB ayrıldığı anlamına gelmez. Diğer değerler uygulamanın ihtiyacına göre seçilmiş örneklerdir:

memory_limit = 512M
max_execution_time = 120
max_input_time = 120
max_input_vars = 5000
upload_max_filesize = 64M
post_max_size = 80M

PHP yönerge belgesine göre post_max_size, upload_max_filesize değerinden büyük olmalıdır. Burada 64 MiB tek dosya sınırına karşı toplam POST gövdesi için 80 MiB ayrılmıştır; çoklu dosyalar, form alanları ve multipart ek yükü bu toplamı paylaşır. Web sunucusu, proxy/CDN ve uygulama sınırları da isteği kabul etmelidir. 120 saniyelik PHP süresi tek başına proxy veya FPM zaman aşımını uzatmaz ve tüm platformlarda geçen gerçek süreyi sınırlamaz; büyük içe aktarmaları modül destekliyorsa kontrollü CLI/zamanlanmış işler olarak yürütün. .user.ini, CGI/FastCGI için dizin düzeyindedir; FPM havuz dosyası değildir ve tüm sistem yönergelerini değiştiremez.

OPcache ve Gerçek Yol Önbelleği (realpath_cache)

OPcache, derlenmiş PHP bayt kodunu bellekte tutarak tekrar derleme işini azaltır. Etkin olduğunu mağazanın web PHP sürecinde doğrulayın. Aşağıdaki değerler bir başlangıç örneğidir; mevcut ortak OPcache alanını kullanan diğer siteler de kapasite hesabına dahildir:

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

opcache_get_status(false) çıktısında cache_full tek başına hangi sınırın dolduğunu söylemez. memory_usage.free_memory, wasted_memory, opcache_statistics.num_cached_keys/max_cached_keys, oom_restarts ve hash_restarts değerlerini birlikte izleyin. Dosya anahtarı sınırı ile bellek tükenmesini ayırt ederek ilgili ayarı değiştirin. Tanılama çıktısını internete açmayın; CLI OPcache durumu FPM önbelleğini temsil etmez. revalidate_freq=2 zaman damgası kontrol aralığıdır; dağıtımda anında yenileme gerekiyorsa web PHP önbelleğini kontrollü yenileyin. validate_timestamps=0 ancak bu işlem dağıtıma güvenilir biçimde eklenmişse kullanılmalıdır. Dosya yolu önbelleği için örnek:

realpath_cache_size=4096K
realpath_cache_ttl=600

4096K, modern PHP varsayılanı olan 4 MiB ile aynıdır; otomatik bir performans artışı sayılmaz. realpath_cache_ttl=600 yol bilgisini daha uzun tutar ve sembolik bağlantıyla dağıtım gibi akışlarla birlikte test edilmelidir. open_basedir etkinse realpath önbelleği devre dışıdır; bu ayarı yalnızca hız için kaldırmayın.

PHP-FPM Havuz (Pool) Ayarları

Aşağıdaki havuz örneğinde prestashop uygulama kullanıcı/grubu ve www-data web sunucusu grubu birer yer tutucudur; gerçek hesaplara, dosya izinlerine ve soket dizinine göre uyarlayın. Web sunucusunun FastCGI hedefi bu soketle aynı olmalıdır. Sekiz çalışan, yukarıdaki 3 GiB PHP bütçesi ve varsayımsal 300 MiB süreç ölçümüne bağlıdır; 4 vCPU için evrensel bir sınır değildir:

[prestashop]
user = prestashop
group = prestashop
listen = /run/php-fpm-prestashop.sock
listen.owner = prestashop
listen.group = www-data
listen.mode = 0660
pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500

• pm.max_children: Eşzamanlı işlenen PHP isteklerinin üst sınırıdır; ziyaretçi veya açık oturum sayısı değildir. PHP için ayrılan bütçeyi yoğun yükte ölçülen süreç belleğine bölün, güvenlik payı bırakın ve toplam tüketimi doğrulayın. Kuyruk büyürken CPU/DB zaten doymuşsa çalışan artırmak sorunu ağırlaştırabilir.
• pm=dynamic: Örnekte iki süreçle başlar, iki ile dört boşta süreç tutar. ondemand farklı trafik düzenlerinde denenebilir; seçim ölçüme bağlıdır.
• pm.max_requests=500: Çalışanı 500 istekten sonra yeniler; modüldeki bellek sızıntısını onarmaz. Sayıyı hata ve bellek ölçümlerine göre ayarlayın.

PrestaShop İçin MySQL/MariaDB Ayarları

PrestaShop, sipariş, müşteri, sepet ve ürün kayıtlarını veritabanında tutar. Bu nedenle iş yüküne uygun olmayan MySQL/MariaDB konfigürasyonu, sayfa oluşturma süresini uzatabilir. WooCommerce için yazdığımız MySQL/InnoDB tuning kontrol listesindeki genel kapasite planlama yaklaşımı PrestaShop için de kullanılabilir; değerler mağazanın sorgu yüküne göre belirlenmelidir.

Sürüm Seçimi ve Depolama Motoru

• Sürüm: Bu bölümün örneği MySQL 8.4 LTS içindir. PrestaShop belgesindeki minimum veritabanı sürümü güncel bir güvenlik önerisi değildir; MySQL 5.7 veya MariaDB 10.4 gibi eski sürümleri yeni kurulum hedefi yapmayın. MariaDB kullanıyorsanız onun sürüme özel yönergelerini izleyin.
• Depolama motoru: PrestaShop çekirdek ve modül tablolarının beklediği şemayı esas alın. Eski MyISAM tablolarını tespit edin; InnoDB dönüşümünü yedek, disk kapasitesi ve modül uyumluluğu doğrulandıktan sonra staging ortamında deneyin. Toplu dönüşüm canlı mağaza için otomatik bir bakım adımı değildir.

Temel my.cnf Ayarları

Örnek 8 GiB ortak sunucuda MySQL için ayrılan toplam 3 GiB bütçenin 2 GiB kısmı buffer pool içindir. Aşağıdaki MySQL 8.4 LTS parçasını mevcut [mysqld] bölümüne birleştirin; 50 bağlantı bir yük testi varsayımıdır. PHP yanında CLI, cron, yönetim ve entegrasyon bağlantılarını da sayın. Yavaş sorgu günlüğünün dizini mevcut, MySQL tarafından yazılabilir ve erişimi sınırlı olmalıdır:

[mysqld]
innodb_buffer_pool_size = 2G
innodb_redo_log_capacity = 512M
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
max_connections = 50
temptable_max_ram = 256M
tmp_table_size = 16M
max_heap_table_size = 16M
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

• Buffer pool ve bağlantılar: innodb_buffer_pool_size tüm MySQL belleği değildir. Bağlantı başına çalışma alanları ve geçici tablolar için kalan payı izleyin; 50 bağlantının tamamı aktifken bütçe aşılabiliyorsa sınırları azaltın.
• Redo ve dayanıklılık: MySQL 8.4 için innodb_redo_log_capacity kullanılır. innodb_flush_log_at_trx_commit=1 korunur; 2 çökmede onaylanmış işlemleri kaybettirebilir. sync_binlog=1, binary log etkin olduğunda bu günlüğün senkronizasyonunu düzenler. Bu ayarlar yedek yerine geçmez.
• Sürüme özel seçenekler: MySQL 8.4 yapılandırmasına kaldırılmış query_cache_type/query_cache_size eklemeyin. Evrensel bir innodb_buffer_pool_instances veya O_DIRECT ayarı da uygulamayın; sürüm, dosya sistemi ve iş yükünü esas alın.
• Geçici tablolar: tmp_table_size ve max_heap_table_size değerlerini topluca 256M yapmayın. MySQL 8.4 TempTable motorunda tablo başına sınır ile temptable_max_ram ortak sınırı farklıdır; Örnekte bu ortak sınır 256 MiB, tablo başına sınır 16 MiB olarak belirlenmiştir; MEMORY tabloları için de 16 MiB sınır kullanılır. Thread-local alanlar ortak sınıra dahil değildir ve diğer bağlantı/çalışma alanları ek bellek tüketir. Bellekte tutmak uğruna toplam RAM bütçesini aşmayın.
• Yavaş sorgular: long_query_time=1 tanılama için örnektir. Günlük boyutunu, dönüşümünü ve hassas parametreleri yönetin; tekrar eden pahalı sorguları staging üzerinde EXPLAIN ile inceleyip indeks değişikliklerini test edin.

Karakter Seti ve Sıralama (Collation)

utf8mb4, Unicode karakterlerin saklanmasını sağlar; collation ise veritabanındaki karşılaştırma ve sıralama davranışını belirler. Google sıralamasını doğrudan iyileştiren bir SEO ayarı değildir. Örneğin mevcut PrestaShop şemasıyla uyumluluğu doğrulanmış bir MySQL sunucusunda şu varsayılanlar kullanılabilir:

[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

Sunucu varsayılanları mevcut veritabanı, tablo veya sütunları dönüştürmez. Türkçe harflerin eşitlik/sıralama sonuçlarını, bağlantı karakter setini, modül sorgularını ve indeks sınırlarını staging ortamında kontrol edin. Şema değişikliği için doğrulanmış yedek ve geri dönüş planı hazırlayın; canlı tabloları topluca dönüştürmeyin.

PrestaShop’ta Önbellek Katmanı: Smarty, Redis ve HTTP Cache

Önbelleğin amacı aynı hesaplamayı gereksiz yere tekrarlamamaktır. PHP bayt kodu, Smarty şablonları, uygulama nesneleri ve HTTP yanıtları farklı katmanlardır; birini etkinleştirmek diğerlerini otomatik olarak yapılandırmaz. Sipariş, fiyat ve kullanıcıya özgü verilerin doğruluğunu korumak temel koşuldur.

Smarty Şablon Önbelleği

PrestaShop’un tema tarafındaki şablon motoru Smarty’dir. Yönetim panelinde:

• Gelişmiş Parametreler > Performans bölümünde Smarty önbelleğini tema/modül uyumluluğunu test ederek etkinleştirin.
• Şablon derlemesi: Dosya değiştiğinde yeniden derleme, düzenlemelerin görünmesini sağlar. “Asla yeniden derleme” seçeneği ancak tema dağıtımında Smarty önbelleği açıkça temizleniyorsa uygundur.
• CCC: CSS/JS birleştirme ve önbellekleme seçeneklerini tek tek deneyin; ödeme, ürün varyasyonları ve mobil menü gibi JavaScript akışlarını kontrol edin.

Smarty varsayılan olarak dosya tabanlı önbellek kullanır. Şablon derleme, önbellek temizleme ve CDN varlık yenileme işlemlerini aynı dağıtım planında ele alın; bunlar kişiselleştirilmiş HTML için genel CDN önbellek izni vermez.

Dosya Sistemi mi, Redis/Memcached mi?

Uygulama nesne önbelleği, Smarty dosya önbelleğinden ayrıdır. PrestaShop 9.0 çekirdeğinde Memcache/Memcached bağdaştırıcıları bulunur; seçilen bağdaştırıcının PHP uzantısı ve servis gereksinimleri karşılanmalıdır. Redis için kurulu PrestaShop sürümünü destekleyen ayrı bir modül veya entegrasyon gerekir; yalnızca Redis servisi kurmak yeterli değildir.

• Önce ölçün: Tek sunucuda dosya önbelleği yeterli olabilir. Nesne önbelleğini hit/miss oranı, SQL süresi ve toplam yanıt süresiyle karşılaştırın.
• Entegrasyonu doğrulayın: Modülün hangi verileri tuttuğunu, TTL ve ürün/fiyat güncellemelerinde önbellek geçersizleştirme davranışını öğrenin. Redis her yoğun mağazada dosya sisteminden daha hızlı olacak diye bir kural yoktur.

Redis nesne önbelleği kullanılacaksa kurulum kapsamını şöyle belirleyin:

• Servisi aynı sunucuda veya düşük gecikmeli özel ağda çalıştırın; erişimi sınırlandırın, kimlik doğrulamayı ve gerekiyorsa TLS desteğini doğrulayın. Bağlantı bilgilerini uyumlu modülün kendi ayarlarına girin.
• maxmemory sınırını toplam hizmet belleği, ek yük ve varsa kalıcılık/çoğaltma tamponlarıyla birlikte bütçeleyin. Uzak Redis bağlantısının gecikmesini de ölçün.
• allkeys-lru yalnızca yeniden üretilebilen önbellek verisinin bulunduğu örnek içindir. Oturumları, kuyrukları ve kritik kayıtları ayrı Redis örneğinde yönetin; ayrı mantıksal veritabanı numarası bellek tahliyesinden yalıtım sağlamaz. Kalıcılık açmak silinmiş anahtarları geri getirmez.

Redis’in web uygulamalarını nasıl hızlandırdığını daha genel bağlamda merak ederseniz, Redis cache ve hosting performansı rehberimize de göz atabilirsiniz.

HTTP Seviyesinde Önbellekleme: Nginx/Apache ve CDN

CSS, JS ve ürün görselleri doğrudan statik dosya olarak sunuluyorsa, CDN isabetleri öncelikle origin bant genişliği ve statik istek yükünü azaltır; zaten PHP çalıştırmayan bir istekte PHP yükü azalması beklenmez. HTML ise fiyat, para birimi, müşteri grubu, vergi ve sepet bilgisine göre değişebilir.

• Statik içerik: Cache-Control politikasını dosyanın güncellenme biçimine göre belirleyin. Uzun TTL ve immutable yalnızca içerik değiştiğinde URL’si de değişen varlıklar için uygundur.
• HTML: Başlangıç politikası CDN ve reverse proxy önbelleğini atlamaktır. Ürün/kategori sayfalarını yalnızca anonim ziyaretçi oldukları için önbelleğe almayın.
• Mikro önbellek: 1–5 saniyelik TTL bile yanlış fiyat, stok veya kişisel içerik sunabilir. Ancak PrestaShop ile uyumlu önbellek geçersizleştirme, doğru cache key ve oturum/çerez bypass kuralları test edilmiş belirli kamusal sayfalarda değerlendirin.

Genel mekanizmayı Nginx mikro önbellekleme rehberinde inceleyebilirsiniz. Oradaki genel kuralları doğrudan mağazaya kopyalamayın; PrestaShop sürümü ve modüllerinin çerezleri, kişiselleştirme ve geçersizleştirme davranışı ayrıca test edilmelidir.

CDN Entegrasyonu: PrestaShop Mağazanızı Küresel Ölçekte Hızlandırmak

CDN, önbelleğe alınabilen statik dosyaları ağ üzerindeki uç noktalardan sunar. Seçilen nokta her zaman coğrafi olarak en yakın olan değildir. Uzak ziyaretçiler ve yoğun görsel trafiği için faydalı olabilir; gerekli olup olmadığını hedef bölgelerdeki gecikme, cache hit oranı, maliyet ve hata ölçümleri belirler.

PrestaShop’ta CDN Alan Adı (Media Server) Tanımı

Kurulu sürümünüzün Gelişmiş Parametreler > Performans ekranında media server alanını ve tema/CCC ilişkisini doğrulayın. Bir CDN alan adıyla başlayıp HTTPS ve varlık yüklenmesini test etmek yeterlidir; daha fazla alt alan adı otomatik hız artışı sağlamaz. Örnek yer tutucu:

• cdn.example.com — kendi CDN alan adınızla değiştirin.

Önce CDN tarafında origin adresini ve çekilecek statik yolları tanımlayın; sağlayıcının istediği DNS kaydını oluşturup sertifikayı doğrulayın. Ardından media server alanına bu adı girin. Yalnızca CNAME eklemek dosyaları önbelleğe almaz; origin döngüsü, 404, karma içerik ve gerekli font CORS başlıklarını test edin.

Cache-Control, HTML Cache ve Dinamik Sayfalar

CDN kullanırken statik içerik ile dinamik içerikleri birbirinden ayırmak önemli:

• İçeriğe göre sürümlenen statik dosyalar: Yeni içerik için yeni dosya adı kullanın. URL sorgu parametresi ancak CDN cache key buna dahilse işe yarar; eski tarayıcı önbelleği CDN purge işlemiyle temizlenmez.
• Değişmeyen URL’de güncellenen varlıklar: Daha kısa TTL ve ETag/Last-Modified ile yeniden doğrulama kullanın; değişiklikte CDN temizleme planını test edin.
• HTML ve API/AJAX: Varsayılan olarak bypass edin. Sepet, ödeme, hesap, yönetim, oturum/çerez kullanan ve kişiselleştirilen yanıtlar; POST işlemleri; CSRF içeren formlar; Set-Cookie, private veya no-store yanıtları için genel cache kuralı yazmayın.

CDN önbellekleme ve edge kuralları rehberi HTTP ilkelerini açıklar. WordPress/WooCommerce yol ve çerez adları PrestaShop için hazır bir bypass listesi değildir; mağazanızın gerçek isteklerini ve modüllerini esas alın.

CDN Seçerken Nelere Bakmalı?

Detaylı CDN karşılaştırmasını WordPress/WooCommerce odaklı CDN seçimi rehberinde uzun uzun anlattık; PrestaShop için de bakmanız gereken temel noktalar aynı:

• HTTP/2 ve HTTP/3 (QUIC) desteği
• Türkiye ve hedef kitlenizin bulunduğu ülkelere yakın POP noktaları
• Ücretsiz/kolay SSL entegrasyonu
• Page Rules / Edge Rules ile esnek cache politikaları

Önce origin performansını ölçün, ardından CDN’yi aynı testlerde karşılaştırın. TTFB sunucu yanıtını teşhis etmeye yardımcı olur; Core Web Vitals metriği değildir. Core Web Vitals için LCP, INP ve CLS izlenir. CDN veya sunucu ayarı bu metriklerde ya da arama sıralamasında tek başına bir sonuç garantisi vermez. Sunucu kaynaklı etkileri Core Web Vitals ve hosting rehberinde inceleyebilirsiniz.

SSL, HTTPS ve Güvenlik Ayarlarının Performansa Etkisi

PrestaShop bir e-ticaret uygulaması olduğu için SSL/HTTPS zorunlu. Güvenlik tarafını çözerken gereksiz performans kayıplarının önüne geçmek mümkün.

• Sunucunuzda TLS 1.2 ve 1.3 aktif, eski ve zayıf şifre takımları kapalı olmalı.
• HTTP/2 ve mümkünse HTTP/3 aktif edilerek, aynı bağlantı üzerinden daha fazla isteğin taşınması sağlanmalı.
• PrestaShop yapılandırmasında “SSL etkinleştir” ve “Tüm sayfalarda SSL kullan” seçenekleri işaretlenmeli.

HTTP’den HTTPS’e geçişte 301 yönlendirmeler, HSTS ve SEO etkileri hakkında daha derin bir yol haritasına ihtiyacınız varsa, HTTP’den HTTPS’e geçiş rehberimiz bu süreci planlarken iyi bir referans olacaktır.

DCHost Üzerinde Örnek Bir PrestaShop Kurulum Senaryosu

Ölçüm planını somutlaştırmak için şu varsayımsal mağazayı ele alalım:

• 5.000 ürünlü, 2 dil destekli bir PrestaShop mağazası kuruyorsunuz.
• Günlük 2–3 bin tekil ziyaretçi, kampanya dönemlerinde anlık 200 eşzamanlı oturum bekliyorsunuz.

Bu veriler tek başına kapasite seçtirmez: 200 açık oturum, aynı anda 200 PHP isteği demek değildir. Yük testine başlangıç için önceki 4 vCPU/8 GiB örneği ve şu bileşenler değerlendirilebilir:

• Uygulama: PrestaShop 9.0 ile uyumluluğu doğrulanmış PHP 8.4, web sunucusu ve OPcache.
• Veritabanı: MySQL 8.4 LTS; çekirdek ve modül şemasına uygun yapılandırma, geri yüklemesi denenmiş yedek.
• Önbellek: Smarty; ölçümle faydası doğrulanırsa uyumlu Memcached veya Redis entegrasyonu. Oturum ve görev kuyrukları ayrı değerlendirilir.
• CDN: İhtiyaç varsa statik varlıklar için; HTML başlangıçta bypass. E-posta, ödeme geri çağrıları ve modül cron görevleri ayrıca çalışır durumda olmalıdır.

Adım Adım Ayar Özeti

1. Uyumluluk ve geri dönüş: Tam PrestaShop/PHP/modül sürümlerini kaydedin; dosya ve veritabanı yedeğinin geri yüklenmesini deneyin. Staging testlerinde ödeme sandbox kullanın, gerçek müşterilere e-posta ve üretim webhook gönderimini engelleyin.
2. PHP: Gerekli uzantıları web ve CLI tarafında ayrı doğrulayın. 512M bellek, 64M dosya/80M POST örneğini form ve yükleme ihtiyaçlarına göre uyarlayın; OPcache kapasitesini durum sayaçlarıyla kontrol edin.
3. FPM ve DB: Örnek 3 GiB PHP, 3 GiB MySQL ve 2 GiB diğer hizmetler bütçesini yük altında doğrulayın. Sekiz çalışan ve 50 DB bağlantısı otomatik kapasite garantisi değildir.
4. Önbellek: Smarty dağıtım/temizleme akışını test edin. Redis varsa modül uyumluluğu, önbellek geçersizleştirme ve yalnızca yeniden üretilebilir veri için tahliye politikasını doğrulayın.
5. Görevler ve iletişim: Modül cron/worker görevlerini doğru CLI PHP, çalışma dizini, hesap ve ortamla çalışacak şekilde planlayın; çakışmayı önleyin. Sipariş e-postası, SMTP teslimatı ve ödeme geri çağrılarının sonuçlarını test edin.
6. CDN ve kabul testi: Statik varlıkların güncellendiğini; sepet, müşteri grubu, para birimi, vergi, stok, ödeme ve oturum verilerinin birbirine karışmadığını kontrol edin.
7. İzleme: Tek değişiklik yapıp yeniden ölçün. FPM kuyruğu, CPU/RAM, disk I/O, DB sorguları, hata oranı ve gerçek kullanıcı deneyimi iyileşmiyorsa nedeni bulun veya değişikliği geri alın.

Sonuç: PrestaShop Mağazanızı İlk Günden İtibaren Hızlı Kurmak

PrestaShop performansı; sürüm uyumluluğu, ölçülmüş kaynak bütçesi, doğru sorgular ve uygulamanın davranışına uygun önbellek kurallarıyla yönetilir. Ürün sayısından paket seçmek veya bir my.cnf parçasını doğrudan kopyalamak yerine her katmanı mağazanızın gerçek iş yükünde doğrulayın.

DCHost hosting, VPS veya dedicated seçeneklerini karşılaştırırken PHP/veritabanı desteği, cron ve e-posta gereksinimleri, yedeklerin geri yüklenmesi ve sunucu yönetim kapsamını netleştirin. Mevcut mağazada önce TTFB, ağır sorgular ve kaynak sınırlarını kaydedin; ardından bu rehberdeki adımları tek tek test ederek uygulayın.