Summary
The Site Health "Blocking assets" check (Enqueued Assets audit) only treats failed HTTP requests (e.g. non-200 status) as errors. It does not treat non-cacheable responses or zero-byte responses as problems, so the audit can report an asset as OK even when it is bad for performance or effectively broken.
Current behavior
In perflab_aea_get_asset_size(), the code:
- Returns
WP_Error for wp_remote_get() failures.
- Returns
WP_Error when the response code is not 200.
- Otherwise returns
strlen( wp_remote_retrieve_body( $response ) ) as the size.
So if an asset returns 200 with:
- Cache-Control: no-store (or similar non-cacheable headers), or
- Body length 0
it is still reported as successful, with no warning or error.
Proposed behavior
- Non-cacheable response: If the response indicates the asset should not be cached (e.g.
Cache-Control: no-store, no-cache, or missing cache headers where caching would be expected), treat it as an error or warning so the audit can surface it as a performance concern.
- Zero-size response: If the response body length is 0, treat it as an error (e.g. return
WP_Error or ensure the audit shows a failure) so the check does not report the asset as OK.
Code location
- File:
plugins/performance-lab/includes/site-health/audit-enqueued-assets/helper.php
- Function:
perflab_aea_get_asset_size() (around lines 497–528)
- Existing TODOs: Lines 525–526 already note these cases:
- "A non-cacheable response should also be considered an error."
- "A size of zero could be considered an error too."
Steps to reproduce (optional)
- Install and activate Performance Lab.
- Go to Tools → Site Health → Status and run the Blocking assets check.
- If any enqueued script or style is served with non-cacheable headers or returns an empty body (e.g. 200 with 0 bytes), the audit currently does not flag it; it would only flag non-200 or request failures.
Acceptance criteria (suggested)
I’d like to work on this after it’s confirmed by the team.
Summary
The Site Health "Blocking assets" check (Enqueued Assets audit) only treats failed HTTP requests (e.g. non-200 status) as errors. It does not treat non-cacheable responses or zero-byte responses as problems, so the audit can report an asset as OK even when it is bad for performance or effectively broken.
Current behavior
In
perflab_aea_get_asset_size(), the code:WP_Errorforwp_remote_get()failures.WP_Errorwhen the response code is not 200.strlen( wp_remote_retrieve_body( $response ) )as the size.So if an asset returns 200 with:
it is still reported as successful, with no warning or error.
Proposed behavior
Cache-Control: no-store,no-cache, or missing cache headers where caching would be expected), treat it as an error or warning so the audit can surface it as a performance concern.WP_Erroror ensure the audit shows a failure) so the check does not report the asset as OK.Code location
plugins/performance-lab/includes/site-health/audit-enqueued-assets/helper.phpperflab_aea_get_asset_size()(around lines 497–528)Steps to reproduce (optional)
Acceptance criteria (suggested)
Cache-Control: no-store/no-cacheor other agreed definition) is treated as an error or warning in the audit.I’d like to work on this after it’s confirmed by the team.