Crucial Core Web Vitals Fixes for Large PrestaShop Catalogs

A large PrestaShop catalog can put serious pressure on Core Web Vitals as database queries, template rendering, and asset delivery become harder to manage. With 10,000+ products, small performance issues can quickly turn into slower pages and weaker user experiences.

In this blog post, we’ll walk through the most important fixes for improving LCP, INP, and CLS on large PrestaShop stores, from caching and image optimisation to database indexing and server-level tuning.

Why Do Large PrestaShop Catalogs Fail Core Web Vitals?

Large PrestaShop catalogs fail Core Web Vitals because database queries, template rendering, and asset delivery all scale poorly past roughly 10,000 products. This guide gives you a prioritized set of fixes: server-side caching, database indexing, image optimisation, and render-blocking resource reduction. Follow the steps in order, testing each change with PageSpeed Insights as you go.

Large catalogs fail Core Web Vitals for reasons small shops rarely encounter. When you have 10,000+ products, every category page forces MySQL to run heavy JOIN queries across multiple tables (product, product_lang, category_product, and stock_available). Without proper indexes, these queries take several hundred milliseconds before Smarty even starts rendering the template. That latency lands squarely on your LCP, because the browser waits for the server response before it can paint anything.

The rendering layer adds a second bottleneck. PrestaShop uses Smarty templates, and each template compile and cache operation consumes CPU. What takes a small shop a fraction of a second can take a 10,000-product catalog several times longer, pushing LCP past the threshold Google uses as the passing grade.

Front-end bloat compounds the problem. Large catalogs often run extra modules for filtering, faceted navigation, and product sliders. Each module injects its own JavaScript and CSS. The result is render-blocking resources that delay First Contentful Paint and inflate INP when users interact with category filters. PrestaShop itself ships with a performance settings page, but most store owners never touch the Smarty cache, CCC (Combine, Compress, Cache) options, or MySQL cache settings that live there.

Finally, CLS failures appear when images lack explicit dimensions. Product images loaded via JavaScript sliders or lazy-load modules without reserved space cause layout shifts as the page settles. On a category page showing many products, one un-dimensioned image can trigger repeated shifts that fail CLS and annoy shoppers enough to bounce.

The fixes that matter most for large catalogs are structural changes to how PrestaShop queries the database, caches rendered templates, and delivers assets. The rest of this guide walks through each fix in priority order, starting with the database layer where most of your time is actually lost.

What You'll Need

Before you start, confirm you have the following access and requirements in place. Missing any of these will block specific steps later in the guide.

• Back office admin access: You need full administrator permissions in PrestaShop to change performance settings under Advanced Parameters.
• PrestaShop 1.7 or 8.x: All settings referenced in this guide exist in these versions. Older versions may lack the CCC or caching options described.
• FTP or file manager access: Required for template edits (header.tpl, product.tpl) and for uploading an .htaccess file if you configure Apache optimisation.
• phpMyAdmin or equivalent: Needed to inspect indexes and run the SQL commands for database optimisation.
• Staging environment: Strongly recommended for testing CCC and template changes before pushing to production.
• Estimated time: 8-12 hours: Most of this time goes to testing after each change and auditing modules, not to the configuration itself.
• Difficulty: Intermediate to advanced: Comfort with PHP, MySQL, and template files is assumed for the server-level fixes.

Prerequisites

These prerequisites are the minimum you need before attempting the fixes in this guide. Skipping them risks breaking your store or wasting hours on changes that do not stick.

• Admin access level: Super admin credentials for the PrestaShop back office, not a limited employee account.
• Plugin and version: PrestaShop 1.7.x or 8.x with the default performance module intact. Do not use a third-party performance plugin for these steps.
• Backup: Take a full database and file backup before changing any Performance settings, especially CCC and caching adapters.
• Estimated time: Budget 2 hours for the configuration steps and 6-10 hours for testing, module audits, and server-level changes.

Why Core Web Vitals Matter for Large PrestaShop Catalogs

Google's Core Web Vitals measure real-world loading performance: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). For stores running 10,000 products or more, these metrics are not abstract numbers. They directly influence your search rankings, your conversion rate, and whether a shopper stays on your page long enough to complete a purchase.

