Intro to Lighthouse
Lighthouse is a free performance auditing tool provided by Google. It runs inside Chrome Developer Tools and can be helpful for understanding performance issues on individual pages. If you're familiar with Chrome Developer Tools, you’ve likely spent some time with Lighthouse.
Lighthouse is an incredibly useful tool to have in your digital experience toolbox. You can think of Lighthouse as a performance “laboratory” where you can carefully control the conditions of an audit to see how your website performs under different conditions such as slow connections or mobile devices. This “laboratory” environment is a natural complement to Fullstory’s real world performance data. When you find performance issues in Fullstory DevTools, and think you have a solution to fix them, it can be helpful to test your hypothesis with Lighthouse.
Because Fullstory is built to make digital experiences better, we were concerned to find that –in some cases– Lighthouse reports that Fullstory’s script has a non-negligible impact on performance. That's why we took a closer look into both how Lighthouse works and whether or not Fullstory impacts performance as a Lighthouse report suggests. (Spoiler: it doesn't! Read on to find out why).
Buckle up. What follows is a deep dive into Lighthouse.
Lighthouse Metrics
First, it's helpful to understand what metrics Lighthouse uses to generate its performance score. There are six in total:
- First Contentful Paint - the time at which the first text or image is painted (shown).
- Time to Interactive - the amount of time it takes for the page to become fully interactive.
- Speed Index - how quickly the contents of a page are visibly populated.
- Total Blocking Time - the sum of all time periods between FCP and TTI when task length exceeds 50 milliseconds.
- Largest Contentful Paint - the time at which the largest text or image is painted.
- Cumulative Layout Shift - the movement of visible elements within the viewport.
The metric most related to Fullstory's impact on site performance is Total Blocking Time, so that's where we'll focus in this article. To define the term more simply, Total Blocking Time is a measure of the total amount of time it takes to complete a task in excess of 50ms. So for example, if a task runs for 75ms, the Total Blocking Time will be 25ms (75ms - 50ms).
Keep this in mind as we proceed to our next section on Lighthouse Audits! It's helpful for understanding how the audit works.
Lighthouse Audits
Lighthouse generates audits that suggest opportunities to improve your site's performance. If you’ve seen Fullstory come up in a Lighthouse audit, it was most likely under the recommendation to “Reduce the impact of third-party code.”
This recommendation is directly tied to the Total Blocking time metric we discussed earlier. It's based on the fact that JavaScript ties up the browser’s main CPU thread when it’s executed which can impact how quickly your website responds to input from users. Lighthouse summarizes the Total Blocking Time for JavaScript from a given domain.
This audit is helpful for understanding how scripts are affecting your user-experience as thread blocking can affect web performance metrics known as First Input Delay (FID) and Time to Interactive (TTI). Still, there are a few nuances with Lighthouse to be aware of when it comes to the Fullstory script and this audit.
Real quick, let’s review how the Fullstory script works. fs.js loads asynchronously, meaning the rest of your site loads without waiting for the Fullstory script to load. This is important for another Lighthouse audit, “Remove render blocking scripts.” Fullstory should never block rendering, and the amount of time the script takes to load should have no impact on users. Still, we serve fs.js over a CDN to reduce this time as much as possible.
After it loads, the script indexes your site, processes privacy rules, and begins capturing. During data capture, Fullstory “phones home” approximately every five seconds with approved user activity.
This initial parse and index of the page as well as the “phone home” are the only times that Fullstory may block the main CPU thread. These separate events, spread out over the entire user session, are what add up to the time reported by the Lighthouse audit. By breaking the work into chunks like this, as opposed to processing all at once, Fullstory is able to minimize the impact of the script on your users.
See the diagram below for a visual breakdown of this action and how it’s calculated.
Fullstory runs on tens of thousands of sites worldwide*. We consider it our duty to our customers and their end users to keep Fullstory as fast as possible. The Fullstory script was designed from the beginning to have a negligible impact on user experience.
What can I do to ensure Fullstory is as fast as possible on my site?
There are a few best practices you can use to make sure Fullstory is working with your site in the optimal way.
First, always make sure to use the latest version of the Fullstory snippet in the <head> of your website. This ensures your users are loading the latest version of the script as we continually work to enhance it.
Second, consider excluding ads or other highly dynamic content which you don’t consider relevant to the user experience. Excluded content is never recorded by the script which cuts down on the work it has to do. Ads in particular can force fs.js to process more data leading to more blocked time.
And last but not least, think carefully about the number of element capture rules that are applied to highly complex or content-rich pages. Each rule adds a small bit of time to your Fullstory task, so a high volume of rules executing on an incredibly content-heavy page may slow things down. Revisiting your settings with an editing eye may help improve performance.
If you have any questions about these recommendations, contact our Support team.
*based on BuiltWith data, February 2020