Alternatively, there's also WEBP.

According to https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study it supports transparency and should be smaller.
According to https://caniuse.com/?search=webp it is widely available.

For reference, I tried the same page, with canvasService!.toDataURL('image/webp', 0.7) and the snapshot is also 11MB.

Thank you for pinging me! I think the work is great. About the compression switch, compression ratio, and final format, personally, I suggest making them configurable. How do you think about it @Yuyz0112

Same here, extending inline images config to an object may help.

Guys, how about creating an optional param object dataURLOptions or something like that.
The default would be { type: null, quality: null }.

Then if you provide something like { type: "image/png", quality: 0.7 }, it would be applied to both record canvas and inline images? Because both tags use canvas.toDataURL(...).
My reasoning is that you can save for both tags and if the browser supports webp, it makes sense to use it everywhere.
I can't think of any reason to use separate image types for canvas, versus img.

What do you guys thing?

Good point! I think it could work. If changing canvas recording, I think @Juice10 may take a look as well.

Nice idea +1. The only concern is the API design since we need to keep compatibility.

So I checked a few pages in both Firefox and Chrome and it seems that providing nullable params to toDataURL() function makes it use the same params as default.

Eg:

document.getElementById('mainCanvas').toDataURL(null, 0) === document.getElementById('mainCanvas').toDataURL()
document.getElementById('mainCanvas').toDataURL(undefined, undefined) === document.getElementById('mainCanvas').toDataURL()

I implemented dataURLOptions like we agreed.
It is optional, and backwards compatible. I tested locally with a few pages and it works as expected.

Good point! I think it could work. If changing canvas recording, I think @Juice10 may take a look as well.
Thanks for looping me in @Mark-Fenng

I can't think of any reason to use separate image types for canvas, versus img.

What do you guys thing?

Unifying the config for canvas and images makes sense to me

If you'd like to decrease the embedded img size for inline images, why not try to use the existing image?
I know it's hard to try and figure out what format an image is in once its loaded into the browser in an image element, but we could request the image a second time by using fetch. This will most likely come straight from the browser cache and will be really fast to load. With the added bonus that this might already be the very smallest file possible if the website owner is serious about performance.

Using fetch comes with the benefit that we won't have to use canvas.toDataURL.
I've been doing some experimenting with recording canvas snapshots periodically and I've been bumping into a lot of issues regarding performance of toDataURL. Depending on what format you choose its either slow or very slow and larger images tend to make browsers drop frames. Alternatively you can use toBlob instead of toDataURL it's async and about 2-3x faster as it doesn't have to do any base64 encoding. But you'll still need to do the base64 encoding so toBlob does just delays the inevitable, but maybe we can do that part in a web worker?

Big downside to both canvas.toBlob and fetch(img.src) is that they are async. So it means a different approach when saving these too events. This might be a good starting point for a discussion around async events @Mark-Fenng @Yuyz0112 @eoghanmurray (in a different issue probably)

I have actually tried the image fetch option, when I started working on the offline image feature. It's a bit of work to make all the functions in the snapshot.ts file async, but it makes it easier to wait for some callbacks and events.
It's a breaking feature tho, and I shouldn't probably implement it in this PR.
Because the code is sync, currently I don't see any other way of of decreasing the size of the images. I already implemented the code and I'm already using it on my end.

I have actually tried the image fetch option, when I started working on the offline image feature. It's a bit of work to make all the functions in the snapshot.ts file async, but it makes it easier to wait for some callbacks and events.

It's a breaking feature tho, and I shouldn't probably implement it in this PR.

Because the code is sync, currently I don't see any other way of of decreasing the size of the images. I already implemented the code and I'm already using it on my end.

I totally agree that this PR is the next logical step to what we already have, and makes sense to do any image fetching or async work in a separate PR. Especially if we want to make the snapshot async.

What we could potentially do to keep everything sync, is to create a new type of event that contains the url of the image, and the contents. And then in the replayer we can loop through all of these new types of events to know what urls have been saved, and when the replayer creates an image it can check to see if we have an offline copy of that url and replace the contents of it with the saved version.
We are doing something similar for the canvas replay. If you search for imageMap throughout the source code you'll see it in action.