I have a not-so-old configuration: Celeron 2 GHz, Windows XP, Firefox 3.6, broadband at least 1 Mbit/s. I always liked how the "classic" (Stack Overflow, Super User, etc.) site worked, but the newer Stack Exchange sites are too slow; sometimes my mouse even freezes moving from one element to another. Am I the only one who's seen this?

Update: I can't even type normally at new Stack Exchange sites; my computer pauses every third typed letter (while here at Meta Stack Overflow, the typing experience is almost as natural as in any lightweight editor).

Update: It seems like it's Firefox-related (mine is version 3.6.12), since in Chrome everything seems to be OK. In Firefox, one of the symptoms is mouse semi-freezing when hovering over questions, tags, users and badges. I tried to run "-no-remote" without extensions, but the effect was the same.

share|improve this question
Which StackExchange sites? I know the Mathematics SE takes up some CPU power because the rendering of mathematical equations is done on the client side via Javascript. Otherwise, I don't have any speed problems with the SE sites so far. Can you reproduce the problem for us to try it out? –  In silico Nov 16 '10 at 8:42
@ins stats.se also uses it, as well as physics.se, which is in beta right now –  Yi Jiang Nov 16 '10 at 9:24
This sounds like a problem with the computer rather than the site –  Pëkka Nov 16 '10 at 10:11
Even my phone can run these sites, so the CPU is likely not the problem –  Ivo Flipse Nov 16 '10 at 10:30
updated info about firefox –  Maksee Nov 16 '10 at 12:19
Have you got an ad blocker or script blocker running in Firefox? –  ChrisF Nov 16 '10 at 12:25
@Pekka: I'd even say as far as that sounds like problem with Firefox, not his computer. –  Esko Nov 16 '10 at 14:14
I have experienced the same problem as you with Firefox3, not just with SE sites though, but web sites in general. I've noticed if I leave Firefox on for a few hours with multiple tabs open, it starts to hog memory. It can eat up up to 700mb to 1gig ram sometimes. Can you quit FF and start a fresh instance(check system resource to make sure you truly killed all FF instances) and check the SE sites you've had problem with? If the problem goes away then it's a known FF memory leak issue. –  Jin Nov 17 '10 at 15:51
I'm also looking into a possible CSS solution for sites with big background images. FF3.n has been reported to have a problem with certain background image CSS. –  Jin Nov 17 '10 at 15:53
add comment

2 Answers

We think this is related to the classic issue Firefox 3.x has had since forever with static backgrounds.


share|improve this answer
Jeff, thanks, but at least no scrolling involved with this problem. The problem is gone is any of the properties listed is removed or replaced. For example changing border-bottom hovering with text-decoration:underlined also helps. BTW, after the investigation that in gmail it's similar but probably with some also css styling. When hovering over the archive button, only this button is redrawn, but if it's "Report spam", the full page is repainted. –  Maksee Nov 18 '10 at 5:26
I just happened to reveal that even removing even the whole background item (so no background image at all) still leaves the full repainting behavior. So for the moment it means that if an element is inside a floating element and hovered with boxing border (not text-decoration), the hovering repaint the full floating element in firefox. Correct me if i'm wrong –  Maksee Nov 18 '10 at 6:49
add comment

Sorry to answer my own quesion, but it seems like it was videocard/firefox rendering related (I have one of comparatively old Matrox videocards)

I narrowed it to a simple fragment (referencing only a single background image). It happens that for three properties at once

  • body background
  • floating element
  • hovering with border-bottom

firefox repaints the whole float element no matter how big it is (for stackexchange it's the full questions list) when the mouse hovers over the links. Supposedly the mouse in my case was frozen because of the matrox videocard bitblitting temporary disabled the mouse. It seems that other videocards not showing the problem just did the blitting fast. The issue that ff repaints all the area can be easily reproducable if you fill the screen with random pixels and try to move mouse afterward seeing which parts are beeing freed from these pixels.

Below is the fragment that reproduces full repaint behavior (in my case when I try to intersect the link with the mouse, it is as though it holds the pointer a litte ("rubber" effect):

  body {
    background:#fff url(bg-site.png) repeat top left;
  h3 a:hover
    border-bottom:1px dotted #ab2020;
  #mainbar {


   <div id="mainbar">
      <a href="/questions/19416/">Is argument or parameter considered more appropriate for a function/method argument/parameter?</a>

update: I'm not sure whether it's a big issue, but actually it means that on all windows machines large parts of the page (at least the whole mini-list with questions) is redrawn when mouse doesn't activate anything, but just moves. When I modified the program to fill the screen randomly on a constant basis, I noticed that ff repaints the whole page on every key press, even here, on meta.stackoverflow.com. Probably time to send a bug report to mozilla's bugzilla.

update interesting that although the users of modern fast videocards usually don't see anything wrong, they still can suffer a little when the site is accessed on a notebook working from battery. The reason is that full repainting consumes more resources than partial. You can see this effect just by opening the Task manager and looking at ff cpu% when moving in and out of the link to a quesion on stackexhange sites. With ATI-bundled notebook I see almost full core consumption for stackexchange and about 20% for stackoverflow

share|improve this answer
add comment

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .