WordPress / performance

Performance plugin from the WordPress Performance Group, which is a collection of standalone performance modules.
https://wordpress.org/plugins/performance-lab/
GNU General Public License v2.0
355 stars 97 forks source link

More granular Server-Timing measurements #1095

Open swissspidy opened 6 months ago

swissspidy commented 6 months ago

Feature Description

I just stumbled over @westonruter's https://github.com/GoogleChromeLabs/wp-origination project. Looking at its feature set now, it feels like it was ahead of its time :-)

One particular feature that caught my eye was the Server-Timing header allowing you to quickly see the impact each plugin had on the page load:

screenshot-1

I think it would be really useful to have this in Performance Lab as well.

And maybe there's more we can learn from Origination besides that :)

westonruter commented 5 months ago

I've been thinking about this lately a bit.

In addition to calculating the aggregated theme/plugin impact on load time in Server-Timing, I think there are new opportunities for attribution of printed scripts and styles or any other markup. In particular, Origination currently injects HTML comments before and after markup that is printed to the page to keep track of its origin. This HTML comment injection has the possibility of breaking some markup (e.g. inside of a script tag or style tag). Also, it only annotates from a limited set of filters which are known to output markup. Instead of injecting these HTML comment annotations into the markup, the new HTML Processor may open up an alternative approach. Namely, whenever an action prints something or a filter modifies a value, we can keep track of what that value was. Then after the page is finished processing, we could iterate over the tokens in the document and look them up in what we had previously captured during hook execution time. The HTML Processor could then be used to annotate the tags with data attributes to indicate the origin which will prevent the document structure from being corrupted by HTML comments. Alternatively, the token byte position in the output can be determined by the HTML Processor and so a sort of "HTML Source Map" could be generated. This would make sense possibly as an extension to Optimization Detective.

Alternatively, calculating the aggregated timing for theme/plugin hooks would be much reduced in scope and could be done without any HTML Processor.

westonruter commented 5 months ago

Oh, also, for an Optimization Detective integration: if the scripts were annotated with the theme/plugin that causes it to be added to the page, then the client-side detection logic could potentially use that to log attribution for INP issues.