La fonction de suggestion automatique permet d'affiner rapidement votre recherche en suggérant des correspondances possibles au fur et à mesure de la frappe.
This is for anyone that requested I show our team's workaround for helping page speed with the bloated Live Chat script.
First set the Hubspot chat setting to not immediately load live chat. This single setting alone prevents the "vistor.js" file from loading which appears to be the main contributing file to the slow down. Only allow the live chat to load immediately if you know the user to be in a chat session or if the live chat auto launch hash url is used. (#hs-chat-open)
//Prevent chat from loading immediately load only if chat is not in progress or #hs-chat-open is not in the url
if (sessionStorage.getItem("chatInProgress") !== "true" && window.location.hash !== "#hs-chat-open") {
window.hsConversationsSettings = { loadImmediately: false };
}
Now that the chat is blocked. We have to artifically create a chat button that will launch live chat only when clicked by the user. The rest of this code will also set a session storage for knowing if the user's conversation is open, which will allow live chat to load itself on page load. There is also observer mutation events to detect when the live chat window is opened, so you can hide the fake hubspot chat button.
if (window.HubSpotConversations) {
hubspotChatReady();
} else {
window.hsConversationsOnReady = [hubspotChatReady];
}
function hubspotChatReady() {
//Proceed to immediately load Live Chat while conversation is persisting
window.HubSpotConversations.addEventListener("conversationStarted", function () {
sessionStorage.setItem("chatInProgress", "true");
});
window.HubSpotConversations.addEventListener("conversationClosed", function () {
sessionStorage.removeItem("chatInProgress");
});
//Fake Hubspot Live chat button to launch real live chat only when user clicks
//Ignore if Live Chat is already loaded
if (window.HubSpotConversations.widget.status().loaded === false) {
var $liveChat = document.getElementById("activate-chat");
$liveChat.style.display = "block";
$liveChat.addEventListener("click", function (event) {
event.preventDefault();
$liveChat.classList.add("loading");
//Chat window is open when the iframe is loaded in the dom (Hubspot doesn't give a callback for the chat window opening)
var observer = new MutationObserver(function (mutationList, observer) {
mutationList.forEach(function (m) {
m.addedNodes.forEach(function (n) {
if (n.id === "hubspot-messages-iframe-container") {
n.querySelector('iframe').addEventListener('load', function () {
$liveChat.classList.remove("loading");
window.HubSpotConversations.widget.open();
observer.disconnect();
});
}
});
});
});
observer.observe(document.body, { childList: true, attributes: false, subtree: false });
window.HubSpotConversations.widget.load({ widgetOpen: true });
})
}
}
I hope this helps some people. This is not a perfect workaround. Some of the shortfalls would be if you use Hubspot's "hide launcher" setting. Where maybe you want to turn Live Chat on or off from the portal. This workaround bakes in a fake button that doesn't know if Hubspot chat should or shouldn't be showing. In our situation we leave Live Chat open 24/7 and just use away messages.
We are still waiting for Hubspot to take some concern with page speed. But until then we'll do what we can to work around it.
Btw for those who confuse how to create the button, i found another workaround by adding delay. So it will load the chat widget after "X" milliseconds.
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.
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.
août 11, 20219:15 AM - modifié août 11, 20219:28 AM
Contributeur
Live Chat App slows page down
Résolue
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.
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.
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.
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!
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.
This is for anyone that requested I show our team's workaround for helping page speed with the bloated Live Chat script.
First set the Hubspot chat setting to not immediately load live chat. This single setting alone prevents the "vistor.js" file from loading which appears to be the main contributing file to the slow down. Only allow the live chat to load immediately if you know the user to be in a chat session or if the live chat auto launch hash url is used. (#hs-chat-open)
//Prevent chat from loading immediately load only if chat is not in progress or #hs-chat-open is not in the url
if (sessionStorage.getItem("chatInProgress") !== "true" && window.location.hash !== "#hs-chat-open") {
window.hsConversationsSettings = { loadImmediately: false };
}
Now that the chat is blocked. We have to artifically create a chat button that will launch live chat only when clicked by the user. The rest of this code will also set a session storage for knowing if the user's conversation is open, which will allow live chat to load itself on page load. There is also observer mutation events to detect when the live chat window is opened, so you can hide the fake hubspot chat button.
if (window.HubSpotConversations) {
hubspotChatReady();
} else {
window.hsConversationsOnReady = [hubspotChatReady];
}
function hubspotChatReady() {
//Proceed to immediately load Live Chat while conversation is persisting
window.HubSpotConversations.addEventListener("conversationStarted", function () {
sessionStorage.setItem("chatInProgress", "true");
});
window.HubSpotConversations.addEventListener("conversationClosed", function () {
sessionStorage.removeItem("chatInProgress");
});
//Fake Hubspot Live chat button to launch real live chat only when user clicks
//Ignore if Live Chat is already loaded
if (window.HubSpotConversations.widget.status().loaded === false) {
var $liveChat = document.getElementById("activate-chat");
$liveChat.style.display = "block";
$liveChat.addEventListener("click", function (event) {
event.preventDefault();
$liveChat.classList.add("loading");
//Chat window is open when the iframe is loaded in the dom (Hubspot doesn't give a callback for the chat window opening)
var observer = new MutationObserver(function (mutationList, observer) {
mutationList.forEach(function (m) {
m.addedNodes.forEach(function (n) {
if (n.id === "hubspot-messages-iframe-container") {
n.querySelector('iframe').addEventListener('load', function () {
$liveChat.classList.remove("loading");
window.HubSpotConversations.widget.open();
observer.disconnect();
});
}
});
});
});
observer.observe(document.body, { childList: true, attributes: false, subtree: false });
window.HubSpotConversations.widget.load({ widgetOpen: true });
})
}
}
I hope this helps some people. This is not a perfect workaround. Some of the shortfalls would be if you use Hubspot's "hide launcher" setting. Where maybe you want to turn Live Chat on or off from the portal. This workaround bakes in a fake button that doesn't know if Hubspot chat should or shouldn't be showing. In our situation we leave Live Chat open 24/7 and just use away messages.
We are still waiting for Hubspot to take some concern with page speed. But until then we'll do what we can to work around it.
@berylindia you've hit on why all of the proposed "workarounds" really indicate that HubSpot needs to fix their bundle. Each workaround is both technical (requiring at least some modicum of Javascript familiarity) and intentionally breaks pieces of existing HubSpot chat functionality in order to "fix" the issue (which is not fixed, just delayed).
@PamCotton is there any ETA on this being fixed? We're likely not going to use HubSpot for an upcoming platform if there isn't any commitment to bundle size changes.
Same here, we won't roll out any new HubSpot projects for our clients nor will we consult them to use it in the future.
Speed is essential these days and the HubSpot Product Team is either not aware of this issue or they don't think it is a problem. Whatever - it is simply not acceptable for a tool in this price range to ignore something like this.
We feel the same way. When you pay a premium price you expect at least a mediocre product. This is unacceptable and is the primary reason why we already migrated from HubSpot to a more fully integrated CRM.
Btw for those who confuse how to create the button, i found another workaround by adding delay. So it will load the chat widget after "X" milliseconds.
Thanks so much for contributing this. I tried it and it removed the chat launcher but didn't replace it with a fake button. I cut and pasted directly into my sites main .js but maybe I'm missing a step.