Do Pop-ups Hurt Core Web Vitals? CLS, INP and Overlays Explained

The short answer

A pop-up drawn on top of the page — a modal, a floating box, or a bar that overlays the header — usually does not cause layout shift, because nothing on the page moves. A pop-up inserted into the page — a bar that pushes the whole site down, or a banner injected between paragraphs — moves content that was already there, and that is exactly what CLS measures. Separately, every tap on a pop-up is an interaction that INP can measure, and a large pop-up image that appears early can become the page’s LCP element.

Core Web Vitals in one table

Google’s web.dev defines three Core Web Vitals and a “good” threshold for each. It recommends measuring them at “the 75th percentile of page loads, segmented across mobile and desktop devices” (web.dev, Web Vitals). INP replaced First Input Delay and, per the same page, “became a stable Core Web Vital metric in 2024.”

Thresholds are from web.dev’s articles on LCP, INP and CLS. As for search, Google states that “Core Web Vitals are used by our ranking systems,” and also that good scores do not guarantee “that your pages will rank at the top of Google Search results” (Google Search Central). They are worth getting right mostly because they describe what visitors actually feel.

How CLS is measured, and why it matters for pop-ups

Four details in web.dev’s CLS article decide whether a pop-up counts against you (web.dev, CLS):

1. Only existing content moving counts. “Layout shifts only occur when existing elements change their start position.” Adding a new element is not a shift by itself; it becomes one only if it moves other visible elements.
2. CLS is the worst burst, not the total. Shifts that happen close together are grouped into a session window, “with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration.” CLS reports the largest window.
3. Shifts right after a tap or click are excluded. “Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set” and are not counted.
4. Scrolling is not that kind of input. The article says continuous interactions such as “scrolls, drags, or pinch and zoom gestures are not considered ‘recent input’.” A shift triggered by scrolling still counts.

Put together, these rules explain the whole topic. A modal that appears over the page adds an element but moves nothing, so it is not a layout shift. A bar that slides in at the top and pushes the page down moves everything below it, so it is. And because pop-ups are usually triggered by time or by scrolling — not by a click — that shift does not get the 500-millisecond exemption. A scroll-triggered bar that pushes content down is close to the worst case: it moves content while the visitor is reading, and the trigger itself is excluded from “recent input.”

The opposite case is also useful to know. If a visitor taps a “Show offer” button and a panel opens inline within half a second, that shift is expected and excluded. CLS penalizes surprise, not change.

Overlay versus content-pushing: format by format

web.dev’s guide to optimizing CLS describes the same split for notices such as cookie banners: either “reserve sufficient space in the viewport for it in advance (for example, using a placeholder or skeleton UI)” or “ensure the element is not part of the document flow by overlaying the content where this makes sense.” It also warns that “dynamically injected content closer to the top of the viewport usually causes greater layout shifts” (web.dev, Optimize CLS).

If you want a bar that pushes content

There are good reasons to want a push-style bar: an overlay bar covers your logo, menu or cart icon, which can be worse for visitors than a small shift. If you choose to push content, reduce the impact:

1. Show it as early as possible. A bar that appears with the page — before anyone starts reading — disturbs far less than one that drops in after several seconds or partway down the page.
2. Reserve the space if your site lets you: a fixed-height slot at the top of the layout that the bar fills, so nothing moves when it arrives.
3. Keep its height stable. A bar whose text wraps differently after a web font loads, or that grows when a countdown starts, shifts the page a second time.
4. Consider the bottom of the screen. A bar fixed to the bottom of the viewport overlays content instead of pushing it, and rarely covers the header.
5. Avoid scroll triggers for push bars. Since scrolling is not “recent input,” a push bar triggered by scrolling is counted every time.

When the bar is closed, the page moves back up. A close that follows a tap usually falls within the 500-millisecond window and is excluded, but a bar that disappears on its own after a timer is not, so avoid auto-dismissing push bars.

Animations: transform is safe, layout properties are not

Slide-in and zoom effects are popular for pop-ups. How they are built matters. web.dev’s CLS article recommends using transform: scale() instead of changing height or width, and transform: translate() instead of changing top, right, bottom or left. The optimization guide explains that “composited animations using translate can’t impact other elements, and so don’t count toward CLS” (web.dev, Optimize CLS).

