-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add new rule to guarantee events are tracked as passive #1689
Conversation
We'll never call `preventDefault` on our events and, for that reason, it's smarter to tag our events as `passive: true` letting the browser know that it can continue processing the event, it doesn't need to wait for us. This should improve performance on lower-end devices.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Size Change: -6.39 kB (-0.19%) Total Size: 3.27 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Is the bundle size smaller if you make a { passive: true}
object somewhere and import it?
src/entrypoints/recorder.ts
Outdated
// | ||
}) | ||
}, | ||
{ passive: true } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can i be precious and we not change this... changes in here can really break customers' sites so i change it very carefully 🙈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah good catch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy not to change it here, I agree this is the finickiest :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, just needs way more careful testing
i'm being too cautious but the last time we broke this was very painful 🙈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so, best to avoid entirely :)
It's slightly more performant to have these in our events, see previous commit for rationale
40e54f1
to
d9719d0
Compare
src/utils/index.ts
Outdated
@@ -236,7 +236,7 @@ export const registerEvent = (function () { | |||
} | |||
|
|||
if (element.addEventListener && !oldSchool) { | |||
element.addEventListener(type, handler, !!useCapture) | |||
element.addEventListener(type, handler, { capture: !!useCapture, passive: true }) | |||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I was trying to understand what this function is for, and it's intended to support extremely old browsers. If you check https://caniuse.com/?search=addEventListener you'll see this is only ever useful for IE 6-8 which we supposedly don't support
"browserslist": [
"> 0.5%, last 2 versions, Firefox ESR, not dead, IE 11"
]
Of course, we have the oldSchool
flag which triggers this code for window.load
when trying to initialize posthog-js
. https://github.com/PostHog/posthog-js/blob/make-all-event-listeners-passive/src/posthog-core.ts#L2315-L2318
That's only triggered, however, if document.addEventListener
doesn't exist which, again, is only if you're running IE6-8. Anything against removing this code?
I'll instead replace it with a generic addEventListener
function intended to avoid having to repeat passive: true
everywhere and reduce our bundle size slightly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nope... that's super early code for sure...
we should check the ES5 bundle still works but hopefully CI just covers that.
This is ancient code, and it's only ever used for IE6-8 - which we don't support. ``` "browserslist": [ "> 0.5%, last 2 versions, Firefox ESR, not dead, IE 11" ] ``` Of course, we have the oldSchool flag which triggers this code for window.load when trying to initialize posthog-js. make-all-event-listeners-passive/src/posthog-core.ts#L2315-L2318 That's only triggered, however, if document.addEventListener doesn't exist which, again, is only if you're running IE6-8. I'll instead replace it with a generic addEventListener function intended to avoid having to repeat passive: true everywhere and reduce our bundle size slightly.
This helper is intended to save us some bytes by avoiding having to repeat `passive: true` everywhere
Force the new helper usage instead
This prevents removing the listener when we stop it
// Add import if needed (note: this is a basic implementation, it won't always work) | ||
const importFix = fixer.insertTextBefore( | ||
context.getSourceCode().ast, | ||
"import { addEventListener } from './utils'\n" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if this makes any sense. Most often than not it'll be correct, but it will be a broken import sometimes
Maybe we shouldn't be autofixing this at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I'd leave the fix (if we can't detect the correct path). most folks' editors should be able to create the import on demand anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll see if eslint
allows me to detect what file I'm in, if so, I'll keep it
@robbie-c @pauldambra Added a couple of new commits to reduce bundle size, and saved some bytes everywhere - even compared to before! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What @pauldambra said about the ES5 bundle still working for people. Do you still have your IE11 setup? Can you make sure that we're still tracking scrolls correctly?
(I'm 99% confident we will be, just... you know.. changes with a large impact if something goes wrong)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, running locally I still see heatmaps and scrolls and things being captured
CI is green 👍
@pauldambra's tests are reassuring, and scroll still works on my IE11 from the change last week, I'll try the changes here locally, let's hope my IE11 installation is trustworthy |
Hmm, I can't run the demo NextJS app on IE11 because it uses |
Ok, found a way, |
Will be merging this tomorrow morning, more time to monitor before I leave for the day |
We'll never call
preventDefault
on our events and, for that reason, it's smarter to tag our events aspassive: true
letting the browser know that it can continue processing the event, it doesn't need to wait for us.This should improve performance on lower-end devices.
I've released this for
scroll
events which are more critical - called hundreds of times a second - and I'm monitoring to see if we'll decrease event ingestion count or not. If I don't see a decrease, I'll ship this as well :)