I talked to our team and they are aware of how this and working on actions that improve this metric.
It is important to remember that performance recommendations surfaced in external tools are typically formulated by bots and automated measures to evaluate a site and assign a score or grade. With that in mind, these scores don’t always replicate the actual visitor’s experience of the page load. In the case of chat, the widget is designed to not load until the site is fully loaded.
That means it won’t impact the speed of the site loading, only the overall time of page load. From the visitor’s perspective, the website is loaded and interactable before the widget loads since these are asynchronous actions. Tests like Google PSI measure based on total time to load, instead, so they are tracking something different than what the visitor really experiences on the page.
All that said, we absolutely understand users tracking that number and hoping to see improvement. On our end, we need to balance whether we are solving for the page visitor or solving for the test since the two are not always aligned. We are always investigating ways to improve these numbers and it is on our radar to do further investigation here.
You are correct, the page speed score actually decreases when delaying the chatbot by 7 seconds. 16/53 to a 16/29 score. TTFL went from 7.6 seconds to 9.9. unfortunately we need our cake and eat it too here. You guys need to implement a button in your delay much like the other guy on here… and when the user clicks the button, THEN the script fires. We need to take the script out of the loading equation all together and have it fire ONLY when the user decides it’s necessary.
Hi all! We recently updated the “Time on page in seconds” trigger. Delaying the chat widget load by at least 5 seconds should optimize for a faster initial page load.
Thanks for the update! Oddly enough, there was an even bigger change on your end which no one has bothered to mention: the visitor.js bundle has been greatly reduced in size as everyone has been requesting, all the way from ~1.39MB to 246kB! This is the degree of minification which we’d been saying should’ve been possible since 2 1/2 years ago, so thank you to whichever unsung hero within HubSpot finally got this knocked out.
The “Time on page in seconds” trigger actually wouldn’t have resolved this issue, as visitor.js still gets loaded immediately and would’ve still had a pretty massive impact on both initial page loads and script compile times. There doesn’t appear to be any load deferred until after the time on page elapses, so our primary complaint wouldn’t have been addressed without the optimization of the visitor.js dependency.
You are absolutely correct, there have been some much larger and more significant changes, happy to hear you’ve noticed the improvement!
More details on your recent changes below:
The payload size of the widget has been reduced. In the past, this project simply has not been possible given the size of the undertaking. It took significant resources and time to see this through, I’m very glad you have seen the change.
We also changed how the “Time on page seconds” trigger loads the widget. You are correct that in the past this would not have had an impact; however, with recent updates we now delay parts of the widget load and startup until after the time delay has completed.
Please let me know if you have any additional feedback or questions!
only improved my site by Largest Contentful Paint .2 seconds, but time to fully loaded increased by over 2 seconds! When you say it “should” optimize, it means you don’t “know”. we need known solutions, not hopeful. sorry.
BAD NEWS -- implementing the delay option actually gave us a worse Pagespeed score!! 16/53 to 16/29 - go fish! It ALSO increased our Time To Fully Loaded by 2 seconds! no bueno!
Hubspot chat slow, v2.js is SLOW and accounts for 1/2 the time required for our site to load. terrible. This is still a conversation a year later.
It seems this is a rather old post, but my Dev team just tried adding the Chat and it significantly slowed down our page speed to the point we can’t use it.
Has there been any updates or new solutions I should relay to them (aside from adding the time delay which seems to have mixed results)?
Hello, @ARelph since this is an old thread. I don’t want it to get missed! I would recommend creating a new thread here with your specific case and more details on the process, this way you will get new input from other users.
16/53 to 16/29 - go fish! It ALSO increased our Time To Fully Loaded by 2 seconds! no bueno!