PrestaShop Hosting: PHP, MySQL, Cache and CDN Settings

PrestaShop hosting needs a compatible software stack, enough capacity for dynamic requests and caching that preserves cart and checkout correctness. Themes, modules, queries and image delivery all affect performance. This guide explains how to assess shared hosting, a VPS, a dedicated server or colocation, then tune PHP, MySQL and caching against measurements. The examples target PHP 8.4 with PrestaShop 9.0 and MySQL 8.4 LTS; verify your exact patch release and modules before adapting them.

What PrestaShop Really Needs From Your Hosting

Before touching config files, it helps to understand what actually makes PrestaShop feel fast. PrestaShop is a classic LAMP/LEMP style PHP application with a heavy reliance on the database. That means your store’s speed depends primarily on four layers:

• PHP: Supported version, handler such as PHP-FPM, required extensions, OPcache and process limits.
• Database: Compatible MySQL/MariaDB release, schema, queries and a measured memory budget.
• Caching: Smarty, optional compatible object-cache integration and carefully scoped HTTP caching.
• CDN: Optional static-asset delivery, measured in the regions your visitors use.

Hardware and plan size still matter, but many stores run badly on powerful servers simply because the software stack is not tuned. If you are unsure about how much CPU, RAM and bandwidth to start with, we strongly recommend reading our capacity planning article how much CPU, RAM and bandwidth a new website needs and then mapping those ideas to your expected PrestaShop traffic.

First record the slow pages and failed requests. Match each change to a measured bottleneck so that additional caching or hardware does not hide a module or query problem.

PHP Settings for a Fast PrestaShop Store

Recommended PHP Version and Extensions

Use the PrestaShop PHP compatibility chart together with the PHP support calendar. The chart supports PHP 8.1–8.4 for PrestaShop 9.0 and recommends 8.4; for PrestaShop 9.1 it supports PHP 8.1–8.5 and recommends 8.5. Compatibility does not mean every PHP release in that range still receives security fixes. These examples use the 9.0/PHP 8.4 combination. Older 1.6, 1.7 and 8.x stores need their own exact-release matrix and an upgrade plan.

Why it matters:

• A compatible PHP upgrade may improve performance; measure the change with your store’s code and workload
• Stricter type handling and error reporting can expose compatibility issues during staging tests
• Choose a compatible version that is still receiving security fixes

The PrestaShop 9 requirements and the 9.0.0 core package definition include these extensions. Some are built into PHP and may not appear as separate panel switches:

• PDO and pdo_mysql for database access.
• curl, dom, fileinfo, iconv, intl, json, mbstring, openssl, simplexml and zip.
• gd is required for image thumbnail generation. Installing Imagick does not replace GD; an individual module may additionally require Imagick.
• Check module-specific requirements such as SOAP, and verify the documented allow_url_fopen=On setting.

Check the actual web PHP runtime and the CLI runtime separately. A hosting panel may expose version and extension controls, depending on the plan. On a self-managed server, install the matching packages and configure the active PHP handler; an extension installed for another PHP version does not satisfy the store’s requirements.

If you are planning a PHP upgrade, our detailed article PHP 8.x upgrade checklist (although focused on WordPress/Laravel) covers the same upgrade mindset you should use for PrestaShop: staging first, logs, OPcache, FPM pools.

PHP‑FPM and Process Manager Settings

PHP‑FPM is one option for serving a PrestaShop store. Its pool settings let you limit worker processes and simultaneous requests. Poorly sized pools can contribute to slow responses or gateway errors; the appropriate settings depend on workload and available resources.

Key PHP‑FPM directives (per pool) to review:

• pm: dynamic keeps spare workers ready; ondemand starts them as needed. Choose based on traffic and startup cost.
• pm.max_children: Maximum simultaneous PHP requests handled by the pool, not concurrent visitors.
• pm.start_servers, pm.min_spare_servers, pm.max_spare_servers: Initial and idle-worker counts for dynamic mode.
• pm.max_requests: Requests served before worker recycling; this does not repair a memory leak in a module.

