Here is a very slow page in Safari 5.1

Question

Here is a very slow page in Safari 5.1

Safari before 5.1 has had no problem loading this page:

But in 5.1 requesting this page makes WebProcess start consuming 100%+ of CPU and it takes 105 seconds under Snow Leopard on a 2 x 2.8 GHz Quad-Core Xeon Mac Pro and 65 seconds under Lion on a 2.3 GHz Intel Core i7 MacBook Pro, before the page is ready to do anything (scroll or press a button) with.

To check whether there might be a font or character causing this problem, I have replicated the situation with various subsets of the table being displayed. Displaying 1000 rows speeds the loading, but it still takes about 15 seconds on the Snow Leopard machine, regardless of which 1000 rows are displayed. (These times are over a LAN, so no Internet latency.) Similar problem on a 2.4 GHz Intel Core 2 Duo MacBook.

The loading time is not appreciably decreased if the page is loaded again in succession.

Mac Pro, Mac OS X (10.5.7), iPhone 8GB, Airport Extreme

Posted on Jul 22, 2011 10:50 PM

Reply

Answer 1

Jul 22, 2011 10:51 PM in response to Jonathan Pool

WebProcess? Do you have LIttle Snitch installed?

Reply

Answer 2

Jul 23, 2011 6:51 AM in response to Carolyn Samit

No, I haven't installed Little Snitch. As for WebProcess, I'm watching it with "top" in the terminal while waiting for the page to become loaded and ready to use.

Reply

Answer 3

Lexiepex

Level 6

14,102 points

Jul 23, 2011 7:20 AM in response to Jonathan Pool

It has nothing to do with Safari or Webprocess or Little Snitch. It is the webcontent itself that makes Safari immediately go to 100% CPU, and you have to (force) quit Safari and not go there anymore!

Reply

Answer 4

Jul 23, 2011 8:10 AM in response to Lexiepex

What you really have to do is use another browser. Amaya and Opera also choke on this page. But Camino, Chrome, Firefox, iCab, OmniWeb, SeaMonkey, and Sunrise all display it and make its controls available rapidly.

So I don't understand why it has nothing to do with Safari. Safari up to 5.0 also had no difficulty with this page.

Safari with the latest nightly build of WebKit is still bad.

Reply

Answer 5

Jul 28, 2011 7:13 AM in response to Jonathan Pool

Safari 5.1 and “WebProcess”: PROBLEM SOLVED

The culprit is “Little Snitch”

I am running OS 10.6.8 (Lion-ready). Yesterday, I installed the Safari updater from 5.0.5 to 5.1 . . . and am experiencing repeated and annoying pop-up windows for "WebProcessing."

I found the culprit to be the third-party utility "Little Snitch" — which monitors outgoing internet connections. (http://www.obdev.at/products/littlesnitch/index.html).

I solved the problem by upgrading (FREE) Little Snitch v2.0.x to v2.4 (for Snow Leopard and Lion).

PROBLEM SOLVED.

Reply

Answer 6

Jul 28, 2011 8:26 AM in response to David_Purnell

PROBLEM NOT SOLVED

This solution is not a solution to the problem. It may solve a different problem, but not the one about which this discussion is being conducted.

If you report that http://panlex.org/u loads within 10 seconds and you can then start tabbing through the submission buttons and scrolling down the page as long as you have Little Snitch installed, then we'll have surprising information relevant to the problem. Is that in fact the case?

Reply

Answer 7

Jul 28, 2011 8:58 AM in response to Jonathan Pool

@Jonathan Pool.

Sorry Jonathan. I thought the problem I'd encountered and solved might be related to what you're experiencing.

I just tried http://panlex.org/u in Safari (5.1). The page loads, but then hangs up. I can't scroll or tab through the table.

Then, I opened the same URL in Firefox (5.0.1), and it worked fine. I was able to scroll down the page.

Reply

Answer 8

Lexiepex

Level 6

14,102 points

Jul 28, 2011 8:56 AM in response to Jonathan Pool

Any of you using SWOT? This hangs a lot of pages too.

Reply

Answer 9

Jul 28, 2011 9:02 AM in response to David_Purnell

Thanks for testing, David. Yes, I get the same result as you. See above, where I list several browsers that load this page OK.

If you just let the window sit there, I think you'll find that after 1-2 minutes the page will be fully loaded by Safari 5.1 and you can tab and scroll.

Reply

Answer 10

Jul 28, 2011 9:04 AM in response to Lexiepex

No, I am not using SWOT (whatever that is).

Reply

Answer 11

Jul 28, 2011 9:17 AM in response to Jonathan Pool

The problem occurs with the WebKit nightly builds starting with r90316.

Reply

Answer 12

Aug 12, 2011 10:17 PM in response to Jonathan Pool

I think this is related to a webkit bug with large tables and border-collapse:collapse that I saw in Chrome a while back. Here's the bug I filed with Google. http://code.google.com/p/chromium/issues/detail?id=68215

Here's an interesting thing I'm seeing on http://panlex.org/u I'm seeing the slowness, same as you, but using the Developer tools, if I turn off the border-collapse:collapse CSS rule the page becomes seemingly normal again. You can even re-enable the border-collapse rule and the page remains fast.

I think this may be a bug with webkit that's now shared in Chrome and Safari.

Reply

Answer 13

Aug 13, 2011 2:40 AM in response to Jonathan Pool

There is a bug report for this in the webkit bug tracker. If you register and add a comment to it, it may help it to get resolved.

https://bugs.webkit.org/show_bug.cgi?id=34649

Here's another example which exhibits the bug:

http://chadvonnau.com/projects/web/examples/webkit-table-bug/bordercollapse.html

Reply

Answer 14

Aug 13, 2011 7:35 AM in response to chad von nau

Thanks for helping diagnose this.

However, my testing indicates that this is not a bug with border-collapse: collapse. Here is why:

If I change the value of border-collapse to "separate" and add "border-spacing: 0", the bug remains. To try this, request http://www.panlex.org/cgi-bin/plxu28-bug2.cgi .

If I leave the value of border-collapse unchanged but change the button elements in the cells to plain text, the bug disappears. To try this, request http://www.panlex.org/cgi-bin/plxu28-bug1.cgi .

On the basis of this testing, it would seem to me that the bug is dependent on the button elements and independent of the border-collapse CSS attribute.

This doesn't explain, however, why you have found border-collapse: collapse producing slow results with other large tables and it doesn't do so with my table in http://www.panlex.org/cgi-bin/plxu28-bug1.cgi . It also doesn't explain why you saw the bug disappear when you changed border-collapse on my page but I didn't see it disappear.

Any further diagnostic help would be welcome.

Reply

Answer 15

HarmE

Level 1

0 points

Aug 16, 2011 12:36 AM in response to Jonathan Pool

I've noticed the same problem with Safari 5.1 on Lion.

I have a webpage with a big (not very big) table with a kinds of INPUT elements in it. (SELECT, INPUT TEXT etc)

Since Safari 5.1 the page is stuck for about 10 secs after loading is complete.

You can see the scrollbar visible during this time. After the 10 seconds, the scrollbars hides (as is normal in Lion) and you can scroll / input etc.

In Safari 5.0 it all worked fine!

Reply