DEV Community: Gokul

Layout Thrashing - The Hidden Performance Killer in Modern Web Apps

Gokul — Sat, 21 Feb 2026 13:34:27 +0000

Have you ever noticed your animations feel janky, the scroll feels laggy or the UI stutters even on powerful machines?

This is likely due to layout thrashing, a common yet often misunderstood performance killer in frontend development.

In this article, I’ll explain what layout thrashing is, why it occurs and how to overcome it and build smooth, high performance animations.

What is Layout Thrashing?

Layout thrashing occurs when JavaScript repeatedly forces the browser to recalculate the page layout synchronously. This disrupts the browser’s ability to efficiently batch render work. That’s the formal definition. Let’s simplify it.

Browsers typically batch layout and paint operations to avoid repeatedly calculating heavy layout computations. However, layout thrashing prevents this batching, which might sound counterintuitive, let’s see why.

Consider the following snippet:

window.addEventListener("scroll", () => {
  updateUI();
});

function updateUI() {
  const top = box.getBoundingClientRect().top;  // forces layout
  box.style.transform = `translateY(${top * 0.5}px)`; // invalidates layout
}

This snippet demonstrates how layout thrashing can occur. The updateUI function is triggered every time the user scrolls, causing the browser to recalculate the layout synchronously (often dozens of times per second).

const top = box.getBoundingClientRect().top;  // forces layout
box.style.transform = translateY(${top * 0.5}px); // invalidates layout

This is a classic example of layout thrashing. The getBoundingClientRect() function forces layout calculations immediately, but the box.style.transform invalidates those calculations when these operations run in a loop. This creates a messy cycle of read and write operations instead of clean batched layout updates.

So, the above approach forces the browser into a cycle:

layout → paint → layout → paint → layout → paint → …

Instead, the browser should leverage batched updates, which aim to:

Collect all DOM reads
Collect all DOM writes
Compute layout once
Paint once
Composite once

This results in a simpler layout-paint cycle:

Layout → Paint

Why Layout Thrashing Is Serious?

At this point, you might think. It’s just a couple of extra reads and writes, so what’s the big deal? Let me explain.

Modern browsers are highly optimised, but layout calculations are expensive.

When layout thrashing occurs, it results in two problems:

The browser cannot batch layout work.
It is forced into sync reflow loops.

As a result, the UI becomes jittery even on powerful machines. This is why even MacBooks and gaming laptops can show jank on poorly optimised UI code.

How to Overcome Layout Thrashing?

It’s possible to prevent layout thrashing by using a couple of techniques, one of which is using requestAnimationFrame() (rAF).

rAF is a web API supported by all modern browsers. It optimises layout updates by instructing the browser to call a specific function before each repaint. For example, consider the previous example but with rAF:

let latestScroll = 0;
let ticking = false;

window.addEventListener("scroll", () => {
  latestScroll = window.scrollY;

  if (!ticking) {
    requestAnimationFrame(() => {
      box.style.transform = `translateY(${latestScroll * 0.3}px)`;
      ticking = false;
    });

    ticking = true;
  }
});

Now, what happens behind the scenes is that our rAF batches multiple scroll events into a single frame update. and provides the browser with the latest one. This allows the browser to pick it up and apply the computation. Instead of a ever ending loop of read and write, it’s simply:

READ → READ → READ → WRITE → WRITE → WRITE → PAINT

In simpler terms:

Without rAF (BAD): READ → WRITE → PAINT → READ → WRITE → PAINT
With rAF (GOOD): READ → READ → WRITE → WRITE → PAINT

Additionally, there are other helpful tips for improving animations:

Prefer transform and opacity
Avoid animating layout properties
Use rAF for scroll and mouse animations
Virtualise long lists
Reduce forced reflows
Use CSS animations where possible
Prefer GPU-based animations over JS/layout-based animations

Key Takeaways

Layout thrashing is a silent performance killer. Understanding and fixing it separates good UIs from great ones. Once you design your UI to cooperate with the browser, smooth performance becomes effortless.

Understanding RSA - The Math behind modern encryption

Gokul — Sat, 19 Apr 2025 06:05:41 +0000

As developers we often come across different encryption algorithms like MD5, AES, DES and so on, however RSA stands out because it is simple yet significant or should I say 'fascinating', so enough chit chats let us dive into how RSA actually works.

How Does RSA work ?

RSA is an asymmetric encryption algorithm that uses mainly 2 types of keys (public and private) to encrypt the data, the working of the RSA is quite simple, here is an example,

so let us assume that Steve needs to send a message to Cathy, so that message is encrypted using Steve's public key and that can only be decrypted by Cathy's private key and vice versa, this is just a vague representation of how it works, but you may think what's so fascinating about this, now let us dive deeper

Math does the magic

Ok "RSA this! RSA that! what if the keys are compromised?" might be a great question, so to answer that let us get our hands on the "Math Problem" which is used to create a public and private key pair,

we need constants such as p, q, n, e and d

step 1: Select 2 prime numbers (p and q)

let $p = 61$ $q = 53$

step 2: Find the (n)

$n = p * q = 3233$

step 3: find the Euler's totient $Φ (n)$

Euler's totient can be found by: $Φ (n) = (p - 1) * (q - 1)$ $Φ (n) = (61 - 1) * (53 - 1) = 3120$

step 4: Choose the public exponent e

e can be any number that satisfies the following

$1 < e < Φ (n)$
$e$ and $Φ (n)$ are co-primes or simply $GC D (Φ (n), e)$ should be 1

so let us assume e = 17

step 5: finding d the private exponent, the secret number

d can be arrived by applying euclidean equation such that $\ * \ e \ mod \ Φ(n) = 1$
so applying this will give $\ * \ 17 * mod \ 3120 = 1$

the above equation solves to 2753

(note: d is just the multiplicative inverse of e, to make it even simpler d is a number that 'unodoes' the effect of e)

step 6: Encryption and decryption

now since we have all the required constants, we can see the encryption and decryption.
let us assume that we have to encrypt a message m 65

cipher (c) = m^e \ mod \ n

c = 65^{17} \ mod \ 3233

c = 2790

now let us decrypt the cipher with d $message (m) = c^d \ mod \ n$ $m = 2790^{2753} \ mod \ 3233$ $m = 65$

where m is our actual message
aight !! I know too much math,so to summarize

e is public exponent
d is private exponent
n is product of p and q

so our

public key is (e,n) that is (17, 3233)
private key is (d, n) that is (2753, 3233)

So how's this math problem difficult to crack ?

So here RSA relies on a principle called prime factorization, so to simply say, it is easy to find the product (n) of 2 prime numbers (p and q) but it is very difficult to find out the 2 factors that make up the number (n) so for example:

it is easy to calculate the product of 61 and 53
but it is difficult to say the factors of 3233 especially when the size of number n is bigger

(note: here we have taken 4 digit number but in real scenario the number would be of 4096 bits)

So this mathematical property makes RSA very difficult to crack, and the important thing to note is cracking RSA is not impossible but the computing that is needed to crack it is extremely high, even for today's standards and some studies say that the computing time that is needed to crack this problem would take even decades.

So, this is how a math problem could solve the need of extremely a strong encryption mechanism and today RSA is one of the widely used encryption algorithms out there.