![](https://www.admonsters.com/wp-content/uploads/2020/07/Ad_Tech_Health_Check_660x320.png)
Web publishers have always had reason to strive for speedy page loads.
Users like going to sites with quick-loading content and snappy responses to their clicks; page performance is a crucial element of good UX, and strong user experience helps build repeat visits and longer page sessions.
But with Google’s end-of-May announcement that they will be using Google Pagespeed Insights metrics as a major part of search engine rankings a few months from now, publishers are suddenly scrutinizing page performance—and worried about how ads affect their metrics.
Pagespeed Insights reports on a wide range of page performance data, but Google is most concerned about three metrics that make up its “Core Web Vitals:”
- LCP (Largest Contentful Paint) measures how long it takes for the user to see the biggest chunk of content on the page. Think of this as a measurement of page loading speed.
- FIP (First Input Delay) measures the time it takes for a user’s interaction – a click on a link or button, an attempt to fill out a form – to register. Good FIP means a site that feels responsive when you try to interact with it; sites with bad FIP feel laggy.
- CLS (Cumulative Layout Shift) measures whether the visible part of the page moves around while the page is loading. Moving elements are bad, both because they make the page to use while it’s loading, and because of the potential for misclicks.
Poorly-implemented website ad tech can cause problems with all three of these metrics, but even when well-done, adtech can impact LCP and CLS.
Historically, many publishers have chosen to load ads as quickly as possible, aiming to maximize revenue by getting ads in place before the user clicks elsewhere; however, this strategy can backfire by increasing LCP. Why? It’s simple: if the browser is taking time to run header bidding auctions or talk to an ad server, then some of the resources it has are “distracted” with this effort, so it has fewer resources to devote to loading content.
The result? Your content loads a little later, and your LCP goes up. Well-engineered code helps, but there is nevertheless a fundamental conflict between loading ads early and loading content early.
CLS, meanwhile, will get triggered any time you embed ads directly in your page. “Sticky” ads that float above the page aren’t a problem, because they don’t move your content around when they load. But embedded ads push content down when they appear, and that’s exactly what Google does not like.
So how do you solve these problems?
At Playwire, we have taken two approaches which you can mimic as well. First, we offer our publishers the option to use delayed ad loading, in order to eliminate LCP problems. Working in conjunction with one of our customers, we researched and experimented with the LCP measurement.
We found that if ad-loading scripts did not execute immediately, but instead waited a couple of seconds after the “DOMContentLoaded” to run, then the LCP hit from ads could be entirely eliminated. So now this is a standard option we give our publishers: a one-liner they can put in if they are willing to trade ad speed for content speed.
Second, all of our embedded ads now have a visible placeholder in the page before the ad loads. When the ad is ready, it replaces the placeholder. The result? No shifting of content, no CLS hit.
If you haven’t yet reviewed your site’s Core Web Vitals, check them out now. Are your LCP and CLS in the green? If they aren’t, your search engine results will be in jeopardy as you enter 2021—and your ad tech could be to blame.