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?
It's web pages that are filled with useless javascript libraries that people think they still need to use for cross-browser support even though Internet Explorer is long dead.
It's web pages that are filled with useless ads that run their own scripts, sometimes with their own libraries too, fetched from multiple servers.
It's web pages that are filled with useless tracking scripts, sometimes with their own libraries too, fetched from multiple servers.
It's web pages that are filled with huge animated GIFs that should be in video form instead.
It's web pages that are filled with auto-loading, auto-playing videos, jamming our connection to download something we don't even want to see instead of downloading the web page we're trying to read.
Disable plug-ins. Disable javascript. You'll see how fast browsers really are.
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.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Using a good, fast third party source
LOL
I see what you did there.
Also, I just clicked on AdBlock Plus --> Open Blockable Items. There are 31 scripts on this page.
31 MOTHERFUCKING SCRIPTS ON ONE PAGE!!! You people are insane.
OK, I just benchmarked 1000 forks in C++ on the lowest-end desktop Sandy Bridge Core i3-2120T running at a reduced frequency of 1.6 GHz. I got 89,130: a whopping 89.13 microseconds per fork.
#include <chrono>
#include <iostream>
#include <unistd.h>
#define N 1000
int main() // std::cout << pid << '\n';
{
auto start = std::chrono::system_clock::now();
for (int i = 0; i < N; ++i)
{
int pid;
if (!(pid = fork())) {
exit(0);
}
}
auto stop = std::chrono::system_clock::now();
auto elapsed = std::chrono::duration_cast<std::chrono::microseconds>(stop - start);
std::cout << elapsed.count() << " microseconds for " << N << " forks\n";
return 0;
}
Looking at RequestPolicy this page redirects to 41 other sites.
41 MOTHERFUCKING REDIRECTS ON ONE PAGE!!! You people are insane.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
Ghostery
My first e-mail address had a comma in it, and token rings sucked for a lot of reasons. That's how long I've been developing web-sites.
But I didn't say I've been building web-site for three decades. I said, quite obviously, that I've been serving pages to clients for three decades.
You may be way too young to understand the difference between real-world practical and academic history, but the world wide web was not the start of the internet, the internet was not the start of networking, and networking was not the start of serving pages to clients.
Caching's been around for a very long time. If you want to learn about the benefits of caching, and the pitfalls, you want to look at archive caches, not transmission caches. When access involves an elevator, or a truck, you quickly learn what does and does not make sense.
Here's a perspective for you. When accessing a cache from a warehouse two miles away involves a truck, you get to consider the effects of rush hour traffic. So when your third-party server caches your javascript file, you get to consider that it isn't geographically in the same place as your primary server, meaning that not only does your client need to hit "another" server, with another connection, another keep-alive, and another set of caches, but it also needs to get there, through an ISP channel full of traffic. You've just doubled the amount of traffic globally. You can't ever bet on it being fast. You can only hope.
So, of course, you have a basement cache of your warehouse cache -- i.e. the disk cache. Elevators don't have traffic; or so you say. But the warehouse is full -- always, because that's what a warehouse is. So you get to search stacks and shelves and indexes. You get to have organizational training, and inventory days. Welcome to the magic of disk thrashing. The file table is incredibly slow in terms of file handles. Welcome to WAD files. Defragging is the inventory day, by the way.
So now you've got your reliable cache, that's only reliable under minimal load. Perfect. But some things get accessed often. So you keep a copy upstairs in the filing cabinet. But the filing cabinet is small. So you shuttle different cabinets up and down per day. Today you need the green cabinet. Tomorrow, the red. And life is good. Welcome to swap files -- memory to disk and back.
Now you've got employees shuttling cabinets, with dollies, and elevators, and warehouses, and trucks, and traffic. And here's the kicker. You haven't eaten yet! You've got a dozen staff, countless duplicate copies of files, trucks, buildings, elevators, desks. But you haven't done a lick of revenue-generating work yet.