Image (.png) generation takes 5-10 times longer in Chrome 138 than it does in Chrome 137

[megaphonecolin]

Something in Chrome 138 has drastically increased the amount of time html2canvas takes to generate images (tested with .png files only, but probably affects all image generation).

Others have reported that the library html-to-image is also impacted by this issue:
bubkoo/html-to-image#542

Tested on a wide range of versions of both Windows and macOS.

[erik-grubbs]

Here to confirm this is happening to me as well.

I've opened a chromium issue for anyone else affected, and to see if there's a browser level issue.

[mromanuk]

I was using htm2canvas, but sadly it's abandoned. Snapdom is a much more modern alternative and significantly faster, check it here: https://github.com/zumerlab/snapdom.

[m-burger]

I also have the same issue when generating svg since recent chrome update to Version 138.0.7204.97 (Build officiel) (64 bits).

EDIT: switched to snapdom as @mromanuk mentioned and it works like a charm :)

[TomaszAdamiak]

Hey, your comment seem to have invalid link to the Chromium issue, would you mind checking it?
I'm using html2pdf lib thats based on html2canvas. I did some debugging and for me the implementation gets stuck when invoking new DocumentCloner(context, element, cloneOptions) (line 7665 in html2canvas.js)

Here to confirm this is happening to me as well.

I've opened a chromium issue for anyone else affected, and to see if there's a browser level issue.

[megaphonecolin]

I was using htm2canvas, but sadly it's abandoned. Snapdom is a much more modern alternative and significantly faster, check it here: https://github.com/zumerlab/snapdom.

For others facing this issue: we have tested Snapdom and confirmed that a) it is not affected by the Chrome 138 issue, and b) it is, indeed, much faster. In our case, Snapdom is almost twice as fast as the html2canvas in Chrome 137 and six times faster than html2canvas in Chrome 138. Thanks for the suggestion @mromanuk!

[erik-grubbs]

To update anyone looking at this, the problem with Chrome 138 is that it enabled enumerating custom CSS properties in getComputedStyle. So unsurprisingly Chromium isn't going to revert it because it's working as expected.

Haven't given Snapdom a try yet, but what I did was make a fork and patched the css cloning to filter out custom properties and that got performance back to expected, but that is a short term not long term fix so recommend giving Snapdom a try.

[gokulk16]

+1 . We have also faced this issue.

[mamjow]

Same here,

    <div id="capture" style="padding: 10px; background: #f5da55">
        <h4 style="color: #000; ">Hello world!</h4>
    </div>

this take 15 second.

print.service.ts:34 #1 0ms Starting document clone with size 1080x1751 scrolled to 0,0
html2canvas.esm.js:7624 #1 14775ms Document cloned, element located at 88,256.796875 with size 889x42.796875 using computed rendering
html2canvas.esm.js:7624 #1 14776ms Starting DOM parsing
html2canvas.esm.js:7624 #1 14781ms Starting renderer for element at 88,256.796875 with size 889x43
html2canvas.esm.js:7624 #1 14781ms Canvas renderer initialized (889x43) with scale 1
html2canvas.esm.js:7624 #1 14789ms Finished rendering

using
"html2canvas": "^1.4.1",

Angular: 20
Chrome 138.

[mwmw7]

Same here ㅜㅜ

html2canvas : 1.4.1
Angualr : 19
Chrome : Version 138.0.7204.100 (Official Build) (64-bit)

[StefanoVe]

Same here using jsPDF to download html elements

Angular: 19
html2canvas: 1.4.1
jsPDF: 2.5.1
Chrome: 138.0.7204.97

[reyoucat]

same
Change snapdom.