One of the common types of feedback we get about Firefox for Android is that it’s slow. Other browsers get the same feedback and it’s an ongoing struggle. I mean, is anything ever really fast enough?
We tend to separate performance into three categories: Startup, Page Load and UX Responsiveness. Lately, we have been focusing on the Page Load performance. We separate further into Objective (real timing) and Subjective (perceived timing). If something “feels” slow it can be just as bad as something that is measurably slow. We have a few testing frameworks that help us track objective and subjective performance. We also use Java, JavaScript and C++ profiling to look for slow code.
To start, we have been focusing on anything that is not directly part of the Gecko networking stack. This means we are looking at all the code that executes while Gecko is loading a page. In general, we want to reduce this code as much as possible. Some of the things we turned up include:
- Writing extra and/or redundant page information to the history database
- Saving session restore information too frequently
- Looking up Android system proxy information was slow
- Drawing unused view backgrounds
- Animating the pageload spinner consumed a lot of CPU cycles
- Extra messaging between the Java UI and Gecko
- Opportunities for predictive networking hints
Some of these were small improvements, while others, like the proxy lookups, were significant for “desktop” pages. I’d like to expand on two of the improvements:
Predictive Networking Hints
Gecko networking has a feature called Speculative Connections, where it’s possible for the networking system to start opening TCP connections and even begin the SSL handshake, when needed. We use this feature when we have a pretty good idea that a connection might be opened. We now use the feature in three cases:
- When a touch occurs on a link in web content, we speculatively connect to the HREF. Technically, we need to wait before really opening the link to make sure you didn’t really start panning the page or start a double-tap.
- When starting to type a URL in the titlebar, we load the current set of search engines. We speculative connect to the default search engine, since it’s somewhat probable that you will perform a search.
- When typing into the titlebar, Firefox tries to use domain autocompletion and searches your history for recent URLs. Both the current auto-completed URL and the top-most search result are speculatively connected.
Animating the Page Load Spinner
Firefox for Android has used the animated spinner as a page load indicator for a long time. We use the Android animation framework to “spin” an image. Keeping the spinner moving smoothly is pretty important for perceived performance. A stuck spinner doesn’t look good. Profiling showed a lot of time was being taken to keep the animation moving, so we did a test and removed it. Our performance testing frameworks showed a variety of improvements in both objective and perceived tests.
We decided to move to a progressbar, but not a real progressbar widget. We wanted to control the rendering. We did not want the same animation rendering issues to happen again. We also use only a handful of “trigger” points, since listening to true network progress is also time consuming. The result is an objective page load improvement the ranges from ~5% on multi-core, faster devices to ~20% on single-core, slower devices.
The progressbar is currently allowed to “stall” during a page load, which can be disconcerting to some people. We will experiment with ways to improve this too.
Install Firefox for Android Nightly and let us know what you think of the page load improvements.
have you ever tried to install ABP for Firefox on FF android? I know they say “use the ABP app instead” but if you install the addon it takes a long time before it is responsive when starting cold – and no doubt people do use the addon.
I do find page loading on Android to be pretty slow. It seems much, much snappier on my desktop, even though I’m using the same connection. (I use tethering.)
Unfortunately, after a while I realized that at least part of this seems to be something out of Firefox’s control. Many pages I open on my phone come from other apps, e.g. twitter. When you click on a link in the twitter app, it goes through at least one level of redirection. (The same thing happens when I click on a google search result.) So the time to load a page becomes [time to load redirect]+[time to load actual link]+[time to render page].
From my pretty naive perspective I don’t see any way Firefox could improve on that scenario, but thought it would be worth mentioning. 🙂
I heard once that HTTP connexions are slow on Android (at least one of the x layer of connexion). Does Fennec use SPDY for those mainstream sites ? (not the perfect solution, but it could improve a bit… I have no idea if this is limited or not :-)).
An other axis of improvement would be Fenec startup time : on my SGS3, the firefox app is killed often when switching to another application, and waiting for Fenec to warn up is sometimes exhausting…
Bon courage et vive Firefox \o/
@Grant – We do file bugs about some add-ons, like Adblock Plus, and work with the add-on developers to get things working better. I thought we had a bug filed on ABP slowing down Firefox startup time, but it wouldn’t hurt to file another one.
@starweb – We are interested in “fixing” the [open redirect] + [open real link] + [render page] problem. We started looking at it in bug 841388, but closed that one because it would be adverse to Twitter. We started looking again with enabling <a ping> in bug 951104, especially since Google is using it to stop doing the redirect. We are also looking at using the new navigator.sendBeacon API in bug 936340. We think these APIs will allow web properties to stop using the redirect as a way to count clicks and let pages load faster.
@shavounet – Firefox for Android does use SPDY whenever possible. We also started a project to investigate startup performance too, in bug 959776.
I am using the experimental ART runtime on the Nexus 5, and Firefox is blazingly fast at cold and warm startup, and at loading pages. the issue I encounter most is scrolling choppiness.
this said, any time that you can shave off of startup would be a win.
Manoj
my main problem with Firefox on android its that it doesn’t cache anything between restarts! I’m not sure if this is a memory saving t technique or what but when I open up desktop Firefox, at least some of the page contents restored from my last session is already there. it’s still annoying that pages seem to need too reload to check for new versions our something but at least some of the content is there from disk cache. this is not the same with android. I initiate a new tab by clicking a link from another app and Firefox starts quickly enough but I should be able to go back and view a restored tab whilst waiting the long wait for the new tab contents to load. when I click on the tab button, I generally get a bunch of genetic thumbnails instead of real thumbs of other tabs and the tabs are empty when I click on them. makes a mockery of season restore. why is this?
@pd – A few things:
1. Firefox for Android creates and uses a disk cache. Depending on the amount of free space on your device, it be can over 200MB. Depending on the type of RAM in the device, reading from disk cache could be slow.
2. When doing a session restore, you should keep in mind that just because the UI is visible doesn’t mean Gecko has finished loading. Until the Gecko libraries are loaded, we can’t really load any page, even a session restored page.
I don’t find startup slow (on my nexus 4). I do however find filling out online forms to be incredibly painful (much worse than using chrome). There are a number of issues there, but in terms of performance the time between clicking a submit button and having the browser respond is VERY slow. Similarly, clicking any other form widget and waiting for the UI to adjust seems to take too long. Wondering if this is on the radar…?
I have considerable difficulties (page refresh stalls, temporary browsers freezes, very slow panning and zooming, unreliable search result updates) when using one of my most favourite mapping services with Android for Firefox. Chrome performs much smother for that very resource intensive application (with lots of layers, bitmap transparencies, …).
Is there a place, where such demanding web sites are collected? I think, the mentioned mapping service web site would give a good benchmark.
[1] http://mobile.map.geo.admin.ch
Excuse me, did I get it right that the old spinner was making the objective (not perceived) load time 5-20% slower?
Longtime user of Nightly for Android with ups and downs but still pleased with it. Personally it am not that charmed by the thin bar indicating page load and often retap the link or bookmark thinking nothing is happening despite the cross in the address bar.
Suggestion, make the background of the adres bar progressive orange to indicate a page load in progress.
I disabled myself ABP because of the slow first page load and am using Ghostery and Self-destructing Cookies and few other plugins.