Hey @arnaud b​, the intercom-lightweight-app node is a version of the Messenger we run in the background until such point as a visitor or user needs to engage with the Messenger (clicks on the launcher, receives an outbound message etc.). If you delete the lightweight app node, you risk hiding the launcher and thus your customer's access point to the Messenger.

I've opened an issue with our engineers to investigate the load this can potentially place on a site.

Hi @eric f11​ , thanks for the answer.

Well after investigation the "intercom-lightweight-app" node is useful for the display of the widget. Without it intercom is not able to inject the "intercom-lightweight-app-launcher intercom-launcher" node. But the "intercom-lightweight-app-style" node inside "intercom-lightweight-app" node is the source of perf issue. So I did a new hack.

If the user doesn't have access to intercom widget, I keep "intercom-lightweight-app" but I delete the "intercom-lightweight-app-style", I stored the css inside a constant. So when needed by intercom to display the "intercom-lightweight-app-launcher intercom-launcher", I manually inject the "intercom-lightweight-app-style" to avoid display issue.

The interesting part is, this "intercom-lightweight-app" is only here to display the widget, as soon as you click on it, the node is automatically deleted by intercom script and a new node is injected instead "intercom-container". So for people allowed to have access to the widget, I simulated 2 clicks on "intercom-lightweight-app-launcher intercom-launcher" to trigger the script which delete the "intercom-lightweight-app". One click is enough, but it will open the chat, so by doing 2 clicks I'm able to keep the chat close while I'm triggering the intercom script and keep this hidden from user.

So yes, it's totally a hack, but it works for our use cases

Best regards.