This is a spinoff of bug 581532, to track the performance issue. With the 20100817 trunk nightly, pages are redrawing properly now. Unfortunately, the page load time is still incredibly slow. My tests: (loading www.cnn.com and recording start-to-stop times (watching the throbber switch to a favicon) 1. 1:04.5 2. 0.58.3 3. 0.58.8 4. 0.48.4 5. 0.45.6 Adding 'perf' to the whiteboard for now.
flagging for 2.0 triage
tracking-fennec: --- → ?
CNN is a heavy plugin site too. Maybe try nytimes and google news as well?
I am making this a CNN-specific bug. Open other bugs for other sites. And include data. Wes - can we profile this?
Assignee: nobody → wjohnston
Summary: Sites with heavy content and divs are slow to load → CNN.com is slow to load
The patch in bug 589905 improves this by ~12%.
Profiling after that patch: Permissions account for 6% of latency, and cookies account for 5%. Loading frame scripts takes a significant amount of time (hard to say exactly how much as it is async). Asking in bug 562406 if the caching there can help.
tchung, patches have landed that should significantly speed this up. Can you please benchmark how long it takes with the latest nightly, to compare to your original numbers?
sure, will do. i'll also check this against android devices.
For the N900: Mozilla/5.0 (Maemo; Linux armv71; rv:2.0b8pre) Gecko/20101011 Firefox/4.0b8pre Fennec/4.0b2pre. Environment: * Connected via Mozilla wifi * dom.ipc.plugins.enabled = false * JIT is on by default My tests: (loading www.cnn.com and recording start-to-stop times (watching the throbber switch to a favicon) 1. 0.33.7 2. 0.31.5 3. 0.34.8 4. 0.27.6 5. 0.33.6 New Fennec Avg: 32.3 secs Prev Fennec Avg: 63.12 secs The new builds seem to load cnn.com in about half the amount of time it took. And just to compare against Maemo's MicroB: 1. 0.28.1 2. 0.24.1 3. 0.24.0 4. 0.19.3 5. 0.24.3 MicroB Avg: 23.9 secs
tchung, thanks for the data! We're still slower than MicroB, but I'm not sure what speed is feasible for us to reach. IPC adds some overhead which MicroB does not have. The remaining dependencies of this bug might help a little, but I think they would mostly help with application startup, not page load. Aside from them, the one remaining significant sync message during load (and not just during load) is the PLayers one. Need to find out if it's feasible to fix that or not. Also, there might be various preferences that make a difference, that can be fiddled with.
alon, do we know why n900 and microb is not picking up m.cnn.com? i just realized its trying to load www.cnn.com, when in fact android picks up m.cnn.com. Doing m. will load up the page significantly faster (between 3.4 - 5.7 seconds)
obviously ua sniffing. you can change this quite easily using about:config. google for "general.useragent.override".
We should do outreach somehow, to get websites to do UA sniffing that works with Fennec. Otherwise when we launch people will think Fennec is broken/slow, and not realize the website's UA sniffing is at fault (already seen such things in user comments about beta 1).
you can file an evangelism bug.
Filed bug 603694 for the UA sniffing evangelism stuff.
Is this bug still blocking b2 or have we squeezed enough for now? We can always make it block final. What work is going to happen in this bug for b2?
This bug basically is a meta bug, and meta bugs do not block.
tracking-fennec: 2.0b2+ → ---
OS: Maemo → Windows Mobile 6 Standard
> What work is going to happen in this bug for b2? I am still doing more profiling here, and the linked bugs have some possible directions. However, it looks like the big wins have already been achieved.
You need to log in before you can comment on or make changes to this bug.