Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More granular Server-Timing measurements #1095

Open
swissspidy opened this issue Mar 27, 2024 · 2 comments
Open

More granular Server-Timing measurements #1095

swissspidy opened this issue Mar 27, 2024 · 2 comments
Labels
[Focus] Measurement Issues related to the Measurement focus area [Plugin] Optimization Detective Issues for the Optimization Detective plugin

Comments

@swissspidy
Copy link
Member

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 :)

@swissspidy swissspidy added the [Focus] Measurement Issues related to the Measurement focus area label Mar 27, 2024
@westonruter westonruter added the [Plugin] Optimization Detective Issues for the Optimization Detective plugin label Apr 30, 2024
@westonruter
Copy link
Member

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
Copy link
Member

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.

@sstopfer sstopfer added [Focus] Measurement Issues related to the Measurement focus area [Plugin] Optimization Detective Issues for the Optimization Detective plugin and removed [Focus] Measurement Issues related to the Measurement focus area [Plugin] Optimization Detective Issues for the Optimization Detective plugin labels May 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Measurement Issues related to the Measurement focus area [Plugin] Optimization Detective Issues for the Optimization Detective plugin
Projects
Status: Not Started/Backlog 📆
Development

No branches or pull requests

3 participants