Support remote asset caching in Replays

[billyvg]

Problem Statement

Session Replay handles static assets differently based on the type of asset. They are either inlined into the recording or the source URL is preserved and fetched during playback-time. There are pros and cons to both of these approaches that will be explained below.

Inline

Currently only CSS is inlined in the recordings. The benefits of this are:

• Preserving the CSS at the time of recording. Viewing the replay will reflect the CSS as the user experienced it regardless of any updates to the CSS since.
• Viewers of the Replay can still access the stylesheet if the original stylesheet requires authentication.
• No CSP/CORS concerns
  • Not being able to load fonts can cause rendering differences which affect mouse precision (e.g. the production font is a bit larger than the default system font in replay, which affects the height of elements in the replay -- ultimately causing clicks to look incorrect because the click happens below the target element)

Remote

The benefits of inlining assets are conversely the downsides of remotely fetching the asset. However, the reason to remotely fetch static assets is to reduce the file size of recordings. This affects how much data the recording clients send, as well as the amount of storage required . Generally these assets (fonts, images, etc) do not change often, so replays can contain a lot of redundant data as well.

In our Session Replays, fonts and images are loaded at playback-time and can face cross-origin issues. By default we block images due to privacy concerns, but have had a handful of tickets from users who choose to unblock and not see their images get loaded during playback due to CORS. This leads them to think our product is broken.

Solution Brainstorm

It would require a bit of complexity, but we can have the best of both worlds if we were to proxy requests to all static assets to a version that is saved on a server we control. This means we are not inling anything so recording file sizes should be reduced (which means our customer's customers are sending less data). We should face less CORS issues as we can add our asset server as an allowed origin.

One thing this approach may not be able to handle however is if an asset requires authentication to access.

[mydea]

To be clear, this is mostly not a js-sdk issue I think, but a server side issue? Or do you see us rewriting urls or similar in the SDK?

[billyvg]

Yes I think this could potentially require SDK work to rewrite URLs, but implementation hasn't really been discussed yet.

[Lms24]

Just for cross-reference: #7020 surfaces an issue around SVGs that use the <use> tag, where asset caching would be the only way to get the SVGs to show up (other than inlining, which we abandoned before) .

[dwd]

I was expecting the proposal to include the Release Artifacts as an option - I'd be absolutely fine with relying on an uploaded asset for the particular release. It puts the asset management effort somewhat onto me, but since I'm already uploading sourcemaps (etc) for the release it's not much effort.

That said, my focus is very much on static assets like CSS - I absolutely don't want any images loaded in my case, and they're all explicitly blocked.

[lucas-zimerman]

maybe the images could be uploaded as an release artifact and the path of images could be replaced with something like

<img src="/{dsn}/{release}/{dist}/http://www.imageurl.com/support.gif">

If the image isn't found, a placeholder image could be shown just to not alter the website layout with sizes.

One disadvantage of it is it would only cover images that are statically stored on the app/website

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[futzlarson]

Bump