Core Web Vitals Lighthouse Monitoring

This article describes Conductor Monitoring’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 Conductor Monitoring monitors.

​

Metrics

For every page, Conductor Monitoring 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.

​

Working with the Web Vitals metrics in Conductor Monitoring

Once enabled, you can work with the Web Vitals metrics across the whole platform, same as with the other page properties and metrics Conductor Monitoring 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: 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: On the page detail screen, you will always see the Web Vitals data for the given page: 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:

​

Using the Web Vitals data in Issues

The Conductor Monitoring 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: 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 Conductor Monitoring here: Issues

​

Using the Web Vitals data in Alerts

Conductor Monitoring will proactively alert you when your pages’ Performance score or any of the other Web Vitals drop below good. You can customize the Web Vitals alerts completely to your needs, in the same way as all the other Conductor Monitoring alerts. You can read more about this here: Configuring Alerts.

​

Enabling the Lighthouse Web Vitals Monitoring

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

1. Follow the path Settings > Monitoring.
2. In the top right corner of the JavaScript Rendering section, click Edit.
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.

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

​

Custom on-page request blocking

To be able to measure and monitor your website’s Web Vitals, Conductor Monitoring needs to render JavaScript on your pages. This means that after enabling the Lighthouse Monitoring feature, Conductor Monitoring will start executing JavaScript when monitoring the website (unless you have the JavaScript Rendering feature already enabled, in which case Conductor Monitoring is already executing JavaScript). When rendering a website, Conductor Monitoring blocks requests to the most common web analytics and ad services to ensure that your web analytics data don’t get inflated by Conductor Monitoring’s monitoring. This means that if you’re using a common JavaScript-based web analytics solution such as Google Analytics or Adobe Analytics, Conductor Monitoring’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 Conductor Monitoring’s monitoring doesn’t affect your analytics data, make sure to configure custom on-page request blocking in Conductor Monitoring. To configure custom on-page request blocking, follow these steps:

1. Follow the path Settings > Monitoring.
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 or 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, Conductor Monitoring uses the same thresholds as Google’s PageSpeed Insights report. This means that if you want Conductor Monitoring 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:

​

Lighthouse Monitoring and JavaScript Rendering

To be able to measure and monitor your website’s Web Vitals, Conductor Monitoring needs to render JavaScript on your pages. This means that after enabling the Lighthouse Monitoring feature Conductor Monitoring will start executing JavaScript on the website and will render the pages in full, including assets like images and videos. Conductor Monitoring 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

When you start monitoring a website, by default Conductor Monitoring 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 Conductor Monitoring 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

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

Both disabled

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

Audit using JS Rendering enabled, Lighthouse monitoring disabled

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

Audit using JS Rendering disabled, Lighthouse monitoring enabled

• Conductor Monitoring 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 Conductor Monitoring 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 Conductor Monitoring for your pages are different from Google’s PageSpeed Insights report. This is because Conductor Monitoring’s Lighthouse Monitoring feature works with the so-called lab data. 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 Conductor Monitoring
• Locally on your device using Chrome DevTools

​

Field data vs. Lab data summarized

You can read more about the difference between field data and lab data in our Academy article.

​

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, Conductor Monitoring simulates a mid-tier device (Moto G4) when measuring your website’s Lighthouse metrics. Conductor Monitoring also supports two different Device Types (viewports):

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

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

​

Location

The location from which Conductor Monitoring 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. Conductor Monitoring 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 Conductor Monitoring 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, Conductor Monitoring 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

Conductor Monitoring 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