Currently, our audit only scans assets located in the WordPress content directory. This raises an question,
how should the audit treat scripts and styles served from a CDN? Should these third-party resources be included in the render-blocking report, excluded entirely, or perhaps flagged separately so we can distinguish external blocking assets from local ones?

I think we’ll also need to consider how to measure their sizes efficiently. One approach could be, sending an HTTP HEAD request to the CDN-hosted URL to check for a Content‑Length header.

cc: @westonruter

From a performance perspective, CDN-served assets could be even worse for performance since they require a new TCP connection, now that browsers don't reuse cached resources across origins. So we definitely should be including them in the render-blocking report.

Sending an HTTP HEAD request for all resources regardless of whether they are on the same origin or not makes sense to me. If the request returns in a 404 then this would be important to report as well.

Once we have the report, then a future enhancement would be digging in to find the theme/plugin responsible for the resource being added in the first place. The AMP plugin implements a lot of this, and it was getting extracted a separate package via https://github.com/GoogleChromeLabs/wp-origination but that effort got stalled and was abandoned. See also #1095.

Should we consider a case where a HEAD request does not return a content length due to server configuration? If so, should we then make a GET request?

Perhaps, but that might be overkill.

OK, sounds good. In that case, let's not do the HEAD request at all and only do GET. The assets should all be relatively small (a few hundred KB at maximum), so it shouldn't be a problem to just go ahead and download them to check the byte size of the body.

Done in aa50fe4.

Sending an HTTP HEAD request for all resources regardless of whether they are on the same origin or not makes sense to me. If the request returns in a 404 then this would be important to report as well.

Now that the GET request is sent, should only 404 errors be added to the report, or should any errors that occur during the request be added to the report?

Once we have the report, then a future enhancement would be digging in to find the theme/plugin responsible for the resource being added in the first place. The AMP plugin implements a lot of this, and it was getting extracted a separate package via https://github.com/GoogleChromeLabs/wp-origination but that effort got stalled and was abandoned. See also #1095.

So does it make sense to add a table in the blocking scripts/styles site health test showing the origin of each blocking asset, or should this be part of Optimization Detective as you mentioned in #1095?

cc: @westonruter

I think this is related to #2059 (comment).

I think instead of just saying whether the sum of of the bytes for blocking assets is above a given threshold, that it would be better to list out the assets in a table with a sum at the end. It wouldn't necessarily be able to identify the theme/plugin responsible for adding the script or stylesheet, but in cases where the script/style is bundled with the theme/plugin then this would be obvious.

We currently skip any URL containing wp-includes (i.e. core assets). Since the goal is to surface all render-blocking resources, should we remove that exclusion and include core scripts and styles in the audit as well?

I think this exclusion should be removed, yes.

Currently each inline SCRIPT is reported as its own entry, do we want to continue treating every inline script separately, or would it make sense to aggregate inline scripts into a single summary?

I don't think inline scripts need to be counted since the render blocking is not significant compared to blocking external scripts.

Todo: verify this assertion is actually getting called, given the exception being thrown above. Do the same in the other tests for this function.

After testing, I can confirm that everything after this->_handleAjax is not getting called it's exiting early. After some digging, I found that if we want to run some assertions afterward, we need to catch the exception manually.

ref: https://infinum.com/handbook/wordpress/automated-testing-in-wordpress/basic-tests-using-phpunit/integration-testing#:~:text=or%2C%20if%20you%20need%20to%20run%20some%20assertions%20afterward%20you%27d%20catch%20the%20exception%20it%20manually

Like this:

diff --git a/plugins/performance-lab/tests/includes/site-health/audit-enqueued-assets/test-audit-enqueued-assets-helper.php b/plugins/performance-lab/tests/includes/site-health/audit-enqueued-assets/test-audit-enqueued-assets-helper.php
index 9f2eb1b0..12e88284 100644
--- a/plugins/performance-lab/tests/includes/site-health/audit-enqueued-assets/test-audit-enqueued-assets-helper.php
+++ b/plugins/performance-lab/tests/includes/site-health/audit-enqueued-assets/test-audit-enqueued-assets-helper.php
@@ -299,8 +299,11 @@ class Test_Audit_Enqueued_Assets_Helper extends WP_Ajax_UnitTestCase {
 	public function test_perflab_aea_enqueued_ajax_blocking_assets_test_unauthenticated_with_nonce(): void {
 		$this->add_filter_to_mock_front_page_loopback_request();
 		$_GET['_wpnonce'] = wp_create_nonce( 'health-check-site-status' );
-		$this->expectException( WPAjaxDieContinueException::class );
-		$this->_handleAjax( 'health-check-enqueued-blocking-assets-test' );
+		try {
+			$this->_handleAjax( 'health-check-enqueued-blocking-assets-test' );
+		} catch ( WPAjaxDieContinueException $e ) { // phpcs:ignore Generic.CodeAnalysis.EmptyStatement.DetectedCatch
+			// Expected exception for unauthenticated access.
+		}
 		$response = json_decode( $this->_last_response, true );
 		$this->assertFalse( $response['success'] );
 	}

I have added fix suggestions for all the AJAX tests please verify them.

@b1ink0 Thanks for digging into that! I've iterated on your suggestions and came up with 46b4df4.

Here, we need to check for '-1', as it seems WordPress returns '-1' when no nonce is present. We also need to use try and catch to check the output see my comment #2059 (comment).

ref: https://github.com/WordPress/wordpress-develop/blob/197f0a71ad27d0688b6380c869aeaf92addd1451/src/wp-includes/pluggable.php#L1360-L1365