When PrestaShop Combinations Kill Performance: Limits and Workarounds

When PrestaShop Combinations Kill Performance: Limits and Workarounds

PrestaShop's combination system allows you to create product variants - different sizes, colors, materials, and other attributes. It works perfectly for products with a handful of variants. But when products have hundreds or thousands of combinations, performance degrades dramatically. Product pages take 10-30 seconds to load, the back office becomes unusable, and category listing pages crawl. This guide explains exactly why combinations cause performance problems, where the practical limits are, and what you can do about it.

Why Combinations Cause Performance Problems

Database Architecture

PrestaShop stores combination data across multiple tables:

• ps_product_attribute - One row per combination (e.g., Red-XL, Red-L, Blue-XL, Blue-L = 4 rows)
• ps_product_attribute_combination - Links each combination to its attribute values
• ps_product_attribute_shop - Per-shop combination data (multistore)
• ps_stock_available - Stock level for each combination
• ps_specific_price - Price overrides per combination
• ps_product_attribute_image - Image assignments per combination

A product with 5 sizes and 10 colors creates 50 combinations. That means 50 rows in ps_product_attribute, 100 rows in ps_product_attribute_combination (2 attributes per combination), 50 rows in ps_stock_available, and potentially 50+ rows in ps_specific_price if you have custom pricing.

A product with 3 attributes (size: 10 options, color: 15 options, material: 4 options) creates 10 x 15 x 4 = 600 combinations. The database rows multiply accordingly.

The Exponential Growth Problem

With 6,000 combinations per product and 100 such products, you are looking at 4.2 million database rows just for combination data. This is where performance falls off a cliff.

Front Office Performance Impact

When a customer visits a product page with many combinations, PrestaShop must:

1. Query all combinations from the database
2. Calculate the price for each combination (applying tax rules, specific prices, group prices, cart rules)
3. Check stock availability for each combination
4. Generate the JSON data structure that powers the attribute selector
5. Render the HTML for the attribute dropdowns or swatches

For a product with 1,000+ combinations, this process can take 5-30 seconds depending on server hardware.

Back Office Performance Impact

Editing a product with many combinations in the back office is often even worse than the front office. The combination tab loads all combinations at once, and saving changes triggers updates across multiple tables for every combination.

Practical Limits

These numbers assume a typical shared hosting environment. Dedicated servers with SSD storage, OPcache, and proper MySQL tuning can push the limits higher, but the underlying architecture still degrades linearly with combination count.

Workaround 1 - Restructure Your Product Catalog

The most effective solution is to reduce the number of combinations per product by restructuring how you organize products.

Split Products by Key Attribute

Instead of one product "T-Shirt" with combinations for every color and size, create separate products for each color:

• "T-Shirt - Red" (sizes: S, M, L, XL, XXL = 5 combinations)
• "T-Shirt - Blue" (sizes: S, M, L, XL, XXL = 5 combinations)
• "T-Shirt - Black" (sizes: S, M, L, XL, XXL = 5 combinations)

Instead of 1 product with 50 combinations (10 colors x 5 sizes), you have 10 products with 5 combinations each. The front office is fast, the back office is manageable, and you get better SEO because each color has its own indexed page.

Use PrestaShop's Product Pack Feature

For products that are genuinely different items sold together (like a furniture set with configurable pieces), consider using product packs instead of combinations.

Workaround 2 - Database and Server Optimization

Add Database Indexes

PrestaShop's default indexes may not be optimal for stores with many combinations. Add these indexes:

ALTER TABLE ps_product_attribute 
  ADD INDEX idx_product_default (id_product, default_on);

ALTER TABLE ps_product_attribute_combination 
  ADD INDEX idx_attribute (id_attribute);

ALTER TABLE ps_stock_available 
  ADD INDEX idx_product_attribute (id_product, id_product_attribute);

ALTER TABLE ps_specific_price 
  ADD INDEX idx_product_combo (id_product, id_product_attribute, id_shop);

MySQL Configuration Tuning

# my.cnf optimizations for combination-heavy stores
innodb_buffer_pool_size = 2G  # Adjust based on available RAM
innodb_log_file_size = 256M
query_cache_type = 1
query_cache_size = 128M
query_cache_limit = 4M
join_buffer_size = 4M
sort_buffer_size = 4M
tmp_table_size = 256M
max_heap_table_size = 256M

Enable OPcache

opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 16229
opcache.revalidate_freq = 60

Workaround 3 - Lazy Loading Combinations

Instead of loading all combinations on page load, implement lazy loading that fetches combination data only when the customer selects an attribute. This requires custom module development or a module that overrides the default behavior.

The approach works like this:

1. On initial page load, show only the first attribute group (e.g., Color)
2. When the customer selects a color, make an AJAX request to fetch the available sizes for that color
3. When the customer selects a size, fetch the price, stock, and image for that specific combination

This reduces the initial page load from loading all 1,000 combinations to loading only the first attribute group (perhaps 10-15 items), then incrementally loading data as needed.

Workaround 4 - Caching Strategies

Full Page Cache

Implement a full-page cache (Varnish, LiteSpeed Cache, or Nginx FastCGI Cache) for product pages. The first visitor triggers the slow combination load, but subsequent visitors get the cached version instantly. Limitations:

• Cart-specific information (logged-in customer prices, group prices) complicates caching
• Pages with customer-specific content cannot be fully cached
• Cache invalidation when prices or stock change

Redis or Memcached for Object Caching

Configure PrestaShop to use Redis or Memcached instead of file-based caching:

# In config/defines.inc.php or via Back Office
# Advanced Parameters > Performance > Caching
# Select Memcached or Redis as cache type

Workaround 5 - Custom Combination Loading with Override

For developers, you can override the combination loading logic to paginate results or pre-compute combination data:

// Pre-compute combination data into a JSON file
// Run this via cron whenever products are updated
$products = Product::getProducts($id_lang, 0, 0, 'id_product', 'ASC');

foreach ($products as $product) {
    $combinations = $product['id_product'];
    $combData = Product::getProductProperties($id_lang, $product);
    
    // Save to a JSON file per product
    file_put_contents(
        _PS_MODULE_DIR_ . 'yourcache/product_' . $product['id_product'] . '.json',
        json_encode($combData)
    );
}

When to Avoid Combinations Entirely

Some use cases are fundamentally incompatible with PrestaShop's combination system:

• Configurable products with 4+ attributes and 10+ values each - Use a product configurator module instead
• Products with unique serial numbers - Use a stock management module with serial tracking
• Dimensional products (custom width x height x depth) - Use a custom dimensions module that calculates price on-the-fly
• Print-on-demand products with customer uploads - Use a product designer module

Monitoring Combination Performance

Use PrestaShop's built-in profiling to identify combination-related bottlenecks:

// In config/defines.inc.php
define('_PS_DEBUG_PROFILING_', true);

This adds a profiling bar at the bottom of every page showing SQL query count, execution time, and memory usage. Look for:

• Pages with 500+ SQL queries (normal is 50-150)
• Single queries taking more than 100ms
• Total page generation time above 3 seconds

Summary of Recommendations

For more details, read our guides: Product Combinations and Variants: When Your Store Needs Them and What Actually Makes PrestaShop Slow: Database, Modules and Hosting.