Core Web Vitals Lighthouse Monitoring
This article describes Conductor Website 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 Website Monitoring monitors.
Metrics
For every page, Conductor Website 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 (opens in a new tab).
Working with the Web Vitals metrics in Conductor Website 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 Website 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 Website 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 Website Monitoring here: Issues
Using the Web Vitals data in Alerts
Conductor Website 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 Website Monitoring alerts.
You can read more about this here: Configuring Alerts.
Enabling the Lighthouse Web Vitals Monitoring
To enable the Conductor Website Monitoring Web Vitals Lighthouse Monitoring feature, follow these steps:
Once enabled, Conductor Website Monitoring 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, Conductor Website Monitoring needs to render JavaScript on your pages.
This means that after enabling the Lighthouse Monitoring feature, Conductor Website Monitoring will start executing JavaScript when monitoring the website (unless you have the JavaScript Rendering feature already enabled, in which case Conductor Website Monitoring is already executing JavaScript).
When rendering a website, Conductor Website 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 Website 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 Website 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 Website Monitoring’s monitoring doesn’t affect your analytics data, make sure to configure custom on-page request blocking in Conductor Website Monitoring.
To configure custom on-page request blocking, follow these steps:
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 Website Monitoring uses the same thresholds as Google’s PageSpeed Insights (opens in a new tab) report.
This means that if you want Conductor Website 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 Website Monitoring needs to render JavaScript on your pages. This means that after enabling the Lighthouse Monitoring feature Conductor Website Monitoring 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 Conductor Website Monitoring and the web server.
Conductor Website 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 Website 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 Website 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 Website Monitoring will be executing JavaScript, and the rendered DOM will be considered the primary source of data about the website
- Conductor Website Monitoring will also measure and monitor the Lighthouse metrics about the website
Both disabled
- Conductor Website Monitoring will not execute JavaScript, and the HTML source code will be considered the primary source of data about the website
- Conductor Website Monitoring will also not measure and monitor the Lighthouse metrics about the website
Audit using JS Rendering enabled, Lighthouse monitoring disabled
- Conductor Website Monitoring will be executing JavaScript, and the rendered DOM will be considered the primary source of data about the website
- Conductor Website Monitoring will not measure and monitor the Lighthouse metrics about the website
Audit using JS Rendering disabled, Lighthouse monitoring enabled
- Conductor Website 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 Website 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 Website Monitoring for your pages are different from Google’s PageSpeed Insights report.
This is because Conductor Website Monitoring’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 Conductor Website Monitoring
- 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, Conductor Website Monitoring simulates a mid-tier device (Moto G4) when measuring your website’s Lighthouse metrics.
Conductor Website 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 Website Monitoring will be using when monitoring your website via the Device Type setting in the Settings section (Mobile is the default):
Location
The location from which Conductor Website 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 Website 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 Website 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 Website 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 Website 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
Need help?
In case you have any questions regarding the Conductor Website Monitoring Lighthouse Web Vitals Monitoring feature that are not covered by our documentation, don’t hesitate to contact us!
