How to Optimize PHP Performance with Xdebug Profiler

4.1 Triggering Xdebug Profiler via Cookie for AJAX Requests

Besides URL parameters, Xdebug Profiler can be activated using browser cookies. This is especially useful for profiling specific AJAX requests without affecting full page loads.

When xdebug.start_with_request=trigger is enabled, Xdebug checks the XDEBUG_TRIGGER value in cookies. By limiting the cookie Path, you can profile only selected endpoints for a limited time.

Examples for Magento AJAX requests with a 120-second profiling window:

Add to cart request:

XDEBUG_TRIGGER=startProfile; Path=/checkout/line-item/add; Max-Age=120; SameSite=Lax

Offcanvas cart update:

XDEBUG_TRIGGER=startProfile; Path=/checkout/offcanvas; Max-Age=120; SameSite=Lax

Checkout info widget:

XDEBUG_TRIGGER=startProfile; Path=/widgets/checkout/info; Max-Age=120; SameSite=Lax

Cart page request:

XDEBUG_TRIGGER=startProfile; Path=/checkout/cart; Max-Age=120; SameSite=Lax

Profiling stops automatically after the specified time or immediately when the cookie is removed by setting Max-Age=0.

This method allows you to capture performance data only for the exact AJAX requests you need to analyze.

Finding the Profiler File Name in Browser DevTools (optional but useful)

Before opening PHPStorm, you can confirm which profiler file was generated by inspecting response headers in the browser.

In Chrome DevTools:

1. Open Network ➤ [your request] ➤ Response Headers
2. Look for the header:
   X-Xdebug-Profiler-Filename

This header contains:

• the exact filename of the generated profiler snapshot;
• the full absolute path to the file on disk.

Example:

X-Xdebug-Profiler-Filename: /tmp/xdebug/cachegrind.out.87.gz

This helps verify that:

• the profiler triggered correctly,
• the file was successfully created,
• you know exactly where it is located.

1. Reviewing the Execution Statistics Table

This table shows:

• total time,
• own time,
• number of calls,
• memory usage for each function.

It is immediately apparent that most of the time is spent inside our custom block.

What we see:

• Vendor\Module\Block\Page->getSaleStats() takes 87% of total request time.
• Inside it, heavyCpuWork() alone consumes 36%.
• getProducts() is also heavy, contributing 17%.

This immediately proves that the performance issue is not Magento core, but our own custom logic.

2. Inspecting the Call Tree

The Call Tree view provides a detailed breakdown of how execution flows through the request. By expanding the stack under our custom template, we can clearly see which methods are called in sequence and how deeply they are nested. This makes it easy to spot the slow sections of the chain and understand why the block takes so long to execute.

Observations:

• getSaleStats() calls heavyCpuWork() thousands of times.
• Each product triggers expensive attribute lookups (getData, getId, getPrice).
• The method chain is inefficient by design – this matches the intentional “slow” test version.

This confirms that the performance problem is structural, not incidental.

3. Verifying Slowest Functions via Own Time

Sorting by Own Time is the most accurate way to find the real bottleneck: it excludes time spent in child calls.

• heavyCpuWork() dominates Own Time – meaning it is the single most expensive function.
• The custom block consumes most execution time overall.
• Magento internal functions appear far below – so the slowdown is entirely our responsibility.

Conclusion of the Analysis Stage

From the profiler data, we now have a clear and evidence-based understanding:

• Our test page is slow because of two custom methods:
  • The excessive CPU function (heavyCpuWork)
  • The inefficient product loading

These functions are the primary targets for optimization.

Step 4: Analyzing and Optimizing the Code

Based on the profiler results from the previous section (see “Analyzing the Profiling Results”), it is clear which part of the system is responsible for the slowdown: our custom block Vendor\Module\Block\Page.

The profiler tables and call tree both show significant execution time inside:

• Vendor\Module\Block\Page->getSaleStats()
• Vendor\Module\Block\Page->heavyCpuWork()
• and additional overhead in getProducts() due to loading all product attributes.

The profiled implementation loads the full product collection with all attributes, iterates over every product in PHP, performs additional CPU-intensive operations inside the loop, and applies sale filtering after the data is already loaded into memory.

Functionally, the block calculates the number of products on sale and the average discount. From a performance perspective, the main issues are excessive data loading, heavy processing inside a tight loop, and late filtering at the PHP level instead of the database.

In the next section, we will review how this logic was optimized.

Optimized Code and What Changed

Based on the profiler results from the previous step (see the analysis section above), it became clear that the main bottleneck was inside our custom block class Vendor\Module\Block\Page. The optimized version keeps the same public API and business result, but removes unnecessary work and reduces the amount of data processed per request.

Below are the key changes shown as compact before and after fragments.

$collection->addAttributeToSelect('*');

$collection->addAttributeToSelect([
    'price',
    'special_price',
    'special_from_date',
    'special_to_date',
]);

$collection->addAttributeToFilter('special_price', ['gt' => 0]);

1. Run the profiler again with the updated code

We use exactly the same URL and trigger as in the first test:

https://test-domain.local/test?XDEBUG_TRIGGER=profile

This is important: the request must be identical to the previous run so that the results are comparable.

Once the page finishes loading, Xdebug generates a new profiler file in the same directory as before, for example:
/tmp/xdebug/cachegrind.out.686.gz

You can again confirm the exact file name and path via the
X-Xdebug-Profiler-Filename header in DevTools, just like in the first test.

2. Comparing Execution Statistics

Open the new profiler snapshot in PHPStorm and switch to Execution Statistics.

Now compare the optimized run with the previous (slow) run:

• The total time of the request is significantly lower.
• Vendor\Module\Block\Page::heavyCpuWork() is no longer present in the table.
• Vendor\Module\Block\Page::getSaleStats() takes much less time and has lower Own Time.
• Magento EAV and collection-related methods show fewer calls and reduced time, thanks to:
  • a smaller set of selected attributes,
  • filtering by special_price at the collection level.

The following comparison table summarizes how the optimized version performs against the original slow implementation. It highlights the key differences in execution time, function costs and collection behavior, clearly showing the impact of each change.

3. Call Tree: confirming that the hot path is gone

Switching to the Call Tree tab is optional.
In my case, I use the integrated tree view directly inside the Execution Statistics table.
To inspect the slow path, I simply locate the row that corresponds to my custom template and expand it to see the full call structure beneath it.

This reveals exactly how the request flows through the block, including:

• the call to getSaleStats(),
• the internal calls such as isOnSale(), getProducts(),
• and, most importantly, the expensive heavyCpuWork() method.

Expanding this tree makes the slow functions clearly visible without switching to a different tab.