Skip to main content

Google Core Web Vitals: What Publishers Can Do About It

Core Web Vitals

Publishers are more concerned about site speed because of Google’s Core Web Vitals roll out in June.  Its focus and effect are on search results and search engine optimization. Realize though, this is nothing new. Site speed was always part of Google’s 200 SERP criteria. Google is just ranking it higher, informing the public, and creating a marketing frenzy. There are a plethora of tools to give publishers insight and enable them to address site speed issues affecting their Core Web Vitals score.

Table of Contents
  • Why publishers should care about site speed
  • Definition of site speed
  • Core Web Vitals Criteria
  • Ways to improve Core Web Vitals Score
  • What NMM does to address concerns

Why publishers should care about Core Web Vitals

Websites are often a numbers game. There’s the number of users coming onto a site, then the amount of users who stay, then how much content they consume, resulting in how many impressions they are served.

Some of a user’s behavior is in the publisher’s control and that is guided by good user experience (UX) and good content. Whatever publishers can do to increase revenue for themselves, and in turn advertisers is good and generally increases value for the users (think quality content, images, relevant updates, good web flow.) Site speed, which is at the core of Core Web Vitals is another aspect that produces a win-win-win when focused on.

Google Core Web Vitals focuses on the user experience and penalizes publishers by ranking them lower on SERP if they have sites or pages that offer suboptimal experiences for users.

Definition of Site speed

Speed is a catch all term, and it’s important to understand what it specifically means in context of site speed. The same way people say the cheetah is the fastest land animal and others contend it’s the pronghorn, they’re both right, they’re just using different more specific evaluations (for those curious, the cheetah wins in speed, but only over a short distance, the pronghorn can maintain fast speeds over longer distances, just not as fast as the cheetah’s burst). It’s the same with Publisher’s speed. There are different aspects that make up speed. Also know, individual pages on a site may have different speeds depending on the content. Site speed is an average of all pages and taking a deep dive under the hood to get a proper handle on it may be necessary.

The following are the top three criteria that Google outlined in their Core Web Vitals: Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift

LCP – Largest Contentful Paint

57% of people leave a page if it take more than 3 seconds to load affecting Core Web VitalsThis refers to how fast the largest pieces of content loads when a user first comes to a page. This is for both mobile and desktop connections.

Speed ranges

Good – 2.5 seconds and less

Needs improvement: 2.5-4 seconds

Poor – 6 seconds +

This information is interesting considering that according to research by Unbounce  57% of people leave a page that takes longer than three seconds to load. Bear in mind the average site takes 15 seconds to fully load according to a 2019 Unbounce report. Interestingly, women are more likely to leave than men. The highest-ranking websites on Google do meet the under three seconds threshold.

While most people think they have more patience when it comes to page loading based on self-reporting, their actual data tells a different story. It seems people FEEL like they’re waiting longer than they are. Kind of like a baby crying, 5 seconds feels like 5 hours (don’t believe us, try it out.)

Good LCP score for Google Core Web Vitals is under 2.5 secondsWhen content takes too long to load users become impatient and leave the site, creating a bounce on the site. In turn this increases the bounce rate, and Google penalizes the site and may rank it lower in SERP.

Publishers often think of bounces as people leaving the page because it wasn’t what they were looking for. In this case, users are leaving before they even view the content.

Regarding running ads, the LCP is very rarely affected by ads as they’re not the largest object on the page. That honor generally goes to the content of the page that is organized by the publisher. Whether it’s images, a video or widget, making sure the largest elements are optimized is key for LCP.

 

FID – First Input Delay

FID refers to how long it takes a site to respond when a user first interacts with an element in the page like clicks on a button or a link. The action needs to be considered finite, meaning it ends, to be part of the FID criteria. Actions like scrolling and zooming in and out are continuous and therefore not considered in FID.

FID is very relevant to form fields and ecommerce sites, but less so to blog posts unless the user immediately clicks to another post.

Speed ranges

Good – 100 milliseconds (feels instant)

Needs Improvement: 100 – 300 milliseconds

Poor – anything more than 300 milliseconds (that’s .3 seconds)

