Confirmed users
162
edits
Perceived Performance: Difference between revisions
→Loading web pages: +nsINetworkPredictor
(→Loading web pages: +nsINetworkPredictor) |
|||
| (33 intermediate revisions by 11 users not shown) | |||
| Line 1: | Line 1: | ||
{{Restricted}} | |||
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. | 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. | ||
| Line 6: | Line 8: | ||
* Startup order, what tasks are performed on startup, and is there anything we can defer in order to make the startup experience faster? | * 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 ([http://sourceforge.net/projects/ffpreloader/ 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 :( | * Implement a preloader in the system tray ([http://sourceforge.net/projects/ffpreloader/ 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). | * 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 == | == Loading web pages == | ||
| Line 15: | Line 27: | ||
** 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 | ** 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 keep trying for me every few hours | ||
** Offer to show cached version of the page | |||
** Offer coral cache link | ** Offer coral cache link | ||
** Show traceroute results while the page continues to not load | ** 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 | * 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) | ** 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) | ||
| Line 33: | Line 48: | ||
** 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. | ** 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 | * 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 | ** Use cached image ''sizes'' even when we can't use the actual cached image | ||
** Cache whether the page layout required a scrollbar | ** Cache whether the page layout required a scrollbar ({{bug|381149}}) | ||
** Use cached page to fire off requests for scripts and stylesheets ( | ** 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 | ** 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), [http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsINetworkPredictor.idl nsINetworkPredictor] | |||
* Preload web pages | * Preload web pages | ||
** Based on time of day | ** Based on time of day | ||
** Based on frequent sequences of clicks | ** Based on frequent sequences of clicks | ||
** Based on hovering over links | ** Based on hovering over links | ||
*** -- Discussion of these issues [http://weblogs.mozillazine.org/gerv/archives/2009/05/mouseover_prefetch.html here]; consensus is that we can't. | |||
* Promote AdBlock | * 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 == | == Scrolling web pages == | ||
| Line 48: | Line 68: | ||
* 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 | * 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. | * 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 | |||
* Use less RAM when many tabs are open | **Warn when too many tabs are open, or when too much RAM has been used. | ||
** 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.) | ||
** Drop the DOM of tabs the user has not interacted with? | *Make session restore faster with many tabs | ||
* Make session restore faster with many tabs | **Load the frontmost tab on startup before the others (filed as [https://bugzilla.mozilla.org/show_bug.cgi?id=496458 bug 496458]) | ||
** Load the frontmost tab on startup before the others (filed as [https://bugzilla.mozilla.org/show_bug.cgi?id=496458 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.) | ||
** On restart, show a list of tabs Firefox can restore, instead of just restoring them. | **Do something about redundant/irrelevant password prompts for master password ({{bug|499233}}, <s>{{bug|348997}}</s>) and http auth | ||
* Nudge users toward opening fewer tabs | *Make it easier to switch tabs among a large number of tabs (how?) | ||
** Give users a good alternative to ''using open tabs as reminders'', something that works better than bookmarks or copy+pasting URLs into Things | **See [https://bugzilla.mozilla.org/show_bug.cgi?id=505214 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 == | == Back and forward == | ||
* Subtle but smooth graphics accelerated back and forward animations, like a very very slight fade and pane | * 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 ( | * 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 | * Show context menu on mousedown on more platforms ({{bug|89308}}) | ||
* Pie context menu ([http://people.mozilla.com/~faaborg/files/daf/pieNav.png mockup of the interface] ) | * Pie context menu ([http://people.mozilla.com/~faaborg/files/daf/pieNav.png 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 | ** 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 == | == Awesomebar == | ||
| Line 71: | Line 97: | ||
* 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). | * 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) | * 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 == | == Other == | ||
* Extend the password manager to allow for automatic log ins (with feedback that this is happening) | * 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 | * 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) | * Switching tabs is not instantaneous when Firefox is busy (e.g. loading complex or multiple web pages) | ||
* Deleting history items has lag. Make them | * 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. | * 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. | * 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. | |||