Firefox/Performance

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

1. 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.
2. 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

1. Add the [fxperf] tag to the whiteboard.
2. Add the perf keyword.
3. Set the bug as a dependency of a user story bug or a meta bug if applicable.
4. 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

1. Mark the bug by adding the [fxperf] tag to the whiteboard.

Triage
Collection of work waiting for the team to review and determine if it should be included in the Product Backlog Bugs blocking photon-performance-triage - View in Bugzilla Bugzilla query error Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 429 [1] => Unknown Error ) ) 1
Tracked bugs without a priority set - View in Bugzilla Bugzilla query error Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 429 [1] => Unknown Error ) ) 1

Releases

Current Release
P1: Must Have - development occurring in the current release - View in Bugzilla Duration: Tuesday January 23 - Monday March 12 Bugzilla query error Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 429 [1] => Unknown Error ) ) 1

Current Release: Completed
View in Bugzilla Bugzilla query error Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 429 [1] => Unknown Error ) ) 1

Next Release
P2: Should Have - targeted for the current release if production capacity exists - View in Bugzilla Bugzilla query error Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 429 [1] => Unknown Error ) ) 1

Backlog
P3: Could Have - planned for development in an upcoming release - View in Bugzilla Bugzilla query error Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 429 [1] => Unknown Error ) ) 1

Patches Accepted
P5: Will Have - not scheduled for any particular release, patches accepted - View in Bugzilla Bugzilla query error Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 429 [1] => Unknown Error ) ) 1

¯\_(ツ)_/¯
P4: (should be reprioritized to P3 or P5) - View in Bugzilla Bugzilla query error Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 429 [1] => Unknown Error ) ) 1