Same issue. Team HubSpot, please look at your competitors like Intercom, Freshchat etc. They load twice as fast. Honestly optimizing this shouldn’t take you this long. It’s not like the chatbot is loading slightly slow so its not a burning issue.
The chatbot is loading slower than the ENTIRE website. This is a huge red flag wow.
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.
Thank you for posting! Quick question - we are pushing pop-up messages upon user login and have logic built in hubspot based on user properties. These properties drive the popup content. Will this solution fail in that scenario? It looks like the chat widget is only enabled upon user-click.
Thank you for posting! Quick question - we are pushing pop-up messages upon user login and have logic built in hubspot based on user properties. These properties drive the popup content. Will this solution fail in that scenario? It looks like the chat widget is only enabled upon user-click.
If by “pop-up messages” you’re referring to the chat bot responses then no this workaround wouldn’t affect any logic you have in your chatflow. You are correct that this workaround requires user interaction to launch the chat widget. A user click is required to know if we should bother loading in chat resources. The exceptions to chat loading with a user click are, having a chat conversation in session OR if #hs-chat-open is present in the url. This hash tells Hubspot to auto launch the chat, so if it’s used we don’t want to restrict the chat from loading immediately.
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.
Appologies for not making that clear. This code will not create the fake button for you. You’ll need to add that yourself and use the click and observation events in the script to control the fake button. We used the ‘activate-chat’ element you see in the code. Which is a graphic that looks exactly like the hubspot button in the same place.
I would note the code I posted is a good start to a workaround, it is NOT a plug and play script. You’ll need a developer who understands it to implement and ammend it to your needs.
The fact that you had to write all this custom script for a Hubspot chat feature is completely ridiculous and should not be necessary.
How can a thread that has this many comments from unhappy users get away with having “it’s probably some other problem with your website, bro” as the only response from a Hubspot rep? This is insane.
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.
@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.