1. Describe the symptom
Choose a few pages: the homepage, a category, a product and the cart. Open them in a normal browser session and a private window. Record the time, device and login state. Compare more than one session so a local browser issue is not mistaken for a store-wide problem.
Use the browser network panel to distinguish a slow initial HTML response from slow image or script downloads. A delayed button response may need a different investigation from a slow server response.
2. Establish a timeline
Compare slowdown times with module updates, theme changes, imports, stock synchronisation and campaigns. If the problem repeats at similar times, inspect scheduled jobs. Several overlapping imports can strain the database even with few customers.
Keep a short log of time, URL, symptom and recent changes. Repeat comparable measurements: one good result is not enough when the original problem was intermittent.
3. Ask hosting for matching evidence
Give your hosting provider specific timestamps. Ask them to review CPU, memory, PHP process limits, database response times and errors. Establish whether resource limits are being reached or individual requests are unusually expensive.
Share only a sanitised excerpt of relevant logs. Remove customer data, tokens, session identifiers and order details. Do not post complete access logs in public comments.
4. Check configuration and recent changes
PrestaShop documentation highlights production configuration, PHP and OPcache. Use diagnostic modes deliberately and temporarily. Cache settings depend on your store version and hosting; enabling every performance-related switch is not a diagnosis.
Back up files and the database before experiments. Investigate a suspected module or theme change on a test copy first. Change one thing at a time so an improvement or regression can be traced to a specific decision.
5. Identify expensive traffic
High request counts do not necessarily mean many customers. Repeated filter combinations, search parameters or requests to one route may trigger expensive work. Compare request frequency with processing cost, rather than relying only on an IP ranking.
A User-Agent label does not verify a search engine bot. Automated payment, delivery and catalogue integrations may be necessary. Understand the pattern and its purpose before blocking it.
6. Match the action to the cause
If unwanted traffic drives the load, Traffic Guard Pro can help with observation and choosing protection. Start with the SHADOW guide. A traffic protection module will not fix every slow database query, theme bug or oversized image.
Repeat the same measurements after the change and complete the customer journey. Keep before-and-after results to inform the next step.
- Record affected URLs and timestamps.
- Review recent changes and scheduled jobs.
- Compare server load with traffic patterns.
- Check products, cart, login and ordering after the change.