35ms GPU time during scrolling near the top of the page with solid, split-composite and image shaders standing out.
Frame time reasonable when re-drawing the frame without scrolling (like when hovering over elements) so picture caching seems to be helping in these cases but the expensive parts appears to be invalidated during scroll.

A lot of overdraw coming from 3 huge background images (3800x2400px) for example look for <div class = "herobg herobg2" and . It doesn't help that we first render them into an intermediate target. We do that because preserve-3d transformations are applied and the saddest part is that these are all actually 2d transformations trying hard to pretend beeing more complicated than they really are:

transform: translate3d(0px, -60px, 0px) scale3d(1, 1, 1) rotateX(0deg) rotateY(0deg) rotateZ(0deg) skew(0deg);
transform-style: preserve-3d;

Side note: Interestingly on my nvidia linux desktop, renderdoc and our integrated profile counters don't agree about where we are spending time (wr's profile counters report a lot of solid shader time while it is rather negligible in renderdoc).
On an intel laptop with the same resolution the solid shader doesn't show up that much, so it looks like on linux + nvidia, our profile counters should be taken with a grain (or a whole bag) of salt, at least on my main development computer :(.

one thing that might help with this page could be to avoid rasterizing an intermediate picture render task if it only contains an image (and directly refer to the image in the render tasks that would have takne the picture task as input).

Appears to run well now at 4k on a low-end AMD GPU (GPU time peaks at ~4ms).