Large catalogs fail these metrics for predictable reasons. The database grows, queries slow down, template rendering takes longer, and the sheer volume of images and scripts overwhelms the browser. The fixes below target those precise bottlenecks, not generic advice about compressing a logo.

Why Database Size and Template Rendering Undermine Your Scores

Every request in PrestaShop hits the database multiple times. On a catalog of 10,000 products, queries that scan entire tables instead of using indexes can add hundreds of milliseconds to every page load. That latency lands directly on your LCP score, because the server cannot send the HTML until the database responds.

Template rendering is the second bottleneck. PrestaShop's Smarty templates compile on every request unless caching is enabled properly. With hundreds of product combinations and category pages, the rendering engine has to process more template files, more hooks, and more block assignments. Each unoptimised template adds measurable time to the critical rendering path.

The fixes below give you a clear priority order. You will address the database layer first, because that is where large catalogs lose the most time. Then you will tackle template rendering, followed by asset delivery through a CDN.

Quick Answer

To fix Core Web Vitals on a large PrestaShop catalog, you need to enable Smarty cache, optimise database queries with indexing, merge and minify assets, enable lazy loading for images, and serve static content through a CDN. This guide walks through each fix step by step, in priority order.

How to Fix Core Web Vitals on a Large PrestaShop Catalog?

The following methods focus on the two most damaging bottlenecks for large catalogs: database query performance and template rendering efficiency. Method 1 covers the configuration changes and module settings. Method 2 covers the manual database and code optimisations for stores where the default settings are not enough.

Method 1: Configure PrestaShop Performance Settings and Modules

Start with the built-in settings that PrestaShop provides. These are safe, well-documented, and immediately effective for most catalogs.

Step 1: Enable Smarty Cache and Set Cache Levels Correctly

Smarty is PrestaShop's template engine. Without proper caching, it recompiles every template on every page view. Navigate to Advanced Parameters -> Performance -> Smarty.

• Template compilation: Set this to "Never recompile template files." This tells Smarty to use the compiled version unless you manually force a refresh.
• Cache: Set this to "Yes." This enables the Smarty cache, which stores the fully rendered HTML blocks.
• Cache lifetime: Set this to a reasonable value such as 86400 seconds (24 hours) for most catalogs. For frequent inventory updates, a shorter lifetime such as 3600 seconds may be better.

You should now see significantly faster page generation times because Smarty stops recompiling templates on every request.

Step 2: Enable CCC (Combine, Compress, Cache) for CSS and JavaScript

PrestaShop can combine multiple CSS and JavaScript files into single files, then compress and cache them. This reduces the number of HTTP requests, which directly improves LCP and INP. Navigate to Advanced Parameters -> Performance -> CCC.

• Combine JavaScript files: Enable this to merge all JavaScript into one file.
• Compress JavaScript files: Enable this to minify the JavaScript.
• Move JavaScript to the end: Enable this to defer JavaScript loading until after the HTML is parsed.
• Combine CSS files: Enable this to merge all CSS into one file.
• Compress CSS files: Enable this to minify the CSS.

You should now see a reduced number of asset requests in your browser's developer tools, often from dozens down to a few.

Step 3: Enable Caching for the Backend and Use a Cache Adapter

Server-side caching stores database query results and rendered pages, so repeated requests do not hit the database again. Navigate to Advanced Parameters -> Performance -> Caching.

• Use cache: Set this to "Yes."
• Caching system: Choose a fast adapter. For most shared hosting, the file-based cache works. For VPS or dedicated servers, you can select Memcached or APC if these extensions are installed.
• Cache lifetime: Set this to a value that matches your store's update frequency. A product-heavy catalog with frequent price updates may need a shorter lifetime, such as 900 seconds.

You should now see a sharp reduction in database queries on repeated page views.

Step 4: Configure Image Quality and Use WebP Formats

Images are typically the largest element on a product page, making them the primary LCP candidate. PrestaShop can serve images in modern formats and optimised sizes, but only if you configure the image settings correctly. Navigate to Preferences -> Images.

