Live Chat App slows page down

[merlinvicki]

Hi,

I have the Hubspot Chat installed here:

https://www.3mediaweb.com/great-b2b-software-company-websites/

There is a file:

https://static.hsappstatic.net/conversations-visitor-ui/static-1.383/bundles/visitor.js

which is almost a 1.39 mb file. Is there no way to compress the scripts so it loads faster?

[jennysowyrda]

Hey @merlinvicki, 

There is no way to shrink the size of the file. If you are noticing your site is running slow, I would recommend looking at other elements of your site. 

Thank you,
Jenny

[skemble]

Hi Jenny,

We've put a lot of work in to improving our mobile pagespeed score and load times. Implementing chat on our site dropped our mobile pagespeed score by an avg of 25 points and our desktop pagespeed score by an avg of 11 pts. Surely you must have a solution other than instructing us to look at other elements of our site. Our site is otherwise fast, the culprit for the reduction in speed is strictly the chatbot/visitor.js.

As you can see in the screenshot linked here it takes 10x longer to load than the next longest script. This isn't really acceptable in what some are calling 'The year of pagespeed'.



@thisisdatis 

[jennysowyrda]

Hi @skemble,

I wanted to share this resource which is a great resource for HubSpot and page speed. 

Thank you,

Jenny

[thisisdatis]

Hi @jennysowyrda - your script is the problem. It loads 10x slower than other scripts. What are you doing to speed things up? As a marketing automation company catering to marketers, you should know the importance of page speed and how it affects mobile rankings. Especially with this being the "year of page speed" according to Google.

[davidmmb]

Was there any update on this?

We are experiencing the same issue?

When we include the tracking code on our website - it will add 20+ requests and slows down the page load by around 2-6 seconds.

[bsplosion]

Hi Jenny and the HubSpot crew - it's now October 2019, and the visitor.js script you bundle is still massive and a tremendous resource hog.  It consumes more resources than the entire rest of our web app combined!  This should really be broken down into consituent components and served separately depending on the requisite functionality - I highly doubt you need to serve such a large file for simple chat and tracking functionality.

For a benchmark of a couple of your competitors, the Heap Analytics dependency has 1/13th of your footprint, and in that they manage to still identify visitors and track page events at a finer grain than your system.  Chatlio's dependency is about 1/40th. 

tl;dr: Tracking and chat with forms takes at most 1/10th of what your library needs and your users (who rely on you for marketing and sales) need your help to get ranked.  It's time to optimize.

Edit: And Jenny, regarding your answer, it's not sufficient.  You're referencing an engineering challenge as impossible, and a cursory review of the dependency reveals that's not true.  An easy example is that your team has chosen to define literal month names 3 (!!!) times in the dependency.  If that's happening in a minified file, I can only imagine what the code itself looks like.

[edsvcs]

We are also very interested in this. Additionally, it appears the app is including js.usemessages.com which is from MarkMonitor. We need to understand what this is tracking and who has access to the data. Is this just facilitating the tracking we see in our contact records or is this data available to any third parties?

[sitmeanssit]

This is a laughable response.

[rawphael]

Any official updates on this issue? We noticed tremendous speed drops after integrating Hubspot into our site. Very disappointing.

[skemble]

I'm also interested in hearing if there has been an update to correct this. We have discontinued the chat functionality entirely because of the associated speed issues.

[thisisdatis]

Same here - as marketing automation platform, your tools shouldn't be hindering a businesses' SEO. 

[davidmmb]

Around 6 months ago - I provided the support team with detailed technical analysis. Unfortunately, they didn't understand the issue and suggested my site was slow. 

In response, I created two versions of my site, one with chat and one without (on the same server). This showed that the page load time was 4-12 seconds slower with chat (according to google page speed insights, GT Metrix and Pingdom).

Ultimately, I had my contract cancelled and no longer use HubSpot. 

[tschemmel]

Performance and speed is very important for our ecommerce site. We depend on hubspot for marketing as well as customer service (live chat). We also noticed Hubspot's live chat has an abnormally high drain on performance. We were met with the same "check your site" solution from Hubspot. Very disappointing. 

[mgwaters]

I too show that as a % of page load it takes up a considerable amount:

static.hsappstatic.net 34.19% 390.0KB

[GregWright]

This needs sorting Hubspot, when I activate live chat on my site my page speed halves!!

[chrisfink]

We are experiencing the same issues here. We just invested thousands of dollars into our site thinking that the theme code (we run on Shopify) was the culprit. Come to find out, and I should have dug deeper prior to this, it's the HubSpot chat widget/app that is causing our slowdown. Our Google rank has dropped significantly because of this.

What is being done to solve this? We spend thousands of dollars every year on HubSpot and for this issue to go unsolved, or at least without a suitable response, is unacceptable.

[tschemmel]

I'm still amazed Hubspot development team doesn't see priority in this issue. Our ecommerce site is nothing without excellent SEO. My dev team works all the time to carve away milliseconds of load time off our site just to keep our page speed score up. All of the Hubspot tracking code weighs heavy on this but the live chat is the worst part of it.

Luckily we found an acceptable workaround for us right now to not load live chat until a user engages with it. This has helped our score without sacrificing live chat for our customers.

We use this config to prevent live chat from loading immediately.

window.hsConversationsSettings = { loadImmediately: false };

And then we artificially create the Hubspot live chat button on our site with an action to launch live chat.

window.HubSpotConversations.widget.open();

There is of course more necessary scripting to allow live chat to load immediately if a chat session is in progress. Feel free to message me if interested in seeing our full script workaround.

[bsplosion]

@tschemmel, I'd love to see how your team worked around this issue!  If it's not sensitive, posting it here would likely be a big help to everyone else who otherwise can't get HubSpot to optimize their bundle.

[rvzello]

Experiencing same issue here - chat load JS is the biggest resource hog on our site... Would love to see Hubspot find a solution.

[udayanw]

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.

[tschemmel · Accepted solution]

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.

[TCNHelp]

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. 

[tschemmel]

---

@TCNHelp wrote:

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.

[seleleospencer]

This is great, thanks. For a total noob does this code go into the CSS or deeper into the core files? (Wordpress)

[tschemmel]

---

@seleleospencer wrote:

This is great, thanks. For a total noob does this code go into the CSS or deeper into the core files? (Wordpress)

---

All the code I posted is Javascript. 

[seleleospencer]

Thanks man, of course it is 🙂

HS needs to take this more serious though

[digitalasamtal]

Thanks a lot for sharing the code! Give your dev team some cred from me, it's well written code 🙂

//Mattias

[JWharton]

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.

[tschemmel]

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.