PrestaShop Hosting Guide: PHP, MySQL, Caching and CDN Settings for a Fast Store

PrestaShop can run on almost any basic hosting plan, but running it fast and stable is a different story. Sluggish category pages, slow checkout steps and random 500 errors usually have nothing to do with your theme or modules and almost everything to do with how PHP, MySQL, caching and CDN are configured on the server side. In this guide, we will walk through the exact settings we use and recommend at dchost.com when preparing hosting for a new or growing PrestaShop store. We will focus on practical, copy‑paste‑ready ideas you can apply on shared hosting, VPS, dedicated servers or colocation. If you are planning a new store, migrating from another provider or simply tired of a slow back office, this article will help you translate PrestaShop’s technical requirements into concrete hosting decisions and configurations.

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 – version, handler (PHP‑FPM), OPcache and memory limits
• MySQL/MariaDB – buffer sizes, connections and indexes
• Caching – PrestaShop’s own cache, object cache (Redis/Memcached) and optional full‑page caching
• CDN – offloading images, CSS, JS and media to edge servers

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.

Once you have the right baseline in mind, the real speed boost comes from getting PHP, MySQL, caching and the CDN to work together instead of fighting each other.

PHP Settings for a Fast PrestaShop Store

Recommended PHP Version and Extensions

PrestaShop runs on multiple PHP versions, but you should always use the latest stable PHP version supported by your specific PrestaShop release and modules. In practice this usually means a modern PHP 8.x version.

Why it matters:

• PHP 8.x can easily be 20–40% faster than older 7.x versions for the same code
• Better type handling and error reporting reduces hard‑to‑debug issues
• Newer versions receive security patches and performance improvements

Must‑have PHP extensions for PrestaShop typically include:

• pdo_mysql
• intl
• curl
• mbstring
• zip
• gd or imagick (for image manipulation)
• openssl
• json (built‑in on modern PHP)

On a cPanel or similar panel at dchost.com, you can usually pick PHP version and extensions per domain from a graphical interface. On VPS or dedicated servers, these are set via package manager and PHP‑FPM pool configuration.

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

For any serious PrestaShop store, PHP‑FPM is the right handler. It lets you control how many PHP processes are spawned and how they share memory. Poor FPM settings are a very common reason for slow stores or 502 errors.

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

• pm – use dynamic for most sites, ondemand for very small test sites
• pm.max_children – how many concurrent PHP processes you allow
• pm.start_servers, pm.min_spare_servers, pm.max_spare_servers – how many processes are pre‑warmed
• pm.max_requests – how many requests a process serves before restart (fights memory leaks)

A simple starting point for a mid‑size PrestaShop store on a 4 vCPU / 8 GB RAM VPS might look like:

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 10
pm.max_requests = 500

The exact numbers depend on:

• Available RAM and other processes (MySQL, Redis, web server)
• Average memory consumption of one PHP process (measure with top/htop)
• Peak concurrent users during campaigns or sales

Rule of thumb: each PrestaShop PHP process may use 80–200 MB depending on modules and theme. You never want to spawn so many children that the server starts swapping.

OPcache: Mandatory for PrestaShop

OPcache caches compiled PHP bytecode in RAM so scripts don’t need to be parsed and compiled on every request. Turning it off is like disabling the engine’s turbo.

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.revalidate_freq=60
opcache.validate_timestamps=1

Notes:

• opcache.memory_consumption: 128–256 MB is usually fine for one store, higher if you host many projects
• opcache.max_accelerated_files: increase if you see cache full warnings in logs
• validate_timestamps and revalidate_freq: keep automatic detection in place unless you use a deploy script that clears OPcache

PHP.ini Limits for PrestaShop

PrestaShop’s back office uses AJAX, large forms and image uploads. Too conservative PHP limits break updates or product imports.

Reasonable defaults for a production store:

• memory_limit: 512M (lower can work, but 512M avoids many headaches in back office)
• upload_max_filesize: 32M (adjust to your largest product/image files)
• post_max_size: 32M or slightly above upload_max_filesize
• max_execution_time: 120 (import/export operations sometimes need more than 30 seconds)
• max_input_vars: 3000–5000 (important if you have large forms or many attributes)

On shared hosting with dchost.com, some of these limits are editable in the control panel. On VPS, dedicated or colocation setups, you manage them via php.ini or per‑pool .user.ini files.

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.

Many of the ideas we share in our article WooCommerce MySQL/InnoDB tuning checklist translate directly to PrestaShop, because both are e‑commerce applications with similar access patterns.

Engine, Charset and Collation

For modern PrestaShop versions, you should use:

• Storage engine: InnoDB for all tables
• Charset: utf8mb4
• Collation: utf8mb4_general_ci or utf8mb4_unicode_ci