• Image format: Enable WebP if your PrestaShop version supports it. This format delivers smaller files at the same quality as JPEG or PNG.
• Image quality: Lower the JPEG quality to around 80% for product photos. This cuts file size significantly without visible quality loss on most screens.
• Regenerate thumbnails: After changing any image setting, click this button to rebuild all cached image sizes. Skip this and shoppers will keep receiving old, larger files.

You should now see smaller image payloads across product and category pages, which directly improves LCP for the hero image and INP for gallery interactions. For stores that need more granular control over image delivery, the PrestaShop Plugins marketplace offers dedicated image optimisation modules that automate WebP conversion and compression across existing product catalogs.

Step 5: Configure Lazy Loading and Preload for Key Images

Lazy loading defers off-screen images, while preload fetches the LCP image before other resources block it. Both settings matter on large catalogs where category pages show dozens of product thumbnails. Navigate to Advanced Parameters -> Performance and check your theme's image handling.

• Native lazy loading: Confirm your theme applies loading="lazy" to images below the fold. PrestaShop 8 includes this by default, but many custom themes omit it.
• Preload LCP image: Add a preload hint for the hero image in your theme's header.tpl file. This tells the browser to fetch the image immediately, before stylesheets and scripts.
• Explicit dimensions: Ensure every tag carries width and height attributes. This prevents layout shift and lets the browser reserve space before the image arrives.

You should now see LCP improve because the hero image loads first, and CLS stabilise because every image has reserved space in the layout.

Method 2: Manual Database and Template Optimisation

When the built-in settings are not enough, the bottleneck lives in your database queries or your template code. These manual fixes go deeper and require careful testing on a staging environment.

Step 1: Add Composite Indexes to Key Tables

Category pages run JOIN queries across multiple tables, and without the right indexes, MySQL scans entire tables. Adding composite indexes on the columns used in those JOINs cuts query time dramatically. Open phpMyAdmin and run the following SQL statement on your database.

CREATE INDEX idx_category_product ON ps_category_product (id_category, id_product, position);

This index covers the three columns most frequently used in category listing queries. Run EXPLAIN on your slowest category query before and after to confirm the index is being used. You should now see category pages respond faster because the database no longer scans the entire ps_category_product table.

Step 2: Audit and Defer Heavy JavaScript Modules

Every module you have installed injects its own scripts, and many load on every page regardless of whether they are needed. Navigate to Modules -> Module Manager and review each third-party module's settings.

• Restrict module output: Many modules let you limit their scripts to specific controllers, such as only product pages or only category pages. Use this to remove scripts from pages where they serve no purpose.
• Defer non-critical scripts: For modules that must run on every page, check if they offer a defer or async option in their settings. If not, consider whether the module is worth the INP cost.
• Remove unused modules: If a module is disabled but still present, its files may still load. Uninstall modules you no longer use rather than just disabling them.

You should now see a reduction in total JavaScript shipped on ordinary pages, which directly improves INP because the main thread has fewer scripts competing for attention. For stores that need to keep several modules active, the PrestaShop Plugins marketplace offers performance-focused modules that can defer third-party scripts globally.

Step 3: Fix CLS by Reserving Space for All Page Elements

Cumulative Layout Shift happens when the browser loads content after the initial paint and pushes existing elements down. On product pages, the biggest offenders are image sliders, category banners, and asynchronous widgets. Open your theme's CSS file and check these elements.

• Slider containers: Give your product image slider a fixed height instead of letting it auto-size to the active slide. Use aspect-ratio: 1 for square product images to reserve the space regardless of viewport width.
• Category banners: Apply a fixed height or aspect ratio to banner blocks on category pages. PrestaShop themes often render these without dimensions, causing a shift when the image downloads.
• Asynchronous widgets: Cross-sell blocks, recently-viewed modules, and cookie consent banners load after the page renders. Wrap each in a container with a fixed min-height so they do not displace the layout.

You should now see CLS drop on your category and product pages because the browser reserves space for every element before it paints.

Measure First: How to Get a Clear Picture of Your CWV Scores

Before you change a single template or query, you need to know exactly which pages are failing and which metric is dragging them down. Guessing wastes hours on fixes that don't move the needle. Start with three free tools that cover your catalog from every angle.

