disabling Javascript - what effect?

Hi Fran,

Some good comments as usual, and 'fishing' for leads is of course welcome because even though I'm fairly convinced that this is not being caused by something 'tangible', rather a low level bug of some kind, you never know when something's been overlooked and it all makes sense later.

I've basically got this problem licked with javascript off (and on when needed) - Safari's still running on one launch: 19 days, which was the core of my issue with it really. This is perhaps slightly overkill but I'm really just seeing how long I can push it now! ;D

I feel I must clarify something though just in case you're wandering down the wrong path slightly; This is not a problem with javascript or sites using javascript per se, rather javascript appears to be the solution to the problem.
It's a problem that affects ALL browsing, not just sites using javascript. For instance, I first really noticed it using these boards on the unix forum which is a 'main site' of mine; a site that's always running and periodically updated. Now, this forum doesn't appear to use javascript, i.e. it looks and works identically with it on or off (there is mention in the source but I haven't noticed any effect - http://www.apple.com/main/js/scoderemote.js ). After a period of time has elapsed Safari exhibits this problem, no matter where one browses to - it just so happens that switching javascript off cures the problem - simple as that. So it's not a problem with it slowing down on some sites and not others, or just sites using javascript, it's a universal slow down (and it even starts to affect little things; window scrolling and the like - in fact, Safari as a whole becomes unusable).

If this hypothesis is indeed correct then I'm guessing the javascript implementation starts to struggle after a period of time has elapsed - switching it off removes it from the 'mix' and Safari is freed from the burden and works as it did from a fresh launch. Therefore, at this moment in time, I surmise that it's Apple's implementation of javascript that is somehow bugged and gets into trouble after it's been in use for some time. (Others suggest similar WebKit apps are affected which indicates it's not Safari itself that is bugged). I'll admit the other suggested fixes add more confusion to the arena though.

Of course, I haven't done any serious testing (perhaps like JNK is considering) - like just running Safari with nothing but a single Apple Discussions page for a week and see if the problem manifests itself regardless. For all I know there could be one site out there that causes javascript to spit the dummy for whatever reason and it's going unnoticed, impossible to tell without some stringent testing and serious time devoted to the problem.

Normally, when people turn JavaScript off, or counsel others to, it's NOT to gain speed; it's for some other reason.

On some sites JavaScript is merely used for rollover effect; but on advanced sites, JavaScript is used for a lot of important functions-- sometimes so important that you won't have full access to the site unless JavaScript is on.

The difference in speed with JS off, if any, should be so insignificant, that it begs the question: is one second or even a few worth the tradeoff in functionality.

That said, if you come across a site that does not work for you, turn JavaScript off and see if it works. Sometimes, some under-educated web site developer tests if your browser is IE or Netscape, and, if it's neither, then you might be locked out of submitting a form or accessing a page. In this instance, it's possible-- especially in the case of submitting a form-- that turning JavaScript off will get you passed the barrier.

Java caches have nothing to do with JavaScript-- they are two entirely different languages that are mutually exclusive, like Flash and JavaScript, or Perl and PHP.

A site may or may not clue you in to using or not using JavaScript. But advanced scripting is very prevalent on major sites; simply view the source code to see for yourself. Sometimes, to see the script source, you have to dig deeper and open the script's "src" URL. These sites use it for a reason: Interactivity!

JavaScript, to date, has been the major key to interactivity on the internet; and the best sites are interactive, as well as attuned to your browser and screen resolution; so that you get the best display possible.

Good luck with your research! 🙂

Many people (including myself) seem to be suffering from an intense and extremely irritating slow-down problem with Safari. This is mainly characterised by a huge lag between doing anything, for example, clicking on a link in a page, and the actual action taking place. In this example the 'clicked' link goes red (as it does), but stays red for a long time, and then the beachball spins and the waiting begins. This waiting is small initially but then progressively climbs as time passes until it gets up into the tens of seconds to minutes long. That may not sound like much but in 'computer responsiveness time', it is an ice age and one that seriously impacts the usability of Safari! Other simple things like attempting to scroll the window produces the same effect - pause, spin, wait, curse, action (finally).

1) It takes a period of time for the problem to manifest - for me it always seems to be a few days.
2) After noticing the first signs of the problem, it continually gets worse and worse over time until Safari becomes utterly unusable.
3) Monitoring file system use (using lsof) shows nothing going on at that level, i.e. no caching to disk, or other unusual disk activity.
4) Processor use however goes through the roof for the period of waiting (like 80% or 160%+ with two processors).
5) Very important :- Any and all symptoms of the problem are completely removed via quitting Safari and then restarting it. (Note. this is of great importance because it hints that there is no problem with any of it's current support files, e.g. favicon caches, page caches, plist file, etc. - none of these things greatly change between quit and restart, i.e. they're still present and as they were two seconds later when Safari is relaunched, at which point it works perfectly again until the next time the problem begins...).

