PrestaShop Module Audit: Checking What Each Module Loads on Every Page

Why Module Bloat Is the Silent Killer of PrestaShop Performance

Every PrestaShop store starts fast. Then you install five modules, ten modules, thirty modules, and suddenly your homepage takes four seconds to load. The culprit is rarely one massive module. Instead, it is dozens of small modules each adding their own CSS file, their own JavaScript file, and their own database queries to every single page load. This cumulative weight is what we call module bloat, and it is the number one reason PrestaShop stores become slow over time.

The problem is that most store owners never audit what their modules actually load. They install a module for product labels, another for social sharing buttons, another for a newsletter popup, another for analytics, and each one silently registers itself on hooks like displayHeader and actionFrontControllerSetMedia. Even if a module only displays content on product pages, it may still load its CSS and JavaScript files on the homepage, category pages, cart page, and checkout. That means your customers are downloading assets they will never use on that particular page.

A proper module audit reveals exactly what each module contributes to your page weight. It tells you which modules are the heaviest offenders, which ones load assets unnecessarily, and which ones you can optimize or remove entirely. This article walks you through the complete process of auditing your PrestaShop modules for performance, using browser DevTools, PrestaShop debug mode, and systematic analysis.

Step 1: Enable PrestaShop Debug Mode and Performance Profiling

Before you open your browser tools, you need to enable PrestaShop's built-in profiling capabilities. PrestaShop has a debug mode that reveals detailed information about hook execution, module loading times, and database queries. To enable it, you need to modify two settings.

First, go to Advanced Parameters, then Performance in your back office. Set Debug Mode to Yes. This enables error reporting and additional logging that helps identify problematic modules. However, the real power comes from the profiling feature.

To enable full profiling, you need to edit the file defines.inc.php located in your PrestaShop config directory. Find the line that defines _PS_DEBUG_PROFILING_ and set it to true. In PrestaShop 1.7 and 8.x, this constant controls whether the profiling bar appears at the bottom of every front office page. Once enabled, reload any page on your store and you will see a detailed profiling panel showing execution times for every hook, every module, and every SQL query.

The profiling panel is divided into several sections. The hooks section shows you every hook that was executed on the current page, which modules are attached to each hook, and how long each module took to execute. The SQL section shows every database query, its execution time, and which module or core function triggered it. The modules section gives you a summary of total execution time per module across all hooks.

Pay special attention to the total execution time column. A well-optimized module should contribute less than 10 milliseconds to a page load. If you see a module taking 50, 100, or even 500 milliseconds, that is a serious performance problem that needs investigation.

Step 2: Using Browser DevTools to Map Module Assets

PrestaShop's built-in profiling tells you about server-side performance, but it does not show you the full picture of what happens in the browser. For that, you need your browser's Developer Tools. Open Chrome or Firefox, press F12, and navigate to the Network tab.

Reload your homepage with the Network tab open. You will see every request the browser makes: HTML, CSS files, JavaScript files, images, fonts, and AJAX calls. The goal is to identify which of these requests come from modules.

In PrestaShop, module assets follow a predictable URL pattern. CSS files from modules are typically served from paths like /modules/modulename/views/css/filename.css or /modules/modulename/css/filename.css. JavaScript files follow the same pattern with js instead of css. Use the filter bar in the Network tab to filter by "modules/" and you will instantly see every asset loaded from your installed modules.

For each module asset you find, note the following information: the file name, its size (both transferred and uncompressed), and whether it loads on the current page type. You want to build a spreadsheet or simple list that maps each module to its assets. A typical audit might reveal something like this: module A loads two CSS files totaling 45 KB and one JavaScript file of 120 KB on every page, but it only displays content on product pages. That means category pages, the homepage, and the cart are all loading 165 KB of unnecessary assets.

The Network tab also shows you the waterfall view, which reveals when each asset starts loading and how long it takes. Assets that block rendering (render-blocking CSS and synchronous JavaScript) are particularly damaging because they prevent the browser from displaying any content until they finish loading. Look for module JavaScript files that load in the head without async or defer attributes, as these are the worst offenders for perceived load time.