Open PageSpeed Insights and test a representative page from each template type in your catalog. For a large PrestaShop store, that means your homepage, a category page, a product page, and a cart or checkout page. Load performance differs wildly between these templates, so a single test of the homepage tells you very little about the rest of the site. Record the field data (real-world CrUX measurements) alongside the lab scores so you can see the gap between what Google observes and what a fresh test shows.

Cross-reference those results with the Core Web Vitals report in Google Search Console. This report groups your URLs by metric and status, which is invaluable when you have 10,000 or more products. Look for patterns: if thousands of product URLs fail on LCP but category pages pass, the problem lives in the product template. If failures cluster on pages with layered navigation, it could be a query issue. The report tells you where to focus, but it won't tell you why, so keep it as your map while you investigate.

For deeper debugging on a single page, use the Web Vitals JavaScript library. It lets you log real CWV measurements from your own visitors' browsers, giving you the exact LCP element, CLS score, and INP timings as they happen in production. Install it temporarily on a staging branch or via your module system, collect data for a few days, and you will see precisely which page elements trigger poor scores rather than relying on estimated lab values.

Run all three tools at the same URL and compare the numbers. If lab and field data disagree sharply, your hosting or caching layer is likely the culprit, not your templates. That distinction saves you from rewriting code that was never the problem.

Step 1: Fix LCP: Optimise the Largest Contentful Paint on Product Pages

On a large PrestaShop catalog, the LCP element is almost always the hero product image. Every millisecond counts when a shopper lands directly on a product URL from Google Shopping or a social campaign, so the image loading path matters more than any other asset on the page.

Start by confirming which element Google Lighthouse flags as the LCP. Then apply these fixes in order, testing after each change with PageSpeed Insights.

1. Compress and convert the hero image. Export product photos as WebP instead of JPEG or PNG. WebP typically delivers smaller file sizes at the same visual quality. Most PrestaShop themes support WebP natively in recent versions, and if yours doesn't, use the built-in image quality settings under Preferences -> Images to lower the compression level across generated image sizes.
2. Preload the LCP image. Add a preload hint for the hero image so the browser fetches it before the stylesheet and scripts block rendering. In PrestaShop, add this via the theme's header.tpl file or through the Advanced Parameters -> Performance section if you are using the built-in header hooks.
3. Set explicit width and height attributes. When the browser knows the image dimensions ahead of time, it reserves the space in the layout. This prevents layout shift and lets the image load without reflowing the page. Every product image in your template should carry fixed dimensions, not just the hero.
4. Lazy load everything below the fold. Images below the initial viewport, such as gallery thumbnails, cross-sell products, and description photos, should load only when the user scrolls near them. PrestaShop 8 and later include native lazy loading via the loading="lazy" attribute, but check your theme actually applies it to product galleries. Many custom themes omit this on purpose.

One common trap on large catalogs: regenerating thumbnails after compression. PrestaShop caches every image combination at first request, so if you lower image quality settings, you must clear the image cache under Preferences -> Images -> Regenerate thumbnails. Otherwise, shoppers still receive the old, larger files.

Test the product page with the worst-case image, the one with the highest resolution photo in your catalog, not your smallest product. Fixing the largest file fixes every smaller one automatically.

Step 2: Reduce JavaScript Blocking for Smooth Interactions

Interaction to Next Paint (INP) measures how quickly your store responds when a shopper clicks, taps, or types. On a large PrestaShop catalog, every product page loads dozens of scripts: sliders, quick-view modules, mega menus, and analytics trackers. Each one competes for the main thread, and when that thread is busy, the browser cannot respond to your customer's click. The fix is to stop loading scripts that the shopper does not immediately need.

The biggest single win is to defer non-critical JavaScript, so it runs only after the page has rendered. Open your back office and go to Advanced Parameters -> Performance. Under the JavaScript section, you will find options for moving scripts to the bottom of the page and combining them. Enable both. These settings tell PrestaShop to load most scripts after the visible content, so the browser can paint and respond sooner.