Cumulative Layout Shift

This refers to how stable the content is when the user scrolls through the page. Do objects on the page shift, making the user reorient themselves? This criterion in particular is where ads come into play will be addressed further in the article.

Speed ranges

Good – 100 milliseconds (feels instant)

Needs Improvement: 100 – 300 milliseconds

Poor – anything more than 300 milliseconds (that’s .3 seconds)

Publishers can review their sites rating at

https://developers.google.com/speed/pagespeed/insights/

Or

https://www.webpagetest.org/

Lighthouse is Google’s lab test. They review the code and assess how it should perform in the real world. WebpageTest is a field test and reveals how the website responds in real time. Real time is key, because that is the actual performance of the site, not how Google thinks it may perform. Unfortunately, Google Lighthouse scores are often lower than real time tests, indicating their testing algorithm needs improvement.

The three criteria together make up a Publisher’s score, but each can be evaluated individually and then further broken down and applies to each page so publishers can understand exactly how each page is performing, and where the issues are. Armed with this information publishers can make data driven decisions on how to best improve their site.

Scores:

0 to 49 (red): Poor

50 to 89 (orange): Needs Improvement

90 to 100 (green): Good

It’s important to note that not everything site speed related is in the publisher’s hands. Things like the user device, browser, and internet connection can affect speed significantly. There comes a point where Publishers have let go and let the Google G-ds do their thing.

Ways to Improve Google Core Web Vitals

  • Remove unnecessary third-party scripts. The more scripts a site needs to run before loading, the slower it will run. Note the word unnecessary. Not all third-party scripts are bad. Publishers don’t want to lose analytics, and ad tech partners that are enabling them to generate revenue in the first place.
  • Upgrade web hosting. Cheap is tempting, but powerful web hosting will make a difference in a site’s performance.
  • Remove or reduce large page elements. This is all about finding balance between aesthetics and user experience. If a page doesn’t need rich media, remove it. Reduce the size of images, effectively making it easier and faster to load.
  • Caching your site will make it load faster for returning visitors. There are many plugins that can do this.
  • Keep in mind: Don’t lose sight of the forest for the trees. Content wins in the end over speeds, so if the third-party scripts and rich media are necessary, keep it.

What NMM does to allay these concerns

As ad partners we understand that the third-party script running on Publisher’s page may feel like a double-edged sword at times. It may be working against the Publishers on the SERP front but is also building the publisher’s revenue. There are a few ways we at NMM are mitigating the issue.

Largest Contentful Paint

As stated before, this criterion is usually irrelevant from an ads point of view as it’s not the largest content on the page and therefore is not a factor in the score.

First Input Delay

NMM containerizes the ad code to reduce the bottleneck and resulting latency. By separating the code into containers, where each packet builds on the first, but is not dependent on the previous action, this allows other elements of the page to load while the ad is pulling itself together. By “taking turns” you can avoid the code traffic jam that would otherwise happen that slows down the site, so when FID comes into play the page will have a faster response.

Cumulative Layout Shift

At NMM are experimenting with adding new container options. In this case the ad slot is always open, so the page doesn’t shift when an ad appears. There are “house ad” available when no ad is served ensuring the space is never left empty and hanging.

Another protocol is to test the site with and without ads and compare speed score to see if ads are affecting the score. Contrary to most people’s assumption, there often is no difference in the site speed. Our algorithm understands and adapts to site speed needs, so the score is unaffected. If there is a drop we do more testing, and tweak elements to bring up speed scores.

Once a publisher makes site improvement, be patient. It takes time to see changes, around 28 days for everything to refresh. So sit tight.

A note to publishers, a site with speed issues is often a sitewide issue. If your scores are low, it’s time to call a web developer, not cancel your ad revenue.

Takeaways

Speed is an overall concern for publishers, but don’t get scared by Core Web Vitals. It was always part of Google’s SERP criteria. Address it as best you can, but for a real work up a web developer is necessary.

At NMM we have a full grasp on Core Web Vitals and take great care that our code doesn’t interfere with your site.

 
 
Esther Kurtz
Esther Kurtz