In May, Google began implementing new metrics for Google Search ranking — Core Web Vitals — with rollout slated to be complete in August.
Core Web Vitals measure page loading, interactivity and visual stability by identifying ranges of performance times for each metric. To then identify the performance of a page or site overall, the 75th percentile measurement is used — if at least 75% of page views meet the “good” threshold, then the site gets strong marks for that metric. Now, publishers are working to understand how to optimize their websites in response to the new metrics, ensuring robust search rankings and improved customer experiences.
While best practices are emerging around each element of Core Web Vitals, page load time (PLT) has taken center stage for many publishers working on the challenge.
“Focus first on time to first byte (TTFB), then time to paint (TTP) and time to interactive (TTI),” said Stephen Flee, CTO of Revcontent, regarding the page load projects publishers are facing. “And this last one is perhaps the most important but can also be the most difficult to get right.”
In the sections that follow, Flee breaks down essential approaches to conquering the Core Web Vitals equation — tips and tactics for publishers working on all aspects of Google’s new systems.
PLT success often comes down to a metric — time to interactive
At the center of Core Web Vitals is the metric of PLT — as improving page load time reduces bounce rates, improves customer satisfaction, revenue per session and more.
Within the overarching outcome of PLT, the time to first byte indicates how long it takes for a user’s browser to receive a response from the site’s server, TTP marks the point when the page’s main content has loaded — i.e., the perceived load speed — and TTI measures the time it takes from when a page starts loading until it’s fully interactive.
There are few things more frustrating for users than prolonged TTI. Flee offered an example: A user is on a website and can see the images and everything looks fine but once they go to scroll and click, nothing happens.
The key to solving TTI lag? “That is most likely a result of having too much JavaScript on the page,” said Flee, and there are steps publishers can take to avoid it.
Beyond TTI, shifting page elements influence Core Web Vitals scores
For publishers hosting content on behalf of advertisers and other brands, it’s important to have a low TTI.
“Space real estate to the lowest common denominator,” said Flee at Revcontent, regarding the key tactic for improving the time to interactive. “That’s something publishers can do to try to help — that, and having the ad load in a more standardized spot.”
Another metric, cumulative layout shift (CLS) can be seen as an extension of ways to improve TTI. Quantifying how often users experience an unexpected shift in page elements, CLS is a measure of how elements such as ads, images and text alter or interrupt the way audiences interact with the page.
Jeff Moriarty, executive vice president and Chief Product Officer at Nexstar, explained how important CLS is for his team. “We have seen our Core Web Vitals scores really go up when we improved mostly CLS. Locking in ad sizes does make a big difference. It can have a revenue impact because there isn’t as much flexibility, but that was one of the first ones we saw that moved the needle for us.”
For publishers, both Flee and Moriarty recommended lightening up JavaScript to improve everything from TTFB to CLS as well. Moriarty emphasized that it’s important to work collaboratively on the challenge: “The key is having advertising partners to work with to make the load only what’s needed; so, sometimes a little bit of customization is worth it — and definitely worth it on speed.”
Testing, testing and more testing
Audience expectations for fast, frictionless mobile experiences are rising, but many sites are falling short — with 70% of mobile landing pages taking more than five seconds to load visual content above the fold. About 47% of users expect pages to load in two seconds or less, marking a wide gap.
With that detail in mind, when it comes to improving Core Web Vitals scores, it’s important to keep both mobile and desktop versions in mind. One approach is to use Google Lighthouse or developer tools within Chrome to test performance. The latter makes it easy to get more people involved in testing. Flee also recommends throttling to see what the website looks like on mobile as well as on fast-versus-slow 3G. “Developers are writing the software for their desktop,” Flee said. “They’re testing it on their desktop and they don’t really have the diligence to test it on mobile devices and especially not on lower end mobile devices — they always have the newest phone and the best hardware.”
Next steps for publishers to succeed at Core Web Vitals
Google’s Core Web Vitals have made it urgent for publishers to stay ahead of problems that can slow down their sites.
“If there’s a small blip in delivery, it affects publishers. It’s the same deal with a lot of these video providers,” said Flee. “I think that’s where publishers need to focus their efforts when it comes to demand-side platforms (DSPs) and banner inventory. With everything that happens in programmatic, it’s so hard to track.”
While some publishers may take this as a sign to quickly get to a page speed score of 100, Flee advises against this, “I don’t think they need to be there, but there’s certainly a lot of publishers sitting at 45 where they have a lot to do and it will have an impact.”
Furthermore, focusing on speed will improve many metrics, such as pages per session, said Moriarty. Once a site loads quicker, ads and content can be delivered faster — making both advertisers and users happy.
“At the end of the day, write good headlines, create content that people want to read and make sure it loads quickly,” Moriarty said. “It’s simple but those are the things that matter. And the quality content that people want to read is the most important piece still.”
The post How publishers are rethinking programmatic marketing in the core vitals space appeared first on Digiday.