Next, be honest about which modules you truly need. Heavy jQuery plugins for carousels, countdown timers, or animated banners often load on every page, even when the shopper only wants to see the price. Look at each third-party module's settings and disable its scripts on pages where it serves no purpose. Many modules let you restrict output to specific controllers, such as product or category only. That one decision can remove significant main-thread work on ordinary pages.

Finally, consider how your theme attaches event handlers. A common pattern is to attach a hover or scroll listener to every element in a list. On a page with many related products, that means dozens of listeners firing on every interaction. Prefer event delegation, where you attach one listener to a parent container and let it catch events from children. This is a theme-level change, usually in your template's JavaScript file, and it has a compounding effect across the whole catalog.

jQuery itself is a common culprit. If your theme uses jQuery for simple tasks that vanilla JavaScript can handle, replacing those handlers removes a large library from the critical path entirely. This is a longer project, but for stores with 10k+ products, the payoff in INP is significant.

The pattern is simple: defer what you can, remove what you do not need, and attach handlers efficiently. Start with PrestaShop's built-in performance settings, then audit your modules, and finally look at your theme's event handling.

Step 3: Eliminate Layout Shifts on Category and Product Pages

On a large PrestaShop catalog, Cumulative Layout Shift (CLS) usually comes from the same handful of culprits: category banner images that load after the text, product image sliders that change height as thumbnails populate, and JavaScript that injects content after the initial paint. When your templates are rendered for 10,000+ product combinations, these shifts compound and drag down your CLS score across the whole site.

The fix is to reserve space before the browser finishes loading. Start with your image containers. In your theme’s CSS, give every tag an explicit width and height attribute, or use the aspect-ratio property. Do this for category thumbnails, product cover images, and especially the large banner blocks on your category pages. PrestaShop themes often render these banners without fixed dimensions, which forces a shift when the image finally downloads.

For product image sliders, set a fixed height on the slider container rather than letting it auto-size to the active slide. This matters on mobile where the slider is the largest element on the page. A common pattern is to apply a fixed height in your theme’s product.tpl template, then use object-fit: cover to crop images cleanly without distortion.

Reserving space for every image is the single highest-impact CLS fix for a catalog-heavy PrestaShop store. The browser needs to know the dimensions before it paints, not after.

Next, audit anything that appends content after page load. Lazy-loaded banners, promotional strips injected by JavaScript, and cookie consent modules are frequent offenders. Move these elements into the initial HTML with reserved space, or ensure they render without pushing existing content down. Finally, check your product page for widgets that load asynchronously, such as cross-sell blocks or recently-viewed modules. Give each one a fixed min-height container so it doesn’t displace the page layout when it appears.

After you apply these changes, run an LCP, INP, and CLS test on a category page with the most images and a product page with the largest gallery. These are the templates where CLS hits hardest in large catalogs.

How to Leverage PrestaShop's Performance Settings for Big Catalogs

The Performance page in your back office (Advanced Parameters > Performance) is the first place to look when your storefront stalls on large catalogs. These settings control how PrestaShop caches templates and serves static assets, and most of them are either off or set too conservatively by default. For a store with 10,000-plus products, the difference between default and tuned settings can be several hundred milliseconds on the critical rendering path.

Start by enabling Smarty cache and forcing compilation off. Smarty is the template engine that renders every page; on a large catalog, it rebuilds templates far too often if left uncached. Set Template compilation to "Never recompile template files". During development, you might use "Recompile templates if the files have been updated", but on a production store every recompile burns CPU and adds time to the first paint. Keep Cache set to "Yes" and make sure the cache system is using "File System" or a fast in-memory backend like Memcached or Redis if your host supports it.

Combine, Compress, Cache (CCC) is your second lever. It bundles your stylesheets and JavaScript files into fewer, minified requests, which is exactly what a large catalog needs when every product page ships with dozens of modules. Go to Advanced Parameters > Performance > CCC settings and enable both Combine JavaScript files and Compress JavaScript files then do the same for CSS. The "Minify" option strips whitespace and comments from each file before combining, shrinking the payload further.

Once CCC is on, hard-refresh a category page and check the Network tab in Chrome DevTools. You should see one combined CSS file and one combined JS file instead of a long list of separate requests. That single change typically shaves the biggest chunk off LCP because the browser stops fetching a dozen small files in sequence.

