A 40KB Optimization Saved Us 50TB of Bandwidth | Hacker News Reader

A 40KB Optimization Saved Us 50TB of Bandwidth

crisp.chat

86 pointsbaptistejamin59 comments

Are chatboxes actually effective?

I hate them with a burning passion. They take up half the screen on mobile, hiding the content I want to see, they often have annoying sounds & animations, and they are always present on pages where I don't expect them to be. A chatbox blocker would be a killer addition to the ABP browser on mobile.

Why not create a "Chat with us" page that loads the chatbox instead of force feeding it to every user who comes to your site, wasting bandwidth and load performance?

Agreed. I block them with https://github.com/bcye/Hello-Goodbye/

Add the following URL to your uBlock Origin filter lists and most of those chat bubbles are gone:

https://raw.githubusercontent.com/bcye/Hello-Goodbye/master/...

Thanks for linking this, I never realised other people were annoyed enough to create a blocklist specifically for those god-awful chat popups.

I help run a SaaS for developers and we receive several pre sales questions and support questions per day. We try to send the support questions to forums or docs pages. People seem to like the chat. I personally hate annoying chat widgets but ours is just on the pricing page and gets good engagement.

I personally think this is a awesome strategy. Or, better than alternatives. I always go to pricing page when evaluated SaaS for my former company, but I NEED to get some grasp of the product before.

Interrupting my observations about the product on the welcome page just makes me angry and harshier against the sale.

This is why I avoid some clothes stores where the first thing you meet is a salesperson. Just say "welcome, I'm here IF you need" is the best approach.

If your product is maybe useful I will ask things against the perceived value, so the pricing page.

Yes, especially for quickly resolving support problems. It's a much more efficient way to communicate complex issues in both directions. Imagine how long a 10 message email chain takes in real time to resolve in comparison. Assumes you have responsive and knowledgeable operators though.

I reluctantly[0] concur. Absolutely agreed that the chat responder must be an actual person and also competent. I get the impression that many sites just use a chatbot for the initial interaction and then maybe escalate to a human (competent or not) if you are persistent enough.

[0] I don't know why exactly. Maybe it's because I abhor phone convos, so I get similarly nervous around chat... but I really shouldn't because you do get a tad more time to actually formulate responses.

I think what you are referring to is different from what is being referred here. This comment is about the chat box on landing webpage which is generally for lead generation/sales

I don't see the difference or where they mention that. Messaging a question you have via a chat box and getting a fast and knowledgable answer is useful and way more convenient than writing an email.

Sounds + pop-up messages are bad though.

10 message email chains aren't the only alternative. There can be a prominent "I need support" button that pops up a chat widget when clicked. Or a "chat with us about pricing" button that pops up the widget when clicked.

Instead what we get is an always-on button that takes up mobile screen real estate.

There's no perfect solution but a small floating mobile button in the corner doesn't seem like a big deal if you know most of the time people on your site are going to be looking for support or sales info.

I don't think anyone is advocating a chat window popping up automatically if that's what you're getting at.

> Why not create a "Chat with us" page that loads the chatbox instead of force feeding it to every user who comes to your site, wasting bandwidth and load performance?

Presumably because having an obnoxious pop-up that follows you around their site is effective. See also Annoying subscription pop ups and annoying "Allow our site to send you notifications" pop ups.

I just wish everyone would standardize on one super annoying pop-up/ follow you everywhere behavior instead of applying all 3+ to their site layered on top of pop up video adverts which stay in sight.

I love them if they're sequestered behind a support link so that they don't get in my fucking face and if the person on the other end is empowered. I'd much rather load up a quick chat than spend 20 minutes on a phone call that requires me to either navigate or punch through an automated menu. But I don't want to see them until I need them.

I love the possibility of chatting, but the chat bubbles are a bad user experience everywhere. The best solutions I've seen just opens a small popup window with the chat inside, and that's it. Native cross-tab-chat, can easily keep an eye on the chat while doing other things, etc.

I hated it until the day I have to go through every SaaS service vendors that I have and this is the quickest way I can actually "chat" with a real person about some questions. Help desk support tickets took 24hrs turn-around, and emails took even longer.

The problem I think it is harder and harder to reach to "real person" for support and questions these days.

To add to this, is cutting load time to one second (or half a second) going to impact the efficacy of the chatbox compared with doubling, tripling that load time?

Certainly there's an upper limit I, as a user, would wait to interact with someone, but load time seems like a pretty non-limiting factor. Since presumably something has pushed me to click this button, I'm going to have to type something into the box that will take more than five seconds to type, and then wait for (hopefully?) a real person to respond, or else play with the chatbot to find the right keywords to redirect me to a real person.