For an overlay pop-up this is mostly about smoothness, since nothing behind it moves anyway. For anything in the document flow — a push bar, an inline banner, an accordion — animating height is a layout shift on every frame. The CLS article also asks you to respect the prefers-reduced-motion setting, which is good practice for any entrance animation.

Pop-ups and INP

INP measures “a page’s overall responsiveness to user interactions,” counting mouse clicks, taps and key presses. web.dev breaks each interaction into three parts: “the input delay,” “the processing duration” and “the presentation delay,” ending when the next frame is shown (web.dev, INP). Scrolling and hovering are not counted.

A pop-up adds interactions to the page: tapping the close button, tapping outside a modal, typing an email address, pressing submit. Each one is measured like any other. Common ways a pop-up makes them slow:

web.dev’s INP optimization guide adds that breaking up long tasks — “yielding” to the main thread — keeps work from blocking the next frame, and that large DOMs “require more work to render than small DOMs” (web.dev, Optimize INP). The practical rule for a pop-up: the close button should make the pop-up disappear on the very next frame. If closing feels laggy on a mid-range phone, that is an INP problem worth fixing.

Can a pop-up become the LCP element?

Yes, in some cases. LCP looks for the largest image, text block or video in the viewport, and web.dev explains that when a larger element is rendered later, “a new PerformanceEntry will also be reported.” Crucially, “the browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress)” (web.dev, LCP).

So a pop-up with a large image that appears immediately on load, before the visitor does anything, can be picked as the largest element. If that image is slow to load, your LCP becomes the pop-up’s load time instead of your hero image’s. The same article notes that Chromium ignores “elements that cover the full viewport, that are likely considered as background rather than content,” so a full-screen dimmed overlay is not the concern — the image inside it may be.

1. Delay the pop-up until after a few seconds or some scrolling. Once the visitor has scrolled or tapped, LCP stops updating, so the pop-up can’t replace the LCP element.
2. Keep pop-up images small in file size and dimensions, especially on mobile.
3. Don’t let the pop-up compete with the page for the first seconds of loading. The content the visitor came for should load first.

Why your lab score may not show the problem

Many people test a page in a lab tool, see a good CLS score, and conclude the pop-up is fine. web.dev explains why that can be misleading: “CLS measured in the lab only considers layout shifts that occur above the fold and during load,” whereas in the field “CLS considers all unexpected layout shifts that occur throughout the lifespan of the page.” Shifts that happen after scrolling “often won’t be caught in a lab test.” For INP, lab tests “cannot accurately predict when users will choose to interact with a page” (web.dev, lab and field data).

A pop-up that appears after 10 seconds or at 50% scroll is exactly the kind of thing a lab load test can miss. Use field data instead. Search Console’s Core Web Vitals report shows “how your pages perform, based on real world usage data,” taken from the Chrome UX Report, with mobile and desktop listed separately and URLs grouped into pages with similar experience (Search Console Help). Low-traffic pages may not have enough data to appear, so expect gaps on a small store.

Testing a pop-up yourself

1. Note the trigger and format of each active pop-up: when it appears, where, and whether it overlays or pushes.
2. Open the page on a phone and watch for movement when the pop-up appears and when it closes. If the text you were reading jumps, that is a layout shift.
3. Repeat the trigger by hand: wait the configured seconds or scroll to the configured depth, since lab tools won’t.
4. Tap close on a mid-range phone and check that it disappears immediately.
5. Compare field data before and after launching a pop-up in Search Console, keeping in mind that the report needs time and traffic to update.
6. Check the rest of the page’s stack. If you run several third-party tools — chat, reviews, pop-ups — each adds script work that can slow interactions.

Core Web Vitals are not the whole story

A pop-up can score perfectly on CLS and still be a poor experience. A full-screen modal over a page someone just arrived on moves nothing, so CLS ignores it, but Google’s separate guidance asks you not to “obscure the entire page with interstitials” and to “use banners that take up only a small fraction of the screen” instead (Google Search Central). Treat CWV and intrusive interstitials as two checks: does the pop-up move the page, and does it block the page?

