GoogleChromeLabs
Unreasonably low FID of iOS/Safari vs Android/Chrome
We have instrumented FID measurements using this Polyfill. We are seeing 5x-10x differences between iOS/Safari vs Android/Chrome. For example, for one of the most visited pages on our site we are seeing the 95th percentile of FID:
iOS/Safari = 65ms Android/Chrome = 435ms Edited: In my original comment I had Safari and Chrome FID numbers reversed
Number of measurements (one week):
iOS/Safari = 66320 Android/Chrome = 15140
Is the difference realistic? we are not seeing such discrepancies in other metrics.
Have you taken a look at the distribution for iOS/Safari? There may be a bunch of values at the 99th percentile in Safari that may be skewing your results higher.
We're already working around several bugs in Safari where the timestamp is clearly wrong, perhaps this is another one of those?
- https://github.com/GoogleChromeLabs/first-input-delay/issues/4
- https://github.com/GoogleChromeLabs/first-input-delay/issues/6
- https://github.com/GoogleChromeLabs/first-input-delay/issues/7
If you can dig in at all to what the event.timeStamp value is or perhaps if this is only applying to certain event types (personally I've noticed weirdness with touch events in Safari), then we could potentially not reports those values in the polyfill.
@philipwalton Please forgive me. I reported the FID numbers backwards :( iOS/Safari is the one that reports lower FID. I will look into the distribution and report back. Thanks!
The ACTUAL numbers are: iOS/Safari = 65ms Android/Chrome = 435ms
Number of measurements (one week):
iOS/Safari = 66320 Android/Chrome = 15140
Is the difference realistic? we are not seeing such discrepancies in other metrics.
Hmmm, that's actually not that surprising to me. It could very well be the case that you have lots of users on low-end Android phones, and less processing power could easily explain the difference in FID values.
Seeing a distribution would still be helpful though in determining if the numbers are correct.
It's also worth noting that the event timestamps in Safari include less of the pipeline than they do in Chrome, which will cause some of this discrepancy. I suspect difference in hardware is a larger factor though.
Philip Walton wrote:
Hmmm, that's actually not that surprising to me. It could very well be the case that you have lots of users on low-end Android phones, and less processing power could easily explain the difference in FID values.
Seeing a distribution would still be helpful though in determining if the numbers are correct.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GoogleChromeLabs/first-input-delay/issues/16?email_source=notifications&email_token=AADS3QLPYLUB5VHR3F6D3A3QWWI4BA5CNFSM4JR4HZMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFW74RY#issuecomment-560856647, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADS3QJ4BDLMY5S6EP44VO3QWWI4BANCNFSM4JR4HZMA .
Using google's FID distribution recommendations for slow, moderate and fast speeds:
Android/Chrome:
95th Percentile = 411ms
75.5% Fast (less than100ms)
16.5% Moderate (between 100ms and 300ms)
8% Slow (greater than 300ms)
iOS Safari
95th Percentile = 60ms
More percentile data:
@philipwalton @tdresser I added some more data in my previous comment. Also, could you please explain what you mean by "the event timestamps in Safari include less of the pipeline than they do in Chrome". Thank you so much for your help!
For touch input in Chrome, the event timestamp is when the touchscreen first observed the event. In Safari, I believe the event timestamp is from when the browser first saw the event.
Any time between when the touchscreen first observed the event and when the browser first receives the event will be captured in FID for Chrome, but not Safari.
