How to Find Slow PrestaShop Modules and Hooks with Super Speed System Analytics
A PrestaShop page can have a slow server response even when the hosting itself is not the main problem. One module may perform an expensive database query, call an external service, or execute unnecessary work every time a particular hook—a connection point where modules attach and run their functionality—executes.
Super Speed System Analytics helps narrow down this type of bottleneck by recording module and hook execution time together with the page where the execution occurred.
The most useful workflow is:
Record → reproduce the slow page → identify suspicious modules or hooks → investigate the cause → test again.
This guide focuses specifically on that process. If you do not yet know whether modules and hooks are responsible for your slowdown, start with Why Is My PrestaShop Store Slow? Causes & How to Diagnose first.
Step 1: Turn on module performance recording
Open Super Speed in your PrestaShop Back Office, then go to System Analytics → Module performance.
Enable Record module performance. Recording starts as modules and hooks are executed during subsequent page requests, so you do not need to leave the option enabled for a fixed amount of time before testing.
Once enabled, Super Speed can record information such as:
- the module being executed;
- the hook it runs on;
- the URL where the execution occurred;
- execution time;
- date;
- hook status.
Performance recording itself adds processing overhead, so use it as a diagnostic tool rather than leaving it enabled permanently. Enable it while you reproduce the performance problem, collect enough data to investigate, then turn it off again.
Step 2: Reproduce the pages that are actually slow
After enabling performance recording, go to your store's Front Office and open the pages where you normally notice the slowdown.
For example:
- If product pages are slow, open several representative product pages.
- If category pages are slow, open several affected category pages.
- If one specific page is consistently slow, open that page and reload it a few times.
Each time the page is generated, PrestaShop executes the modules and hooks required for that request, and Super Speed can record their execution time.
You do not need to perform any special action beyond visiting and loading the affected pages normally. A few representative page loads are usually more useful than browsing many unrelated pages, because the goal is to see whether the same module or hook repeatedly takes unusually long to execute.
Try to test under similar conditions each time. For example, use the same login state and avoid changing several store settings between page loads. This makes the recorded results easier to compare.
Step 3: Find the modules and hooks consuming the most time
After opening and reloading the affected pages several times while performance recording is enabled, return to System Analytics → Module performance and review the recorded entries.
You are not simply looking for the module with the single largest execution time. The goal is to identify a repeatable pattern that helps explain the slowdown.
Start with execution time
Execution time shows how long a recorded module-hook execution took.
Look first at the entries that consume noticeably more time than the others. A single module taking a large amount of processing time can delay the entire server response because PrestaShop must wait for that work to finish before completing the page.
However, do not assume that every relatively slow entry represents a bug. A module may legitimately perform more work than another. Execution time tells you where to investigate, not automatically what needs to be removed.
Match the module, hook and URL
The combination of these three fields is often more useful than execution time alone.
For example, you may find that:
- one module is slow only on product pages;
- the same module is expensive every time a particular hook runs;
- several modules attached to the same hook create significant cumulative processing;
- one unusually slow result appears only once and does not reproduce.
A repeated pattern across several similar requests is generally more useful evidence than a single isolated spike.
The URL is especially important because it connects the execution time to the page where the problem occurred. If your slow product pages consistently show the same module taking a large amount of time, you now have a much more focused area to investigate.
Example: Investigating a slow product page
Suppose you notice that /product/example-product takes unusually long to load.
With Record module performance enabled, open that product page in your storefront and reload it three times. If full-page caching is active, make sure each test triggers a fresh page generation rather than serving cached HTML. You may need to temporarily disable page cache during testing.
Next, return to System Analytics → Module performance and look for recorded entries matching /product/example-product. Compare the module names, hooks, and execution times across those page loads.
The example below shows how repeated high execution times can help you identify a module worth investigating further.
Step 4: Investigate what the slow module or hook is doing
Once you have identified a suspicious module or hook, the next step is to determine why it takes so long.
Super Speed identifies where execution time is being spent, but it does not automatically rewrite inefficient code inside another module.
Depending on what you find, investigate whether the module:
- runs database queries that are unnecessarily expensive;
- performs repeated calculations on every request;
- calls an external API and waits for a response;
- loads data that is not needed on the affected page;
- executes on a hook where its functionality is unnecessary;
- has configuration options that enable expensive functionality.
If the module is third-party software, also make sure you are using an up-to-date version and check whether its developer has documented performance fixes.
Use Unhook carefully
System Analytics provides an Unhook action for recorded module hooks.
Unhooking can be useful when you confirm that a module does not need to run on a particular hook. Removing that execution can eliminate unnecessary processing.
But do not unhook a module simply because its execution time looks high. Hooks often provide visible or functional parts of the storefront, and removing the module from a hook can make that functionality disappear or stop working correctly.
Before using Unhook, identify what the module provides on that hook and verify that removing it is safe.
If the module is required, the better solution may be to adjust its configuration or have the module developer optimize its code, database queries, or external requests.
Step 5: Test the same pages again
After making one meaningful change, repeat the same test.
Use the same page type and similar conditions, then compare:
- the module or hook execution time;
- overall server response time;
- whether the original slowdown can still be reproduced.
Avoid changing several modules at once. If you disable three modules, change caching, and modify the theme before testing again, you will not know which change actually improved performance.
A simple cycle works better:
Measure → change one relevant cause → measure again.
If the suspicious hook becomes faster and the page response improves at the same time, you have stronger evidence that the change addressed part of the bottleneck.
When you have finished profiling, turn Record module performance off again.
What if no slow module or hook explains the problem?
A high PrestaShop response time does not necessarily come from module hooks.
If your recorded modules and hooks look reasonable but the page is still slow, broaden the investigation. Possible causes include:
- slow SQL queries outside the recorded hook execution;
- PHP or server resource limitations;
- database configuration;
- repeated full-page generation without effective caching;
- network or hosting latency;
- other application-level processing.
Super Speed System Analytics helps identify slow module and hook executions, but it does not diagnose every possible cause of poor server performance.
If the recorded results do not explain the slowdown, return to Why Is My PrestaShop Store Slow? Causes & How to Diagnose to investigate other potential causes.
Avoid disabling modules without evidence. The goal is to identify what is actually slowing down your store, make the appropriate change, and verify whether performance improves.
