Core Web Vitals Google Report


Google's PageSpeed Insights report currently combines three (or four, depending on the reporting system you use) of its previously existing metrics into one section called "Core Web Vitals". This document explains those particular metrics.

Note: Site speed (performance) is not equivalent to SEO.


For your reference and for comparison purposes, we ran a PageSpeed Insights test on the CNN website, which fails the Core Web Vitals assessment on both mobile and desktop versions (April 2022). The same is true for The Washington Post and other globally renowned publications.


CNN website Core Web Vitals report for mobile (April 2022):




CNN website Core Web Vitals report for desktop (April 2022):




Publishers must balance their content presentation, site features, user-friendliness, digital revenue opportunities (e.g. ads, and sponsored content), and performance. This means that compared to a static website with evergreen content spread across a handful of pages, a digital publication will always score much more poorly. The report does not take individual website requirements into consideration.


Note: You will find guidelines listed below the individual metrics with instructions to "minimize main thread work" or "remove unused JavaScript", for example. For explanations of these and other suggestions for improvement provided by the Google report that aren't outlined here, please review the following help document: PageSpeed Insights Report



First Contentful Paint (FCP)

Here are excerpts from Google's documentation defining the FCP metric:

The First Contentful Paint (FCP) metric measures the time from when the page starts loading to when any part of the page's content is rendered on the screen. For this metric, "content" refers to text, images (including background images), <svg> elements, or non-white <canvas> elements.

FCP marks the first point in the page load timeline where the user can see anything on the screen.

To provide a good user experience, sites should strive to have a First Contentful Paint of 1.8 seconds or less.

This means that the FCP metric is designed to find resources such as scripts or CSS stylesheets that may be impeding page elements from rendering quickly.



Largest contentful paint (LCP)

Here are excerpts from Google's documentation defining the LCP metric:

Largest Contentful Paint (LCP) marks the point in the page load timeline when the page's main content has likely loaded.

LCP is the amount of time to render the largest content element visible in the viewport, relative to when the page first started loading. The largest element is typically an image or video, or perhaps a large block-level text element.

To provide a good user experience, sites should strive to have Largest Contentful Paint of 2.5 seconds or less.

Caution: Since users can open pages in a background tab, it's possible that the Largest Contentful Paint will not happen until the user focuses the tab, which can be much later than when they first loaded it.

In other words, LCP only measures partial load time of a page: that of the largest item above the fold. You may find a link to that item in the LCP section of the report. If it is an image, you could consider reducing its file size. PNG images tend to be very large compared to JPGs, for example. Lossless Image Compression is also always a good thing for site performance.

However, every time a website user opens a link from their search engine results or from within your site in a new tab, without immediately switching to that tab, it will skew the results for the LCP to a lower score. Google does not provide numbers detailing how often this may or may not occur for your site in the report.



First input delay (FID)

Here are excerpts from Google's documentation defining the FID metric:

First Input Delay (FID) is a metric that measures a page's responsiveness during load. As such, it only focuses on input events from discrete actions like clicks, taps, and key presses.

It is the time from when a user first interacts with your page (when they clicked a link, tapped on a button, and so on) to the time when the browser responds to that interaction. This measurement is taken from whatever interactive element that the user first clicks. This is important on pages where the user needs to do something, because this is when the page has become interactive.

To provide a good user experience, sites should strive to have a First Input Delay of 100 milliseconds* or less.

Gotchas: FID only measures the "delay" in event processing. It does not measure the event processing time itself nor the time it takes the browser to update the UI after running event handlers. While this time does affect the user experience, including it as part of FID would incentivize developers to respond to events asynchronously—which would improve the metric but likely make the experience worse.

* 100 milliseconds = 0.1 seconds

Rest assured that Metro Publisher developers understand the FID metric, including the difference between asynchronous and synchronous event handling. Metro Publisher follows best practices for user experience and performance. Global web standards and best practice are not based on Google metrics alone.



Cumulative Layout Shift (CLS)

Here are excerpts from Google's documentation defining the CLS metric:

Cumulative Layout Shift is the amount that the page layout shifts during the loading phase. The score is rated from 0–1, where zero means no shifting and 1 means the most shifting.

CLS helps quantify how often users experience unexpected layout shifts. This is important because having pages elements shift while a user is trying to interact with it is a bad user experience. If you can't seem to find the reason for a high value, try interacting with the page to see how that affects the score.

Unexpected movement of page content usually happens because resources are loaded asynchronously or DOM elements get dynamically added to the page above existing content. The culprit might be an image or video with unknown dimensions, a font that renders larger or smaller than its fallback, or a third-party ad or widget that dynamically resizes itself.

In other words, this is about ads, other images, and 3rd party widget loading, i.e. display times, and since we implement lazy loading (on purpose for performance), that is also a trigger for this Google report. Please note that we cannot influence third-party codes and the resources they consume.

Lazy loading means images won't load until users scroll, so therefore, text will load first on any image-heavy site, especially when those images aren't compressed to an ideal file size. This is to save time on loading your pages for the visible area in readers' browser windows.

Improving CLS means that the browsers would have to know the space that the image will need before that image loads, which is difficult with CSS and responsive design in play. At Metro Publisher, we have already implemented all the best practice features we can for the CLS metric.

As long as website pages aren't jumping a lot for readers, which is what the CLS metric is about, then it's not really an issue. CLS is trying to measure user experience, rather than technical errors.

That being said, there are things you can do to improve image loading on your site by reducing file size or especially large images, including ad creatives. That will affect the CLS. 

We have information on compressing images in Metro Publisher here:

Lossless Image Compression
Responsive Image Sizing



More Help with Core Web Vitals Metrics

Please note that any troubleshooting of third-party services as well as individual performance reviews of your site or specific pages of your site is generally outside of the scope of our standard support service.

You are welcome to submit a ticket with inquiries regarding your Core Vitals and PageSpeed Insights report and we will respond to any general questions.

Questions requiring deeper investigation will be passed along to our custom services team for a quote.


Have more questions? Submit a request


Powered by Zendesk