[WebProfilerBundle] Improve performance #54421
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fabpot
added a commit
that referenced
this pull request
Apr 5, 2024
…filer layout (javiereguiluz) This PR was squashed before being merged into the 7.1 branch. Discussion ---------- [WebProfilerBundle] Update the search links in the profiler layout | Q | A | ------------- | --- | Branch? | 7.1 | Bug fix? | no | New feature? | yes | Deprecations? | no | Issues | - | License | MIT While working on #54421, I noticed that the page jump is mostly caused by the "profile search form" that we embed in the page via Ajax. This is how it looks expanded:  However, thew workflow is as follows: 1. Click on `Search` link 2. The embedded search form expands 3. Input the search criteria 4. Click on `Search` button 5. You are redirected to the Search page to see the results ----- In this PR, I propose to NOT embed the search form in any pages and change the workflow as follows: 1. Click on `Search` link 2. You are redirected to the Search page to see the results 3. Input the search criteria (in the already expanded search form) 4. Click on `Search` button to see the results This fixes some of the perceived performance slowdown and looks like a better workflow to me. ----- Also, the current sidebar shows these shortcut links:  * "Last 10" shows the 10 most recent profiles * "Latest" shows the most recent profile available * "Search" expands the search form This PR changes it to only show 2 shortcuts: * "Search profiles" shows the last 10 profiles and also the search form expanded * "Latest" shows the most recent profile aaailable It looks like this:  Commits ------- 7baa29e [WebProfilerBundle] Update the search links in the profiler layout
|
To avoid any redraw and ensure maximum performances, we should implement the reordering directly in CSS #menu-profiler {
/** ... existing rules */
display: flex;
flex-direction: column;
}
#menu-profiler li:has(span.disabled) {
order: 1;
}( |
cae2cb9 to
03fc648
Compare
|
Simon, you are a genius 🙇 🙇 I did what you suggested: it works perfectly and it solves the remaining performance issues. The profiler pages now feel very snappy. Thanks! This is now ready for a final review. |
❤️ Thank you for tackling those issues :) |
smnandre
approved these changes
Apr 12, 2024
fabpot
approved these changes
Apr 13, 2024
493b2f9 to
29a271b
Compare
|
Thank you @javiereguiluz. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR tries to solve the following problem:
When clicking on panels like
LogsorDoctrine, the page contents take some time to be ready ... and the JavaScript code that runs to change/Add things to UI, produces visible jumps:profiler-panel-jump.mp4
I debugged this behavior and the browser shows a "Long Task" warning message but not many other details:
I followed Google's recommendations: https://web.dev/articles/optimize-long-tasks and split the
SymfonyProfilertasks in two group: critical (menu and tabs) and normal (the rest of features).That change in addition to
<meta name="view-transition" content="same-origin">improves the situation, but it's still not perfect.So, this PR is mostly a call for help to JavaScript experts. Please help us make the UI as fast as possible. Thanks!