Posthog Script causing the UI components to load slow.

[abhisanson]

Bug description

Wanted to report an issue after the last upgrade we did to the posthog. Our users started to report slowness in loading of our app modals(which are in Angular) After investigation we found out the posthog script is interfering with the load times. we turned off the script and suddenly the issue was gone. Can you please advise. I am happy to share the before after screen recordings
Please describe.
If this affects the front-end, screenshots would be of great help.

How to reproduce

1.Script added to index.html
2. when loading certain pages the script blocks UI components loading
3.

Environment

• self-hosted PostHog, v1.37.1

Additional context

With.posthog.mov

After.Removing.Posthog.mp4

Thank you for your bug report – we love squashing them!

[pauldambra]

Hey @abhisanson thanks for your report!

Do you see any console errors or failing network calls when PostHog is present?

Are you able to record and export a performance profile with and without PostHog to share with us? (We can share separately to GitHub if you're worried about what that might expose)

[abhisanson]

@pauldambra there was an issue . We did an npm i to update the packages and it seems there is a dependency thats not letting us compile the code. We commented Posthog again and it works but the moment we add the code its give the error (see screenshot)

[pauldambra]

Ah, thanks @abhisanson! Can you confirm what version of posthog-js you're using?

@benjackwhite is this related to the recent Typescript changes?

[benjackwhite]

Could be. Perhaps @mariusandra would have some ideas here

[pauldambra]

Looking in posthog-js we have rrweb as a dev dependency and rrweb-snapshot as a dependency

[pauldambra]

@abhisanson I made an index.js that imports and uses posthog-js and then used webpack to bundle it and didn't get any errors. Which might only mean I don't know how to recreate your error :)

I don't want to add dependencies and then discover it didn't fix anything for you :)

Where do you get the error pasted above? In your IDE, only on build, something else?

[abhisanson]

@pauldambra it was on visual studio code also from terminal. When I try to start our frontend node server it occurs. See attached . It used to work just fine before the upgrade

Screen.Recording.2022-08-16.at.7.56.59.PM.mov

.

[abhisanson]

@pauldambra the posthog JS version i have posthog-js@1.29.0

[abhisanson]

@pauldambra any update?

[pauldambra]

@benjackwhite @mariusandra do we need to add those dependencies more explicitly?

[abhisanson]

@pauldambra @benjackwhite @mariusandra any update. One of our environments is running Posthog.js@1.21.0 and it compiles fine, but we do have the issue of slow loading.
Please advise..

thanks

[abhisanson]

@pauldambra would really appreciate some help here. We have paused our scripts in prod and are loosing lot of customer recordings

[mariusandra]

I've pushed out a fix that will hopefully let you import the library without issues: PostHog/posthog-js#441

[abhisanson]

@mariusandra Thanks that helped . However we still have the same issue @pauldambra I have performance recordings with and without posthog. Please let me know where can share those?

[pauldambra]

Are you able to join our [community slack](https://posthog com/slack)?

[abhisanson]

@pauldambra Yes I am on it. sent you a direct message there

[pauldambra]

Adding comment from slack here

---

The difference in time spent is all in recorder.js. It looks like a conflict in a polyfill (although these performance graphs are really hard to read 🙂

My guess is that if you turn off session recording the performance impact will disappear. Although that’s not a long-term fix 😊

Do you know which version you upgraded from so I can see what might have changed?

I’ve seen Angular apps be very aggressive with changing the DOM and our screen recorder reacts to DOM changes. So my next bit of intuition would be to experiment there. Maybe try adding ph-no-capture to the timeline or other parts of the page. That would let us see whether a particular component on the page is causing the issue.

Are you able to test those two routes?

1. is the performance impact still present without recording
2. can we determine if specific components cause the slowdown by excluding them with ph-no-capture

[abhisanson]

@pauldambra thats correct, confirming if I turned off recording from the dashboard, the performance issue disappears. Yes, we need those recordings :)

we upgraded from 1.33 to 1.37.1 6 -7 weeks back.

trying code changes to test with ph-no-capture. Will post the results shortly.

[pauldambra]

cc @rcmarron

We've not tracked down the source of the performance impact from recordings here. But thought I'd tag you in case there are changes since 1.37.1 you think might affect things

[rcmarron]

Thanks @pauldambra, any impact from recordings would be related to posthog-js versions, and nothing substantial has changed there since the last rr-web upgrade in the spring.

@abhisanson Is there an environment or account that I could use that shows the performance issue? (if it's easier you can DM me in the PostHog user slack - I'm @rick marron). I've seen a few customers hit similar issues before in Angular apps, and in the past, it had been a loop that's constantly re-rendering a component, and as a result the MutationObserver is constantly firing massive events. Taking a look at what's firing from the mutation observer would be the first thing I check here.

[rick]

[abhisanson]

@rcmarron Thanks , I will enable PHog in my test environment and send you on slack.

[abhisanson]

@rcmarron I have shared the login details with you on slack. please let me know if you able to access

[rustho]

We have a very similar case on the project. We have a table that has lazy loading every 25 elements. As soon as these elements are rendered, the entire application dies until render not finish

[pauldambra]

Hey @rustho 👋

The incomparable @rcmarron discovered that in this case the site in question had a polyfill for older browsers. Recording relies on mutation observer and the polyfill version was way slower.

If you don't think that's the issue here it's probably best to log a separate issue with as much as you can share publicly. If you can't share publicly feel free to join our community slack posthog.com/slack

We have a different support hero each week and you can DM them in the slack with private info

[pauldambra]

@abhisanson I'm going to close this issue since we've discovered the source. Please feel free to keep the conversation going in the community slack 💖