Firefox/Performance
Contents
Firefox Desktop Perceived Performance Team
The purpose of this team is to improve the perceived performance of Firefox. Our focus is mostly on front-end code that impacts the perceived performance of the browser itself, not the performance of rendering web pages. There are other teams focused on the latter.
Members
- Mike Conley (:mconley)
- Florian Queze (:florian)
- Paolo Amadini (:paolo)
- Gijs Kruitbosch (:Gijs)
- Philipp Sackl (:phlsa)
- Panos Astithas (:past)
Operating principals
- Our work should impact key user interactions of the browser front-end. From a high-level, these are:
- Browser startup
- Tab operations
- Opening
- Closing
- Switching
- Drag and drop
- Scrolling
- Window operations
- Opening
- Closing
- Focusing
- Menu operations
- Opening
- Closing
- Navigating submenus / subviews
- URL bar operations
- Showing the URL bar panel
- Showing results in the URL bar panel
- Jank, real or perceived slowness that can occur at seemingly random times in the parent process
- Browser shutdown
- If you notice a pattern of performance issues, it is better to try to address the pattern in general than to spot fix individual instances.
- The playbook is usually: create a whitelist of pre-existing cases of the bad behaviour to make adding new cases impossible, then whittle down the whitelist. Once the whitelist is empty, remove the whitelist.
- Example: Making main-thread IO impossible is better than fixing a single instance of main-thread IO. We should aim to have a whitelist of places where main-thread IO is currently used, and crash if new main-thread IO is added. We should then file bugs to whittle down the whitelist.
- If you improve something, try to write regression tests to ensure it doesn't get worse. Mochitests are preferred, as Talos tests can be too noisy to be truly useful.
- Example: We moved a lot of scripts so that they don't run until after first paint. There are still some scripts remaining, and we've added a whitelist for those scripts. This ensures that the problem we identified cannot get worse, and only better.
- Example: We've eliminated some synchronous layout flushes caused by our JavaScript code, and have written tests to exercise the user interactions that caused them. Those tests ensure that a whitelist of synchronous layout flushes are possible, which makes it much harder to accidentally add new ones in the future.
Contact
Team Meeting
Day of week | Pacific Time | Eastern Time | UTC | Central European Time |
---|---|---|---|---|
Fridays | 8:30AM - 9:00AM | 11:30AM - 12:00PM | 4:30PM - 5:00PM | 5:30PM - 6:00PM |
- Frequency: One meeting per week on Friday.
- Duration: 30 min
- Vidyo Room: Firefox
- Meeting notes: Google Doc
- IRC: #fx-team
- Mailing list: firefox-dev
Bugzilla
Bugzilla components don't tend to align properly with this project's boundaries, so this team is monitoring bugs across a number of components that block the photon-performance meta bug. Here is the dependency tree. Common components of interest are Firefox:General, Firefox:Tabbed Browser, Toolkit:General and more.
Selecting a New Bug for the Current Release
- Select any 'P1' bug which is currently unassigned and not blocked on a dependency. If no 'P1' bugs are available then select from the available 'P2' bugs, and so on.
- Add the following if not already present:
- [fxperf] whiteboard tag.
- perf keyword.
- qe-verify-, unless it is a bug that QA can reasonably verify.
Adding a New Bug to the Backlog
- Add the [fxperf] tag to the whiteboard.
- Add the perf keyword.
- Set the bug as a dependency of a user story bug or a meta bug if applicable.
- Set the bug priority per the following guidelines or call it out for a priority decision in the Weekly Meeting:
- 'P1': Must Have - development occurring in the current release.
- 'P2': Should Have - targeted for next release.
- 'P3': Could Have - planned for development in an upcoming release.
- 'P5': Will Have - not scheduled for any particular release, patches accepted.
Submitting a Bug for Triage
- Mark the bug by adding the [fxperf] tag to the whiteboard.
Releases
Current Release |
---|
P1: Must Have - development occurring in the current release - View in Bugzilla Duration: Tuesday January 23 - Monday March 12
No results. 0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%); |
Current Release: Completed | |||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
6 Total; 0 Open (0%); 6 Resolved (100%); 0 Verified (0%); |
Next Release |
---|
P2: Should Have - targeted for the current release if production capacity exists - View in Bugzilla No results. 0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%); |
Backlog | ||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
P3: Could Have - planned for development in an upcoming release - View in Bugzilla
6 Total; 6 Open (100%); 0 Resolved (0%); 0 Verified (0%); |
Patches Accepted | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
P5: Will Have - not scheduled for any particular release, patches accepted - View in Bugzilla
1 Total; 1 Open (100%); 0 Resolved (0%); 0 Verified (0%); |
¯\_(ツ)_/¯ | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
P4: (should be reprioritized to P3 or P5) - View in Bugzilla
1 Total; 1 Open (100%); 0 Resolved (0%); 0 Verified (0%); |