Step 3: Analyzing the Network Waterfall Per Module

The waterfall view in DevTools deserves its own section because it reveals performance problems that raw file sizes do not. When you look at the waterfall, you want to identify three types of problems.

First, look for render-blocking resources from modules. These appear as bars that start early in the waterfall and delay the first paint event (the vertical green or blue line). In PrestaShop, CSS files added via the displayHeader hook or through addCSS in setMedia are typically render-blocking. If a module adds a large CSS file that is only needed on specific pages, it blocks rendering on every page for no reason.

Second, look for sequential loading chains. Some modules load a JavaScript file that then triggers loading of additional resources: more JavaScript files, CSS files, web fonts, or external API calls. Each link in this chain adds latency. A module that loads jQuery UI, then a jQuery UI theme CSS, then a custom widget script, then the widget's CSS creates a chain of four sequential requests that could take 200 to 400 milliseconds even on a fast connection.

Third, look for external requests. Some modules make calls to external servers for analytics, tracking, font loading, social media widgets, or API data. These requests are particularly dangerous because you have no control over the external server's response time. A social sharing module that calls Facebook, Twitter, and Pinterest APIs on every page load can add 500 milliseconds or more of latency, and if any of those servers is slow or unreachable, it can block your entire page from finishing its load.

To quantify the impact per module, use Chrome DevTools' blocking feature. Right-click on a request from a specific module and choose "Block request domain" or "Block request URL." Then reload the page and compare the load time. This gives you a direct measurement of how much that module's assets contribute to your total page load time. Repeat this for each module to build a ranking of heaviest to lightest.

Step 4: Hook Execution Analysis

Understanding which hooks each module uses is critical for identifying unnecessary loading. PrestaShop's hook system is the mechanism by which modules inject their content, assets, and logic into pages. The most performance-relevant hooks for front office pages are displayHeader, actionFrontControllerSetMedia, displayTop, displayHome, displayFooter, displayProductAdditionalInfo, and displayProductListFunctionalButtons.

The displayHeader hook is the most commonly abused hook in the PrestaShop ecosystem. Modules register on this hook to add their CSS and JavaScript to the page head. The problem is that displayHeader fires on every single front office page. If a module registers on displayHeader without checking which page the customer is currently viewing, it loads its assets everywhere.

To see which modules are registered on each hook, go to Design, then Positions in your back office. This page shows every hook and every module attached to it. Look specifically at displayHeader and actionFrontControllerSetMedia. Count how many modules are registered there. In a typical store with 30 or more modules installed, you might find 15 to 20 modules on displayHeader alone. Each one is adding at least one CSS or JavaScript file to every page.

Now cross-reference this with your DevTools findings. For each module on displayHeader, check whether that module actually needs to load on the current page. A product reviews module only needs its assets on product pages. A wishlist module only needs its assets on product and account pages. A size chart module only needs its assets on product pages. Yet all of them are loading on your homepage, your category pages, your CMS pages, and your checkout.

The profiling data from Step 1 adds another dimension to this analysis. Some modules not only load unnecessary assets but also execute expensive PHP code on every hook call. A module that runs database queries in its hookDisplayHeader method to check configuration values or fetch data is wasting server resources on every page, even when its output is not needed.

Step 5: Identifying the Heaviest Modules

With data from profiling, DevTools, and hook analysis, you can now rank your modules by their performance impact. Create a list with the following columns: module name, number of CSS files loaded, total CSS size, number of JavaScript files loaded, total JavaScript size, server execution time from profiling, number of database queries, and pages where the module actually displays content.

The modules that score highest across these metrics are your heaviest offenders. In our experience auditing hundreds of PrestaShop stores, the following categories of modules are consistently the worst performers.

Page builder modules are often the heaviest. They load large CSS frameworks, multiple JavaScript libraries for their visual editor, and sometimes even load editor assets on the front office. A page builder that loads 300 KB of CSS and 500 KB of JavaScript on every page is not unusual.