Consider a hypothetical 4 vCPU/8 GiB Linux host with a 3 GiB PHP budget, a 3 GiB total MySQL budget and 2 GiB for the OS, web server, shared OPcache, monitoring and any optional Redis service. If a busy worker is measured at about 300 MiB, eight workers use about 2.4 GiB, leaving PHP headroom. This is an example measurement assumption, not a guaranteed store capacity. Replace the prestashop application user/group and www-data web-server group with existing service accounts, verify file/socket-directory permissions, and point the web server’s FastCGI configuration to the matching socket:

[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

The exact numbers depend on:

• Memory reserved for MySQL and all other services, including background jobs.
• Worker memory measured under representative busy requests, plus a safety margin; validate total FPM memory as well.
• Simultaneous dynamic requests, CPU saturation, FPM queue length, database waits and error rates during campaigns.

Divide the available PHP memory budget by measured worker consumption to estimate a ceiling, then leave headroom and load-test it. A script’s memory_limit is not preallocated worker memory or a complete process-memory measurement. Raising pm.max_children when CPU or MySQL is already saturated can make response times worse.

OPcache: Recommended for PrestaShop Performance

OPcache retains compiled PHP bytecode so requests can avoid repeated compilation. Confirm it is enabled for the web runtime and measure its memory and key capacity, including other sites sharing the same OPcache instance.

Core OPcache settings for PrestaShop could be:

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

Notes:

• Capacity: Use a restricted diagnostic in the web PHP runtime to inspect opcache_get_status(false). Compare memory_usage.free_memory and wasted_memory with opcache_statistics.num_cached_keys/max_cached_keys, oom_restarts and hash_restarts. cache_full alone does not distinguish exhausted memory from key capacity.
• Example values: 256 MiB memory, a 16 MiB interned-string buffer and a requested 20,000-file capacity require measurement; PHP selects an actual supported hash capacity. A CLI status check does not represent FPM’s OPcache, and the diagnostic must not be public.
• Deployments: validate_timestamps=1 with revalidate_freq=2 checks timestamps at a two-second interval. Coordinate immediate code changes with controlled web-runtime cache renewal. Disable timestamp validation only if the deployment reliably resets/restarts the relevant web PHP cache; a separate CLI reset is insufficient.

PHP.ini Limits for PrestaShop

Large forms, image processing and imports need compatible PHP, application and request-body limits. Increasing a timeout cannot fix a slow query or a failing module; investigate those failures first.

PrestaShop 9 documentation recommends at least memory_limit=512M. The following PHP 8.4 limits are an illustrative starting point; adapt them to your actual upload and form requirements:

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

The PHP manual requires post_max_size to exceed upload_max_filesize. The example allows a 64 MiB single file within an 80 MiB total POST body; multiple files, form fields and multipart overhead share that total. Match web-server, proxy/CDN and application limits too. PHP’s 120-second execution setting does not change FPM/proxy timeouts or provide a universal wall-clock deadline. Use supported CLI/batch jobs for lengthy imports. .user.ini is directory-level configuration for CGI/FastCGI, not an FPM pool file, and cannot change every system directive. For realpath caching, realpath_cache_size=4096K matches the modern 4 MiB default; a realpath_cache_ttl=600 example needs deployment testing. open_basedir disables that cache; do not remove an isolation restriction solely for speed.

MySQL/MariaDB Configuration for PrestaShop

PrestaShop is very database‑centric: category filters, layered navigation, search, cart, checkout and statistics constantly hit MySQL/MariaDB. Even a well‑tuned PHP stack feels slow if the database is struggling.

Our WooCommerce MySQL/InnoDB tuning checklist provides useful measurement principles. PrestaShop has its own schema and module queries, so its indexes and cache rules must be assessed separately.

Engine, Charset and Collation

Use a supported database release that matches your exact PrestaShop installation and modules. The example below targets MySQL 8.4 LTS. Minimum versions listed by an application are compatibility floors, not a recommendation to deploy an old database release.

• Storage engine: Follow the core and module schema; assess legacy MyISAM tables before planning an InnoDB conversion.
• Charset: utf8mb4 supports Unicode storage, but connection, table and column settings must agree.
• Collation: Check comparison and sorting behavior against the application. For example, utf8mb4_unicode_ci is a compatibility choice to test, not a Google ranking setting. Changing server defaults does not convert existing tables.

Back up and test restoration before schema changes. Validate any storage-engine or collation conversion on staging, including indexes, module compatibility, disk space and locking behavior; do not issue a blanket conversion against the live store.

Key MySQL/InnoDB Settings

On the hypothetical shared 8 GiB host, reserve 3 GiB for total MySQL use, with 2 GiB assigned to the buffer pool and the rest available for connections, temporary tables and other overhead. Merge this MySQL 8.4 LTS example into the existing [mysqld] section. Fifty connections is a load-test assumption; include PHP, cron, CLI and integrations in the count. The slow-log directory must exist, be writable by MySQL and have restricted access:

[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

What these do for PrestaShop:

• innodb_buffer_pool_size: Table/index cache is only part of MySQL memory. Verify total usage with busy connections; reduce limits or revise the host budget if it exceeds the reserved 3 GiB.
• Redo and durability: MySQL 8.4 uses innodb_redo_log_capacity. Keep innodb_flush_log_at_trx_commit=1; setting it to 2 can lose committed transactions in a crash. sync_binlog=1 controls binary-log synchronization when that log is enabled. Neither replaces tested backups.
• Version-specific directives: Do not add removed query_cache_type or query_cache_size settings to MySQL 8.4. Do not copy a universal innodb_buffer_pool_instances or O_DIRECT recommendation across versions and operating systems. MariaDB needs its own matching configuration.
• Temporary tables: Do not blindly raise tmp_table_size and max_heap_table_size to 256M. In MySQL 8.4 the TempTable per-table limit and global temptable_max_ram budget are distinct. The example caps the shared TempTable budget at 256 MiB and each internal table at 16 MiB, with a 16 MiB MEMORY-table limit too. Thread-local allocations are outside the shared budget, and connections and other workspaces consume additional memory. Extra in-memory capacity can increase memory pressure.
• Slow queries: A one-second threshold is a diagnostic example. Protect logs, rotate them and review frequently repeated expensive queries; logging alone does not optimize them.

Indexes and Slow Query Analysis

Even with good my.cnf values, missing or suboptimal indexes can kill performance—especially on modules that add their own tables. Use slow query logs and tools like EXPLAIN to identify queries that scan entire tables.

Practical workflow:

1. Record a baseline using representative staging data and a restorable backup.
2. Enable a bounded slow-query log and simulate category browsing, filters, search, cart and checkout using test accounts and payment sandbox mode.
3. Inspect repeated expensive queries and their execution plans with EXPLAIN.
4. Test an appropriate index or query change on staging; consider write overhead, module upgrades and locking as well as read speed.
5. Repeat the same workload and plan a controlled production change with rollback only after correctness and performance pass.

A quiet traffic period does not replace staging or a rollback plan. Prevent staging from sending real customer email, production webhooks or live payment transactions. Avoid copying customer data into an unnecessarily exposed test environment.

Caching Layers for PrestaShop: From Simple to Advanced

Treat caching as separate layers with separate invalidation rules. Start with the work you can safely reuse, and compare hit rate, latency and correctness before keeping a change:

• Smarty template compilation and application caches.
• Optional object cache through a compatible Memcached or Redis integration.
• HTTP page caching only for explicitly audited public responses.
• Browser/CDN caches for static assets with a reliable update strategy.

PrestaShop’s Built‑In Caching Options

Inside the back office, PrestaShop offers basic caching options under Advanced Parameters → Performance. At minimum, you should:

• Enable Smarty caching after checking theme and module behavior.
• Use recompile when files change to detect edits. “Never recompile” requires an explicit Smarty cache-clear step in theme deployments.
• Test CCC CSS/JS options individually; verify product variations, menus and checkout scripts after changes.

Smarty’s file cache, PHP OPcache and CDN asset caches have different lifecycles. Coordinate their refresh steps during deployment. These settings do not make personalized HTML safe for shared page caching.

Object Cache with Redis or Memcached

An object cache can reuse application data that an integration explicitly stores and invalidates. PrestaShop 9.0 includes Memcache/Memcached adapters; the selected adapter needs its matching PHP extension and service. Redis requires a compatible module or other integration for your exact release. Installing Redis alone does not redirect Smarty, sessions or all database queries into it.

Which one should you choose?

• Memcached: Suitable for reconstructible cached values when the chosen adapter is compatible and measured results justify it.
• Redis: An option when a supported integration provides the cache operations, TTLs and invalidation you need. Its additional features do not guarantee better store performance.

A local Redis service avoids an extra network hop; a remote service adds latency that must be measured. Limit access through a private network or local socket and configure authentication/TLS where appropriate. Budget maxmemory together with overhead and persistence/replication buffers. Use allkeys-lru only for a cache instance containing reconstructible values. Keep sessions, queues and critical records in a separately managed instance; a different logical Redis database does not isolate eviction. Persistence does not undo an evicted key.

If you want a deeper dive into how Redis behaves as an object cache (TTL, eviction policies, persistence strategies), our article Redis vs Memcached for WordPress/WooCommerce gives you a mental model that also applies nicely to PrestaShop.

Full‑Page Caching: Reverse Proxy, Microcaching and Edge Cache

Full-page caches can serve reusable HTML without invoking PHP. PrestaShop pages may vary by cart, customer group, currency, tax rules, language or session even for visitors who have not signed in. Start with HTML bypassed at the reverse proxy and CDN.

There are three common approaches:

• Varnish with application-aware cache keys, bypass and invalidation.
• Nginx FastCGI microcaching with the same correctness requirements.
• A compatible LiteSpeed/PrestaShop integration when supported by the chosen server and modules.

A 1–5 second TTL does not guarantee fresh stock, prices or cart state. Do not enable generic product/category microcaching for every anonymous visitor. Only add an HTML cache after the exact PrestaShop and module behavior has been audited and tested across all personalization and mutation paths.

The Nginx microcaching guide explains the general mechanism. Its sample rules are not a ready-made PrestaShop policy; cache keys, cookie bypasses and invalidation must match the store.

If HTML caching is justified by measurements, evaluate one explicitly public page type at a time:

• Verify that the response contains no session-specific fragment, CSRF token or personalized price/content.
• Include every representation-changing input in the cache policy and test invalidation after content, price and stock changes.
• Run cross-user and cross-currency tests with cookies and authenticated requests; keep the page bypassed if correctness cannot be demonstrated.

Always bypass cache for:

• Cart, checkout, account and back-office routes.
• POST requests, state-changing actions, authenticated/session-dependent responses and personalized content.
• AJAX/API requests and forms with CSRF tokens unless a compatible integration explicitly handles them.
• Responses with Set-Cookie, Cache-Control: private or no-store; do not override them with a generic cache rule.

CDN Settings for PrestaShop: Offload What You Can

A CDN can help with two aspects of static delivery:

• Serve cacheable assets from network edge locations selected by the CDN; the chosen node is not necessarily the geographically closest.
• Reduce origin bandwidth and static requests on cache hits. If the origin already serves a file without PHP, this does not directly remove PHP or SQL work.

If you are new to CDNs in general, our article what is a Content Delivery Network and its advantages for your website gives a solid foundation before you dive into concrete PrestaShop settings.

When Should a PrestaShop Store Add a CDN?

Measure a CDN trial when one or more of these conditions applies:

• You have international traffic (visitors far from your data center)
• Your pages contain many large images (fashion, furniture, electronics)
• You expect strong traffic peaks from campaigns or marketplaces
• Your TTFB is fine but total load time is high due to asset downloads

Local audiences may also benefit, but compare latency, cache hit rate, request/bandwidth costs and reliability. Optimize image size and formats as well; a CDN does not make oversized assets disappear.

Configuring PrestaShop to Use a CDN

PrestaShop can be configured to load static assets from a media server or CDN subdomain. The typical pattern looks like this:

• Configure an origin and the static paths to be fetched, then create a CDN hostname such as cdn.example.com using the provider’s DNS instructions.
• Verify HTTPS before enabling it in the store; a CNAME alone does not configure cache behavior.
• Check the media-server field and its CCC/theme requirements in the installed release’s Advanced Parameters → Performance screen. Start with one hostname; additional domains do not automatically improve speed.

Important details:

• Verify a valid SSL certificate, correct origin routing and no mixed-content or missing-asset errors.
• Avoid forwarding unnecessary store session cookies to a static-asset origin. Verify font CORS requirements if fonts use a different origin.
• Check product image changes and theme deployments against both browser and CDN caches. Keep HTML bypassed initially.

Choose TTLs by update strategy, not just file extension:

• Content-fingerprinted assets: Long TTLs and immutable can be appropriate because every changed file gets a new URL.
• Mutable URLs: Use shorter freshness periods and ETag/Last-Modified revalidation; test CDN purging when content changes. CDN purge does not clear a visitor’s existing browser cache.
• HTML: Keep bypassed unless a specific application-aware policy passes the tests above. A short TTL alone is insufficient.

Cache‑Control Headers from the Origin

Check the CDN’s actual origin-header and override behavior. The following Nginx example only matches filenames containing a hexadecimal content fingerprint of at least eight characters, such as theme.a1b2c3d4.css. It assumes those files really change names when their content changes and are ordinary static files under the existing document root. Merge it into the actual server configuration after reviewing location precedence and access restrictions:

# Only content-fingerprinted static files; merge into the real server block.
location ~* "\.[0-9a-f]{8,}\.(css|js|gif|jpe?g|png|webp|svg|ico|woff2?)$" {
    try_files $uri =404;
    add_header Cache-Control "public, max-age=31536000, immutable";
}

The escaped dots match literal filename dots, and try_files returns 404 for a missing file without falling back to PHP. No expires directive is combined with the explicit Cache-Control header, avoiding a second generated cache policy. On the usual Nginx inheritance rules, a location with its own add_header does not inherit parent add_header directives; include any required security headers in this location or deliberately configure version-supported inheritance. This example is not a PrestaShop default asset naming scheme. If your theme uses mutable filenames, use a suitable shorter policy instead. Query-string versioning works only if the CDN cache key includes the parameter. See Cache-Control and asset fingerprinting for the update strategy.

Picking the Right Hosting Type at dchost.com for PrestaShop

Now that we have talked about tuning, what kind of hosting should you pick for a PrestaShop store?

Shared Hosting: Good for Small or New Stores

Shared hosting can be sufficient when the plan meets the following needs:

• Exact PHP/database compatibility and required extensions, with ongoing security updates.
• CPU, memory, I/O and simultaneous-request limits that pass representative store traffic.
• Working scheduled tasks, email delivery, backups and the access needed for your modules.

Confirm these capabilities and limits for the specific DCHost plan. Catalog size or local traffic alone cannot establish suitability; document who manages updates, restores and performance tuning.

NVMe VPS: More Control for a Growing Store

A VPS can provide configuration control and more capacity when measured limits justify a move. NVMe helps workloads constrained by storage latency or I/O throughput; it does not fix CPU-heavy modules, database locks or slow external APIs.

For guidance on how to select vCPU, RAM and storage, our article choosing VPS specs for WooCommerce, Laravel and Node.js shows the same sizing logic we use for PrestaShop: start from traffic and queries, not from random plan labels.

Use a memory budget and a representative load test to compare VPS sizes. For the common 8 GiB example in this guide:

• Reserve 3 GiB for PHP, including headroom above the eight-worker/300 MiB assumption.
• Reserve 3 GiB for total MySQL use, including the 2 GiB buffer pool and variable connection/temporary-table overhead.
• Reserve 2 GiB for the OS, web server, shared OPcache, monitoring and optional Redis. If this is insufficient, lower other budgets or increase capacity; test CPU and storage limits separately.

A self-managed VPS lets you configure these services, but also makes their operation your responsibility unless management is included. Verify package compatibility, monitoring, patching, backup restoration and recovery ownership before migration.

Dedicated Server or Colocation: When PrestaShop Is Mission‑Critical

Dedicated hardware or colocation may suit measured capacity or infrastructure-control requirements. Depending on the contract and hardware, they can offer:

• Dedicated machine CPU/RAM and control over storage layout; network and upstream services can still be shared.
• Custom storage and networking options that must be confirmed for the service.
• Room to split application, database and cache services where measurements justify the added complexity.
• In colocation, responsibility for the owned hardware, spares and operating system unless separately contracted.

At that scale, you might deploy:

• One or more web servers with compatible PHP handlers and a tested deployment process.
• A database service with backups, recovery and connection limits sized for every application node.
• Compatible cache services with invalidation and session/queue storage designed separately.
• Search services or queue workers only where the installed modules require and support them.

Splitting services adds network latency and operational work. Verify shared files, session behavior, cache invalidation, payment callbacks and background jobs across nodes before assuming the single-server design will scale unchanged.

Monitoring, Testing and a Simple Optimization Workflow

Configuration is not a one‑off task. Stores evolve, modules are added, traffic patterns change. To keep your PrestaShop fast, you need a simple, repeatable workflow.

1. Baseline: Measure Before You Change

• Record server TTFB and page behavior using browser tools or WebPageTest; monitor Core Web Vitals: LCP, INP and CLS using field data where available. TTFB is a useful diagnostic, not itself a Core Web Vital.
• Test heavy categories, search, product variants, cart and checkout with realistic test accounts.
• Measure CPU/RAM, I/O, FPM queueing, database waits and error rates under a repeatable workload.

2. Apply One Change at a Time

• Change one resource limit only when measurements identify that constraint.
• Test Smarty and any compatible object-cache integration for correctness and measurable benefit.
• Trial static-asset CDN delivery with a verified deployment/purge strategy.

After each change, measure again. Do not bundle five tweaks together and then guess which one helped or hurt.

3. Keep an Eye on Logs

• PHP errors and FPM queue/worker-memory trends.
• Slow-query frequency, log size and database memory/connection pressure.
• Web-server 4xx/5xx rates, latency and static-asset cache behavior.
• Module cron/worker outcomes, SMTP delivery and payment callbacks. Use the correct CLI PHP, account, working directory and environment; prevent overlapping scheduled runs where required.

With even basic monitoring, you can catch issues early and avoid the pattern where small performance regressions accumulate until the store feels unusable.

Wrapping Up: Putting It All Together for a Fast PrestaShop

A reliable PrestaShop stack starts with compatible supported versions and a measured host budget. Tune FPM, OPcache and MySQL within that budget, then test Smarty and any optional object-cache integration. Keep sessions and critical jobs separate from evictable cache data. Add a CDN for static assets when measurements justify it, with HTML bypassed unless an application-aware policy has been validated. Repeat the same workload after each change and retain a tested rollback path.

When comparing DCHost shared hosting, VPS, dedicated and colocation options, confirm the exact software support, resource limits and management scope for the plan. Include backup restoration, scheduled jobs, SMTP and payment integration in acceptance testing. These checks turn a hosting specification into a store that behaves correctly under its real workload.