This content originally appeared on Web Performance Calendar and was authored by Andrea Verlicchi
Even though Cumulative Layout Shift (CLS) has been a well-known metric for about five years now, I still frequently encounter negative scores on major websites during my web performance audits.
The most frequent causes of CLS I encounter fall into two categories:
- Promotional banners at the top of the page, which appear with a slight delay, pushing all content down just as the user is reading or about to click a call to action—often leading them to click the wrong link entirely.
- Dynamic loading of new content (such as on product listing pages) when the user scrolls to the end of the page. This generates CLS because the new elements push the footer out of the visible portion of the site (the viewport).
The first case is quite common, and I have already addressed it in a previous article: Mitigating CLS Caused by Promotional Banners: A Practical Solution.
In this article for the Advent Calendar, I will specifically address case #2: the CLS caused by loading new content, which is typical of e-commerce sites.
Modes of Dynamic Loading
Dynamic content loading generally happens in one of two ways:
- Automatically (Infinite Scroll): Triggered when the user reaches the end of the visible content.
- Manually: Triggered when the user presses a “Load more” button.
Both modes can cause a frustrating user experience and a high CLS score. The problem for developers is that, because these shifts occur after the initial page load, they often escape basic automated testing tools.
The Rules of the Game: The 500ms Tolerance
To understand how to solve the problem, we must remember how CLS is measured. There is a 500ms tolerance window starting from a user interaction: if the layout shifts within this timeframe, the shift is excluded from the CLS score.
Be careful, though: scrolling is not considered a valid user interaction for resetting the CLS timer. Valid interactions include clicks, screen taps, and key presses.
So, when we add content, we must handle two distinct scenarios.
Scenario 1: Automatic Loading (Infinite Scroll)
In this scenario, the user is simply scrolling the page. There is no click involved, so we do not get the 500ms “grace period.” Any layout movement here will negatively impact your Core Web Vitals.
The problem usually manifests like this:
- The user scrolls to the bottom.
- The footer enters the viewport.
- New content loads and is inserted above the footer.
- The footer is suddenly pushed down, out of view. CLS Penalty!
The Solution: Skeleton Screens
To prevent this shift, you must ensure the footer never enters the viewport before the content above it is ready.
The solution is to append a Skeleton Screen (a set of gray placeholders) the exact moment the data fetch begins. These placeholders must have a height roughly similar to the incoming content.
By reserving the space immediately, the scrollbar behaves naturally, and the footer remains “pushed” down in its correct position. When the real data arrives, you simply swap the skeleton for the actual product cards. Since the dimensions match, no visual shift occurs.
See it in action:
Scenario 2: The “Load More” Button
If you require users to manually click a button, you have an advantage: the click opens the 500ms tolerance window.
Here, you have two options:
- The Fast Fetch: If you are certain your API will respond and the browser will render the new content within 500ms, you technically don’t need a skeleton. However, relying on the user’s network speed is very risky. If the response arrives after 600ms, you will get a CLS penalty.
- Immediate Placeholders (Recommended): The safest approach is to treat this exactly like the infinite scroll. As soon as the user clicks, insert the skeletons immediately.
By doing this, the layout expansion (inserting the skeletons) is guaranteed to happen within 500ms of the click. When the network finally responds (even if it takes 2 seconds), you are simply replacing pixels within an already allocated area, without causing any layout shifts.
See the difference:
- Demo B1 — No skeleton, content injected late (Bad CLS)
- Demo B2 — No skeleton, content injected immediately (Good CLS)
- Demo B3 — With skeleton, content injected later (Good CLS)
Lessons from the Field
During my web performance audits, I always advise my clients to adopt these measures.
These specific CLS issues are often the most “invisible” and difficult to spot because they slip past automated checks that only analyze the initial page load without simulating deep scrolling. However, once resolved by correctly reserving space, the impact on visual stability and the user’s perceived quality is immediate.
The Golden Rule
Whether you are building a simple blog or a complex e-commerce storefront, the golden rule for avoiding CLS remains the same:
Don’t move any visible portion of the page while users are scrolling. You are allowed to shift the layout only if the user has explicitly requested it (with a click), and even then, you must be quick (under 500ms). For everything else, reserve the space before the content becomes visible.
Happy holidays, and may your layout shifts be zero!
This content originally appeared on Web Performance Calendar and was authored by Andrea Verlicchi
Andrea Verlicchi | Sciencx (2025-12-20T08:22:39+00:00) Optimizing CLS for Infinite Scroll and Load More. Retrieved from https://www.scien.cx/2025/12/20/optimizing-cls-for-infinite-scroll-and-load-more/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.