feat(perf): Detect "Uncompressed Asset" performance issues #37633
Conversation
Large assets can affect First Contentful Paint (FCP) and overall page load time. One easy way to make text assets smaller is to apply HTTP compression to them. Mark transactions containing uncompressed script or CSS resource loads (over a configurable minimum size, currently 500 KiB) as having an Uncompressed Asset performance issue.
github-actions
bot
added
the
Scope: Backend
| return | ||
|
|
||
| # Ignore assets that are already compressed. | ||
| if encoded_body_size != decoded_body_size: |
There was a problem hiding this comment.
I'm not sure they are always equal anyway, I'd maybe verify iirc message payload or body payload mean slightly different things, but I can't remember since it's been a while since I've fixed a compression issue. It's either decoded or transfer that can be larger because of headers, I believe.
There was a problem hiding this comment.
Good callout - this was true in my local testing but I'll double-check the SDK & Performance API docs.
There was a problem hiding this comment.
Confirmed again that these are the same in practice locally, and it seems safe based on my reading of MDN (both encodedBodySize and decodedBodySize measure the size of the payload body specifically.)
| "size_threshold_bytes": 500 * 1024, | ||
| "allowed_span_ops": ["resource.css", "resource.script"], |
There was a problem hiding this comment.
I think it's possible we'll also want some timing threshold on top of this in practice since 500kb might be fine depending on your use case or user conditions.
|
Closing in favour of detection for render-blocking assets in particular. |
Large assets can affect First Contentful Paint (FCP) and overall page load time. One easy way to make text assets smaller is to apply HTTP compression to them. Mark transactions containing uncompressed script or CSS resource loads (over a configurable minimum size, currently 500 KiB) as having an Uncompressed Asset performance issue.