How marketingLABO inserts pop-up banners

If you use marketingLABO, here is how its banners behave in these terms. The tag you add to the <head> of each page loads the banner after the page has loaded and adds it at the end of the page. Modals, floating boxes and bars are displayed in a fixed layer over the page, so showing them or animating them in does not move your content.

The block option for top bars exists for sites where covering the header is the bigger problem. If you use it, follow the push-bar advice above. Separate desktop and mobile images, device targeting (all, mobile only or desktop only) and the show-immediately / after-N-seconds / scroll-depth triggers help you keep large creatives off small screens and out of the first seconds of loading. The Free plan includes one pop-up banner along with analytics and heatmaps; see pricing for Light and Standard limits, or create a free account.

For what to put inside the pop-up, see Email Sign-up Pop-ups, Free Shipping Banners and Countdown Timer Pop-ups.

Frequently asked questions

Does a modal pop-up count as a layout shift?

Not if it is drawn over the page. A layout shift requires existing elements to change position; adding an overlay doesn’t move anything underneath. It can still be an intrusive interstitial if it covers the page.

Is a sticky announcement bar bad for CLS?

A bar that overlays the screen is not. A bar that is inserted into the page after it renders and pushes content down is, and the later it appears, the worse.

Does closing a pop-up cause a layout shift?

Closing an overlay doesn’t. Closing a push bar moves the page back up, but if it happens within 500 milliseconds of the tap it is excluded. Bars that close on their own are not excluded.

Why does a speed test show a good CLS when my pop-up obviously shifts the page?

A lab test loads the page once and measures during load. A pop-up that appears later or after scrolling is often never triggered. Look at field data, and test the trigger by hand.

Should I remove pop-ups to pass Core Web Vitals?

Usually not. Start by finding out which metric is failing in your field data. If it is CLS, switch push-style bars and injected banners to overlays or reserve their space. If it is INP, look at the total script load and at what happens when people tap. If it is LCP, delay large pop-up images. Removing everything is the last resort, not the first step.

Summary

Pop-ups don’t automatically hurt Core Web Vitals. Overlays — modals, floating boxes and overlay bars — don’t move content, so they don’t add to CLS. Bars and banners that push content down do, especially when they appear late or on scroll. Every tap on a pop-up counts toward INP, so closing should be instant, and a large image shown immediately can become the LCP element. Check field data rather than lab scores, and keep Google’s intrusive interstitial guidance in mind as a separate test.

Sources

1. web.dev, “Web Vitals” (last updated October 31, 2024; accessed October 12, 2026): https://web.dev/articles/vitals
2. web.dev, “Cumulative Layout Shift (CLS)” (last updated April 12, 2023; accessed October 12, 2026): https://web.dev/articles/cls
3. web.dev, “Optimize Cumulative Layout Shift” (last updated February 7, 2025; accessed October 12, 2026): https://web.dev/articles/optimize-cls
4. web.dev, “Interaction to Next Paint (INP)” (last updated September 2, 2025; accessed October 12, 2026): https://web.dev/articles/inp
5. web.dev, “Optimize Interaction to Next Paint” (last updated September 2, 2025; accessed October 12, 2026): https://web.dev/articles/optimize-inp
6. web.dev, “Largest Contentful Paint (LCP)” (last updated September 4, 2025; accessed October 12, 2026): https://web.dev/articles/lcp
7. web.dev, “Why lab and field data can be different (and what to do about it)” (last updated July 18, 2022; accessed October 12, 2026): https://web.dev/articles/lab-and-field-data-differences
8. Search Console Help, “Core Web Vitals report” (accessed October 12, 2026): https://support.google.com/webmasters/answer/9205520
9. Google Search Central, “Understanding Google Page Experience” (last updated September 22, 2026; accessed October 12, 2026): https://developers.google.com/search/docs/appearance/page-experience
10. Google Search Central, “Avoid intrusive interstitials and dialogs” (last updated December 10, 2025; accessed October 12, 2026): https://developers.google.com/search/docs/appearance/avoid-intrusive-interstitials