Slashdot Mirror
Slashdot Asks: Why Are Browsers So Slow? (ilyabirman.net)
Designer Ilya Birman writes: I understand why rendering a complicated layout may be slow. Or why executing a complicated script may be slow. Actually, browsers are rather fast doing these things. If you studied programming and have a rough idea about how many computations are made to render a page, it is surprising the browsers can do it all that fast. But I am not talking about rendering and scripts. I am talking about everything else. Safari may take a second or two just to open a new blank tab on a 2014 iMac. And with ten or fifteen open tabs it eventually becomes sluggish as hell. Chrome is better, but not much so. What are they doing? The tabs are already open. Everything has been rendered. Why does it take more than, say, a thousandth of a second to switch between tabs or create a new one? Opening a 20-megapixel photo from disk doesn't take any noticeable amount of time, it renders instantaneously. Browsers store their stuff in memory. Why can't they just show the pixels immediately when I ask for them? [...] Unfortunately, modern browsers are so stupid that they reload all the tabs when you restart them. Which takes ages if you have a hundred of tabs. Opera was sane: it did not reload a tab unless you asked for it. It just reopened everything from cache. Which took a couple of seconds. Modern browsers boast their rendering and script execution performance, but that's not what matters to me as a user. I just don't understand why programmers spend any time optimising for that while the Chrome is laughably slow even by ten-years-old standards.Do you agree with Birman? If yes, why do you think browsers are generally slow today?
Pretty much this.
I feel that so many websites have gone to insane levels on ad loading that the web has become almost unusable by some standards.
Yes, I say that with at minimum, 12 tabs open, but most problems I have are around specific ad revenue driven, ad block loathing sites.
Place something witty here
Do you agree with Birman? If yes, why do you think browsers are generally slow today?
Not really, no. Tabs open up basically instantly on the computer I'm typing this with. Doesn't matter much which browser I'm using either. I'm almost always limited either by the bandwidth of my internet connection or the slowness of the database on the other end of the line. I hear people bitching about this browser or that one being "slow" and I frankly have no idea what they are talking about. If you have an even vaguely recently built computer with reasonable hardware then it is a non problem. I also see comparisons between the browsers which claim this one or that one is faster and I simply don't see any meaningful difference. The only difference between them to me is the user interface and what bugs I run into. If there are speed differences they are simply too small for me to care.
Now he did say "hundreds of tabs" which is probably the root of the problem. My guess is that he's overtaxing his computer and running out of RAM. If you have hundreds of tabs open then you are Doing It Wrong.
I have a 2012 vintage Mac Mini and it runs just fine. Safari, Firefox, Chrome, doesn't matter. I'm typing this on a PC with a Intel i5 chip and an adequate amount of RAM and it's fine no matter what browser I use. I mostly use Firefox but I'm pretty agnostic about which browser to use as long as it works and I can block ads and trackers adequately. So no I don't think there is a problem with browser speed as a general proposition. I do think people can do stupid things that slow down browsers significantly.
The idea of not hosting your own local copy is that if everyone uses a common source for the library, then the browser should already have that resource cached even if it's the first time you hit the page. For large enough libraries that the Google CDN (or another CDN) includes it, it's worth it.
https://developers.google.com/...
https://www.asp.net/ajax/cdn
https://www.keycdn.com/support...
Now, for obscure libraries, you're better off hosting your own so that you can control the version and not worry about the referenced script changing/moving/breaking stuff.
This would involve admitting the (arguably ugly; but undeniable) truth that web pages have become a somewhat dysfunctional software development platform; but it'd be nice to see browser caching mechanisms that don't just treat giant JS libraries as a special case of cacheable assets generally and hope for the best; and instead offered something more in the vein of what Linux package managers do.
If you host your own; the user ends up downloading a copy even if it is identical to the one they pulled from somebody else for a different site that uses the same library. If you avail yourself of Google's...generous...hosted offer, the user is more likely to cache; but then every load of your page also involves a chat with Team Mountain View.
Ideally, you'd specify that you use JSLibXYZ, with cryptographic has and/or signature specified, and at least one source for a client who doesn't have it to get a copy; but the user's browser could make use of JSLibXYZ from any source, so long as the hash and signature match, since that provides assurance that it's the same thing. Caching mechanisms based on domain of origin are sensible enough for assets that are likely to be site specific(pictures, stylesheets, etc.); but, like it or not, giant javascript libraries, many shared across a large number of otherwise unrelated sites, have a lot more in common with dlls than with images; and it would be handy if they were treated as being a different case. With hashes and/or signatures, you could ensure integrity even in cross-site sharing situations; allow caching to work regardless of how the site operator has set up script hosting, and end the choice between 'serve yourself, lose out of caching/let google do it, get caching but add a 3rd party to everything you do'.
It's not just ads; a lot of websites pull in JS helper scripts from other sources (instead of hosting local copies of their own). And those sources do not always have the best performance.
What we should do is get the web standards updated to add a Rule:
Remotely-loaded scripts (Loading from a different server) must specify a SHA256 sum in the Script tag such as
<script src="https://example.com/mycode.js" integrity="sha256-7d774a8ff0e73f2791c3a12dfc3ef1f9a1a640d470584b9b9222d395e8519fc5">
If the hashcode is not specified, then the script will not be run.
If the hashcode IS specified, then it can be cached by any 3rd party.
The URL becomes "Advisory", and Popular hashcodes can be distributed by Amazon, Google, or your local ISP.
There should be a way to have a DNS suffix DNS record to specify local object-caching servers that can be queried by code.
Caching is permanent. An outage of the original source server has no affect.
The UI is not slow.
What's slow is the fact you're loading MEGABYTE APPLICATIONS full of commands through the web that have to be processed before display.
Go to a 90's era website with HTML3.2. Watch how magically fast everything is displayed.
Check out the old website, "Internet Explorer is Evil":
http://toastytech.com/evil/
Watch how magically fast the animated GIF backgrounds display. How magically instantaneous the text renders. Why? NO CSS. NO JAVASCRIPT. No 5 MB app being downloaded.
And even then CSS and JS don't have to be slow. But people designing these websites simply don't give a shit about speed. Have you ever tried to load a Google Document on a Netbook with an Atom processor? Apparently a dual-core CPU with 2 GB of RAM isn't enough TO DISPLAY TEXT and if you try and multi-task it'll bring your computer to a complete halt. I've literally had to panic close tabs in Linux with my netbook with Google Docs open with other tabs, because if it starts getting laggy, it'll quickly get to the point it freezes the whole computer (>15 seconds between mouse moving) and it's actually faster to reboot the entire thing. (SSD ftw.)
You're talking about fast, as seen by the user. They don't care about that at all - they're optimizing for fast as seen by the server: less bandwidth. Anything they can offload is a win, no matter how much the user experience sucks.
Socialism: a lie told by totalitarians and believed by fools.
Dell machines are usually designed to be quiet. That's why things are slow. But that's a different story.
You aren't working cradle-to-grave. hitting the local disk isn't about the disk speed. Those 15ms can be zero for this discussion. Similarly, the ping to the site of 125ms is meaningless. Here's what happens, cradle-to-grave:
Scenario 1, live streaming:
connect to site: 125 ms
download 200KB of html and javascript, compressed to 100KB, 1s
Scenario 2, external file:
connect to site: 125ms
download 100KB of html, compressed to 50KB, 1s
download 100KB of javascript, compressed to 50KB, 1s
Scenario 3, external file cached:
connect to site: 125ms
download 100KB of html, compressed to 50KB, 1s
wait for disk to be available, access disk for 100KB of javascript, wait for disk to spin up, 15ms
wait for virus scan, read cache meta data, determine that our cache file isn't already too old, 1s
HEAD the web-site file, to compare meta data, check to see that our cache is good enough, 1s
-- look at all of the side-work involved, and we're still hitting the site much of the time to check the cache anyway!
Scenario 4, external site
connect to site: 125ms
download 100KB of html, compressed to 50KB, 1s
connect to second site: 125ms
download 100KB of javascript, compressed to 50KB, 1s
Scenario 5, external site, cached
connect to site: 125ms
download 100KB of html, compressed to 50KB, 1s
wait for disk to be available, access disk for 100KB of javascript, wait for disk to spin up, 15ms
wait for virus scan, read cache meta data, determine that our cache file isn't already too old, 1s
connect to second site: 125ms
HEAD the web-site file, to compare meta data, check to see that our cache is good enough, 1s
-- now we have side work, a second connection, traffic everywhere
And all of this gets even worse when you realize that the connection to your primary site is keep-alived for your entire visit -- minutes at a time -- but to your secondary site, you're lucky to get a full second. Add all of the other hardware that you're using, in terms of disk, cpu, virus scanners. Now add the entire local permission system, cooling system, throttling systems, battery savers, and you're now conflicting with everything else running in the background.