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?
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/...
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.
[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.
Instead what we get is an always-on button that takes up mobile screen real estate.
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.
The problem I think it is harder and harder to reach to "real person" for support and questions these days.
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.
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.
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.
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.
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?
And where does that savings come from? The improved compression and minification? Reduced packet retransmit? Both?
Reader mode works to read the site
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.
They spread the Shamwow thick and early in this advert-o-blog don't they?
I guarantee that they are going to get burned by a middlebox down the road that breaks websockets.
We removed polling from SocketIO because it was just useless since 4 years.
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>
data:image/svg+xml;base64,PHN2ZyBoZWlnaHQ9IjMwIiB3aWR0aD0iMzUiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiPjxkZWZzPjxmaWx0ZXIgaWQ9ImEiIGhlaWdodD0iMTM4LjclIiB3aWR0aD0iMTMxLjQlIiB4PSItMTUuNyUiIHk9Ii0xNS4xJSI+PGZlTW9ycGhvbG9neSBpbj0iU291cmNlQWxwaGEiIG9wZXJhdG9yPSJkaWxhdGUiIHJhZGl1cz0iMSIgcmVzdWx0PSJzaGFkb3dTcHJlYWRPdXRlcjEiLz48ZmVPZmZzZXQgZHk9IjEiIGluPSJzaGFkb3dTcHJlYWRPdXRlcjEiIHJlc3VsdD0ic2hhZG93T2Zmc2V0T3V0ZXIxIi8+PGZlR2F1c3NpYW5CbHVyIGluPSJzaGFkb3dPZmZzZXRPdXRlcjEiIHJlc3VsdD0ic2hhZG93Qmx1ck91dGVyMSIgc3RkRGV2aWF0aW9uPSIxIi8+PGZlQ29tcG9zaXRlIGluPSJzaGFkb3dCbHVyT3V0ZXIxIiBpbjI9IlNvdXJjZUFscGhhIiBvcGVyYXRvcj0ib3V0IiByZXN1bHQ9InNoYWRvd0JsdXJPdXRlcjEiLz48ZmVDb2xvck1hdHJpeCBpbj0ic2hhZG93Qmx1ck91dGVyMSIgdmFsdWVzPSIwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwLjA3IDAiLz48L2ZpbHRlcj48cGF0aCBpZD0iYiIgZD0iTTE0LjIzIDIwLjQ2bC05LjY1IDEuMUwzIDUuMTIgMzAuMDcgMmwxLjU4IDE2LjQ2LTkuMzcgMS4wNy0zLjUgNS43Mi00LjU1LTQuOHoiLz48L2RlZnM+PGcgZmlsbD0ibm9uZSIgZmlsbC1ydWxlPSJldmVub2RkIj48dXNlIGZpbGw9IiMwMDAiIGZpbHRlcj0idXJsKCNhKSIgeGxpbms6aHJlZj0iI2IiLz48dXNlIGZpbGw9IiNmZmYiIHN0cm9rZT0iI2ZmZiIgc3Ryb2tlLXdpZHRoPSIyIiB4bGluazpocmVmPSIjYiIvPjwvZz48L3N2Zz4=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?)