User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170323105023 Steps to reproduce: I have a suggestion to improve the perceived page load performance of Firefox: favicons in the tab should show immediately instead of waiting until the page is finished loading to show. Instead of showing the loading spin animation as the page is loading, a progress bar could be show at the top of the tab (what most mobile browsers have). And not only would this increase perceived performance but I strongly believe this is just the better way of doing things, people should be able to see the tab favicon right away, they shouldn't have to wait for the page to finish loading to see the favicon!
I think I'd rather see the actual page content load before a tab icon to "improve the perceived page load performance of Firefox".
(In reply to Worcester12345 from comment #1) > I think I'd rather see the actual page content load before a tab icon to > "improve the perceived page load performance of Firefox". I don't understand what you mean?
What I'm saying is this: the page loading animation that is where the favicon SHOULD be actually makes Firefox seem slow, and I think it should be scrapped and replaced by a progress bar at the top of each tab (maybe make the progress bar orange because Firefox is orange?). So the favicon would show right away, which would make Firefox seem faster and is just generally better. This would also be perfect because Photon has squared off tabs now, if the tabs were still curvy, putting a progress/loading bar at the top of the tabs probably wouldn't look good.
Another reason this is a good idea is because some pages get stuck on loading forever or for a very long time and the pages favicon never shows, instead the user just sees a loading animation
Philipp, do you have thoughts on this? How much does it impact perceived performance? Should we attempt to show the page's favicon before the tab has finished loading? I think the case where this personally made me feel Firefox was slow is when restoring a session, when Firefox seems to have my tab, but actually when I click that tab, Firefox just replaces it with a loading unusable tab. I was wondering if in that case we should keep the favicon (and tab title!) in the tab when loading the page, and maybe overlay a smaller loading indicator above the favicon. That could also work for pages that keep loading forever and currently never show the favicon.
I think some will say they won't notice an improvement and some will say they do, but for what it's worth, I clearly remember the day this change was made and immediately thought "this is making Firefox feel slow". And another reason I think this should go: the page loading favicon animation doesn't show you how much of the page has loaded, it's "dumb", it just spins. If there was a progress bar at the very tip of the tab (like what mobile browsers use) people would be able to see the progress, unless it's decided that will also just be a 'dumb' animation. Either way would be an improvement, the favicon should be visible immediately, you shouldn't have to wait for the entire page to finish loading to see the favicon.
The human performance testing on loading indicators is running right now (and this is very tightly coupled with the type of indicator that we use). So we should know more soon! Eric, could we make sure that we have at least one progress-bar-style indicator in the test rotation? Thanks!
Flags: needinfo?(philipp) → needinfo?(epang)
Another reason I think this should be done: in the cases where a page takes a very long time to completely load or never fully loads, users don't see that favicon and thats a real issue. You COULD change it so after 20 seconds or so, a pages favicon will show whether the page is fully loaded or not, but all of this is too complicated and it would still be worse. It's much easier/simpler and also better to show the favicon immediately + have a progress bar at the top of tabs (a 'dumb' progress bar animation is also completely fine and I'm sure less work)
Created attachment 8862004 [details] Loading 4.mp4 (In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #7) > The human performance testing on loading indicators is running right now > (and this is very tightly coupled with the type of indicator that we use). > So we should know more soon! > > Eric, could we make sure that we have at least one progress-bar-style > indicator in the test rotation? Thanks! We have one indeterminate bar indicator in the set for performance testing. From my understanding we are not able to use a determinate indicator without faking it (is that something we want to do? - I believe we do this on Fennec). Imho, when the favicon shows up it's an indicator that the site is ready to be consumed. I don't feel it should show up if a page is taking long to load (or doesn't load...this should be an error) - if it's still loading we should be honest and show the indicator so the user knows what's going on. For example, if I right click and "open in new tab" I might want to stay on the page I'm on until the site I've opened is done loading. Once the favicon appears I see this as an indicator that the site is ready. One idea Philipp brought up in the past that I think would work well here is to stop showing the loading indicator and show the favicon when the page has loaded enough to be consumed but not completely.
But I'm not suggesting there should be no page loading indicator, that would be crazy, a page loading indicator is a necessity. Also, wasn't one of the purposes of APZ to allow people to scroll and consume a website before it's 100% finished loading?
How about a compromise, overlay a loading indicator on top of the favicon? It's just strange to not display the favicon at all until the page is finished loading
Coming back to this because I've payed attention to this more closely and there are just so many websites that show the loading animation forever, and you never get to see the favicon! (it's not my machine or internet connection, I've ruled that out). The best decision is to show the favicon immediately but there should be a loading animation. There are 2 options. A bar animation at the top of the tabs (this is the option I support) and the other would be a loading animation overlayed on top of the favicon, like when a pinned tab is playing audio (attaching a picture of that in a moment in case anyone is wondering what I'm talking about). Even though this isn't a serious problem, it's still an issue and it shouldn't be dismissed...
https://web.archive.org/web/20151206201603/http://people.mozilla.org/~bwinton/ - Quick Load (https://github.com/bwinton/quick-load) ever does this and it is cool. ASAP got favicon is a good perception experience, but getting progress / status is also an important requirement for some applications, however any identifier may break this cool unless it is obscure and accessible. Adding a progress bar is a common practice, but it may be heavy for UI. Thinking: Position, shape and transition. A small loading badge at favicon corner? It may halve the cool, see the favicon but still long loading. An option for the loading icon? (Like disable UI animation and hardware acceleration in Options.) This may be a good way if most users to not concerned about the actual loading progress of page (some pages may break if resources is not fully loaded).
Somebody please add: Keyword: Perf
For the concern about the favicon indicating the page is ready, you could have it blink while still loading.
I have to come back to this again because I've been using Photon since it graduated to beta channel and honestly, the only thing about Photon that seems/feels slow is waiting for the favicons to show. Showing the loading tab animation for so long is misleading, it's making it seem like the page isn't finished loading even though it is. A lot of websites are fully loaded, but I'm still seeing the tab loading animation instead of the favicon. I'm really surprised SOMETHING wasn't changed to improve this in time for Photon release, this was one of the stand out perceived performance issues...
it was actually done on purpose to avoid having the favicon connections and network load fight with the page that is more important. We can prioritize the page traffic to the icon traffic. while loading favicons sooner may improve performance perception, it would instead do the exact opposite.
(In reply to Marco Bonardo [::mak] (Away 16 Dec - 2 Jan) from comment #18) > it was actually done on purpose to avoid having the favicon connections and > network load fight with the page that is more important. We can prioritize > the page traffic to the icon traffic. > while loading favicons sooner may improve performance perception, it would > instead do the exact opposite. Makes lots of sense. I'd just as soon see them gone completely.
Hey epang, I know this bug has been kinda long and windy, but is there something actionable here that we want to do with tab loading indicators / favicons? In comment 9, you end with saying: (In reply to Eric Pang [:epang] UX from comment #9) > One idea Philipp brought up in the past that I think would work well here is > to stop showing the loading indicator and show the favicon when the page has > loaded enough to be consumed but not completely. Is this something we still wanted to explore? Tentatively marking this fxperf:p5 until I hear more.
Whiteboard: [fxperf] → [fxperf:p5]
(In reply to Mike Conley (:mconley) (:⚙️) (Totally backlogged on reviews and needinfos) from comment #20) > Hey epang, I know this bug has been kinda long and windy, but is there > something actionable here that we want to do with tab loading indicators / > favicons? In comment 9, you end with saying: > > (In reply to Eric Pang [:epang] UX from comment #9) > > One idea Philipp brought up in the past that I think would work well here is > > to stop showing the loading indicator and show the favicon when the page has > > loaded enough to be consumed but not completely. > > Is this something we still wanted to explore? > > Tentatively marking this fxperf:p5 until I hear more. Hey mconley, Is there anyway we can determine when most of the visible content has loaded? For example, we don't need to wait until all the background scripts are done running to show the favicon/burst. This will also mean showing the "burst" sooner. The idea of the favicon/burst is to let the user know that content is ready to be viewed. I'm happy to show the favicon/burst sooner only if there's enough content ready.
Flags: needinfo?(epang) → needinfo?(mconley)
(In reply to Eric Pang [:epang] UX from comment #21) > Hey mconley, Is there anyway we can determine when most of the visible > content has loaded? For example, we don't need to wait until all the > background scripts are done running to show the favicon/burst. > That's a good question. I'm not entirely certain the front-end is given any information on rendering state like that. I suspect it isn't. It'd be tricky, too - how do we know how much is "enough"? Just because a webpage has caused some pixels to be written in the content area doesn't necessarily mean that those pixels are meaningful to the user. I'd be worried about significant portions of the page showing up or becoming visible in the content area _after_ we've finished showing the throbber. So on reflection, maybe trying to move the favicon / burst sooner doesn't really fit with how we load pages. :/
You need to log in before you can comment on or make changes to this bug.