Why is the web so slow? | Hacker News Reader

Why is the web so slow?

calendar.perfplanet.com

42 pointsssttoo45 comments

Latency is funny, it is so because:

* It is additive. It is necessary for just one component in the chain to add latency (monitor refresh, uncompressing, a bad cable modem, a bad router in the path, overloaded server, bloated JS code in the page). It is very hard to remove (one can argue impossible, but I am thinking of a multi-path set up with redundant hardware or network connections)

* Even though we can process teraflops per second on home GPU cards, our websites load about as a fast as they did 10 years ago.

* Border-line imperceptible UI or audio latencies still lead to bad user experience. They might not even know why they don't like it but in an A/B test they would pick the faster more response one. This was the case with Android vs Apple up until not too long ago. Even tiny UI jerkiness is enough to annoy a large number of users.

* OS and whole software stacks are usually designed for improved throughput not low latency processing. It takes tuning (proc and sys params) or even installing a special kernel to get better latency support for low level code.

* More benchmarks also measure throughput more than latency. Software is often picked and compared based on throughput, latency is second citizen most often. In a sequential setup for example, the two are compliments of each other, the more requests per second, the lower the latency of each request. It is only in concurrent and parallel contexts when latency starts to behave widely different. Send 100 requests at the same time towards the server? What happens? Do 50 get processed in 1ms but the rest block for 25ms?

* Low latency and liveliness has to be baked into the innards of the system/VM/framework. Depending on what is picked (and it often is picked based on throughput) a lot of time might end up being wasted fighting latency in a highly concurrent situation.

Your point about android v ios really hit home with me. People who have tried both often express to me that they enjoy ios far more than android, but can't really explain why. I, myself, appreciate the fluid 60fps experience, and generally on explaining that difference to them, a lightbulb goes off in their head, and they realize that does actually bother them as well, but they just didn't know it was something to be noted.

In ui development, we recognize things like responsiveness and fluidity, and something as clearly different as 60fps v 30fps is conjures a very clear picture in our minds, but most people are not versed in such language.

Of note: you can achieve a solid 60fps yet still have latency issues. What instinctively bothers people is not just framerate, but the fact that on iOS†, scrolling (for example) has the content literally glued to your finger due to whatever scheduling trick, whereas the ever so slight latency on Android breaks the illusion as the content plays an uncanny catch up with the fingers. Project Butter made great strides to solve the framerate issue but also enabled triple buffering, which by definition increases latency. It's definitely noticeable even on both my N4 and N5 and absolutely jarring on my 2012 N7.

† also available on my Mac right now, even though the finger is on the touchpad instead of the screen, the scrolling response is instantaneous.

Very insightful.

"More benchmarks also measure throughput more than latency.": Yup, latency benchmarks are really very hard, especially when humans are involved (UI/UX), due to biases and the way perception and cognition quite often try to adapt sparing us "the worst of latency" but at the same time leave us with a gut feeling of "lag". The journey J. Carmack undertook to find and work around latencies for the Oculus Rift is good example for all this, i think. You can't do this for each and every app to give all users this "snappy" feeling... especially when a huge system like "the internet" is involved.

I believe there is also "latency creep": even if "a system" has low latency at the beginning, operating it, maintaining it and especially scaling it will more easily accept increased latency than lower throughput... up to an threshold of course when the system becomes "apparently and unbearably slow" (still not the case for google, facebook etc. i guess)

Add servers to a farm because the median req. latency increased by 30%? Hmm...

Add servers to a farm because the number of users increased by 30%? Sure! ;)

So most probably facebook, yahoo etc. are missing serious absolute latency SLAs [1] and those huge organizations as a whole tend to neglect them until things break... they don't care about "slow(ish)".

[1] http://en.wikipedia.org/wiki/Service-level_agreement

ps: it's "funny" to see the gaming big-biz industry fighting this: they are huge organizations willing to accept "slow" if the money comes in right, at the same time some of them are in a market where the customers are much more sensible to this issues than the typical facebook is slow poster.

> I believe there is also "latency creep":

Very good point. I'll have to steal that phrase. Latency is additive in the system but also over time usually. Prototypes look good from then on it is usually just API layers, paths and more code on top. Those usually add latency to the stack.

... and I will have to steal your additional and concise points from the software development perspective ;)

