Measure an enabled tweak
A useful performance review follows the tweak’s real trigger. Measuring the homepage cannot evaluate upload optimization, and measuring Settings → POM Tweaks cannot represent an anonymous product page.
Choose the affected request
Build the test around the feature:
| Feature type | Representative context |
|---|---|
| Administration appearance | The affected dashboard, menu, toolbar, or login view |
| Media processing | One controlled upload and, separately, the documented bulk action |
| Public generated text | The generated endpoint, its first request, and a later cached request |
| WooCommerce cart logic | Product, cart, mini-cart, checkout, and recalculation requests that can invoke it |
| PDF generation | The administration generation action and later access to its generated output |
| Cleanup | A staging dataset with known counts and a measured maintenance window |
Include a negative context where the tweak should remain idle. This shows whether its scope is appropriately narrow.
Establish a comparable baseline
- Record the site, URL, user, device, dataset, PHP version, and active dependencies.
- Disable only the target tweak.
- Clear the relevant page, object, browser, generated-file, or CDN cache.
- Run one warm-up when the scenario normally benefits from warming.
- Repeat the request several times and keep the stable range.
- Enable the tweak alone and repeat with the same inputs.
- Check that the expected feature result is present; a faster broken request is not a success.
Do not compare a cold baseline with a warm enabled run or an empty cart with a populated checkout.
Record the right evidence
Depending on the feature, capture:
- server response time and peak PHP memory;
- database query count and slow queries;
- number and size of added scripts, styles, images, or generated files;
- upload or bulk-operation duration;
- cart fragments and repeated commerce requests;
- cache generation, invalidation, and warm reuse;
- storage growth before and after the operation.
Browser timing alone can hide server work, and an average alone can hide a slow first generation.
Interpret the result
An enabled module can be inexpensive on most pages yet appropriately expensive during its explicit task. Image conversion should consume resources while processing an upload; that does not imply it should work on every frontend request.
Investigate when:
- work appears outside the documented context;
- every request repeats generation that should be reused;
- cost grows disproportionately with products, attachments, terms, or orders;
- the feature loads assets on screens where no control or output exists;
- enabling one module changes an unrelated journey.
Finish with an off-state check
Disable the tweak, repeat the same request, and confirm its runtime cost disappears. Measure retained files or data separately because disabling does not reclaim storage or reverse completed work.
For unexplained output after the off-state check, use Resolve overlapping tweaks. For persistent results, use the rollback guide.