With that, I don't think waiting three to five seconds would hugely impact my experience in the scheme of the conversation that's going to follow it. However - since this is a 3rd party add on to my site, I would certainly appreciate it having a smaller footprint. Can't argue with that.

It would be nice if chat boxes only loaded the full chat functionality once the user has interacted with it. Why do they need so load so much just to show a chat widget circle in the corner that likely won't even be clicked on the majority of the time?

170KB for the chat widget is good but when you're trying to make minimal fast loading pages, this is still feels like a lot. If you avoid JS, use minimal CSS and stick to SVG images, you can get whole landing pages to load in under 500KB.

One trick I use though is to delay loading chat widget JS for about 5 or 10 seconds after the page loads. It's not needed immediately and the delay lets the browser prioritise loading the rest of the page first.

Hello Sean!

You are totally right, in many cases splitting the chat in many sub-parts can improve loading time.

It is something we tried during our optimization batch.

We figured that it wasn’t improving so much the loading time in our case. Saving around 10KB.

In fact our JS size is 80KB and CSS 30KB. The rest are fonts.

We offer an option for our customers to delay the chat. It’s a built-in feature. Not enabled by default.

About landing pages, you are totally right. SVGs make a real difference.

Per the article, your total size is something like 230kb, so more than half your size is in fonts? I'm sure I'm in the minority here in that I don't like loading external fonts, but couldn't system fonts be good enough, or using the default of the site you're hosted within?

> We figured that it wasn’t improving so much the loading time in our case. Saving around 10KB.

Would you be able to offer the feature I mentioned? Load only enough CSS + JS to show the chat widget circle then load the rest after the user clicks? It would need less than 10KB of code total before compression, and then optimising the size of the full widget wouldn't be as critical.

I know you can trigger the Crisp chat pop-up programmatically so I guess it's something a user could implement but it would be a feature I would really appreciate since I'm always optimising the page speed of websites I help with.

Fun fact: loading chat boxes on pageload can get you in hot water with GDPR/PECR! Most such services use cookies in some fashion. You don't need consent for cookies that are "strictly necessary" to provide a service, but you can only use that exemption for users who initiate a chat session.

FYI this is a concrete example given by a regulatory authority of non-compliant behavior they observe in the wild, so it's not just theoretical.

> FYI this is a concrete example given by a regulatory authority of non-compliant behavior they observe in the wild, so it's not just theoretical.

Can you give a link to this?

Would it still apply to Crisp chat?

"You do not need to ask for user consent regarding Crisp cookies. Crisp uses cookies solely for messaging purpose, and not for tracking purposes."

https://help.crisp.chat/en/article/crisp-chatbox-cookie-and-...

Also, is there a good source to answer when you need and don't need a consent pop-up? It's maddening how difficult it is to get a straightforward yes/no for common use cases. Has nobody made a questionnaire/wizard where you tell it what you store and why, and it'll tell you if consent is required?

The report I am referring to is this "cookie sweep" performed by the Irish DPA. It is especially significant because the Irish DPA is the one with jurisdiction over many US tech companies, who incorporate their EU operations in Ireland for tax reasons [PDF]: https://www.dataprotection.ie/sites/default/files/uploads/20...

There is not enough information in (that page of) Crisp's documentation to tell for sure whether they're compliant. The key question is: are cookies written when the JS loads, or only when the user initiates a chat session? They seem to be appealing to the "strictly necessary" exemption, but that only applies when the user actually tries to chat. Cookies set before a user tries to chat are not strictly necessary.

In general, if you read or write data from a user's device (including cookies, but also things like User Agent from HTTP headers), you need consent unless it's strictly necessary for providing the service that the user requested. "Strictly necessary" and "service" should both be interpreted narrowly. That guidance only applies to reading/writing user device data, because it's governed by PECR rather than GDPR directly. GDPR allows a lot more leeway for collecting data for narrowly-defined-but-not-strictly-necessary reasons (like analytics).

The UK regulator, ICO, actually has some pretty thorough write-ups about cookies and consent and things of that nature. The UK is no longer part of the EU and its laws will diverge, but for the moment PECR and GDPR are both UK domestic legislation and will generally mirror EU law (except for international transfers). ICO's cookie guidanec: https://ico.org.uk/for-organisations/guide-to-pecr/guidance-...

> In general, if you read or write data from a user's device (including cookies, but also things like User Agent from HTTP headers), you need consent unless it's strictly necessary for providing the service that the user requested.

What's the rational behind this if the data stored locally isn't used for user tracking or even uploaded anywhere? By the same logic, why shouldn't we have to ask for consent to cache web files and to store data in a URL parameter?