Thinking about it, maybe to ensure some latency awareness we should adapt the "timeout-exception" concept in areas it is not used today. Given some runtime-lib support call sites in a project could be given a timing threshold to complete their work... if the threshold is exceeded an exception could break the code-flow in a specially prepared build of the project. In very modern dynamic environments ;) such thing could be implemented by transparently wrapping the call sites (via attributes, annotations, monads etc), in more traditional env. the compiler could generate specially adapted code measuring the latency using the high precision timers most CPUs provide...

Well-intended advice from another non-native speaker: You probably meant "sensitive" instead of "sensible" in your P.S.

right ;) thanks.

>Even though we can process teraflops per second on home GPU cards, our websites load about as a fast as they did 10 years ago.

Well, they are also 10x the size of what they were 10 years ago, with all the new fangled assets, large images, etc.

>OS and whole software stacks are usually designed for improved throughput not low latency processing. It takes tuning (proc and sys params) or even installing a special kernel to get better latency support for low level code.

Well, I don't think that has anything to do with the web latency as perceived client side. 99% of the lag/slowness is (should be?) because of network latency, not because the OS/browser is slow to receive and render.

I was wondering if the 10x was accurate, and it seems it is...

Complete assets of...

  "google.com": 1,09MB
  "bing.com": 332,95KB(!)
  "yahoo.com": 1,84MB (1,47MB with ADblock)

I was actually estimating more than 10x, due to the heavy use of linked JS, CDNs and whatnot, but I would say it's actually quite correct (I checked other websites I use with similar results, so I didn't post it here).

I was actually quite surprised by bing here, though google adds around 300k (which is the size of the whole bing assets) for the doodle in my country.

Not to mention the background image in the bing homepage as well.

Well played bing...

Good point. Yeah it is a trade-off. One can ask "Do we need much larger images if it means stuttering load?". Or "Has anyone looked at why we are loading 1MB worth of JS on each page refresh?". Most places don't have a "latency czar" so to speak. It is usually UI testing or QA department that might notice it. (I used the "czar" word because it is really someone who need to look over all the system front to end, the database in the very back of the stack, up to the pixels on user's screen, which is very different perspective as most work in layers that go horizonatal -- front-end, ui, content delivery, back-end, database).

What sucks is that latency hiding techniques are not applied. For example, prefetching HTTP requests unfortunately breaks a lot of (HTTP GET misusing) web apps.

Designers aren't the only ones with work to do.

CDNs appear to be messing with performance in ways that aren't really transparent to users or content providers.[1]

We need better tools than speedtest sites. We need a way to see an ISP's provision of popular sites over time.[2]

Or just encrypt everything and bounce it through proxies or route anonymizers, make that standard. Either way.

[1] http://mitchribar.com/2013/02/how-to-stop-youtube-sucking-wi... ; http://www.reddit.com/r/technology/comments/13kmvd/have_time...

[2] http://www.youtube.com/my_speed may be an example worth following for Netflix, Vimeo.

| Or just encrypt everything and bounce it through proxies or route anonymizers

Yep, that'll speed things up

Its not about speeding it up, its about finding a fair test, this would create a worst case delivery scenario which you know someone hasn't messed with.

If you can optimise your applications under those conditions you know its going to be gravy for those without lots of hops. The problem is that developers have very fast computers AND are usually a very short hop count from their deployment servers. They make really bad testers.

Regarding [2]...

https://www.evernote.com/shard/s74/sh/f033a734-455b-427a-90a...

