JS optimization: Stop margin-top calculation once sticky block out of viewport

Columns block

• Left column: Gutenslider block
• Right column: H3 + paragraphs (in total longer than image slider height).

Performance without Sticky Block:

• Idle: 0-1% CPU (0% if over a static area, 1% if over image slider with auto play)
• Scrolling: 10% CPU

Performance with the Sticky Block wrapping the Gutenslider block, the next columns block acting as the pushup block (btw: via concrete ID #section-name it works, via more class .wp-block-columns it didn’t):

• Idle: 5% (1% of this is the image slider wrapped in the sticky block)
• Scrolling: 20% CPU

As soon as the .wp-block-senff-sticky-block starts to get sticky it gets a CSS inline style like this:

position: fixed
left: …
top: …
width: …
margin-left: …
pading: …
margin-top: …
z-index: …

All values get initialized when the collision with the viewport top occurs first. And margin-top then gets constantly updated while scrolling.

Even when the object is long gone from the viewport.

Now when I have 10 column blocks on a page, each with a sticky image or image slider, I imagine the performance to degrade even more, as the JavaScript then needs to monitor and update more and more the further you scroll down.

I) Optimization potential

Is it maybe possible to set the sticky block back to its default CSS position value when it passed outside the viewport?

Possibly not so easy as when scrolling up you need to detect that too and update the value accordingly. So constantly updating margin-top sure was the easiest solution. But I doubt that it scales well performance wise for many objects in a page.

Idea: Create a lookup table like this:

scroll-position-y-axis ; object-to-reactivate ; margin-top
1240px ; #sticky-block-1 ; -240px
2240px ; #sticky-block-2 ; -1240px
...

If you scroll upwards and pass those scroll-position-y-axis treshhold values you re-activate the object-to-reactivate to its margin-top value again.

II) Other idea: Entirely different paradigm:

Only have 2 event:

1. on page loading
2. on viewport resizing

On these two events do this:

• Calculate the sticky’s parent’s element height in pixel and copy it into a data-attribute of that parent object and set its size to a concrete pixel value.
• Calculate the sticky child element dimension and set it to the sticky block statically.
• The sticky object uses simply “position: sticky ; top: top-distance-value”.
• This is CSS only and works really well.
• The only problem is that the parent and sticky element both need a concrete height (height: 100% did not work in my experiments).
• So all the plugin does then is to measure the distance between sticky element top until pushup element-top and set this as the parent elements size.
• JavaScript does far less in that plugin variant. Only on viewport resizing it re-calculates. Then during scrolling JavaScript does nothing and CSS does all the sticky positioning.

What do you think about this entirely different approach?