DEV Community: Yangren

🌊Layout thrashing: what is it and how to eliminate it

Yangren — Sat, 01 Mar 2025 11:47:35 +0000

Have you ever come across (or event built!) a cool, modern, sleek, animation-heavy website... and opened it on mobile only to see that it runs like Alan Wake 2 on a 2003 Dell Inspiron?

What is layout thrashing?

Layout thrashing, a.k.a. forced synchronous reflow, occurs when the browser is continuously forced to drop its optimized queueing of layout and style recalculations and do it ASAP because a script running needs to know the latest layout measurements.

Because layout re-calculation and repainting are resource-heavy operations, if the browser is forced to do them too often and not "at the right time", this leads to very jittery laggy and possibly unresponsive page.

What causes it?

As a user interacts with the page and layout changes or animations play, the browser has to keep re-rendering the latest version of a page. It does in roughly two distinct steps:

🌊 Reflow: re-calculate the position, size, etc of the elements on the page
🎨 Repaint: re-draw elements whose appearance has changed

(I refer you to this great article for more info on those.)

How often reflow and repaint happen depends on the screen refresh rate and on the what the JavaScript is doing.

Ideally this happens at most once every display refresh "tick", i.e. 60, 75 or more times a second (the screen refresh rate). This is because, as mentioned, reflow and repaint are quite resource expensive and lead to laggy performance when done more often than that.

However, unless the scripts on the page have been specifically optimized for that, chances are good that reflows and/or repaints are happening multiple times in each animation frame.

Normally browsers are pretty good at optimizing the reflows/repaints and defer them until just before the next display refresh tick. The browser is also clever about caching layout information and knows whether it actually needs to re-calculate it or not by keeping track of what has changed since the last reflow, i.e. whether the style/layout has been "invalidated". But if a script reads or "measures" a layout property, such as the height of an element or its offset on the page, after the style has been invalidated, then the browser is forced to re-calculate now in order to give the correct measurement.

Image credit

So for a forced synchronous reflow to happen, then 2 things need to follow in order:

A script modifies the style in a way that invalidates the current style, by for example adding a CSS class or directly modifying the inline style. From now on I will refer to this as a "mutation".
Then it asks for measurement that depends on the latest style such as the height of an element. From now on I will refer to this as a "measurement".

How to avoid it?

The ideal order of operations that avoids forced reflows is:

Start of frame: Browser runs is scheduled (optimized) recalculation and repaint.
JavaScript can freely read or "measure" any layout values such as offsetHeight, clientHeight, getBoundingClientRect, getComputedStyle, event.offsetX, etc. See here for a comprehensive list of "measurement" operations that if not done on a valid layout will force synchronous reflow.
... more calculations
End of frame: requestAnimationFrame callbacks fire; callbacks can now "mutate" the style by adding/removing CSS classes, adding, removing, moving elements, etc.
Repeat.

To achieve this, the general principle is to

Batch and defer all style mutations and to just before the end of the frame, which is the scheduled time for reflows.
Ensure that any measurements are done after a scheduled reflow has happened and before the style has been invalidated.

Step 1 is easy: any code that needs to modify the style should run in a callback to requestAnimationFrame. You can do this yourself or use something like fastdom.

// Step 1: batch all mutations to the end of the frame

requestAnimationFrame(() => {
  // ... modify the DOM, e.g.
  element.classList.add("cls");
  element.append(newChild);
});

Step 2 could be a bit tricky. If all the code running on the webpage is yours and all your style modifications are batched and deferred as mentioned in step 1, then you can safely just do all measurements at any time except inside the mutation callbacks (because at that time the style has been invalidated and doing measurements will force a reflow).

// Step 2: Simpler naive approach
// Just do your measurements synchronously,
// assuming that all mutations will be deferred
// till the end of the frame

// Fingers crossed the style is not invalidated here
const elHeight = element.offsetHeight;