SF: Is there something that I'm missing that isn't shitty comcast? (And I'm not eligible for Webpass, though I can dream)

Comcast Business Class is pretty solid in SF (as opposed to their normal service, which I've also had and is terrible).

MonkeyBrains

As a Canadian I notice as 2 consecutively ranked queries:

"Why are Canadians so rude"

"Why are Canadians so friendly"

And I'm suddenly reminded of Jay Leno's "Jaywalking" segments. And my guess is that for the majority of these queries, it's because the person has 7 different toolbars loaded into IE. IE8 if we're lucky, but probably IE7. Maybe IE6. Plus they probably have a ton of autostart crap on their computer and don't know how to differentiate between "my computer is slow" and "the web is slow."

I wholeheartedly agree! After spending half my career cleaning up malware, this seems to be the #1 reason for performance complaints.... That, and the fact many vendors pre-load crappy software to subsidise the cost of the PC... It is hell for the average everyday user. We here know better than to click on the numerous green ad 'Download Now' buttons that litter a single page.

Add some torrents downloading/uploading continuously.

Block all advertising, tracking an analytics, and a considerable part of the web becomes much faster.

The amount of worthless crap that comes with a simple web page where only a bit of text is relevant is staggering.

I believe this is one of the most, if not the most, under-appreciated "features" of websites and software (all types, including games).

It directly affects usability and therefore user engagement. And that means it directly affects the bottom line for most companies.

But most companies fail to see or ever really do anything about it.

I have a feeling that most of those searches could be answered by, "It's because you're on an unreliable internet connection".

Shouldn't we then build sites with that assumption in mind?

For example, why is It that almost no site uses appcache, when it is a way of ensuring that resources are already local and the only network traffic is the truly essential part? Why do we care about retina imagery, when it is obvious that the majority of users get a worse experience as a consequence? Why have sites doubled in size in two years time without adding a meaningful percentage in content?

These all point to an industry that lacks perspective on their user's actual user experience because they are sitting on a nice fiber line two hops from the server.

I believe the canonical answer to that is that even Google Search, the page you'd expect to be the most cacheable bundle of HTML/JS/CSS on the Internet, has to deliver its pages from a "cold-start" more than 60% of the time. Making sure visits 2..N work smoothly won't improve the average user's experience when most of them are on visit 1.

why is It that almost no site uses appcache, when it is a way of ensuring that resources are already local and the only network traffic is the truly essential part?

HTTP caching is fine for that. appcache is more about allowing the site to largely work even after going offline. That's more than most sites need.

Yes, but the fact that most websites these days have to load seven dozen javascripts and CSS stylesheets to become usable probably doesn't help either

Add to that Webkit's retarded decision not to render any text at all if the web-page uses custom fonts.

The reasoning behind this is a wish to avoid annoying or "unestethical" flicker from one font to another once the font has loaded.

That's great if you're on 10mbps or more.

Now put yourself on a 64kbps barely functioning link on the metro, you have DLed the 800bytes of article text you really want read 5 minutes ago but you're still waiting for that one special font which webkit requires to be able to see anything. And that wont fully load until you're off the metro.

I tell you: Lesser things can drive a otherwise reasonable person completely mad.

Don't use custom fonts on any mobile stylesheet ever. Thanks.

the real killer here is scripts that load scripts, often several layers deep, and a blocking load and a round trip each time....

Google groups comes to mind. It's not uncommon to have to wait several seconds before you can read the text, and then it all collapses and you need to fish for the right post.

I'm pretty sure 95% of those searches are people googling "why is X so slow" when they are having connection issues, as opposed to wondering why in general a service is always so slow.

And those people never come back asking google "why is facebook so fast" or at least "back to normal". Obviously a search engine reflects more problems than good things.

How many people are going to google: "why is facebook so fast" ?

tried "Why is my computer " or "Why is my car"? It's just some pattern picked up by the search engine. no thing is fast enough.

Yes, it works even with "Why is my brain..."

And maybe some things are fast enough, but nobody searches for "why is my computer fast enough" or "why is my brain too fast"

This should apply to games too lol. I hope one day we can rid the world of the 'load screen'! Perhaps with more SSDs and developers putting effort into streaming (both from net and hard-drive), it'll be possible ;)

I'm hardly an expert on games, but I think I hardly think streaming from the hard drive would a big improvement. You would (at best) see stuff partially loaded, or there would have to be some generic replacement (assuming it's a 3D game) for textures, meshes and what not. This would prove to be just as annoying, if not more so.

The key is the pacing of the asset streaming relative to the rate of environmental change the player is creating on the screen.

Streaming essentially disables fast travelling and teleporting to some extent, but makes slow travelling seamless and much, much more enjoyable. World of Warcraft was among the first online games to get it about right at launch, and I'm pretty sure the absence of loading screens was a huge factor in its universal acclaim.

A more recent example would be Diablo 3. There the absence of load screens and on-demand asset loading resulted in performance problems which persist to this day. I believe they're even considering re-introducing loading screens in the expansion.

I'm not hopeful, thing have generally been going in the other direction over time.

Because some people use 1MB+ .png images to measure latency of involuntary testers (visitors)?

(the OP contains: http://lognormal.net/boomerang/config.js)

Because: http://www.renesys.com/2013/11/mitm-internet-hijacking/

Because of incessant cryptocurrency price checking?

It's slow because it's text based. I think there could be advantages to switching to compiled html or any other open binary page format. It would be less flexible, but at least it would be less abused: no more pages and pages of CSS, weird js widgets, blurbs of html. Compressing html with gzip is not that much efficient either.

I don't think it's a great idea, but in some case it would sort of force everyone to make content that is just lighter.

Reply on news.ycombinator.com