Core Web Vitals Lighthouse Monitoring

This article describes ContentKing's Core Web Vitals Lighthouse Monitoring feature, which allows you to track the Web Vitals metrics for every page on your website and work with them in the same way as with all the other properties and metrics ContentKing monitors.

Metrics

For every page, ContentKing monitors the following Web Vitals metrics:

  • Performance
  • First Contentful Paint
  • Time to Interactive
  • Speed Index
  • Total Blocking Time
  • Largest Contentful Paint
  • Cumulative Layout Shift

You can read more about these metrics in this dedicated Academy article: Core Web Vitals Explained (opens in a new tab).

Working with the Web Vitals metrics in ContentKing

Once enabled, you can work with the Web Vitals metrics across the whole platform, same as with the other page properties and metrics ContentKing is monitoring.

Using the Web Vitals data in Pages

Each Web Vital has its own dedicated column on the Pages screen which you can use for filtering:

Screenshot showing filtering on the Core Web Vitals data on the Pages screen in ContentKing

When filtering on the Web Vitals data, you can easily create segments which can be very useful when targeting your highest or lowest performing pages.

You can also use the Graphs view to quickly spot how your pages are doing in terms of the different Web Vitals metrics:

Screenshot showing the charts with Core Web Vitals data on the Pages screen in ContentKing

On the page detail screen, you will always see the Web Vitals data for the given page:

Screenshot showing the Core Web Vitals data for a specific page in ContentKing

And in the Tracked Changes tab of the page detail screen you will also see the full log of how the Core Web Vitals metrics changed over time:

Screenshot showing the tracked changes of the Core Web Vitals data for a specific page in ContentKing

Using the Web Vitals data in Issues

The ContentKing Lighthouse Web Vitals have a dedicated category in the Issues section.

In the issue category, the Web Vitals metrics are being audited separately on each page as well as on the whole website overall:

Screenshot showing the Core Web Vitals issues in ContentKing

This allows you to easily zoom in on the parts of the website where the Web Vitals experience is poor or needs improvement, and prioritize among the other issues that are being detected across the website, based on the impact on the Website Health.

You can read more about the Issues section in ContentKing here: Issues

Using the Web Vitals data in Alerts

ContentKing will proactively alert you when your pages’ Performance score or any of the other Web Vitals drop below good.

Screenshot of an alert from ContentKing notifiying the user about the Performance score worsening on a significant number of pages

You can customize the Web Vitals alerts completely to your needs, in the same way as all the other ContentKing alerts.

You can read more about this here: Configuring Alerts.

Enabling the Lighthouse Web Vitals Monitoring

To enable the ContentKing Web Vitals Lighthouse Monitoring feature, follow these steps:

  1. Go to Settings and then to the Monitoring tab.
  2. Click Edit in the top right corner of the JavaScript Rendering section.
  3. Enable Lighthouse Monitoring using the toggle.
  4. After enabling the toggle, configure the Web Vitals settings and custom on-page request blocking if needed (more about this below).
  5. Click Save.
Screenshot showing the process of enabling the Lighthouse Monitoring feature in ContentKing

Once enabled, ContentKing will start monitoring your website’s Web Vitals.

Note that it can initially take up to a few hours before the Web Vitals metrics are first calculated for all of your pages.

Custom on-page request blocking

To be able to measure and monitor your website’s Web Vitals, ContentKing needs to render JavaScript on your pages.

This means that after enabling the Lighthouse Monitoring feature, ContentKing will start executing JavaScript when monitoring the website (unless you have the JavaScript Rendering feature already enabled, in which case ContentKing is already executing JavaScript).

When rendering a website, ContentKing blocks requests to the most common web analytics and ad services to ensure that your web analytics data don’t get inflated by ContentKing’s monitoring.

This means that if you’re using a common JavaScript-based web analytics solution such as Google Analytics or Adobe Analytics, ContentKing’s monitoring does not have any effect on your web analytics data.

If you’re using a non-standard web analytics solution and you want to ensure that ContentKing’s monitoring doesn’t affect your analytics data, make sure to configure custom on-page request blocking in ContentKing.

To configure custom on-page request blocking, follow these steps:

  1. Go to the Monitoring tab of the Settings
  2. In the top-right corner of the JavaScript Rendering section click Edit and then click change next to the On-page request blocking setting.
  3. In the window that appears, choose whether you want to use a deny-list (Allow all except) or an allow-list (Deny all except) to configure the request blocking.
  4. Define which requests will be allowed/denied using the Operator (more about the operators here) and the URL Pattern.
  5. Click Apply changes.

Web Vitals Settings

The Web Vitals Settings section allows you to customize the Needs improvement and Poor thresholds for the individual Web Vitals.

By default, ContentKing uses the same thresholds as Google’s PageSpeed Insights (opens in a new tab) report.

This means that if you want ContentKing to audit your website’s Web Vitals the same way as Google, there’s no need to change these settings.

However, you have the option to customize the thresholds according to your specific needs and use-cases:

Screenshot showing the customization of the Needs improvement and Poor thresholds for the Web Vitals metrics in ContentKing

Lighthouse Monitoring and JavaScript Rendering

To be able to measure and monitor your website’s Web Vitals, ContentKing needs to render JavaScript on your pages. This means that after enabling the Lighthouse Monitoring feature ContentKing will start executing JavaScript on the website and will render the pages in full, including assets like images and videos.