What Works?

1) Switch javascript off in Safari's prefs - I had occasion to try this during a particularly serious case of the slows...; BAM, instant dodge viper performance! - back to normal in fact, just like a fresh launch. Well, clearly the cause has been found...
2) Clean the Java caches - Others (including yourself JNK) have reported similar successes. (I've not confirmed this to myself as yet because I've been too busy enjoying a Safari that lasts over a day or two...)

So, there we have it, two clear winners on this weird issue. And whilst you're quite correct Fran that they're two different things, so far they share a strange similarity as successful 'solutions' (and also provide hints to the source of the problem).

JNK - It's not desperately bad with javascript off but what you will find is that you'll browse to some page somewhere and click on a link and nothing happens, you'll wonder what's going on, then you'll notice "run script()" or some such in the 'status bar' at the bottom of the window and the penny will drop: switch javascript back on and reload the page to get back full functionality. Sometimes a page won't look right at all, bit's missing, overlapped text, that sort of thing, again - switch it back on and reload. This switching on and off can be somewhat speeded up by using the associated keyboard shortcuts.

As for the memory leaks thing - I'm not convinced the two problems are related at all now, but using the above technique I've managed to have Safari running and usable non stop for 12 days now! Anyone want to know what the leaks are up to at this point?:

<pre><small>
Process 206: 3447558 nodes malloced for 500605 KB
Process 206: 52956 leaks for 2238128 total leaked bytes.
</small></pre>

Curious: do you have any third party browser "enhancement" software running-- or maybe, any scripts that are constantly monitoring something?

I have not experienced these leaks or cpu problems and I'm almost constantly on the internet (professionally)-- but, then again, I habitually quit Safari and unplug the cable modem every night.

I guess that's one easy solution, rather than surfing without two of the web's interactivity building blocks.

Hi Fran,

No, no 'enhancement' software, in fact I've long ago abandoned those sorts of apps, finding amusement and solutions in more and more of my own unix/cocoa/AS abilities (which aren't that much by the way, but what a collection of technologies!). Nothing's working with, or monitoring Safari that I'm aware of.

Actually, and most disconcerting, I think I've experienced this problem since 10.4.0 - clean fresh install on a clean drive as well.

Yes, if you quit Safari every night then I guess you won't ever see this problem. But that's at the root of it though, I don't want to have to quit it every night - often I have a few windows open with many tabs from research/reading/surfing/learning from the previous day that I don't want to have to lose on a quit, nor make temporary bookmarks of them all for obvious reasons. In fact it's a pain that shouldn't be there - Safari should be quite capable of running as long as any other app. (There may well be a compromise here via the use of Saft to save the browsing state on a quit...).

You're right - we need javascript - switching it off is indeed a poor 'solution' to this problem, but it's not an insurmountable situation to manage in the meantime. I haven't needed to mess with the java caches because it seems that switching off javascript is good enough, so it's just a question of being alert for those sites that need it on. I'm a lot calmer than I used to be, put it that way ;D