However, in most cases not all of the code on the page is yours and other code isn't so considerate so as to defer its mutations to the end of the frame, and so when you do a measurement and it happens to run in an already invalidated style it will force a reflow. fastdom takes a simple approach by also deferring all measurements, in addition to mutations, to the end of the frame, and runs all measurements first, then all mutations. This ensures that a reflow forced by your code can happen at most once in a frame: during the first measurement task that runs in the requestAnimationFrame callback. Then at the end of the frame of course there will be a scheduled reflow, because the style would have been invalidated by the mutation tasks.

For this reason I chose to not use fastdom in my latest project but wrote my own implementation in which I:

Batch and defer mutations till the end of the frame as before.
Batch and defer measurements till just after the start of the next frame when the style is almost certainly still valid, having just been re-calculated.

Now forced reflows by my own code are eliminated (even if other code on the page has mutated the layout during the frame).

Step 2 is achieved by first waiting for the requestAnimationFrame callbacks to fire, which happens just before a paint, and then scheduling a high priority task using either the Scheduler.postTask method which is only available in recent browsers, or the fallback legacy MessageChannel. These two methods schedule a new task (not a microtask, but a ~~macro~~task) that runs with higher priority than say setTimeout. I refer you to this excellent post on the event loop and tasks.

This works because tasks scheduled from inside requestAnimationFrame callbacks will be deferred till after any scheduled reflow/repaint that will follow said callbacks. Again note that I'm not talking about microtasks such as Promise resolve callbacks: these will run in the same frame, before the repaint.

// Step 2: A more robust approach
// Defer your measurements till after the next scheduled reflow

const scheduleHighPriorityTask = (task) => {
  if (typeof scheduler !== "undefined") {
    scheduler.postTask(task, {
      priority: "user-blocking",
    });
  } else {
    // Fallback to MessageChannel
    const channel = new MessageChannel();
    channel.port1.onmessage = () => {
      channel.port1.close();
      task();
    };
    channel.port2.postMessage("");
  }
};

requestAnimationFrame(() => {
  // end of frame here, mutations will run/have just run
  scheduleHighPriorityTask(() => {
    // start of next frame: scheduled reflow has just happened
    const elHeight = element.offsetHeight;
  });
});

How to test for it?

The browser's built-in Performance monitoring tool can help you spot forced reflows.

Open the Performance tab and start recording
Do something on the page that you suspect causes reflows
Stop recording and examine the timeline. Force reflows will be little purple boxes that say "Recalculate style" that appear below the top row of events (ones on the top row will be the scheduled ones that run at the optimal time). When you click on those boxes it will also tell you which line of which file caused that:

Here is the simple pen I wrote that you can use to play with it (screenshot taken from there when running the unoptimized version).

TL;DR;

Layout thrashing is when the browser is forced to perform a synchronous, out-of-schedule, re-calculation of the style because JavaScript has previously modified the layout or style and invalidated the browser's cached measurements, and now JavaScript wants to read the latest value of a property from the layout.

To avoid it:

Batch and defer all code that modified the DOM till just before the end of the frame using requestAnimationFrame.
Batch and defer all your measurements till just after the start of the next frame using requestAnimationFrame and then a high priority task scheduler like Scheduler or MessageChannel.

Thanks for reading!

Thank you for reading, like if you like, follow me you X. And be happy and kind 🌞

Resources/references

🦄Cool things with CSS only: carousel, slider, menu, tabs, input animation

Yangren — Mon, 24 Feb 2025 12:44:22 +0000

CSS is becoming more and more powerful. Static CSS animations of course have been around for a long time, but nowadays, on modern browsers at least, you can even implement certain scroll-based animations with pure CSS.

But CSS has also been used for a long time for implementing other interactive features that normally require JavaScript. This is not a new technique; there are already tons of examples of implementing tabbed content, sandwich menus and so on using the "checkbox trick".

Here I'll show some variations on those two I mentioned, plus a few more interesting examples of CSS-only interactivity.

I've also made the examples as compatible as possible with old browsers. 🦖🦖 No scroll snapping, not even using :has selector! Instead, relying on good old sibling selectors.

Image slider

⚡ Add as many images as you want, same CSS
🦖 Works on all browsers

How it works