For very large catalogs, consider enabling Apache optimization if you run the classic setup. This setting uses Apache’s mod_deflate and mod_headers to compress responses and set far-future expiry headers for static resources. Combined with CCC, it means returning visitors fetch almost nothing from the network on repeat visits, which keeps LCP stable even when your product feed grows.

You should now see a noticeable drop in the number of network requests and a faster time to interactive on product pages, especially for visitors who have visited another part of your store before.

Advanced Server-Level Fixes: Database and Hosting Tuning Every Large Store Needs

With a catalog of 10,000 or more products, your database is the bottleneck long before your front-end assets are. Every category page triggers multiple SQL queries, and unoptimised indexes turn a fast query into a slow one. On a busy day, that compounds across every visitor and every request. Fixing this layer is where the biggest Core Web Vitals wins hide for large PrestaShop stores.

Start with MySQL query optimisation. Use the Slow Query Log in your hosting control panel or via phpMyAdmin to identify queries taking longer than one second. The most common offenders in large catalogs are category listing queries and attribute combination lookups. Add composite indexes on the id_category, id_product, and position columns in the ps_category_product table. This single change frequently cuts category page load times because the database can satisfy the query without scanning the entire table. Also check that your MySQL buffer pool size is set to a substantial portion of available RAM when you are using InnoDB, which is the default storage engine for modern PrestaShop installations.

PHP OPcache is the next lever. It stores compiled PHP scripts in memory, so PrestaShop does not recompile the same files on every request. Enable it in your PHP settings (usually opcache.enable=1), set the memory limit to 128MB or higher, and configure opcache.validate_timestamps=0 in production so file checks do not slow things down. You should see a noticeable drop in Time to First Byte (TTFB) after this takes effect, because the server spends less time parsing the many PHP files that make up a full PrestaShop installation.

A Content Delivery Network (CDN) handles the static side of the equation. For large catalogs, the value is twofold: it serves product images from edge locations close to the visitor, and it absorbs traffic spikes during sales or flash promotions. PrestaShop works well with Cloudflare and similar providers, and you can configure the CDN URL in Preferences -> Performance under the "CDN" section. This shifts image delivery off your origin server entirely, which frees server resources for the dynamic database queries that matter most.

When you engage your hosting provider, come prepared with specific questions rather than vague requests for "more speed". Use this checklist to guide the conversation:

• MySQL version: Are you running a recent version that includes optimiser improvements for complex JOIN queries?
• Buffer pool allocation: What percentage of available RAM is dedicated to the InnoDB buffer pool? Ask for a substantial allocation.
• OPcache: Is OPcache enabled with a 128MB or larger memory limit and timestamps validation disabled?
• SSD storage: Are the database and web root on NVMe SSD, not spinning disks? Disk I/O directly affects query response time.
• PHP worker count: How many PHP-FPM workers are configured, and what is the current average worker utilisation during peak hours?
• CDN integration: Does the hosting plan include or support a CDN that integrates with PrestaShop's built-in CDN settings?
• Staging environment: Is there a staging environment where you can test these changes without risking the live catalog?
• Backup frequency: How often are automated backups taken, and what is the restore time for a database of your size?

These server-level changes work together. Database tuning reduces the time spent generating the page, OPcache reduces the time spent bootstrapping PHP, and the CDN reduces the time spent transferring bytes. Address all three, and you will see LCP and INP scores improve in tandem, not just one metric at the expense of another.

The single highest-impact question to ask your host is about InnoDB buffer pool allocation and whether your database fits comfortably in memory. If it does not, no amount of code optimisation will get you green Core Web Vitals scores at peak traffic.

For stores on shared hosting, these settings are often locked down and unchangeable. That is the clearest signal that a move to a managed VPS or dedicated server is necessary, because the database layer of a 10,000-product catalog simply cannot perform well on infrastructure shared with dozens of other tenants.

Conclusion

Improving Core Web Vitals on a large PrestaShop catalog is not about applying one quick fix. Start with caching and image optimisation, then reduce JavaScript, eliminate layout shifts, and optimise the database and hosting environment. Test each change with real performance data so you can focus on the fixes that deliver measurable improvements.