Thanks for the links. I think part of the problem is there's just so much information and discussion on this, that it's hard to get a clear answer you can be 100% sure you can trust. PECR, GDPR, Irish DPA, ICO, UK law, EU law, cookie sweep... how are you suppose to keep up, know what applies to your particular case, and be sure you've interpreted and collated all the guidelines correctly?

I hold a certification in information privacy, so my totally-biased answer is "hire an expert!" :p

The reading/writing requirements are from PECR, which is old and dumb. Passed in 2003ish, and was basically ignorable until GDPR changed the definition of consent. Updating it to include GDPR's much-saner concept of "Legitimate Interest" has been a priority goal for several years, but never actually happens.

This might be one of the most obnoxious articles I have read. Randomly making every other sentence bold, underlined or italicized does not serve readability in any way.

Obnoxiously written article by the authors of an obnoxious popup, huh.

Yep. Nothing more I hate than seeing crisp or tawk or whatever other bullshit "ENGAGEMENT GROWTH HACKING" ding noise.

Is the 50TB bandwidth saving actually discussed at all in the article? I certainly can't see it

I think the 10 items at the end were supposed to be where they cut the sizes down, but it doesn't sound like huge numbers. Unless they are saying that by cutting 40kb out of what is sent across results in 50TB or bandwidth savings over a period of time. Would they have anywhere near that amount of traffic?

I was about to ask the same thing.

And where does that savings come from? The improved compression and minification? Reduced packet retransmit? Both?

> We are performing those comparisons from the EU, over fiber Internet and a good WiFi access point.

That seems like a really stupid marketing move.

According to their charts, Zendesk is over 6x the size, but only takes 0.36s longer to load with more network requests and equal CDN latency. If their size difference only matters over a weak connection, they should have done their comparisons with a weak connection. They either threw away an opportunity with their charts or maybe their optimization didn't make a big enough difference to matter in the end.

If I were them, I'd redo these tests quickly from somewhere else and update the charts to make it look like what they did matters.

Also the "Saved Us 50TB of Bandwidth" in the title isn't discussed anywhere in the post. (And why would a customer care?)

> "Through this quick article, you'll understand which company offers the fastest live chat solution for website."

They spread the Shamwow thick and early in this advert-o-blog don't they?

Being proud of your work isn't Shamwow, it comes naturally when you actually like the thing you made.

Chatboxes seem fairly unobjectionable, what really grinds my gears is chat bubbles on landing pages. If I'm on a landing page, the last thing I want is a distraction ping and a bunch of notifications trying to boost "engagement." Easiest way to get me to bounce off a page.

Looks like an advertisement pretending to be interesting tech.

Was the optimization breaking scrolling on mobile?

It is a bug with the default Ghost template that we are using. We are currently fixing this issue.

I don’t know what it is but trying to scroll this page on an iPhone is barely possible, it keeps bouncing back at certain points.

But think of all the bandwidth they’re saving!

Reader mode works to read the site

It is a bug with the default Ghost template that we are using. We are currently fixing this issue.

Hi, there’s some issue where your site gets stuck / won’t scroll on an iPhone 8 Plus, Safari, iOS 14.0.1.

I see it too. Same software stack, iPhone 11 Pro.

Works fine Firefox/Android.

One of my hopes for the next ten years is that we normalize collecting and graphing of telemetry data over time, for things like binary size, disk space, memory usage, and network bandwidth.

We are fairly good at tracking feature regressions, but it's always only a couple voices calling for tracking these metrics, which are a part of the cost of doing business, one that we often have control over. We shouldn't have to wait for a major event to start looking at these sorts of things.

One of my hopes is that "we" (i.e., the software development industry) STOP collecting telemetry data.

You are talking about human telemetry, unless I’m mistaken. I don’t disagree with you. We’re gonna collect telemetry, but some of it helps us without hurting others.

> Vendored libraries should be built with special optimizations as to remove unused code, for instance Socket.IO which we use to establish a RTM messaging connection to our servers contains a legacy HTTP long-polling connection method — that is quite heavy! — though we only need to use the WebSocket connection method with today's modern browsers;

I guarantee that they are going to get burned by a middlebox down the road that breaks websockets.

We are enforcing websocket since 4 years now and not using long polling since. It works really great as it is widely supported.

We removed polling from SocketIO because it was just useless since 4 years.

If you are so concerned about size, why are you using a custom font? Even optimized, that is apparently 10KB that is completely unnecessary.

I like having easy access to chat with a real person, but I hate the icons overlaying the content, especially with an even larger tooltip. It directly interferes with my engagement with the content. Why not make it part of the site navigation instead, such as next to login on the web page?