This slider uses images that are overlayed on top of each other with the "upcoming" ones being translated to the right, out of view. In between each image there's a checkbox. Checkboxes that are ticked are displayed on the left hand side, and unchecked ones on the right. Of course they are invisible and their respective labels are styled as arrows and overlayed on top.

All images associated with a ticked checkbox are in-view, and all the other ones are out of view. The trick here is to use a flat structure with each checkbox and image following one another, so that you can find images corresponding to unchecked ones using the sibling selector ~ alone, and so that you don't have to hard code the number of images and rely on :nth-child pseudo-selector.

Carousel

😎 Auto-slides overflowed ones into view
🦖 Works on all browsers

How it works

This carousel slider has items that can be focused. If the slides don't fit on the page, their wrapping element will be automatically translated so that the current slide is in view.

It relies on tabindex and the :focus pseudo-selector to make each slide (in this case a simple image) focusable (using click or TAB). The CSS uses media queries and some trickery to calculate the width and transforms for the slider container. The downside is that you need to partly hardcode the number of slides in by providing selectors for each possible number of slides. You can do super easily with SCSS and loop until some very large number (it doesn't need to equal the number of slides, just be >= to that number). But here I've kept it simple and manually laid those out for up to 10 slides.

Page tabs

The good old one, here for completeness
🦖 Works on all browsers

How it works

Similar to the slider, but using radio buttons instead of checkboxes

Valid input animation

🙃 Just for fun! Or an idea for something more interesting...
🦖 Works on all browsers

How it works

There are several inputs each one having a pattern and required attributes in order to enable the use of the :valid pseudo-selector.

It lays the inputs out in a grid. The grid has a "ghost" column and a "ghost" row using some dummy line elements to create spacing around the inputs. Then relying only on sibling selectors (+ and ~) we add a state where all 8 inputs are valid and then shrink the ghost lines to bring all inputs together.

Sandwich menu (auto-closing)

🦄 Auto-closes on clicking outside
🦖 Works on all browsers

How it works

The well known checkbox trick here as well: have a checkbox and a label overlayed on top and styles as the menu button. The menu content is a direct sibling of it (again, in order to avoid using :has). When the check is ticked, the menu is brought into view, otherwise translated out of view. The addition here compared to the standard examples is a second label for the same checkbox that acts as the page overlay so that clicking either the close button (the first label) or the second label, closes the menu.

Thanks for reading!

Thank you for reading, like if you like. And be happy 🌞

Introducing LISN.js: handle user interactions and layout events + widgets! ⚡

Yangren — Mon, 17 Feb 2025 14:06:45 +0000

Hey there awesome people! Firstly, let me briefly say hello, this will be my first post on dev.to 👋 I want to introduce you to my new project.

What is LISN.js?

In a nutshell, LISN.js is a flexible, full-featured and simple to use library for handling user gestures (drag, scroll, zoom, with any type of device) and interactions (like scrolling, clicking, etc) as well as observing elements for changes in viewport position, size and so on.

There are React wrappers available as a separate package. It works in
server-side rendering environments like Next.js.

LISN also comes with many awesome widgets, like collapsible, floating popup, modal, offcanvas menu, pager (carousel/slider/tabs), flex same-height, scrollbars (native scrolling), sortable, scroll-to-top button and page loader.

"Why not use X, Y and Z?" you say

So you go like, "Well there's Hammer.js for gesture handling, Waypoints for viewport observation, Trigger.js or GSAP for scroll based animations, Sortable.js for sortables, OverlayScrollbars for scrollbars, and gosh-you-name-it for modals, popups, sliders, and so on? What's new here 🤷

Well you can use all of those (and I'd probably recommend each one ❤️). But in general, do you prefer to install 15+ libraries, learn how to use each one, possibly survive a dependency hell, find out that some of them may not be actively maintained, some of them don't work in server-side rendering context, some of them are too rigid and don't allow for extensive customization, some of them don't work with touch or on browser X... (P.S. I'm not saying this is the case for any of the libraries I just mentioned)... or do you prefer to install 1 library that is:

100% vanilla TypeScript (no dependencies)
Has React wrappers
Extensively tested
Highly optimized, no layout thrashing
Works with server-side rendering
Super flexible and customizable
Simple to use

and in addition to the standard JavaScript API it has an HTML-only mode where you can do almost anything the full JS API can do without writing a single line of JavaScript.

Want a modal to open the first time the user scrolls to the middle of the page? Easy.

<div
  data-lisn-modal
  data-lisn-on-view="@open +target=top: 50% +rootMargin=-48%,0px +once"
>
  <p>
    Here's a modal popping up to tell you you've reached the middle of the page!
  </p>
  <p class="footnote">P.S. Don't do that, popups are annoying.</p>
</div>

Want scroll-tabs/sections that show the current section in the page and can scroll to it (smoothly and as slowly as you like)? And a cool configurable scrollbar (maybe as a progress bar)? Here, just sprinkle some CSS to taste.

  <div class="tabs">
    <div
      class="tab"
      data-lisn-ref="tab1"
      data-lisn-on-view="at @add-class:inview
                         +root=next.scrollable
                         +rootMargin=0px
                         +target=next-section1"
    >
      Intro
    </div>
    <div
      class="tab"
      data-lisn-ref="tab2"
      data-lisn-on-view="at @add-class:inview
                         +root=next.scrollable
                         +rootMargin=0px
                         +target=next-section2"
    >
      The real deal
    </div>
  </div>

  <div class="scrollable"
       data-lisn-scrollbar="positionV=top | click-scroll=false">
    <div
      data-lisn-ref="section1"
      data-lisn-on-click="@scroll-to: offsetY=-5, scrollable=this.scrollable
                          +target=prev-tab1 +oneWay"
    ></div><!-- target is the click target -->
    <div class="section">
      <h1>Yada yada...</h1>
      Does anyone even read intro?
      Norem hipsum color something something
    </div>

    <div
      data-lisn-ref="section2"
      data-lisn-on-click="@scroll-to: offsetY=-5, scrollable=this.scrollable
                          +target=prev-tab2 +oneWay"
    ></div>
    <div class="section">
      <h1>Now we're talking</h1>
      ...
    </div>
  </div>
</div>

🙄 But I'm an experienced dev and I write JavaScript TypeScript (React TypeScript!)

Sure, you can still do that with LISN and the syntax/API is just as simple and intuitive and even more powerful. (👉 Demos | Docs)

But for the curious, I'll explain how the HTML-only mode came about; well actually how and why LISN itself came to be!

The HTML-only mode was actually the original aspect of LISN before it underwent 3-4 stages of metamorphosis 🦋 You see, I was making a website... in Wordpress... (don't ask). And let me tell you, it ain't easy to make it look like and walk like and talk like the animal you want 🦖 A lot of the Wordpress plugins are limited, rigid and full of bugs.

Sigh... I just wanted to have nice, glitch-free customizable modals and collapsibles... And animate elements when they come into view... And scroll to an alert box when the page loads... And have a flexbox section with an image and text that stay the same height no matter what aspect ratio image I put in there (cause it's all dynamic™ you know). (If you've ever tried to do the last one and ended up writing 3 pages of polynomial equations and calculus you'll know my ~~pain~~ sense of reward.)

Well, I guess if you want a job done well, you gotta do it yourself. So I did. And then the idea came...

Ok, ok, docs, demos, now

I won't copy paste the quick start and doc here, but just refer you to the latest docs.

DEV Community: Yangren

🌊Layout thrashing: what is it and how to eliminate it

What is layout thrashing?

What causes it?

How to avoid it?

How to test for it?

TL;DR;

Thanks for reading!

Resources/references

🦄Cool things with CSS only: carousel, slider, menu, tabs, input animation

Image slider

How it works

Carousel

How it works

Page tabs

How it works

Valid input animation

How it works

Sandwich menu (auto-closing)

How it works

Thanks for reading!

Introducing LISN.js: handle user interactions and layout events + widgets! ⚡

What is LISN.js?

"Why not use X, Y and Z?" you say

🙄 But I'm an experienced dev and I write JavaScript TypeScript (React TypeScript!)

Ok, ok, docs, demos, now

Official website | Demos | Docs | GitHub