Site Health tests for enqueued scripts and styles are inaccurate

[westonruter]

Bug Description

On my blog, I have two enqueued scripts and one enqueued script module. For stylesheets, all of them are inlined except for one external stylesheet which I've moved to the footer. Nevertheless, Enqueued Scripts test is reporting an invalid number of scripts being enqueued and the Enqueued Styles test is not accounting for the inlining.

We've talked before about using a loopback request to fetch the HTML to look at what is actually printed to determine the external scripts and styles added to the page. We can easily analyze the HTML via the HTML Tag Processor.

Screenshots

[westonruter]

Enqueued Scripts test is reporting an invalid number of scripts being enqueued and the Enqueued Styles test is not accounting for the inlining.

This is surely due to being logged in as an administrator while on the frontend, so all admin bar assets are being included. See #134

This would be fixed by doing an unauthenticated loopback request an analyzing the HTML response.

[b1ink0]

@westonruter I was working on implementing this issue using the HTML Tag Processor and was able to extract the scripts with the src attribute and the styles from the link tag with the rel attribute set to stylesheet. However, for calculating the inline script and inline style sizes with respect to their main script or style, it’s necessary to extract the id (which is the handle) from the main script or style. Then, if the corresponding inline script or style exists (i.e., id + '-after' for scripts and id + '-inline-css' for styles), the get_modifiable_text method on the HTML Tag Processor can be used to calculate the inline size.
Here is the POC I created for this: b1ink0@1e60c9a

Currently, to process three different tags—SCRIPT, STYLE, and LINK—I am looping over the entire document three times because the next_tag method does not support querying multiple tags. I was thinking that if the document is not large, looping three times may not cause a performance issue. I have used the bookmark and seek functionality to rewind to the start of the document before each loop, so it doesn't need to parse the HTML string repeatedly.

However, would it be better to implement a custom traversal logic using next_token directly—similar to next_tag—that supports checking for multiple tags? I'm not talking about extending the existing class; it would just be a custom loop using next_token instead of next_tag.

So, the HTML Tag Processor can be used to resolve this issue, but I also want to consider the method suggested by @felixarntz in #134, which involves making an unauthenticated loopback request with a query parameter and a nonce. When the specific query parameter is received and the nonce is valid, it will invoke the existing functions perflab_aea_audit_enqueued_scripts and perflab_aea_audit_enqueued_styles to process the assets. This approach will likely require less logic than the HTML Tag Processor one.

So I would like a suggestion on which method should be implemented.

[westonruter]

@b1ink0 Hey! Instead of looping over the document three times, I suggest just looping over once and just call next_tag() without any arguments. Under the hood, when you do a query it's ultimately visiting every tag anyway. This is the approach that Optimization Detective takes, looping over the document once and calling all tag visitors when landing at each open tag.

Also, I don't think we technically need to worry about whether the script was enqueued or not. What matters is whether there are blocking scripts and blocking stylesheets. In fact we want to catch specifically scripts which weren't enqueued but were printed manually or via wp_print_script_tag(). These are what we really should be reporting as as being problematic. If we find there are script modules, or scripts with async/defer, or inline scripts, or inline styles... then all of these are less of an issue and I don't think we should necessarily put them in the same category as external blocking scripts and styles.

So yeah, I think a loopback request with HTML Tag Processor is the way to go, and to rename the test to report blocking scripts and blocking stylesheets.