Perceived Performance

	RESTRICTED
	Please do not edit this page without permission; comments should be added to the discussion page.

The aim for the "Perceived Performance" effort is to identify changes we can make that will make Firefox feel faster — as opposed to the classic optimizations that generally involve rewriting code to make it faster. In these cases, there are definitely elements of code improvement involved, but it's not the main reason why things seem faster.

Add your ideas for things we should look at to make Firefox feel faster below:

Firefox startup

• Startup order, what tasks are performed on startup, and is there anything we can defer in order to make the startup experience faster?
• Implement a preloader in the system tray (this project has been abandoned since 2005 and breaks in FF 3.5). There used to be a preloader in the Mozilla Suite, and you removed it in Firefox :(
• Checkbox: "Start Firefox when I start [OS]". So I can turn on my computer, go do something else, and return to find it actually ready.
• Keep firefox running for a moment after close for the set of users who close and reopen the application in order to do a search (because the start page has a search field, and they don't know about the search bar, location bar, or home button).
  • But what about users who restart Firefox because it's acting weird or in a loop? If it hung around, the command to restart would just reinvoke the broken copy.
• A splash screen could alleviate the issue of users not knowing whether their initial double-click to launch Firefox was successful, and inadvertently slowing down startup by making Firefox open two windows.
  • This would only make a difference if new window time was a significant component of startup time. And anyway, it's the OSes job to indicate whether or not an application-start action was successful. (E.g. on Mac, the Dock icon bounces.)
  • An alternative to the splash screen could be to show the window itself with the size it will have, but empty, and fill it with menus and controls when they are available. Maybe even fill it gradually (ie. progressive rendering for xul).
• Newly opened and currently selected tabs should have higher priority than other loading in background (from previous session). Additionally most-visited websites and nearby tabs could also have some priority boost (I'm talking about >10 or >20 open tabs scenario).

Update

• Install updates with a background process so updating doesn't delay the next startup (bug 307181)
• Install add-on updates automatically too (bug 321789)

Loading web pages

• Web pages that load very slowly
  • Faster timeouts on pages that don't load at all
  • Time out script loads, especially third-party script loads, more readily than page loads
  • Increase the amount of visual change when loading a slow page, for instance transition to a large water mark style throbber that appears in the center of the content area if no information has loaded yet
  • Make it clear when a page is loading slowly, so users know they should go to another tab for a while instead of just waiting
  • Offer to keep trying for me every few hours
  • Offer to show cached version of the page
  • Offer coral cache link
  • Show traceroute results while the page continues to not load (some descriptive information would be better for non power-users)
  • Make page transitions more obvious. Often you click a link and the page you are currently viewing is not altered in any way until the next page is loaded enough. We should provide immediate feedback that the next page is loading.
    • But maybe still allow altering the old page until the new one is loaded ?
• Give users tools to avoid waiting
  • Indicate when a page is going to take a long time to load, so users know they should do something else (like read another tab)
  • Nudge users toward using "open link in background tab" more
    • Indicate when a tab opened in the background has finished loading
    • Promote shortcuts for "open link in background tab" (Cmd+click, middle-click) on first-run page
• Perception of how fast Firefox is working
  • Make the throbber faster :p (we honestly do it every release)
  • Make the throbber accelerate (aza)
  • Change all progress bars in Firefox to use an easing function that automatically biases progress to appear slower at the beginning and faster at the end (aza)
  • Use a 1 pixel pulsing progress bar at the bottom of the location bar to denote progress in addition to activity (safari 3 style, but not as heavy).
  • More incremental layout
• Perception of when web page is "done" loading or "done enough" for interaction
  • De-emphasize the throbber and loading indicators once content is visible
  • Reduce amount of info shown in status bar while a page is loading (hostnames from which scripts are being fetched, etc).
  • Less incremental layout: except on very slow pages, show content only once layout is stable, so users don't get in the habit of waiting for the activity indicator to go away.
• Optimistic use of cache
  • Use cached images while waiting on if-modified-since request (bug 510120)
  • Use cached stylesheets while waiting on if-modified-since request (bug 510121)
  • Use cached image sizes even when we can't use the actual cached image
  • Cache whether the page layout required a scrollbar (bug 381149)
  • Use cached page to fire off requests for scripts and stylesheets (bug 510122)
  • Show entire page from cache, and then fade to a copy loaded off of the network once it is ready
• Perform overhead (DNS lookup, TCP handshake, TLS handshake) before the connections are actually needed:
  • See Privacy/Reviews/Necko (network Seer, renamed to predictor), nsINetworkPredictor
• Preload web pages
  • Based on time of day
  • Based on frequent sequences of clicks
  • Based on hovering over links
    • -- Discussion of these issues here; consensus is that we can't.
• Promote AdBlock
• Open a lot of links with images (e.g. entire PhD Archive). Firefox loads all HTML files first, but no images at all. I have to wait a long time before the first tab finishes. Firefox should move http requests for the current tab up the request-queue.

Scrolling web pages

• Implement the OS X acceleration model for scrolling on Windows and Linux (bug 462809)
• Use a real time strategy game style scroll box in the content area, so you can quickly move around a page just by moving the mouse
• Make up/down arrow keys scroll by larger increments.
• When holding down arrow keys, scroll smoothly and with acceleration.

Too many tabs

• Use less RAM when many tabs are open
  • Warn when too many tabs are open, or when too much RAM has been used.
  • Drop the DOM of tabs the user has not interacted with? (Decrease memory use, increase lag when switching to that tab.)
• Make session restore faster with many tabs
  • Load the frontmost tab on startup before the others (filed as bug 496458)
  • On restart, show a list of tabs Firefox can restore, instead of just restoring them. (Like we currently do when recovering from a crash.)
  • Do something about redundant/irrelevant password prompts for master password (bug 499233, bug 348997) and http auth
• Make it easier to switch tabs among a large number of tabs (how?)
  • See bug 505214 – Rejected, but still answers the "how?" question.
• Nudge users toward opening fewer tabs
  • Give users a good alternative to using open tabs as reminders, something that works better than bookmarks or copy+pasting URLs into Things

Back and forward

• Subtle but smooth graphics accelerated back and forward animations, like a very very slight fade and pane
• Pref to turn off the "disable bfcache if page has unload handler" heuristic. (Opera has a pref like this, but I'm not sure if it disables 'onunload' or breaks the 'nothing can happen after onunload' tradition.)
• Show context menu on mousedown on more platforms (bug 89308)
• Pie context menu (mockup of the interface )
  • Show previous page when hovering over the Back command in the context menu, now that Back is not on the way to the other menu items
• Consider some of the ideas from here (if not already implemented): http://webkit.org/blog/427/webkit-page-cache-i-the-basics/

Awesomebar

• Don't require the user to hit the down arrow in order to access the first result in the awesome bar (complicated, details in bug 410837)
• Give the awesome bar the focus on open so you don't have to focus it yourself before navigating to a particular location
• Don't show the progress spinner for the address bar until 200-300ms have passed (it currently appears instantly, and makes it feel like you're waiting for results).
• Move awesome bar loading to occur before most other async tasks that happen, Almost always when I open a new firefox the urlbar is frozen (I type some chars and nothing is shown). This gives a very slugish impression. (santagada)
• Awesomebar should carry on looking for suggestions when the Firefox window loses focus. (Sometimes I get bored waiting for it to find a suggestion I know is there from more than a week or two ago and switch to another window and then I have to rerun the search.)

Other

• Extend the password manager to allow for automatic log ins (with feedback that this is happening)
  • bug 223636 covers this for http auth. Or did you mean for password forms in web pages?
• Color change impact when creating a new tab
  • Are you talking about the link changing e.g. from blue to purple?
• Switching tabs is not instantaneous when Firefox is busy (e.g. loading complex or multiple web pages)
• Deleting history items has lag. Make them disappear when delete is pressed, then delete them.
• History sidebar cannot be closed until history has been loaded.
• Applications tab of the Options dialog freezes Fx, you cannot close the dialog or move to another tab until it has loaded.
• Closing the (only) Firefox window with the close button ("X" on Windows and Linux, red dot on Mac) is instantaneous, but pressing Ctrl+Q makes Firefox hang completely for a second while still showing the window. Ctrl+Q should also instantly close the (current?) window so it disappears from view before it silently shuts down completely in the background.
• Friendlier looking error pages. Most people blame Firefox and not the site causing an issue when they see an error page. A little style and color psychology might help to ease the frustration that a user is feeling when they can't get to where they are trying to go.
• Smarter text selection. It's difficult to select the text you want, because text selection follows invisible page layout elements rather than the locations of actual text. It takes fitts-law-aggravating pixel precision, and you can't even see what you're aiming for.
• Performance of innerHTML is not so good, especially if many <span> elements are used. See also bug 500237. This bug is wanted, but not yet assigned. innerHTML is important for interactive sites, such as GMail.
• It looks like if some layout calculations are slow. Go to the Wikipedia and visit pages with lot of floating pictures. For instance country sites, like USA, Russia and France. Google Chrome loads those pages about 33% faster then FF. Take also a look to the related bug 505328. Resizing this in Chrome is much faster then in FF. It is clear that FF has problems with calculating layout.