If you are migrating from an old server, ensure tables are not still using MyISAM. MyISAM prevents row‑level locks and can become a bottleneck under concurrent writes (e.g. high checkout traffic).

Key MySQL/InnoDB Settings

A sample my.cnf (or mysqld section) for a dedicated PrestaShop database on a 4–8 GB RAM server might include:

innodb_buffer_pool_size = 2G
innodb_buffer_pool_instances = 2
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 1
innodb_flush_method = O_DIRECT
max_connections = 200
query_cache_type = 0
query_cache_size = 0
tmp_table_size = 256M
max_heap_table_size = 256M
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 – most important parameter; this is where MySQL caches table and index data. Aim for 50–70% of RAM on a dedicated DB server.
• innodb_log_file_size – larger logs improve write throughput for busy stores.
• query_cache_type/size – query cache is deprecated/removed in newer MySQL versions; turning it off avoids locking issues.
• tmp_table_size / max_heap_table_size – larger temp table space reduces on‑disk temp tables for complex reports and filters.
• slow_query_log – mandatory if you care about performance; it tells you which PrestaShop queries are really slow.

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. Enable slow_query_log and set long_query_time to 1–2 seconds.
2. Simulate common store actions: browse categories, apply filters, search, add to cart, checkout.
3. Inspect slow.log and look for queries that repeat often.
4. Run EXPLAIN on them and see if proper indexes are being used.
5. Add composite indexes where appropriate (e.g. on columns used together in WHERE or ORDER BY).

Do this first in a staging environment or off‑peak hours if you are not comfortable altering tables in production.

Caching Layers for PrestaShop: From Simple to Advanced

Caching is where PrestaShop performance can jump dramatically with relatively little effort. Think of caching as multiple layers:

• Application‑level cache inside PrestaShop
• Object cache with Redis/Memcached
• Full‑page HTTP cache (reverse proxy or web server)
• CDN cache for static assets (we will cover in the next section)

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 (check the recommended option for production)
• Enable template compilation on changes only, not on every request
• Turn on CCC (Combine, Compress and Cache) for CSS and JS when your theme supports it

Smarty and CCC reduce repeated work for layout and assets. However, they do not remove database calls completely, so you still benefit a lot from deeper caching layers.

Object Cache with Redis or Memcached

Object caching stores frequently used data structures (e.g. configuration, translations, some query results) in RAM, reducing repeated SQL queries. PrestaShop supports Memcached in core and Redis via third‑party modules.

Which one should you choose?

• Memcached: simple and well supported, good for ephemeral cache.
• Redis: more features (persistence, advanced data types), usually better tooling and observability.

On a VPS or dedicated server at dchost.com, running a local Redis instance for a busy PrestaShop store is often the sweet spot. You get low‑latency RAM access and can enable basic persistence so cache does not evaporate on every restart.

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 caching means the dynamic HTML of certain pages is cached so future visitors receive the cached version without invoking PHP or the database at all. For PrestaShop, you must be careful not to cache personalized content like carts, logged‑in user pages or checkout steps.

There are three common approaches:

• Varnish in front of Apache/Nginx
• Nginx FastCGI microcaching in front of PHP‑FPM
• LiteSpeed cache if you use a LiteSpeed web server

For many stores, Nginx microcaching is a practical starting point: cache category and product pages for 1–5 seconds for anonymous users. This drastically reduces CPU spikes during traffic peaks but still keeps stock, prices and carts fresh.

We have a dedicated article explaining this concept for PHP apps: how Nginx microcaching makes PHP feel instantly faster. The examples are generic enough to adapt to PrestaShop, with the same principles: short cache TTL, precise bypass rules and cache purge when needed.

Key idea: do not try to cache everything. Focus on:

• Anonymous product and category pages
• CMS pages (FAQ, about, contact forms with CSRF exceptions)
• Home page, landing pages and blog/news area if you have one

Always bypass cache for:

• Cart and checkout
• My account area
• Any page with user‑specific content or non‑idempotent actions

CDN Settings for PrestaShop: Offload What You Can

A CDN (Content Delivery Network) does two things for your PrestaShop store:

• Serves static assets (images, CSS, JS, fonts, media) from locations physically closer to your visitors
• Shields your origin server from a large part of the traffic, especially images

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?

We usually recommend enabling a CDN when at least one of these is true:

• 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

Even small stores with local audiences benefit from less load on the origin: fewer requests, lower CPU usage and more room for growth without changing servers.

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:

• Create a subdomain such as cdn.yourstore.com and point it to your CDN.
• Configure your CDN so it pulls content from your origin (your main store domain).
• In PrestaShop back office (Advanced Parameters → Performance), set your media server / CDN domain for static assets.

Important details:

• Make sure your CDN is configured for HTTPS and has a valid SSL certificate.
• Respect cookies: serve static files from a domain that does not need PrestaShop’s session cookies when possible.
• Configure sensible cache TTL values on the CDN (e.g. 1 week or 1 month for images, shorter for CSS/JS during development).

Many CDNs support override rules based on paths and file extensions. Use these to differentiate cache times:

• Images: high TTL, maybe 30 days
• CSS, JS: medium TTL, 1–7 days (with cache‑busting / versioned filenames)
• HTML: usually bypass or very short TTL unless you know what you are doing

Cache‑Control Headers from the Origin

CDNs respect the Cache‑Control headers sent by your origin server unless you override them. Configure Apache or Nginx (or LiteSpeed) to send efficient headers:

# Example for Nginx
location ~* .(css|js|gif|jpg|jpeg|png|webp|svg|ico|woff2?)$ {
    expires 30d;
    add_header Cache-Control "public, max-age=2592000, immutable";
}

The key is to pair long TTLs with versioned filenames (e.g. style.v123.css) so you can deploy new designs without waiting for old assets to expire. For a deeper dive into browser cache‑control strategies, see our article how to stop fighting your cache with Cache-Control and asset fingerprinting which, while written with general web apps in mind, applies perfectly to PrestaShop themes.

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 is enough if:

• Your catalog is small (hundreds, not tens of thousands of products)
• Traffic is modest and mostly local
• You do not run heavy custom modules or complex integrations

On our shared hosting platforms, you still get modern PHP versions, OPcache and MySQL, but with stricter resource limits. It is a great starting point while you validate your product‑market fit.

NVMe VPS: The Sweet Spot for Growing PrestaShop Stores

As soon as you see performance issues or CPU/RAM limits on shared hosting, a VPS with NVMe storage becomes very attractive. NVMe disks drastically reduce IO wait on database and cache workloads, which is exactly what e‑commerce generates.

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.

Rough orientation for PrestaShop on NVMe VPS:

• Small store, light traffic: 2 vCPU, 4 GB RAM
• Medium store, regular campaigns: 4 vCPU, 8 GB RAM
• Large store, many modules/integrations: 8+ vCPU, 16+ GB RAM

On a VPS you can run local Redis, finely tune PHP‑FPM and MySQL, and add monitoring tools. That level of control is what lets you squeeze maximum performance per euro.

Dedicated Server or Colocation: When PrestaShop Is Mission‑Critical

For very high traffic or mission‑critical PrestaShop stores, dedicated servers or colocation at our data centers provide:

• Full control of CPU and RAM, with no noisy neighbors
• Custom storage layouts (RAID, NVMe + HDD tiers)
• Dedicated networking and firewalling options
• Room to scale to multi‑server architectures (separate DB, cache, search, queue workers)

At that scale, you might deploy:

• One or more web servers running Nginx/Apache + PHP‑FPM
• A dedicated database server with tuned MySQL/MariaDB
• One or more cache servers (Redis/Memcached, full‑page cache)
• Optional search engine nodes (Elasticsearch/OpenSearch, etc.)

The good news is that the tuning principles in this article stay the same; you just apply them to each layer separately instead of one all‑in‑one server.

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

• Use tools like WebPageTest, GTmetrix or your browser dev tools to record TTFB, time to interactive and total load time.
• Note down worst pages: heavy categories, search results, checkout.
• Record CPU/RAM usage on the server during light and heavy traffic.

2. Apply One Change at a Time

• Increase innodb_buffer_pool_size or adjust PHP‑FPM children counts.
• Enable Redis/Memcached and PrestaShop caching.
• Add a CDN for static assets.

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 error logs: look for memory errors, fatal errors from modules.
• MySQL slow query log: track queries over 1–2 seconds and optimize or cache them.
• Web server logs: monitor 4xx/5xx status codes and response times.

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

Making PrestaShop fast is less about magic tricks and more about getting the fundamentals right and aligned. Use a modern PHP 8.x version with OPcache enabled and properly tuned PHP‑FPM pools. Give MySQL or MariaDB enough RAM via innodb_buffer_pool_size, track slow queries and fix indexing where it hurts. Turn on PrestaShop’s built‑in caching, layer Redis or Memcached on top, and optionally introduce microcaching on the web server for anonymous product/category pages. Finally, let a CDN handle the heavy lifting for images, CSS and JS so your origin server can focus on generating dynamic content.

At dchost.com, we design our shared hosting, NVMe VPS, dedicated and colocation options with exactly these needs in mind, so you can start small and scale without rewriting your architecture every six months. If you are planning a new PrestaShop project or want to move an existing store to a faster and more controllable environment, our team can help you choose the right plan and apply the PHP, MySQL, caching and CDN settings outlined here in a safe, tested way. Build a store your customers enjoy using—and a hosting stack you do not have to fight with every campaign day.