Live data from Hacker News

Firefox fixes save gigabytes of memory on image-heavy pages

blog.mozilla.org

111–120 of 203 posts

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#111
post #59

Is it time to switch back to Firefox from Chrome? I remember when I originally switched around Firefox 3.5.x Chrome was much leaner and faster. Has the pendulum finally swung back the other way?

I never saw a reason to switch to Chrome to begin with. Performance was acceptable for me, while other benefits always made Firefox more useful (privacy with encrypted Sync, better add-ons and etc.). And some time ago, Firefox clearly became a leader in performance as well. All this "jumping to Chrome" was simply a hype thing IMHO, and I generally don't care about hype.

There was a period around FF14 where FF was performing terribly for me, and Chrome was acceptably fast as ever. That was what made me switch for a while.

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#112
post #68
post #27

Earlier quoted context omitted.

Yea, I also noticed that, save for the pages with tons of images, firefox has actually been better than chrome in that respect for the last few releases. Now with this fix, I'm seriously thinking of jumping back. Then I'll finally have my sweet DownThemAll again. Many kudos to the firefox devs, performance and memory-usage is very important, and it seems they realized that before it was too late. Even with my 16GB I'…

Last I tried Firefox, pretty recently, it still needed to address some serious issues, when compared to Chrome: * Unresponsiveness due to one tab thrashing * Bad use of screen-space (bookmarks always visible, cannot disappear titlebar like in Chrome [there's only a Windows extension for that], menu-bar takes up another bar of space by default) * Launching firefox has stop-the-world behavior to check/update extensions…

I switched to Firefox from Chrome a couple of months ago, and liked it so far. The UI is fine, and the speed is also fine. But the MacOS+Firefox+Gmail bug (https://bugzilla.mozilla.org/show_bug.cgi?id=341886) drives me nuts. Can't jump to the start or the end of line while editing the message (OK, it is possible with emacs shortcuts instead of standard Mac shortcuts). Can't select text from the current position to start/end of line with keyboard (emacs shortcuts don't help). I haven't appreciated how much I used these shortcuts for email editing before switching to Firefox. And the bug is open since 2006.

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#113
Interestingly, this optimization is already unnecessary if you are using the common technique of setting the CSS background-image on an element rather than using IMG src - on Chrome, Firefox and even Internet Explorer memory usage will be stable on a grid of images that way and, as a bonus, you trivially get cross-browser scaling and centering for vertically scaling thumbnails to be the same size.

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#115
post #87
post #66

Earlier quoted context omitted.

Why should one use bookmarks rather than many tabs? I have many concurrent projects going, and things I refer to regularly, so I just leave them grouped in my tree of tabs on the sidebar. Much more efficient than digging through nested bookmark menus, or trying to make sure the bookmarks are properly classified. Basically, my tabs are bookmarks, except tabs are integrated into the web-browser better.

> Why should one use bookmarks rather than many tabs? Because, as the parent posts point out, tabs take up memory and can cause the browser to become sluggish.

Yes, that is true but there is no problem with just 60 tabs. I have 260 open tabs and my browser is not sluggish and the memory usage isn't too bad either, 3GB.

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#116
post #88

Earlier quoted context omitted.

Bookmarks don't save state, which is especially annoying in a time where async calls are used so heavily.

A URL should contain all of the state needed. If it doesn't then it's a poorly designed website.

URLs do not contain scroll position on the page.

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#117
post #101

Earlier quoted context omitted.

Firefox has to work with the internet as it is, not the internet as we wish it were.

So do users. Keeping several dozen tabs open indefinitely decreases the stability of every browser. Computers have resource limitations. 95% of websites have bookmarkable links; use them.

Not Firefox, which is why I use it instead of Chrome. I am not saying tabs are without problems but they fit way better into my usage patterns than bookmarks.

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#118
post #59

Earlier quoted context omitted.

I never saw a reason to switch to Chrome to begin with. Performance was acceptable for me, while other benefits always made Firefox more useful (privacy with encrypted Sync, better add-ons and etc.). And some time ago, Firefox clearly became a leader in performance as well. All this "jumping to Chrome" was simply a hype thing IMHO, and I generally don't care about hype.

There was a period around FF14 where FF was performing terribly for me, and Chrome was acceptably fast as ever. That was what made me switch for a while.

I guess for lower end computers that could be more critical (netbooks and etc.).

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#119
post #20

I just compared it with Chrome using the example page mentioned in article: In Firefox Nightly at the initial page load it uses around 250 MB memory and with scrolling it stays around that. In Chrome (in Canary too) initial it uses around 300 MB but scrolling keeps filling the memory indefinitely (I stopped scrolling above 1.2GB)

Chrome became very resource hungry and poor at memory management recently. Sometimes I see half blank pages when scrolling which I've never seen before on the desktop.

Yep. In fact, I've noticed performance appearing to get worse and worse in both my Canary browser and regular Chrome. Canary always seems to perform quite a bit worse than regular Chrome. Not sure if that's just due to bugs because of the unstable build, or further changes they're making that is continuously hurting performance.

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#120
post #108

Earlier quoted context omitted.

We've been using stuff like Infinity.js ( http://airbnb.github.io/infinity/ ) for quite a while now, and it's basic functionality is to improve long scrolling panes by dynamically adding and removing elements (including images) in real time as you scroll to keep the number of elements low and the page responsive. Sites that use this technique usually feel just as responsive as if the site really did have a page with…

I don't know that I'd characterize this as a workaround. Infinity.js is definitely a good approach, but you should expect good baseline performance from the browser even without more complicated techniques.

I expect good baseline performance from a combination of both the HTML and JavaScript code of the page, and the browser. Sure it's nice if the browser does some tricks to make a badly written page that has 2 GB of image data on it play somewhat more nicely on the system, but if that page loads badly its not the browsers fault, its the fault of the web developer who didn't paginate, or use Infinity.js or something like that.

The reason why I call the Firefox fix a workaround is because the proper way to solve the problem of 2 GB of image data on a page is by using a UITableView style wrapper.

But HTML 5 doesn't have such an element for us to make use of. The proper fix would be to add such an element to HTML itself, but obviously that's something that takes years to do and to get it adopted across all browsers.

So in the meantime tricks like what Firefox is doing are nice to help prevent inexperienced web developers who create abominably inefficient webpages from consuming too much system resources when an unfortunate victim downloads the page.

Post reply on HN