Due to this, enabling this feature on a website can lead to an increase in data traffic between ContentKing and the web server.

ContentKing also supports JavaScript Rendering as a standalone feature. This is why in the JavaScript Rendering section of the Monitoring settings you see two different settings:

  • Audit using JS Rendering
  • Lighthouse Monitoring
Screenshot showing the JavaScript Rendering and Lighthouse Monitoring features in ContentKing

When you start monitoring a website, by default ContentKing doesn’t execute JavaScript and picks up all on-page elements from the HTML source code of the website. The source code is therefore considered the primary (and only) source of data.

However, you can enable the Audit using JS Rendering setting which will make ContentKing execute JavaScript on the website and pick up elements from the full rendered DOM as well as the HTML source code, with the Rendered DOM being considered the primary source of data.

You can read more about the JavaScript Rendering feature here: JavaScript Rendering

You can combine these two features in the following ways:

Both enabled

  • ContentKing will be executing JavaScript, and the rendered DOM will be considered the primary source of data about the website
  • ContentKing will also measure and monitor the Lighthouse metrics about the website

Both disabled

  • ContentKing will not execute JavaScript, and the HTML source code will be considered the primary source of data about the website
  • ContentKing will also not measure and monitor the Lighthouse metrics about the website

Audit using JS Rendering enabled, Lighthouse monitoring disabled

  • ContentKing will be executing JavaScript, and the rendered DOM will be considered the primary source of data about the website
  • ContentKing will not measure and monitor the Lighthouse metrics about the website

Audit using JS Rendering disabled, Lighthouse monitoring enabled

  • ContentKing will be executing JavaScript for the purpose of measuring the Lighthouse metrics
  • The HTML source code will still be considered the primary source of data about the website

Why do the ContentKing Lighthouse metrics differ from the PageSpeed Insights report?

In some cases you might see that the values of the Lighthouse Web Vitals metrics reported by ContentKing for your pages are different from Google’s PageSpeed Insights report.

This is because ContentKing’s Lighthouse Monitoring feature works with the so-called lab data (opens in a new tab).

As opposed to the field data which Google collects from real users, lab data is collected within a controlled environment with a predefined device and network connection settings, without any involvement from real users.

The field data can only be obtained one way: by measuring how real-world users interact with your website.

The lab data, on the other hand, is collected by simulating real users and can therefore be obtained in multiple ways:

  • The Lab data report in Google’s PageSpeed Insights
  • Monitoring solutions like ContentKing
  • Locally on your device using Chrome DevTools

Field data vs. Lab data summarized

  Field data Lab data
Data origin Real users Simulated user
Data freshness Gathered in last 28 days Collected in real time
Device Unique to each user One device (default: Moto G4)
Network connection Unique, across all users One network connection speed (default: fast 3G)
Locations Unique, across all users One location
Main purpose Gain insight on real user experiences Debug and test

You can read more about the difference between field data and lab data in our Academy article (opens in a new tab).

Factors influencing the lab data

As seen above, the lab data is collected from a specific environment (device) with a specific configuration (parameters), which influences the resulting metrics.

These parameters include:

  • Device type
  • Location
  • Network throttling
  • CPU performance
  • Lighthouse and Chrome versions

Device type

Same as Google’s PageSpeed Insights report, ContentKing simulates a mid-tier device (Moto G4) when measuring your website’s Lighthouse metrics.

ContentKing also supports two different Device Types (viewports):

  • Mobile (width 360px, height 640px)
  • Desktop (width 1,350px, height 940px)

You can choose which viewport ContentKing will be using when monitoring your website via the Device Type setting in the Settings section (Mobile is the default):

Screenshot showing the Device Type setting which allows the user to determine the device type ContentKing is simulating when monitoring a website

Location

The location from which ContentKing monitors your website in relation with the location of the server on which your website is hosted has an impact on the Lighthouse metrics measured.

For example: if you live in the US, browsing a website hosted on a US-based server will be faster than browsing a website hosted on a server located in the UK.

The reason for this is that in the latter case the data must travel much further – from the server in the UK to your phone or laptop in the US.

Google’s PageSpeed Insights chooses the test location dynamically based on your current location. So if you are running a PageSpeed Insights test from the US, Google will also measure the metrics from their US server, etc.

ContentKing supports three monitoring locations out of the box:

  • US
  • UK
  • EU (The Netherlands)

The monitoring location you set for your website is also the location from which ContentKing will be measuring your website’s Lighthouse metrics.

You can read more about our monitoring locations here: Monitoring locations

Network Throttling

When visiting a website in your browser, the speed of your internet connection is one of the major factors that determine how fast the website loads.

When calculating the Lighthouse metrics for your website, ContentKing automatically throttles the internet connection to make the results reflect the average user as closely as possible.

CPU performance

When a website uses a lot of JavaScript-based content which relies on your browser to be executed and loaded, a device with a higher CPU performance will be able to load the page faster than a device with a lower CPU performance.

This also influences the Lighthouse metrics, as different devices which are being used to visit your website have different CPU performances.

Lighthouse and Chrome versions

ContentKing uses the latest version of Lighthouse, and the Chrome version recommended by the Lighthouse documentation as a best practice for the given Lighthouse version:

  • Lighthouse v9
  • Chrome v110

Need help?

In case you have any questions regarding the ContentKing Lighthouse Web Vitals Monitoring feature that are not covered by our documentation, don’t hesitate to contact us!