Adding ad units to a site is one of the few changes that degrades all three Core Web Vitals at once, through three unrelated mechanisms. Most guides talk about layout shift and stop there, which leaves you fixing a third of the problem.<\/p>\n\n\n\n
I am going through this on my own site right now, so this is written from the position of someone who has to live with the result rather than someone recommending it from a distance.<\/p>\n\n\n\n
An ad container starts at zero height. The script resolves, an iframe lands, and everything below jumps down by however tall the creative turned out to be. If that happens after the user began reading, you have a layout shift, and if it happens while they were reaching for a link you have an accidental click.<\/p>\n\n\n\n
The complication with automatic ad placement is that you do not know in advance where the units will go or what size they will be, which makes reserving space for them structurally harder than for a unit you placed yourself.<\/p>\n\n\n\n
Ad scripts compete for bandwidth and main thread time with the resources that render your largest element. A hero image that used to arrive in 1.4 seconds now queues behind a third party script chain that itself calls further scripts.<\/p>\n\n\n\n
Worse, if an ad unit sits above the fold and renders large, the ad iframe can itself become your LCP element. You are then optimising a metric measured against something you do not control and cannot preload.<\/p>\n\n\n\n
Ad scripts run long tasks. While one is executing, the main thread cannot respond to a tap. The user presses your menu button, nothing happens for 300 milliseconds, and your interaction latency degrades even though your own code is fast.<\/p>\n\n\n\n
This is the hardest of the three to fix because the work is not yours. Mostly you manage it by limiting how many units load and how early.<\/p>\n\n\n\n
The standard advice is to give every ad container a fixed height. That works and it is also the reason ad heavy sites have large empty gaps when a unit does not fill.<\/p>\n\n\n\n
A better default is a minimum height sized to the most common creative for that slot, rather than a fixed height sized to the largest possible one.<\/p>\n\n\n\n
.ad-slot {\n min-height: 280px; \/* common in-article rectangle *\/\n display: block;\n contain: layout; \/* isolate its layout from siblings *\/\n}\n\n@media (max-width: 480px) {\n .ad-slot { min-height: 250px; }\n}<\/code><\/pre>\n\n\n\nTwo details matter here. Set the reservation per breakpoint, because mobile and desktop creatives differ and a desktop sized reservation on a phone is a screen of nothing. And use contain: layout<\/code> so that changes inside the slot do not force layout recalculation of everything around it.<\/p>\n\n\n\nIf a slot renders shorter than reserved you get a gap, which is a visual cost. If it renders taller you get a shift, which is a metric cost. Bias toward the gap.<\/p>\n\n\n\n
Placement rules that hold up<\/h2>\n\n\n\n\n\n- Nothing above the fold on mobile.<\/strong> A unit there competes directly with LCP and is the most likely to shift content the user is already reading.<\/li>\n\n\n
- First unit after the second or third paragraph,<\/strong> not immediately after the title. This also protects the part of the page a reader uses to decide whether to stay.<\/li>\n\n\n
- Never inside the flow of a code block, table, or list.<\/strong> On a technical blog this destroys the readability the reader came for.<\/li>\n\n\n
- Exclude your conversion pages.<\/strong> Home, contact, portfolio, pricing. On a personal site these are where a client or recruiter lands, and the revenue from ads there is rounding error against one contract.<\/li>\n\n\n
- Cap the count per page.<\/strong> Each unit is more script, more long tasks, more INP. Beyond a handful the marginal revenue per unit falls while the performance cost stays linear.<\/li>\n\n<\/ul>\n\n\n\n
Loading strategy<\/h2>\n\n\n\n
The provider’s script goes in the head as async, which is what they specify and which is correct for their measurement. What you control is what else is competing at that moment.<\/p>\n\n\n\n
Preconnect to the ad origin so the connection is warm before the request goes out. Preload your LCP image so it is not queued behind third party work. And defer everything of your own that is not needed for first render, because the ad script is going to take the thread whether you are ready or not.<\/p>\n\n\n\n
For units far down a long article, lazy loading them when they approach the viewport is worth doing. It reduces the script work during initial load, which helps LCP and INP, at the cost of a slightly higher chance of shift when they arrive. Reserve space and that trade is favourable.<\/p>\n\n\n\n
Measure before, not after<\/h2>\n\n\n\n
Take a baseline before you enable anything. Lighthouse on your three highest traffic templates, mobile profile, and note the numbers somewhere you will find them again.<\/p>\n\n\n\n
Without a baseline you will not be able to tell whether ads cost you fifteen points or five, and that number is the input to the only decision that matters: whether the revenue is worth the degradation.<\/p>\n\n\n\n
Lab scores also vary run to run by a noticeable margin, so do not chase small differences. Field data from real users is the number that reflects experience, and it takes weeks to accumulate. Plan for that lag rather than reacting to the first lab result after launch.<\/p>\n\n\n\n
The accessibility angle nobody mentions<\/h2>\n\n\n\n
Ad units inject focusable content into your page, usually inside iframes, sometimes with their own close buttons and overlays.<\/p>\n\n\n\n
Run your keyboard pass again after enabling them. Check that iframes carry titles, that tab order still moves top to bottom in a way that matches the visual page, that no sticky or anchored unit obscures a focused element, and that a keyboard user can dismiss anything dismissible. Anchored bottom units are the usual offender: they cover the focused control at the bottom of the viewport, so the user is typing into something they cannot see.<\/p>\n\n\n\n
Your ad provider’s markup is inside your page, and from a conformance standpoint it is part of your site.<\/p>\n\n\n\n
\n\n\n\n