Image (.png) generation takes 5-10 times longer in Chrome 138 than it does in Chrome 137
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: https://github.com/bubkoo/html-to-image/issues/542
Tested on a wide range of versions of both Windows and macOS.
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.
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.
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 :)
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.
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!
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.
+1 . We have also faced this issue.
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.
Same here ㅜㅜ
html2canvas : 1.4.1 Angualr : 19 Chrome : Version 138.0.7204.100 (Official Build) (64-bit)
Same here using jsPDF to download html elements
Angular: 19 html2canvas: 1.4.1 jsPDF: 2.5.1 Chrome: 138.0.7204.97
Note: these use cases are already super slow for html2canvas in Firefox and Safari. This "slowdown" was caused by Chrome 138 starting to follow the spec and include custom properties when returning computed styles.
html2canvas needs to be fixed to improve its performance in this situation.
For anyone who has the ability to patch their copy of html2canvas for a quickfix, the change in https://github.com/niklasvh/html2canvas/pull/3252 should do the trick.
Note that the change was reverted in Chrome, but we'd like to try rolling it out again. To test it right now you need to use the command line flag --enable-features=CSSEnumeratedCustomProperties since it's disabled by default.
This change is rolling out again in Chrome 141, tracked by https://chromestatus.com/feature/5070655645155328. The workaround for anyone affected is to apply https://github.com/niklasvh/html2canvas/pull/3252 to switch to another library.