Social media modules that embed widgets from Facebook, Instagram, or Twitter load external scripts that are both large and unpredictable in their loading time. A single Instagram feed widget can add 1 MB or more of JavaScript to your page.

Analytics and tracking modules that use multiple tracking pixels load scripts from external domains. Each tracking pixel typically adds 20 to 50 KB of JavaScript plus additional network requests for pixel images and API calls.

Slider and carousel modules load large JavaScript libraries like Slick, Owl Carousel, or Swiper along with their CSS. Even if the slider only appears on the homepage, the assets often load on every page.

Live chat modules load substantial JavaScript bundles for the chat widget interface, typically 100 to 300 KB, plus they establish WebSocket connections that consume resources throughout the browsing session.

Step 6: Measuring Performance Before and After

Before you start disabling hooks or removing modules, establish a baseline measurement. Use multiple tools to get a comprehensive picture.

In Chrome DevTools, go to the Lighthouse tab and run a performance audit. Record the Performance Score, First Contentful Paint (FCP), Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Cumulative Layout Shift (CLS). Run the audit three times and average the results to account for variability.

Use the Performance tab in DevTools to record a page load trace. This gives you a flame chart showing exactly what the browser is doing at every millisecond. Look for long tasks (blocks longer than 50 milliseconds) and identify which module scripts cause them.

Also measure your page weight. In the Network tab, look at the total number of requests and total transferred size at the bottom of the panel. Filter by CSS and JS separately to get module-specific totals.

Record all these numbers before making any changes. Then, as you optimize modules by unhooking them from unnecessary hooks or disabling them entirely, re-run the same measurements. The difference tells you exactly how much performance you gained from each change.

A well-executed module audit typically reduces page weight by 30 to 50 percent and improves load times by one to two seconds. On stores with many poorly optimized modules, the improvement can be even more dramatic.

Step 7: Disabling Unnecessary Hooks

Once you have identified which modules load assets on pages where they are not needed, you have several options for optimization. The simplest approach is unhooking modules from hooks where they do not need to be.

Go to Design, then Positions in your back office. Find the module on the hook you want to remove it from. Click the trash icon or the unhook button to remove the module from that specific hook. This prevents the module from executing on that hook entirely.

However, be careful with this approach. Some modules use displayHeader not only to load CSS and JavaScript but also to perform essential initialization tasks. Unhooking such a module from displayHeader might break its functionality on pages where it is actually needed. Always test on a staging environment or at minimum test the specific pages where the module should still work after unhooking.

A better long-term approach is to contact the module developer and request conditional asset loading. A well-coded module should check the current controller or page type before loading its assets. For example, a product reviews module should only load its CSS and JavaScript when the current controller is ProductController. This way, the module stays hooked to displayHeader for compatibility but only loads assets when they are actually needed.

If you are comfortable editing module code, you can add conditional checks yourself. In the module's hookDisplayHeader or hookActionFrontControllerSetMedia method, add a check for the current controller name. If the controller is not one where the module displays content, return early without adding any assets. This is the most targeted and effective optimization you can make.

Practical Checklist for Your Module Audit

To summarize the entire audit process, here is a practical checklist you can follow. Start by enabling PrestaShop debug profiling. Open DevTools Network tab and reload your homepage. Filter requests by modules path and list every module asset. Note the size and type of each asset. Check Design, then Positions for modules on displayHeader. Cross-reference hook registrations with where modules actually display content. Use DevTools request blocking to measure per-module impact. Record baseline Lighthouse scores. Unhook modules from hooks where they are not needed. Add conditional loading to modules that load globally. Re-measure Lighthouse scores after each change. Document your findings and changes for future reference.

This systematic approach ensures you do not miss any performance opportunities and gives you concrete data to justify every change you make. Module bloat is not a mystery. It is a measurable, solvable problem, and every PrestaShop store benefits from a thorough module audit at least once a year.

For more details, read our guides: What Actually Makes PrestaShop Slow: Database, Modules and Hosting and Why Module Quality Matters More Than Module Quantity.