If you can handle it, it would be interesting for you to try it: leave it on at night and see how far you get. If security is a worry then perhaps make sure all 'services' you need are unchecked in sys prefs when you leave it to make sure all the ports in the firewall are closed, open them back up in the morning. You might even be able to disconnect the cable but leave Safari running. (Of course, no pressure if all this doesn't sound like a good idea!)

Kind regards.

You know, "CD", I think I will try leaving Safari on for a time; because the more research that's done, the closer we are to knowing what's causing it.

After reading all of your postings on this subject, I realize why quitting Safari is not the ideal solution for you, as it may not be for many others; but for some who may read this topic, it's a perfectly reasonable solution, because they have no paramount reason to leave it on.

That said, may I ask? "Do you:
-- use dashboard widgets; or
-- have any flash thingy running or querying the internet (on your desktop probably)
because closures are used frequently in Action Scripts (based on ECMAScript/JS); or
-- frequent some sites that, as part of our research, you or others can monitor?"

The reason I ask, is because a technique called "Closures", specifically, in this instance, JavaScript Closures-- an advanced programming technique, can cause leaks, if they are improperly, or accidentally coded. There is a documented memory link in IE 4-6 that is proported to be due to bad garbage collection of circular references (caused by an ill-formed, or accidental closure). Here's a link to an article that describes this position.

This is something we might explore more, in the quest for the culprit.

Are you keeping a log of this "slowdown" process, yet? JNK, I think I
really would, based on what you believe to be occurring.

Use a site like one of these:
-- http://www.bandwidthplace.com/speedtest/
-- http://www.dslreports.com/stest

... to test at different times; sometimes, when you think Safari seems
fast, and sometimes when it seems slow. Keep it in a little database
with your comments, which should be logged before the test, so you're
not coloring the results.

That log will also come in handy as you and others, here, start to hone
in on different sites and perhaps test some things, together, from
various machines. Additionally, it is something concrete that you can
submit to Apple to help them study the problem.

There is a lot to respond to in your post 😉.

re: speed tests:
Yes, the speed tests are testing your connection speed and are affected by traffic on your (Comcast highspeed cable) network. They do it by downloading some code to your computer; they download a little more, then more, and more if your speed is apparently high, until they can interpolate the results. So, indeed, what they are downloading is quite different than content you are downloading on a site. But, nevertheless, it gives you a base, which should be an item (column) in your log.

About a year ago, I created companion js files that, when included in the download of any page, will give you the speed of that download. Of course I created it to test my own pages-- those, especially that were media-rich, wherein the total file size of the tested page was passed to my "SpeedCheck" function. You can get the total size of any page, using Safari's Activity link (under the Window menu), and adding up all of the sizes of the target page, if there's not already a total listed.

Here's what I'll do for those of us here wanting to run similar tests, independently. I'll gather the code, include it in a frameset with instructions, and load it to my .mac homepage, then post back the link-- if that appeals to you. It will probably be tomorrow before I'll post the link.

re: log record columns:
Besides the columns you listed, you'll want, of course a "Perception", column, where by which ever name it goes, you can describe "slow", "fast", or whatever consistent terms you decide to apply to your initial perception of Safari's performance before testing. Then add a "Comments" column where you can add notes. Play it by ear; you may well come up with more.

re: faster load emulating MSIE 6.0:
Yeah, I'm not convinced that the user agent emulations are right on; so I would not put a lot of stock in the fact that an emulation of MSIE 6 loaded a page faster-- it could be because it was already in cache, for example.

re: comparing a page with JavaScript enabled vs. disabled:
Most interactive sites use either browser detection (not so good) or feature sensing so that they can present you automatically with material that you'll see correctly; instead of asking you which you want to use, or giving you options that you may not fully understand-- which is a clumsy method of getting, hopefully, to the same place.