Google Core Web Vitals is a set of technical metrics to calculate the Quality of the user’s experience.
Google's goal is to make it easier for publishers to understand, measure, and monitor whether or not they’re providing their visitors with a good user experience.
Google will gradually update its search engine starting mid-June by combining Core Web Vitals metrics with existing Google search ranking signals.
There are three main metrics in Core Web Vitals: Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS).
Largest Contentful Paint
Largest Contentful Paint (LCP) is used to measure the render time of the largest image or text block visible within the viewport, relative to when the page first started loading.
As Teads formats are not part of the main content, always loaded asynchronously, and out of view, our impact on LCP is null.
First Input Delay
First Input Delay (FID) measures the time from when a user first interacts with a site to the time when the browser is actually able to respond to that interaction.
Many actions have been undertaken by Teads to:
minimize code size & impact
optimize network usage
limit creative’s weight
Cumulative Layout Shift
Cumulative Layout Shift (CLS) measures how often users experience unexpected visual changes on a web page.
Teads has removed all format animations causing layout shift, so our direct impact on CLS is null.
But depending on the integration, ads can have an impact on CLS.
Layout shifts especially happen when a publisher is using:
- Collapse/Expand Banner ads
- Using responsive ads (like our inRead)
- Using Multiple Size in a single slot on HB
As a rule of thumb, the easiest solution to fix CLS issue for a Publisher is to reserve the space for every visual element before they are loaded
Solutions for Layout Shift
Question #1: Banner Slots Expand or Collapse
Many publishers are either collapsing the ad slots when there is no ad to display. Or waiting for the 3rd party partner to expand the slot when there is an ad. This introduces unwanted layout shifts of the web elements on the page.
Solution
To mitigate the impact of layout shift, Publishers should ensure that:
The ad slots that are likely to be filled should always start out ‘expanded’ with the proper space available.
The ad slots that are unlikely to be filled should always start out ‘collapsed’.
Question #2: inRead Slots
Our inRead slots do not specify a fixed set of ad sizes and automatically resize to fit the ad creative. Due to this, publishers cannot reserve the exact ad space for the inRead ad slots prior to requesting ad content.
Solution
To mitigate the layout shift, publishers should try to:
Always put Teads below-the-fold (BTF) so we can expand without any CLS impact
Fetching Teads ad as soon as possible so that by the time users view the ad slot, Teads is already resized and fully loaded.
Question #3: Banner multi-size on HB
As we said earlier, the layout shift can be avoided for banner ads by reserving enough ad space. But this method works fine for static ad slots, not for multi-size ad slots when Publishers can declare a list of available sizes for a single slot in their HB config.
Solution
For multiple size ads, publishers should:
Reserve space for the largest ad size configured to serve
This suggestion comes with a drawback as the ad creative served may be smaller than the reserved ad size. When this happens, users will see blank spaces around the ad.
Question #4: Smart & Slider
Sticky placements, like Teads Smart and Teads Slider, do no create any additional layout shift as they appear on top of existing content.
Of course, as the Smart start as an inRead, the inRead position can create some layout shift (see issue 2). But the Smart behavior doesn't add any extra layout shift.
What is Google Core Web Vitals?