You removed long polling from Socket.io which kills your mobile users since they can’t NAT that web socket. Have you received feedback from your mobile users?

click-bait: No mention of 50TB bandwidth in the article.

It's good to see web developers taking resources into account. Something the rest of software development has been doing since the start.

You probably did great engineering, but wow, you could still fit multiple websites in that.

Your page does not scroll properly if at all on iOS 14.0.1 and Safari.

I wonder how difficult it would be to synthesize the sound instead of loading it from a file. :+ )

As somebody who generally disables JavaScript, I don't really understand why some people here find the little corner chat buttons that obnoxious; I actually use them to get things done on a fairly regular basis and some of them at least tend to work very well (Crisp being among the best).

Probably the worst I could say about them is that when people don't design their websites properly, and the button is overtop of something important, there's often nothing you can do.

For various business reasons we'll probably end up implementing our own, and I don't see why the loader can't be a couple hundred bytes in one script tag, including its icon, but Crisp at least appears to be the least bad “modern webapp”-style implementation of this.

P.S. you can cut down the size of some of your inline SVGs by urlencoding them instead of using base64. So in the CSS for the button, in addition to getting rid of the redundant "result" and "in" parameters (i.e. the default "in" of filter elements is the previous "result", even if it has no name), and just doing your compositing in the filter rather than with use elements, you can use

    data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' height='30' width='35'><defs><filter id='a' height='140%' width='140%' x='-15%' y='-15%'><feMorphology in='SourceAlpha' operator='dilate' radius='1'/><feOffset dy='1'/><feGaussianBlur stdDeviation='1'/><feColorMatrix values='0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.07 0'/><feComposite in2='SourceGraphic'/></filter></defs><path fill='white' filter='url(%23a)' d='M14.23 20.46l-9.65 1.1L3 5.12 30.07 2l1.58 16.46-9.37 1.07-3.5 5.72-4.55-4.8z'/></svg>

instead of

    data:image/svg+xml;base64,PHN2ZyBoZWlnaHQ9IjMwIiB3aWR0aD0iMzUiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiPjxkZWZzPjxmaWx0ZXIgaWQ9ImEiIGhlaWdodD0iMTM4LjclIiB3aWR0aD0iMTMxLjQlIiB4PSItMTUuNyUiIHk9Ii0xNS4xJSI+PGZlTW9ycGhvbG9neSBpbj0iU291cmNlQWxwaGEiIG9wZXJhdG9yPSJkaWxhdGUiIHJhZGl1cz0iMSIgcmVzdWx0PSJzaGFkb3dTcHJlYWRPdXRlcjEiLz48ZmVPZmZzZXQgZHk9IjEiIGluPSJzaGFkb3dTcHJlYWRPdXRlcjEiIHJlc3VsdD0ic2hhZG93T2Zmc2V0T3V0ZXIxIi8+PGZlR2F1c3NpYW5CbHVyIGluPSJzaGFkb3dPZmZzZXRPdXRlcjEiIHJlc3VsdD0ic2hhZG93Qmx1ck91dGVyMSIgc3RkRGV2aWF0aW9uPSIxIi8+PGZlQ29tcG9zaXRlIGluPSJzaGFkb3dCbHVyT3V0ZXIxIiBpbjI9IlNvdXJjZUFscGhhIiBvcGVyYXRvcj0ib3V0IiByZXN1bHQ9InNoYWRvd0JsdXJPdXRlcjEiLz48ZmVDb2xvck1hdHJpeCBpbj0ic2hhZG93Qmx1ck91dGVyMSIgdmFsdWVzPSIwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwLjA3IDAiLz48L2ZpbHRlcj48cGF0aCBpZD0iYiIgZD0iTTE0LjIzIDIwLjQ2bC05LjY1IDEuMUwzIDUuMTIgMzAuMDcgMmwxLjU4IDE2LjQ2LTkuMzcgMS4wNy0zLjUgNS43Mi00LjU1LTQuOHoiLz48L2RlZnM+PGcgZmlsbD0ibm9uZSIgZmlsbC1ydWxlPSJldmVub2RkIj48dXNlIGZpbGw9IiMwMDAiIGZpbHRlcj0idXJsKCNhKSIgeGxpbms6aHJlZj0iI2IiLz48dXNlIGZpbGw9IiNmZmYiIHN0cm9rZT0iI2ZmZiIgc3Ryb2tlLXdpZHRoPSIyIiB4bGluazpocmVmPSIjYiIvPjwvZz48L3N2Zz4=

It is something we already tried, but it is not improving anything.

Reply on news.ycombinator.com