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.
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 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 recording 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 recording. During recording, 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 recording 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 recording 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.
If you have any questions about these recommendations, contact our Support team.
*based on BuiltWith data, February 2020