-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
[NoQA] fix: real startup metric #39070
Conversation
@hurali97 may I ask you to check these changes? Are you happy to have them? I've changed a code from your 452595f commit and made it cross-platform (I know that tests are running on Android only at the moment, but we plan to add more running platforms in the future so it's good to have already a cross-platform code in place). Will be happy to hear your thoughts! 👀 |
Hey @kirillzyusko 👋 I agree with the idea of having the cross-platform code already in place. The only thing that I have a concern over is that we are calculating TTI and it gives us a number. This fulfils the requirement of measuring the TTI but if we want to see the break down of what areas took longest in the App startup lifecycle, we won't have a clue. To help us in this we added markers to locate the start and stop of each part in the App startup lifecycle, see the below image which breaks down the App startup lifecycle in general: ![]() These markers are added in this commit and if we add up these markers, we get the total value which is equal to what we get in TTI. So the idea is to measure TTI with it's own dedicated markers and also measure the metrics which makes up the App startup lifecycle, as discussed in this comment. Where we can see almost all of the time is spent in JS side by reading the value of If we are not interested in finding out what took longer in the App startup lifecycle, we don't have to worry about adding these individual markers. Personally, I would prefer if I can have a sneak on what part of App startup lifecycle is causing the issues, while analysing the results reported by the tool. The reason I emphasized on this is that it will be good to have this standardized what we record in e2e regression monitoring tool with what we will record in production with Grafana, so if we decide to only record TTI in e2e tool then we should only record and report TTI with Grafana 👍 |
@hurali97 thanks for a detailed explanation 🙌 I'm currently working on adding more markers. I opened this PR because I wanted to ship small PRs that solves a particular problem - so capturing a mark in different lifecycle (this PR) and adding more marks sounds like a different tasks. Let me prepare then this PR for review (fix CI, update description, etc.) and then I'll roll out a PR with more markers 👍 |
@@ -130,6 +131,7 @@ function Expensify({ | |||
|
|||
const onSplashHide = useCallback(() => { | |||
setIsSplashHidden(true); | |||
Performance.markEnd(CONST.TIMING.SIDEBAR_LOADED); |
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.
On splash hide we are considering the sidebar loaded(ie. performance entry name SIDEBAR_LOADED), wondering if that is correct or name should be different? Asking bcoz earlier we did it in setSidebarLoaded
.
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.
@kirillzyusko I think I don't need to run the e2e test for this PR change, right?
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.
@Pujan92 from one side - you are right, it's confusing that we use SIDEBAR_LOADED
when splash screen gets hidden. But the start mark is added in BaseSidebar
component (on mount).
So in my opinion it's better not to rename it 🙂
@Pujan92 sorry I think think this will require C+ review |
Reviewer Checklist
Screenshots/VideosAndroid: NativeAndroid: mWeb ChromeiOS: NativeiOS: mWeb SafariMacOS: Chrome / SafariMacOS: Desktop |
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.
Sorry @Pujan92 I meant it wont need a C+ check
Thanks for adding the checklist 🙇 |
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
🚀 Deployed to production by https://github.com/Julesssss in version: 1.4.60-13 🚀
|
Details
Changed a place where we capture a metric according to 452595f but made it cross-platform.
How it affected TTI can be found below (captured in dev mode):
Before
After
Fixed Issues
$ #35234 (comment)
PROPOSAL: #35234 (comment)
Tests
run e2e tests;
be sure that TTI metric still can be collected;
Verify that no errors appear in the JS console
Offline tests
N/A
QA Steps
run e2e tests;
be sure that TTI metric still can be collected;
Verify that no errors appear in the JS console
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodSTYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Design
label and/or tagged@Expensify/design
so the design team can review the changes.ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
MacOS: Desktop