Optimizing Page Load Times

John Callender writes, "Google engineer Aaron Hopkins has written an interesting analysis of optimizing page load time. Hopkins simulated connections to a web page consisting of many small objects (HTML file, images, external javascript and CSS files, etc.), and looked at how things like browser settings and request size affect perceived performance. Among his findings: For web pages consisting of many small objects, performance often bottlenecks on upload speed, rather than download speed. Also, by spreading static content across four different hostnames, site operators can achieve dramatic improvements in perceived performance."

Comments

Erm.. huh?

[Turn-X Alphonse]

I'm not quite sure how this really has any "real world" effects.. Browsing speed is already insanely fast to the point where if you blink you miss the loading on most connections these days. How does speeding up this second or so really help anything?

I can see it's use on large sites but this seems aimed at smaller sites.

Then again HTML isn't my thing so it goes over my head I guess.

Re:Erm.. huh?

[rf0]

If you are on a fast broadband pipe you are correct but there is still a lot of other people on small connections with low upload limits (64k-256kbit) and I can see why this could be a bottle neck as it can't get the requests out fast enough. That said there are things a user can do to help themselves.

Firstly if the ISP has a proxy server then using it will reduce the trip time for some stored content meaning it only has to go over a few hops than prehaps all the way across the world. You can also look at something like Onspeed which is a paid for product but compresses images (though makes them look worse) and content and can give a decent boost on very slow (GPRS/3G) connections and also get more out of your transfer quota.

Re:Erm.. huh?

[Jussi K. Kojootti]

Browsing speed is already insanely fast to the point where if you blink you miss the loading on most connections these day.

Unfortunately that is not true. Many "broadband" connections are definitely not insanely fast, and at least here in Finland the upload speeds of most connections are so pathetic that the problems mentioned in the article are very easily observed.

Re:Erm.. huh?

[mabinogi]

1.5Mbps ADSL.
5 Seconds to refresh the page on slashdot. That's just to getting the page to actually blank and refresh, there's still then the time it takes to load all the comments.
Sometimes it's near instant, but most of the time it's around about that.
Most of the time is spent "Waiting for slashdot.org", or "connecting to images.slashdot.org".
It used to be a hell of a lot worse, but I installed adblock to eliminate all the extra unecesary connections (google analytics, and the various ad servers). I didn't care about the ads or the tracking, it just bugged me that those things made my browsing experience slower.
I find it funny that this guy is suggesting spreading across multiple hosts, it's my completely unscientific and entirely anecdotal experience that the more host names the browser has to resolve to load the page, the longer it takes before you get to see anything.

I'm in Australia so there's a minimum 200 ms latency on roundtrips - five roundtrips and you've added 1 second to the rendering time. Approaches that add extra DNS lookups really aren't going to help. (Though the DNS lookups themselves aren't necesarily going to take 200ms - they could be much faster if they're in my ISPs DNS cache, or the could be longer if it's got to query them)

Re:Erm.. huh?

[jakoz]

It has very big implications still. For you it obviously has no effect, but let me give you an example.

We are in the middle of the planning of a software release that rolls out to thousands of users. So that they can access it remotely, we are toying with the idea of supporting 3G PCMCIA cards.

In the area we're benchmarking in, latency and a retarded slow-start windowing algorithm are the limiting factors. Keep in mind that this software is crucial to the company, which is a fairly large one. Adoption rates of it drive the company.

We are limited by the existing platform to use IE. A simple registry hack such as the one discussed to increase max connections can (and will) make the difference to our customers, and was my number one recommendation when they ran into performance problems, with me betting it would influence benchmark times faster than their next two solutions combined.

Re:Erm.. huh?

[LiquidCoooled]

Clear your cache and then try loading something like digg
The front page is so chocka with javascript files it takes an age to come up.
As an example I can click digg into the first tab, click slashdot boingboing and gmail into others.
I can glance at the front pages of all of them and most of the time clear out my spam before digg even appears, it sticks on the js files.

Re:Erm.. huh?

[mabinogi]

A little clarification to that - I have pipelining on, which may be why multiple hosts is a net loss for me, instead of a gain.

Re:Erm.. huh?

[x2A]

There are other factors.

1 - keepalive/pipelining connections means only 1 dns lookup is performed, often cached on your local machine means this delay is minimal.

2 - the dns lookup can be happening for the second host while connections to the first host are still downloading, rather than stopping everything while the second host is looked up. This hides the latency of the second lookup.

3 - most browsers limit the number of connections to each server to 2. If you're loading loads of images, this means you can only be loading two at once (or one while the rest of the page is still downloading). If you put images on a different host, you can get extra connections to it. Also, cookies will usually stop an object from taking advantage of proxies/caches. Putting images on a different host is an easy to way make sure they're not cookied.

Re:Erm.. huh?

[orasio]

User perception of responsiveness on interfaces has a lower bound of 200 ms. Some times even lower.

Just because 1 seconds seems fast, it doesn't mean that it's fast enough to stop improving.
When you reach that 200ms barrier, the interface has perfect responsiveness, a bigger interval is always perfectible.

Re:Erm.. huh?

[freeweed]

1. HTTP pipelining has nothing to do with DNS. Your machine's IP stack takes care of this, and caches DNS entries regardless. You'll never make multiple DNS requests for the same host in a short period of time, unless you've seriously screwed something up on your client. HTTP pipelining keeps a TCP connection open for more than one object - so, you save yourself the time of a SYN/SYN-ACK/ACK handshake for every further object from the same host. With high-latency links, this can improve performance dramatically as you save a couple of trips back and forth for each object being requested.

2. Even without pipelining, you can make multiple HTTP requests to different hosts while the first is busy. Again, this has nothing to do with DNS.

3. is mostly correct, though.

Re:Erm.. huh?

[Gr8Apes]

Unless things have changed significantly, IE is the only browser that limits you by default to 2 threads per server. All netscape derived browsers defaulted to 8, unless that's changed lately, and I don't know about the thread limitations of the others, although I can't imagine they artificially lowered their potential performance like IE did. (I believe I read that this was done for various performance issues they had on multiple MS OSes when threads were increased.)

Re:Erm.. huh?

[macurmudgeon]

Connections may be fast for you and the people you know but the last surveys I've seen show that over 40% of the US is still on dialup. And broadband in the US is defined as 128K or faster not the 1.5 megabit connection used for calculations in the article. Upload speeds are correspondingly slow.

Maybe if you are living in a place where more people enjoy faster connections you can ignore load times. You certainly can't for commercial sites in America.

Re:Erm.. huh?

[jones_supa]

Unfortunately that is not true. Many "broadband" connections are definitely not insanely fast, and at least here in Finland the upload speeds of most connections are so pathetic that the problems mentioned in the article are very easily observed.

Pathetic? Most Finns have something like a 1024k/512k connection. It's not that slow.

Re:Erm.. huh?

[sowth]

Your machine's IP stack takes care of this, and caches DNS entries regardless.

I don't think GNU libc does this. At least on my linux system here, DNS lookups have the same delay whether they should have already been cached or not...

I have been thinking of finding a decent daemon for DNS caching, but I don't want something I'll have to fiddle with alot to get working or uses a huge amount of resources. (I don't want to use bind)

Re:Erm.. huh?

[x2A]

"You'll never make multiple DNS requests for the same host in a short period of time"

We're not talking about the same host... the parent poster said:

"I have pipelining on, which may be why multiple hosts is a net loss for me, instead of a gain"

and I explained that dns lookups for connections to the second host can be occuring in the background while data is being transferred over the connection to the first (ie, when an tag is found pointing to another host in an html page that's downloading, a new connection can be spawned to that server, before the html page has finished downloading).

"Even without pipelining, you can make multiple HTTP requests to different hosts while the first is busy. Again, this has nothing to do with DNS"

Again, I replied within the context of the parents post, which, for example, said:

"Approaches that add extra DNS lookups really aren't going to help"

So, to say that approaches that add extra DNS lookups have "nothing to do with DNS" is just silly. It's all about context, which your post seems to have missed altogether.

Re:Erm.. huh?

[sowth]

Speak for yourself. I am on dialup. There are way to many sites out there with 100kb+ pages. Often just for simple crap like a few links or less than 1k of text in the main body. They take minutes to load.

Gmail is one of the worst offenders (of well known sites). It takes several minutes before the message shows up in my browser. Even worse, the javascript crap disables the page loading animation after the initial load, so I can't just look at the tab to see if it is done. WTF???

Re:Erm.. huh?

[Anonymous Coward]

What do you mean?

If I click on a link and get a 1ms page render time, compared to getting a 200ms render time, I guarantee I'd know the difference. I'd be happy either way, but 200ms is very easily perceived. If I had to compare 10000ms versus 10200ms, I'd have to guess, but compared to instantaneous, 200ms is a huge amount of time. Unless you mean microseconds, instead of milliseconds?

Re:Erm.. huh?

[ncc74656]

I have been thinking of finding a decent daemon for DNS caching, but I don't want something I'll have to fiddle with alot to get working or uses a huge amount of resources. (I don't want to use bind)

dnscache (part of djbdns) works well and has a small footprint.

Re:Erm.. huh?

[alx5000]

ISP proxies suck. I almost cried in bliss when Telefonica (Spain) took theirs away.

Cached content means speed, but also makes it harder to get up to date pages. If I have to reload a forum (or a /.) 3 times in order to see the latest posts, to hell with those 30ms I gain.

And then there's the "One destination IP to rule 'em all" issue. Rapidshare was never usable with Telefonica's proxy. Same for Slashdot (You can't log in since some sux0r played with their 1337 new proggie behind your same proxy).

Re:Erm.. huh?

[freeweed]

I was responding to this:

1 - keepalive/pipelining connections means only 1 dns lookup is performed, often cached on your local machine means this delay is minimal.

Pipelining does not change behaviour to multiple hosts in the slightest. It's a keepalive of the connection to the same host.

I think I misinterpreted your second point a bit :)

Re:Erm.. huh?

[mabinogi]

1 - yes, one per host. So in theory it should be OK by the time I refresh.

2 - In theory, but it can't be done in parralel with the actual request to the host being looked up, so if the main page is waiting for some component on a separate host before it can continue rendering then the extra DNS query will in fact count towards the total time.
I'd say that 4 hosts are probably better than 2, because of the ability to do things in parralel, but 1 (with pipelining) would be better that either of those. Unfortunately he didn't do any tests of 4 hosts with pipelining.

3. Yes, but if you're already choking your outgoing then 8 connections instead of 2 won't help that situation. (Don't know if that's what happens in my case though).
The last sentence makes sense, though you could just put your images in a different path on the same server and restrict your cookies to the paths they actually apply do (Which is something he advocates anyway to reduce the size of requests)

Also I guess there's a difference between spreading your own content over a few hosts on your own network (which should all have similar response times to each other), and what I see with sites like slashdot, where the other servers are on entirely different networks. The latter shouldn't really make much difference, but it does mean that the response times of those external servers are completely unrelated to and out of the control of the site I'm trying to get to.

Re:Erm.. huh?

[Anonymous Coward]

Conspiracy theories abound. Savvy readers know that IE is following the recommendation of RFC2616.

See enhanceie.com/tweaks.asp if you want the regkey to up the limit.

Re:Erm.. huh?

[orasio]

Milliseconds.
Of course you can perceive 200 milliseconds.
The issue is that your brain can be tricked into thinking that it happened right away, because moving your attention from the button to the new page takes roughly as long as that.
Of course, if you concentrate, like in a game, you can perceive shorter times, but for regular desktop UI stuff, 200ms would be good enough not to notice.

HTTP Pipelining

[onion2k]

If the user were to enable pipelining in his browser (such as setting Firefox's network.http.pipelining in about:config), the number of hostnames we use wouldn't matter, and he'd make even more effective use of his available bandwidth. But we can't control that server-side.

For those that don't know what that means: http://www.mozilla.org/projects/netlib/http/pipeli ning-faq.html

I've had it switched on for ages. I sometimes wonder why it's off by default.

Re:HTTP Pipelining

[SanityInAnarchy]

I always wonder why it's off by default. IE I can understand -- they still don't support XHTML -- but Firefox?

Re:HTTP Pipelining

[baadger]

This is NOT just Opera fanboyism, but Opera however *does* do pipelining by default (with a safe fallback)

Opera pipelines by default - and uses heuristics to control the level of pipelining employed depending on the server Opera is connected to

Reference

Re:HTTP Pipelining

[Anonymous Coward]

Here's a comment linking to it.

Re:HTTP Pipelining

[Urza9814]

Oh wow. My load times suck because I'm running freenet, but that pipelining thing just cut them in half.

Re:HTTP Pipelining

[tweakt]

Hmm. I just tested this with Firefox 2.0 and it seems to cause problems immediately.
Not all sites will handle this correctly. It seemed like some of the piplined requests were being ignored -- I'd get a page and none of the images would load. Certain application servers are probably written under the assumption that 1 connection = 1 request. Also hardware load balancers, reverse proxy servers and application layer firewalls might not handle pipelining properly as well. It's surprising though, because it is part of the HTTP/1.1 spec.

Can anyone confirm this actually works most of the time? It could be something specific to me, mine is certainly not a definitive test.

HTTP/1.1 Design

[keithmo]

From TFA:

By default, IE allows only two outstanding connections per hostname when talking to HTTP/1.1 servers or eight-ish outstanding connections total. Firefox has similar limits.

And:

If your users regularly load a dozen or more uncached or uncachable objects per page load, consider evenly spreading those objects over four hostnames. Due to browser oddness, this usually means your users can have 4x as many outstanding connections to you.

From RFC 2616, section 8.1.4:

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.

It's not a browser quirk, it's specified behavior.

Re:HTTP/1.1 Design

[jakoz]

It might be specified behavior, but it's stupidly outdated, and seriously needs to get with the times.

It has been that way since I had dialup many years ago. It might have been prudent at the time, but now it is sadly outdated.

Things have changed. The popularity of FasterFox, which happily breaks all specifications, is a reflection of it.

I feel that 10-20 is a much more realistic figure now. I haven't seen many webmasters complaining about FasterFox.

Re:HTTP/1.1 Design

[ben there...]

I feel that 10-20 is a much more realistic figure now. I haven't seen many webmasters complaining about FasterFox.

I've seen webmasters complain right on FasterFox's download page on Mozilla Update.

Re:HTTP/1.1 Design

[jakoz]

Then perhaps they need to invest in some modern systems. The following definitions are interesting:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. They don't say DO NOT or MUST NOT. Like they say, the behavior can is useful... and they could see this would be the case IN 1997!

It is time we updated things. It's particularly funny that Microsoft found this RFC, of all things, to obey.

Re:HTTP/1.1 Design

[x2A]

The limit's not to do with your connection speed as such - it's to do with being polite and not putting too much drain on the server your downloading from.

Re:HTTP/1.1 Design

[jakoz]

I realize that, but the limits need to be revised. 2 might have been courteous a decade ago, but now it isn't realistic.

Re:HTTP/1.1 Design

[x2A]

Depends on server load; how many of the objects are static vs dynamic etc. 5-10 connections for images might be okay, but for dynamic objects it might not be. Perhaps it should be specifiable within the html page?

Re:HTTP/1.1 Design

[jakoz]

You know... that's a damn good idea and should be modded up. It's a very good solution that should be in the specs already. Granted that some browsers could ignore it, but they could anyway,

Re:HTTP/1.1 Design

[Sulka]

Uhh... I bet you haven't ever administrated a large website.

When you have a lot of concurrent users, the amount of TCP sockets you can have open on a given server while still maintaining good throughput is limited. If all users out there had 20 sockets open to each server, making sites scale would be seriously hard on very large sites.

I do agree the two socket limit is a bit low but 20 would be a total overkill.

Re:HTTP/1.1 Design

[hany]

At the end you have just one pipe to push that data even if you have say 100 connections.

By still having one pipe with certain capacity (i.e. bandwidth) but increasing amount of connections, you're wasting your bandwidth for maintenance of multiple connections.

Also you're wasting the resources of the server for the same reason.

At the end, you're slowing yourself down.

Yes, there are scenarios where using for example 4 connections as opposed to just 1 yields better download performance but AFAIK almost all such scenarios are very specific for given implementation of webserver, given implementation of network, given implementation of browser, ...

So to sum myself up: I think that the 1-2 active connections per client as mentioned in RFC 2616 was generaly valid in 1997, is generaly valid now and also will be generaly valid in the future.

Contrary, "the hack" of using multiple connections to speed-up downloads may have been, is and may be in the future sometimes valid but generaly degrades performance.

Pity is, Aaron Hopkins is mentioning true solution (HTTP pipelining) only as "(Optional)" and at total end of the article. But he correctly describe his previous propositions as "tricks". :)

Re:HTTP/1.1 Design

[Anonymous Coward]

please people mod parent up

Re:HTTP/1.1 Design

[statusbar]

The wonderful thing about the RFC language "SHOULD" and "SHOULD NOT" is that it really is only a suggestion that do not need to be followed. It makes it wonderful to test all possible combinations of "should" and "should not" options in the protocol with both clients and servers, probably the biggest source of bugs and problems.

rfc2119 defines the terms:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

--jeffk++

Re:HTTP/1.1 Design

[hehman]

It's not a browser quirk, it's specified behavior.

Indeed, and the 2-connection limit is a good idea. In crushing load situations (e.g. a slashdotting), a server wants each client to have as few connections as possible to reduce overhead per request. Allowing more connections per client will mean fewer clients can be served. Perhaps, ideally, a server should be able to tell a client how many simultaneous connections it can handle, so it can offer better performance when load is lower.

People should bear this in mind when deciding whether to take that advice about 4 domains pointing to the same server. You're trading performance for capacity.

Re:HTTP/1.1 Design

[Gr8Apes]

That would be for persistent connections. In general, HTTP requests are not persistent, so you can have as many as you want. Gecko browsers with 8 connections works just fine, thank you.

Re:HTTP/1.1 Design

[MikkoApo]

Slashdot effect * pipelining with 20 connections = 20 times faster slashdotting.

I think you're right about the 2 connections being a little 1990s, but over eight seems a little excessive. And hitting HTTP servers with 20 simultaneous connections is a bit nasty. Instead of serving nice clients with two connections each, the server might allocate ten times more resources to serve the greedy one. Also, "keep-alive" keeps the connections alive for a while (FF default: 300 (seconds?)) so the server might keep holding on to the resources much longer than that one page load.

Hitting an idle server won't probably have any effect, but slashdotting with 20 connections per client is much faster than with 2 per client.

Re:HTTP/1.1 Design

[ben there...]

Perhaps I should have been more clear, but I was about to head to work.

The problem that webmasters have with FasterFox has nothing to do with HTTP/1.1 or any RFC. It has to do with that FasterFox prefetches all of the links on a page. That's why there are webmasters figuring out how to block FasterFox requests.

As a webmaster, I happen to agree with them. I don't want people downloading pages that they're not even going to look at, wasting my bandwidth. The pipelining and max connections I don't have a problem with. But they're in about:config and you don't need FasterFox for that.

Re:HTTP/1.1 Design

[bigpat]

The limit's not to do with your connection speed as such - it's to do with being polite and not putting too much drain on the server your downloading from.

The design of the website is what would be causing greater server load, not a browser setting. The total amount of resources is the same if we are just talking about getting all of a pages images in parallel instead of serially. So, if you are just getting all the needed files more quickly then you are just getting out of the way more quickly for when the next guy tries to connect. Seems that this balance should be decided on the server side based on available resources and likely number of connections, not the client.

When I ran a small web server back in the nineties which was serving up large files over a slow connection hosted on slow computers, I remember the biggest benefit to increasing bandwidth was that quicker download times meant that people were no longer tying up processing power and memory because they could complete their downloads more quickly. Being able to handle more simultaneous connections is great, but if you can get the downloads done more quickly then you can free up processing power more quickly.

Re:HTTP/1.1 Design

[a.d.trick]

Putting it within HTML code would be ugly and problematic, but putting it in the HTTP response headers seems like a mighty fine idea. I honestly don't know why their not doing that. Lazyness?

Re:HTTP/1.1 Design

[dfghjk]

...and the performance article is suggesting ways to get around such politeness by tricking the browsers into thinking they are connecting to a larger number of servers. If that's not evidence of outdated advice then what do you want?

Re:HTTP/1.1 Design

[poot_rootbeer]

"A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy."

It's not a browser quirk, it's specified behavior.

It may be considered a quirk that browsers use hostname to determine whether two servers are the same, rather than IP address.

Re:HTTP/1.1 Design

[Trogre]

From RFC 2616, section 8.1.4:

        Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.

It's not a browser quirk, it's specified behavior.

Ah, got it: the RFC is broken and needs updating. Thanks.

Anyone else care to provide Comments for this Request 2616?

Re:HTTP/1.1 Design

[Extide]

No... you arent slowing yourself down you still need to make the same number of connections whether you do it 2 at a time or 10 at a time. You still send the exact same amount of bits across the pipe, you are just getting it all done with at once instead of doing each thing one at a time.

Re:HTTP/1.1 Design

[Gothmolly]

Specified but not mandatory. Thus the description of "browser oddness".

Re:HTTP/1.1 Design

[hany]

Well, your statement is correct for HTTP/1.0 and also would be correct for HTTP/1.1 if:

• establishing (and also destroying) of TCP connection required 0 (read zero) packets
• HTTP Keep-Alive and HTTP Pipelining did not deploy the concept of "connection reuse" to speed up download

Please take a look for example at HTTP/1.1 Connections and HTTP/1.1 Pipelining FAQ and also maybe some TCP/IP RFCs.

To sum the above: Keep-alive reuses one TCP connection to download multiple objects from the server thus saving you the time and resources to send extra packets needed to close current connection and establish new one.
Pipelining is helping you to reduce the latency by taking this concept a little bit further and issuing your next request before the response for previous request has been fully received.

Simulation software available?

[leuk_he]

"Regularly use your site from a realistic net connection. Convincing the web developers on my project to use a "slow proxy" that simulates bad DSL in New Zealand (768Kbit down, 128Kbit up, 250ms RTT, 1% packet loss) rather than the gig ethernet a few milliseconds from the servers in the U.S. was a huge win. We found and fixed a number of usability and functional problems very quickly."

What (free) simulation is available for this? I only know dummynet which requires a linux server and some advanced routing. But surely there is more. Is there?

Re:Simulation software available?

[OffTheLip]

NIST Net (http://www-x.antd.nist.gov/nistnet) can be used for latency and bandwith simulation. It is no longer supported though. Not sure what other free alternatives are out there.

Re:Simulation software available?

[Jussi K. Kojootti]

Try trickle. It won't do fancy stuff like simulating packet loss, but a
trickle -d 100 -u 20 -L 50 firefox
should limit download, upload and latency rates.

Re:Simulation software available?

[rHBa]

Try going back to 56k(or less)dial-up.

Re:Simulation software available?

[leuk_he]

Actually Dail up cost me money. While i have a always on adsl already available.

And it is impossible so simulate faster lines than my current adsl.

Re:Simulation software available?

[ggvaidya]

You could try using Sloppy. I've only ever heard about it because its programmer has a very nice page on getting a free Thwarte FreeMail certificate to work with Java WebStart, so this isn't a recommendation or anything. Looks pretty decent, though.

Re:Simulation software available?

[badfish99]

If you're running linux you can do all of this with iptables (even simulating random packet loss). The command syntax is a bit complicated but once you've got the hang of it, it is extremely powerful.

Re:Simulation software available?

[Slashdiddly]

From the home page:

Sloppy deliberately slows the transfer of data between client and server.

So basically a straight proxy then - only in Java!

Re:Simulation software available?

[Anonymous Coward]

you're looking for "honeyd". it's what you need

Re:Simulation software available?

[wralias]

Fiddler for Windows - http://www.fiddlertool.com/ - and Charles for Mac OSX - http://www.xk72.com/charles/ - are debugging proxies. Very easy to use, and both allow you to throttle bandwidth to something lower than what you are using. Charles has a native way to do it, but I think you either have to program or download a new "rule" for Fiddler in order to throttle. Anyway, both are extremely valuable for solving a multitude of problems, not just throttling bandwidth.

Re:Simulation software available?

[hacker]

Too bad it doesn't work on Firefox 1.5.x or 2.x on Linux with the latest Java plugin from Sun.

concurrent web server connections

[dysfunct]

Also, by spreading static content across four different hostnames, site operators can achieve dramatic improvements in perceived performance.

I've worked with heavily loaded servers that serve many pictures per page and can confirm that this does decrease perceived load time, but it does have its drawbacks. Pushing the concurrent browser requests to num_hostnames * browser_default on the same physical host, you'll have to increase the maximum concurrent requests of your web server, which can badly increase system load and lead to easy slashdotting situations. Only do this if you can modify those settings, know what your server is capable of and are not limited by bandwidth as this can also quickly fill your tubes. And as the article states: only do this with small objects or you might be under heavy load in no time.

Css and Scripts

[Gopal.V]

I've done some benchmarks and measurements in the past which will never be made public (I work for Yahoo!). And the most important bits in those have been CSS and Scripts. A lot of performance has been squeezed out of the HTTP layers (akamai, Expires headers), but not enough attention has been paid to the render section of the experience. You could possibly reproduce the benchmarks with a php script which does a sleep() for a few seconds to introduce delays at various points and with a weekend to waste.

The page does not start rendering till the last CSS stream is completed, which means if your css has @import url() entries, the delay before render increases (until that file is pulled & parsed too). It really pays to have the quickest load for the css data over anything else - because without it, all you'll get it a blank page for a while.

Scripts marked defer do not always defer and a lot of inline code in <script> tags depend on such scripts that a lot of browsers just pull the scripts as and when they find it. There seems to be just two threads downloading data in parallel (from one hostname), which means a couple of large (but rarely used) scripts in the code will block the rest of the css/image fetches. See flickr's organizr for an example of that in action.

You should understand that these resources have different priorities in the render land and you should really only venture here after you've optimized the other bits (server and application).

All said and done, good tutorial by Aaron Hopkins - a lot of us have had to rediscover all that (& more) by ourselves.

Re:Css and Scripts

[Evets]

I've found that once a page has layout it will begin rendering and not before. CSS imported in the body do not prevent rendering. CSS imported in the HEAD will. In fact, the css and javascript in the head section seem to need downloading prior to rendering.

I have also found that cached CSS and Javascript can play with you a little bit. When developing a site you tend to see an expected set of behaviors based on your own experience with a site - but you can find later that having the external files either cached or not cached can have an effect on things. (i.e. a cached javascript file with a load event may be triggered before the DOM is ready if you aren't checking for the readiness of the DOM itself)

ETAG headers are very important as well. Running "tail -f access.log" while you browse your own site will show a lot of redundant calls to javascript, css, and image files that should be cached but aren't. IE has a setting of "Check for new content" or something like that that really fouls up css background images without proper expiration headers (lots of flickering).

There is still a significant portion of the web community that utilizes dialup connections. These users are seemingly ignored by many popular sites. I try to get pages to load in under 8 seconds for dialup users, but with any significant javascript or CSS it is sometimes a difficult task. It's much easier on consecutive page loads by forcing cacheing, but that doesn't matter one bit if the user goes elsewhere because the initial page load was too slow.

There are certainly a plethora of optimization techniques not even touched on in this article. I know that Google and Yahoo are very keen on these subjects and it's worth taking a look at the source of some of their pages for ideas. Last I checked, they could care less about validation, though. But with the bandwidth they must utilize saving a few bytes here and there can mean significant dollar differences at the end of the month and what truly matters is whether or not the browser renders the page correctly.

Re:Css and Scripts

[RAMMS EIN]

``The page does not start rendering till the last CSS stream is completed''

On the other hand, stylesheets are often static and used by many pages, so they could be cached (Opera does this). The same is true of scripts.

Re:Css and Scripts

[Anonymous Coward]

The remarkable thing here is that Google is one of the major causes of slow loading web pages due to the way their adsense system works. The webmaster is not allowed to modify the code which loads the script that creates the ads. Thus the script always loads inline, and since ads are usually placed at the top of a page, delays in delivering the adsense script, which have become more frequent and severe lately, cause the rest of the page to stall.

Possibly a little contradictory

[Anonymous Coward]

Glad to see somebody has taken the time to write about these things, even if they are mostly self-evident. One thing that I'm not sure about...

"Load fewer external objects. Figure out how to globally inline the same one or two javascript files"

You see this in forum html where they have inlined hundreds of lines of js and CSS, this increases response size per request. The page will display faster first time but the correct thing to do is set expires headers and have the browser cache external CSS and javascript files. It's a tradeoff, larger CSS segments and javascript that are used site-wide should always be external, 200 bytes in a head element thats sent over the wire using gzip (because deflate confuses some browser vendors) is probably not worth bothering with.

Spreading content across hostnames...

[bigmouth_strikes]

Just what we need in the time of phising attacks being a constant worry: having to figure out whether not just one, but four different hostnames belong to the site operator in question.

Re:Spreading content across hostnames...

[Anonymous Coward]

hostnames != domainname

Why would a sub-domain confuse anyone?

rss.slashdot.org
apple.slashdot.org
ask.slashdot.org
backslash.slashdot.org

Caching of dynamic content

[baadger]

This is a good place to start testing the 'cacheability' of your dynamic web pages. Quite frankly it's appauling that even the big common web apps used today like most forum or blog scripts don't generate sensible Last-Modified, Vary, Expires, Cache-Control headers. With most of the metadata you need to generate this stuff stored in the existing database scheme theres just really no excuse for it.

Abolishment of nasty long query strings into nicer, more memorable URI's is also something we should be seeing more of in "Web 2.0." Use mod_rewrite, you'll feel better for it.

Re:Caching of dynamic content

[RAMMS EIN]

``Quite frankly it's appauling that even the big common web apps used today like most forum or blog scripts don't generate sensible Last-Modified, Vary, Expires, Cache-Control headers.''

The problem is that things don't usually break if you don't use these headers effectively. In other words, you don't notice that something could be improved.

Re:Caching of dynamic content

[hacker]

Woops!

Not Found
The requested URL /cgi-web-caching/cacheability.py was not found on this server.

Apache/1.3.31 Server at www.web-caching.com Port 80

Re:Caching of dynamic content

[Anonymous Coward]

Why must you mall the English language so?

Re:Caching of dynamic content

[PitaBred]

With his misspelling of "appalling" and your misspelling of "maul", I'm ready to call you both "loosers" with my tongue firmly in my cheek.

Re:Caching of dynamic content

[StoneIsle]

The Cacheability Engine which runs this is open source (Freely Distributable, according to freshmeat), and can be found at http://www.mnot.net/cacheability/. There is another online demo available at http://www.ircache.net/cgi-bin/cacheability.py

Re:Caching of dynamic content

[ae]

Speaking of mod_rewrite, do you know how it scales? Can it be used on a website with millions of users without significantly increasing load? Surely, the answer to this question will depend at least in part on the complexity of your rewrite rules, but do you know if there are some public load tests or guidelines? Thanks!

Re:Caching of dynamic content

[baadger]

I'm not entirely sure, I suspect it all depends on the quality of your regular expressions and whether you stick them in local .htaccess files (bad) or in the main web server configuration file (better).

I know from other libraries and apps that use regular expressions that they can be 'compiled' of sorts for faster re-evaluation.

To be honest I haven't had any experience with mod_rewrite from the web server admin's perspective.

Re:Caching of dynamic content

[ae]

Ok, thanks! I'll probably just have to test it. :)

Those tenths of seconds add up

[giafly]

If a big part of your job involves using a Web-based application, reducing page-load times really helps. My real job is writing one of these applications and getting the caching right is much more important than sexier topics like AJAX. There's some good advice in TFA.

Pipelining

[RAMMS EIN]

FTFA:

``Neither IE nor Firefox ship with HTTP pipelining enabled by default.''

Huh? So all these web servers implement keep-alive connections and browsers don't use it?

Re:Pipelining

[smurfsurf]

Pipelining is not the same as keep-alive. Although pipelining needs a keep-alive connection.
Pipeling means "multiple requests can be sent before any responses are received. "

Re:Pipelining

[TheThiefMaster]

Pipelining is not keep-alive. Keep alive means sending multiple requests down one connection, waiting for the response to the request before sending the next. Pipelining sends all the requests at once without waiting.

Keep-alive no:
Open connection
-Request
-Response
Close Connection
Open connection
-Request
-Response
Close Connection
-Repeat-

Keep-alive yes:
Open connection
-Request
-Response
-Request
-Response
-Repeat-
Close Connection

Pipe-lining yes:
Open connection
-Request
-Request
-Repeat-
-Response
-Response
-Repeat-
Close Connection

Re:Pipelining

[x2A]

Keep-alive sends the next request after the first has completed, but on the same connection (this requires the server to send Content-length: header, so it knows after how many bytes the page has finished loading. Without this, the server must close the connection so the browser knows it's done).

Pipelining sends requests out without having to wait for the previous to complete (this does also require a Content-length: header. This is fine for static files, such as images, but many scripts where output is sent straight to the browser as it's being generated will break this, as it won't know the content length until generated has completed).

Re:Pipelining

[guy-in-corner]

...it won't know the content length until generated has completed.

Which is what Chunked Transfer Coding is for. See Section 3.6 of RFC 2616.

Re:Pipelining

[Nevyn]

Pipelining sends requests out without having to wait for the previous to complete (this does also require a Content-length: header

Not true, chunked encoding is fine. You just can't use connection close as end of entity marker ... but that's bad anyway.

DNS

[Anonymous Coward]

Also, by spreading static content across four different hostnames, site operators can achieve dramatic improvements in perceived performance.

Isn't it common knowledge that DNS is a significant bottleneck?

Re:DNS

[Anonymous Coward]

How so? There are trade offs between fast site response and initial load time, usually the expense of a few DNS lookups is easily outweighed by having servers dedicated to serving static content. Unless you routinely set insanely low TTLs?

Re:DNS

[Anonymous Coward]

The reason for delivering static content from different domains is that HTTP defines a maximum of 4 concurrent connections per server (=domain). On a page with many small files, you have to wait the roundtrip time per file and the browser can't do anything else in the meantime since it isn't allowed to open more connections. HTTP pipelining would fix that, but it is not enabled by default because there are still some servers out there which get confused by it. Another way to improve load time is to ignore the HTTP spec and increase the number of concurrent connections, but just like pipelining, this is beyond the control of the server admin. Consequently: distribute static objects over subdomains to circumvent the connection limit. DNS lookups of subdomains are faster than complete lookups because the resolver only needs to ask the same server again, not the whole chain of servers.

@Slashdot: decrease the stupid delay for anonymous posting. This is a worthwhile comment and I'm not going to wait half an hour to post it.

Re:DNS

[Anonymous Coward]

@Slashdot: decrease the stupid delay for anonymous posting. This is a worthwhile comment and I'm not going to wait half an hour to post it.

Slashdot: encouraging the anonymous to stay anonymous.

Connection Limits

[RAMMS EIN]

``By default, IE allows only two outstanding connections per hostname when talking to HTTP/1.1 servers or eight-ish outstanding connections total. Firefox has similar limits.''

Anybody know why? This seems pretty dumb to me. Request a page with several linked objects (images, stylesheets, scripts, ...) in it (i.e., most web pages), and lots of these objects are going to be requested sequentially, costing you lots of round trip times.

Re:Connection Limits

[Anonymous Coward]

On a loaded server where each client has n+ connections, you can run up against concurrency limits quickly. Some servers handle concurrency better than others.

Re:Connection Limits

[MathFox]

The "max two connections per webserver" limit is to keep resource usage in the webserver down; a single apache thread can use 16 or 32 Mbyte of RAM for dynamicly generated webpages. If you get 5 page requests a second and it takes (on average) 10 seconds to handle the request and send back the results you need 1 Gb RAM in the webserver, if you can ignore Slashdot. (2-4 Gb to handle peaks)

If you have a second webserver for all static data, that can be a simpeler http deamon with 1 Mb/connection or less. You can handle more parallel connactions (and Akamai the setup if needed!)

Yes, it's best to avoid inline images, Google text ad objects, etc. But allowing parallel loading of the objects (and that's the trick with using several separate hosts for images) you can take 8 or 16 roundtrips at the same time; here is your perceived speedup.

Re:Connection Limits

[RAMMS EIN]

``The "max two connections per webserver" limit is to keep resource usage in the webserver down''

I understand that, but why write it into the standard? Couldn't servers be made to handle this? If you don't have the resources right now, just hold off on retrieving/handling the request for a while. If you can handle the load, you will be able to service clients quicker. Now, even if the server can handle the load, the clients will slow themselves down.

``If you get 5 page requests a second and it takes (on average) 10 seconds to handle the request and send back the results''

10 seconds to process a request is a very long time. If it takes that long, a few extra round trip times don't matter much.

Re:Connection Limits

[MathFox]

If you don't have the resources right now, just hold off on retrieving/handling the request for a while.

And make your self extra vulnarable to DoS attacks... I know that it is hard to find the right balance of priorities when your site is slashdotted, been there :-(.

10 seconds to process a request is a very long time. If it takes that long, a few extra round trip times don't matter much.

Generating the megabyte of html is easily done within a second, there are few users that have a fast enough connection to receive it within a second. Luckily most browsers start rendering before they received the whole page and all graphics, which means that the users see sub-second response. But you still have those server side resources that you use... And a swapping webserver is no fun!

Re:Connection Limits

[Malc]

It's per the HTTP spec.

Re:Connection Limits

[Raphael]

This is not only for keeping the resource usage in the server down, but also for improving the overall performance of the whole network by avoiding congestions and packet losses. Note that the "whole network" includes not only the last mile (cable or DSL link between your home or office and your ISP), but also all routers at your ISP, in the backbone, etc.

Here is the general idea: if all clients use only one or two TCP connections and they use HTTP pipelining, then the traffic will be less bursty on these connections and TCP will be able to find the optimal transfer rate easily. As a result, the risk of congestion in the routers will be decreased and the overall performance of the network will be improved. The assumption of the HTTP/1.1 working group was that most of the traffic on the Internet would be TCP-friendly (using similar congestion avoidance algorithms). Although this is not really true for many peer-to-peer applications, many ISPs use traffic shaping and lower the priority of agressive P2P protocols compared to more "network-friendly" TCP-based applications.

Re:Connection Limits

[archen]

All this actually looks very similar to debates over Lighttpd benchmarks. There was a Lighttpd benchmark showing much better performance than Apache, but then another apache benchmark that showed they could saturate a T1 connection just as fast. However, that's not really the problem, it's more a function of bandwidth. Consider an internet connection over a 33.6k modem - that's a max of 3.8kb per second. If I download 10 elements with a mix of css/images/html I have to fit it over that pipe. It doesn't matter how many connections I open, it just isn't going to download faster. And actually you're just stressing the server since the server isn't sending information faster either, it's just holding more connections open and juggling more resources. And what the server does when it runs low is hard to say because it's dependent upon the server, OS, and possibly dynamic content.

Could servers be made to handle it? Sure. You take your average page from 1998 and stick it on any modern machine and you'd be fine. However now we have tons of flash, and HUGE images on pages. Honestly I think that the spec will make allowances for more connections most people are off of dialup and we can say you'll be able to actually utilize the extra connections, and not just tie up servers for no reason.

Re:Connection Limits

[RAMMS EIN]

``

If you don't have the resources right now, just hold off on retrieving/handling the request for a while.

And make your self extra vulnarable to DoS attacks...''

No, actually. At least, having no 2-connection-per-hostname limit in the standard doesn't make you any more vulnerable than having such a limit, because there's no way to force clients to respect that limitation. If one is going to perform a DoS attack, why respect the standard?

Of course, I see the point that when you get _many_ clients connecting, your resources run out quicker if each of them makes 12 connections than if each of them makes only 2, but then, I think the real cost is (or, at least, should be) in the actual processing of requests - so that should slashdot you much quicker than having many connections would.

Re:Connection Limits

[Extide]

I think he meant that queueing up incoming request forever while the host is busy would make you more vulnerable to DoS attacks. Not the 2 connection limit.

Not the same thing

[Anonymous Coward]

Pipelining depends on keep-alive to concatenate multiple HTTP responses into a single TCP packet.

Requests Too Large

[RAMMS EIN]

FTFA:

``Most DSL or cable Internet connections have asymmetric bandwidth, at rates like 1.5Mbit down/128Kbit up, 6Mbit down/512Kbit up, etc. Ratios of download to upload bandwidth are commonly in the 5:1 to 20:1 range. This means that for your users, a request takes the same amount of time to send as it takes to receive an object of 5 to 20 times the request size. Requests are commonly around 500 bytes, so this should significantly impact objects that are smaller than maybe 2.5k to 10k. This means that serving small objects might mean the page load is bottlenecked on the users' upload bandwidth, as strange as that may sound.''

I've said for years that HTTP requests are larger than they should be. It's good to hear it confirmed by someone who's taken seriously. This is even more of an issue when doing things like AJAX, where you send HTTP requests and receive HTTP responses + XML verbosity for what should be small and quick user interface actions.

Re:Requests Too Large

[Anonymous Coward]

Browser vendors are aware of the problem, they don't add HTTP headers without a good reason. Common sense may be in low supply, seems there's just enough to stop web devs from setting 20 4KB cookies. The issue with AJAX (which rarely uses XML BTW) is that it's a dirty hack on top of HTTP. When all you have is a hammer...

Re:Requests Too Large

[Pollardito]

if you think AJAX requests are bad on asynchronous bandwidth, take a look at the viewstate explosion going on in the MS VisualStudio.NET world.

ooh sub domain spam

[hauntingthunder]

Isn't using 4 subdomains going to confuse the google algoritem (abuse of subdomians has beeen adressed in a few updates) let alone duplicate content - or is it just for iamges and objects.

Latency

[RAMMS EIN]

Latency matters a lot. My connection does up to 512 KB/s downstream, meaning a 10 KB object would take about 0.02 seconds to receive. However, before I start receiving the bytes, my request has to travel to the server, and the response has to travel back to me. When the site is in the US (I'm in Europe) the round trip time to the server can easily be 100 to 200 ms. If the TCP connection is already open, this time gets added once. However, if the connection still has to be established, this will result in another round trip time being added. So, because of the latency, that 0.02 seconds becomes 0.03 through 0.06 seconds, instead.

If you read the article, you will see that the default behavior for Firefox and MSIE is to use only up to two connections per hostname (resulting in many objects being received sequentially - add one round trip time for each), and that they don't use HTTP pipelining, meaning a new connection is set up for each object (add one round trip time for each).

In other words: it's the latency, stupid.

Re:Latency

[Anonymous Coward]

That may be true, however the limit is in the HTTP/1.1 spec for a reason. Think about what happens when you connect to a typical forking httpd. Let's suppose a server is being slashdotted and instead of 2 connections, each client makes 8 concurrent connections. How long is that server going to last?

Re:Latency

[RAMMS EIN]

``If you read the article, you will see that the default behavior for Firefox and MSIE is to use only up to two connections per hostname (resulting in many objects being received sequentially - add one round trip time for each), and that they don't use HTTP pipelining, meaning a new connection is set up for each object (add one round trip time for each).''

Whoops. I somehow got confused into thinking that pipelining == keep-alive (despite clicking on the provided link). HTTP pipelining means that multiple requests can be sent over the same (keep-alive) connection without waiting for a response first. This eliminates both sources of latency: no round trip time between requests on the same connection, and no need to establish new connections for new requests.

Re:Latency

[RAMMS EIN]

``That may be true, however the limit is in the HTTP/1.1 spec for a reason.''

Yeah, namely that there are so many sucky web servers and operating systems out there. So what we do? We protect these poor little things by writing their limitations into the standard. I mean, a web server worth its salt is able to cope with many concurrent connections, be they from one client or from many clients.

Re:Latency

[Anonymous Coward]

You're forgetting that the problems we face today aren't with static content. So for performance you would want to disable keep-alive on Apache for the dynamic content and handle static content using lighttpd, mathopd etc...

You need multiple dedicated web servers for this and most businesses can't justify the expense. Don't forget that a single shared host can handle a couple of hundred low traffic dynamic sites. Do the math.

Re:Latency

[fruey]

_every_ packet you receive has to be ACKed, and so latency can affect your download speed no matter how long your connection stays open.

Re:Latency

[RAMMS EIN]

``_every_ packet you receive has to be ACKed, and so latency can affect your download speed no matter how long your connection stays open.''

Larger sliding windows for TCP can significantly reduce that problem.

Re:Latency

[fruey]

OK, but the article is mostly about what you can do as a content provider, rather than tweaks based on changing clients...

Re:Latency

[Anonymous Coward]

milli- |mli| combining form (used commonly in units of measurement) a thousand, chiefly denoting a factor of one thousandth : milligram | millipede. ORIGIN from Latin mille 'thousand.'

When the round trip is 100-200ms, how can the total transfer time be ~0.06 Seconds or 60ms for any sized file?

Also 512KB/s.. do you mean KiloByte or KiloBit, .. because communications usually uses KiloBit/S and in terms of data files are usually refered to in bytes, so 10 KiloByte.. therefore, assuming you're using some standard 512Kbit/s ADSL, that 10KiloByte file would take (using theoretical maximums of 64KiloByte/s [8 bits to a byte]) 0.15625 Seconds..

Assuming no other delays, (no connection establishment or anything) that leads us to

100ms (min round trip) + 156.25ms == 162.25ms

Isn't it all about the numbers?

Gmail

[protomala]

I hope they apply this study on Gmail. Using it on a non-broadband connection (plain 56k modem) is a pain unless you use the pure HTML view that is crap compared to other HTML webmails.
The fun is that newer AJAX products from google (like goffice) don't suffer from this behavior, they have a much more cleaner code (just pick view code on your favorite browser and see). Probally Gmail HTML/Javascript is already showing it's age, and paying the price for being a first at google AJAX apps.

Re:Gmail

[Peeteriz]

Yes, I have the problem also, it's very painful - my upload speed at home is severely limited, and GMail gets timeout messages occasionally - and if something like Bittorrent is running, then it's impossible to send anything with attachments - for example, a small 50 kb document is impossible to send.

Re:Gmail

[badfish99]

YMMV, but I find that throttling Bittorrent to 90% of its maximum upload speed makes the difference between "internet connection almost unusable" and "internet connection working almost normally".

Re:It's talking about 'percieved performance'

[mdarksbane]

Since every fricking developer seems to think that the web is the end all be all future solution for everything, then yes, it does matter.

When I click on an element in a web page to manage my email or use a word processor, the response time is going to be around my ping (30-90 ms depending on where in the country it is) plus the time to load. That is long enough that I am clicking, and waiting. If I were working on a local native app, the response time would be under 30 ms and I would probably not even notice it.

For a quick email check or reading webpages, it doesn't really matter too much. But if you're trying to use that for constant daily productivity sorts of things (or even have a lot of email to go through) it is wasting a ton of your time. There are some real advantages to moving applications online and into a web browser (I've even heard people suggesting we should move to a web-browser for the full interface of our windowing system) but speed is currently NOT one of them. Since it seems like it's going to be more or less forced on me, anything that can make it faster and more tolerable is quite appreciated.

Some reasons

[harmonica]

I've had it switched on for ages. I sometimes wonder why it's off by default.

Some reasons against pipelining.

Re:Some reasons

[Chris Pimlott]

Er, not a very informative page; the only caveat listed is a vague notion that it's "unsupported" and "can prevent Web pages from displaying correctly" because it's "incompatible with some Web servers and proxy servers". There may well be good reasons, but that page doesn't really explain why.

Re:Some reasons

[Meccanica]

Towards the lower half of the page, someone says "Also, to anyone trying to start a browser pissing contest, remember, this isn't slashdot."

Re:Some reasons

[budgenator]

First a couple points, Asa Dotzler comments were dated December 26, 2004, that's a few relese cycles ago, but the comments he made were actualyy about the following:

Here's something for broadband people that will really speed Firefox up:

1.Type "about:config" into the address bar and hit return. Scroll down and look for the following entries:
    network.http.pipelining network.http.proxy.pipelining network.http.pipelining.maxrequests
Normally the browser will make one request to a web page at a time. When you enable pipelining it will make several at once, which really speeds up page loading.

2. Alter the entries as follows:
Set "network.http.pipelining" to "true"
Set "network.http.proxy.pipelining" to "true"
Set "network.http.pipelining.maxrequests" to some number like 30. This means it will make 30 requests at once.

3. Lastly right-click anywhere and select New-> Integer. Name it "nglayout.initialpaint.delay" and set its value to "0". This value is the amount of time the browser waits before it acts on information it recieves.

If you're using a broadband connection you'll load pages MUCH faster now!

Now you'll notice that step 2 is one of the things that the article actually discused, step 3, setting nglayout.initialpaint.delay wasn't discussed, however I've preformed both this morning and am quite impressed, but I might increase nglayout.initialpaint.delay to a higher value zero seems to quick and the rendering does glitch due to re-paints. One thing I did notice is the browser responds before the page is loaded, so if your serving ads off a dog-ass slow server, I'm all ready scrolled past your banners so you better upgrade.

Is this really news?

[iritant]

There is a paper about this in SIGCOMM 1997 (!) by Nielsen, Gettys, et al that goes into far more detail of the "whys" and "wherefores". I'm not sure this shows ANYTHING new. In fact, what this gentleman demonstrates is the way that TCP windows work. By spreading requests over four hosts you are in effect getting four times the window size, arguably more than your fair share. Without looking at the aggregate impact, one cannot really judge what's going on.

Also, the reason pipelining is turned off by default in many browsers is that there are a lot of middleboxes that can't handle it.

Re:Is this really news?

[Gothmolly]

"arguably more than your fair share"

So what, we're going to socialize the Internet now?

Page load time is still important

[Dekortage]

There are a lot of posts here asking "why is this important" and saying that pages already load fast enough on their broadband Internet connection. That may be true for you, but I'm frequently in a position where I am designing a site that needs to load over a slow satellite connection in rural Africa, say, or into a remote village in Nepal. They have a fairly recent computer, OS and browser on the recieving end, but their Internet connection is dog slow; anything I can do to speed it up will be greatly appreciated. It's back to 1980s dial-up speeds.

This isn't everyone's problem, I admit, but it's an issue for a lot of people in the world.

Re:Page load time is still important

[Gothmolly]

This won't help your pet poor people. This paper assumes relatively high bandwidth, and examines latency introduced by things like pipelining and script execution. If you have a slow pipe, whether you open 2 TCP sessions to 1 server, or 10 to 5 servers, you're limited by your slow pipe. You need localized caching and prefetching logic to keep your pipe full all the time, so that when people need the data, its likely already there.

Re:Page load time is still important

[Dekortage]

Respectfully, there are quite a few things worth noting in the article that are still useful in low-bandwidth situations, such as:

• Load fewer external objects.
• Allow static images, stylesheets, and javascript to be cached by the browser... Set an Expires header on everything you can, with a date days or even months into the future.
• If you have a lot of uncached or uncachable objects per page and big, domain-wide cookies, consider using a separate domain to host static content, and be sure to never set any cookies in it.

...and others.

"Also, by spreading static content..."

[mumblestheclown]

"Also, by spreading static content across four different hostnames, site operators can achieve dramatic improvements in perceived performance."

How ironic that a google engineer would say this, since doing this will also pretty well kill your google pagerank rankings. Google is great, yes, but among is many, many problems are the ridiculous ways that it forces people to do web design if they want a decent pagerank. another is how it "helpfully" directs you to "geographically relevant" searches - meaning that, for example, if you want a hotel room in egypt and browse from the UK, you get all the links from (much more expensive) UK based hotel and travel shops rather than, say, ones in egypt or elsewhere that, while also in english, are much cheaper.

sloppy.

[leuk_he]

Read the faq. It is a vey simple webserver in java. Not a proxy.

"Sloppy doesn't work as a real HTTP proxy so don't configure your browser to use it."

4 hostnames and security

[suv4x4]

Nice trick with 4 hostnames, but this means 4 security contexts for your content, which may make a lot of development hard (especially client based with JavaScript).
Not to mention the management issues of having to link to content on 4 different domains in an efficient enough manner.

This leaves us with pipelining on the client, which could results in much worse load peaks on the servers though.

In the end: let the page load a little slower, the workarounds are not worth it.

Re:4 hostnames and security

[mrsbrisby]

Nice trick with 4 hostnames, but this means 4 security contexts for your content, which may make a lot of development hard (especially client based with JavaScript).

Why? Doesn't your javascript explicitly state document.domain to the common root?

Not to mention the management issues of having to link to content on 4 different domains in an efficient enough manner.

You mean creating four hostnames for the same address? Or do you mean changing a few src="" attributes?

This leaves us with pipelining on the client, which could results in much worse load peaks on the servers though.

Wrong. It leaves us with nothing. Didn't you read the article? HTTP Pipelining isn't enabled in the big two web browsers, so as far as "reality" is concerned it doesn't exist. It's like IPV6- who cares how much "better" it is if no one is using it?

Re:4 hostnames and security

[suv4x4]

        Nice trick with 4 hostnames, but this means 4 security contexts for your content, which may make a lot of development hard (especially client based with JavaScript).

Why? Doesn't your javascript explicitly state document.domain to the common root?

        Not to mention the management issues of having to link to content on 4 different domains in an efficient enough manner.

You mean creating four hostnames for the same address? Or do you mean changing a few src="" attributes?

        This leaves us with pipelining on the client, which could results in much worse load peaks on the servers though.

Wrong. It leaves us with nothing. Didn't you read the article? HTTP Pipelining isn't enabled in the big two web browsers, so as far as "reality" is concerned it doesn't exist. It's like IPV6- who cares how much "better" it is if no one is using it?

From your tone I assume it was very important part of your day arguing with someone on Slashdot for the hell of it. If I were you, I'd take measures QUICK.

Re:4 hostnames and security

[mrsbrisby]

From your tone I assume it was very important part of your day arguing with someone on Slashdot for the hell of it. If I were you, I'd take measures QUICK.

Do you make it a point to often reply on subjects you know nothing about with ``points'' that are easily verified as false?

Re:4 hostnames and security

[Anonymous Coward]

Typical programmer response - blame the network or the hardware when it is your code that is the problem.
Don't use javascript until it is an intranet app. Personally, I browse with javascript disabled. Much of the interacdtivity that lazy programmer think they can only get with javascript are available in CSS.
Here's a link: http://www.grc.com/menu2/invitro.htm with more info.

Don't get me wrong, sometimes it is the hardware or network, but that's about 5% of the time. That leaves 95% that is the fault of the programmer.

Public Proxies

[Anonymous Coward]

Use public proxies -- they are usually very slow.

render time

[Spliffster]

this is an interesting summary about network affected display time. i would like to add that nowadays, with more complex pages, the rendering time has also to be taken into account. for example; with the use of bloated/redundant/unneeded css declarations, java and flash applets the pageload (until it is actualy display to the user) can be slowed down pretty badly. if you don't belive me, go an check out myspace.com :P

Cheers,
-S

Optimization of slashdot?

[karolgajewski]

Ok, now how will this help the loading of Slashdot? In that Slashdot has this terrible habit of occasionally slowing the browser to a halt when opening discussions with a lot of posts to parse (I'm using the new discussion system).

The problem, as I see it, is that issues like page load times are partly caused by browser issues (HTTP pipelining, cache, etc) and partly caused by server issues. (yes, yes, I know it's obvious) However, consider the idea of specialized configurations. Essentially a per-site set of conditions. For Slashdot.org, allow multiple HTTP connections (have to load that style file) and just load the images from the old cache (after all, the Microsoft Borg icon hasn't changed, has it?)

To a certain extent, this could be handled almost in a cookie-like fashion, except it's read before the initial HTTP request is made. You'd know that you're only requesting parts of the page, and could do a background query for elements which have been updated (i.e. a new category image, etc).

Then again, I also hate it when the loading of a PDF causes a loss of focus and slowing of the browser. Not the same, but in the same category of annoyance.

How nice of you...

[shaneh0]

It's obvious how much you identify as part of the slashdot community. I mean, only dedicated slashdotters would go to the trouble to adblock the few banner adverts on this page just so they can get to the comments faster. That's a clear sign that you care more about the good of the community than yourself. I just wanted to say: Thank you for making such a commitment to this website. If everyone took the extraordinary steps to block completely unobtrusive advertising than this website would be a much better place.

We all know that slashdot doesn't NEED advertising revenue. It's a little-known fact that Slashdot servers don't need bandwidth or electricity: You just pour a four-pack of redbull directly into the gigabit ethernet port and it serves requests like a daemon for 2-3 days without needing to sleep().

Re:How nice of you...

[LordSnooty]

Ok, I promise to unblock the ads, but I'll be damned if I'm going to actually READ them. net effect = same?

Re:How nice of you...

[budgenator]

I agree with you in principal, but google-analytics, runner.splunk and double-click really do need to beef up their response times. I've made the changes suggested in the article to my copy of firefox 2.0 and it's made a real seat of the pants difference to the felt load times, yet the total load times seems about the same. The main effect now is because the browser is more responsive and doesn't block, I've scrolled down below the slow loading ads before they've even started to load.

Re:How nice of you...

[Skreems]

I suppose now may not be the time to mention that I fast-forward through television commercials too...

Re:How nice of you...

[Millenniumman]

Do advertisements "know" when they are adblocked? Otherwise, it's the same as not looking at them, which is what most people do anyway. If so, perhaps adblock could do something about that?

Re:How nice of you...

[Man Eating Duck]

Do advertisements "know" when they are adblocked?

I didn't think so. I mean, the main host doesn't know when a request is made from your browser to the ad-server, and the ad-server obviously doesn't know that a connection was NOT made to it just now.
Nonetheless, this site seems to know that their google ads have been blocked.
With Adblock Plus active, in place of the ads, they put an image with "Thank you! For blocking our ads!".
I haven't researched whether Adblock or Firefox somehow divulges information that make them able to tell the blockers and the rest apart, or if there is any serverside trickery they're doing. Anyone knows this?

Anyway, as the site is awesome I unblocked them :)
On there and on natetrue.com you can check out lots of hacking in the broadest sense of the word, BTW. Well worth a visit.

Re:How nice of you...

[Man Eating Duck]

Yay for replying to myself...

I did what I should have done in the first place, glanced at the source, and found this little script:

function bees() {
  var e = document.getElementsByName("google_ads_frame");
    if (!e || e.length == 0) {
    var e1 = document.getElementById('topbanner');
    var e2 = document.getElementById('sidebanner');
    e1.innerHTML = "<img src='/images/blockedtop.png'>";
    e2.innerHTML = "<img src='/images/blockedside.png'>";
  }
}
setTimeout(bees, 500);

So, they do it clientside. If they want to check who's blocking ads, I guess they can just check their server logs for requests for those images.
I guess that should work for any kind of ad.

Re:How nice of you...

[mabinogi]

I come here because I sometimes find interesting stories. I don't come here out of any sense of obligation to "The Slashdot Community". And that's been how it has been since 1998.
If they want to show ads, that's fine, I don't have a problem with ads in themselves - the slashdot ones aren't _too_ intrusive most of the time. But no one can expect people to like a feature that degrades the performance of a web site. It doesn't take too long of looking at a blank window with the status bar saying "contacting ad.doubleclick.net" before you start to think that it'd be so much nicer if your web browser never tried to contact ad.doubleclick.net in the first place.

So my point is that the ads aren't inobtrusive, they are extremely detrimental to the perceived performance of the site. If they were hosted locally on slashdot servers, or some effort was made to place them such that rendering didn't block while they were loaded, then they'd be fine.

Re:How nice of you...

[Dan Hayes]

Indeed, google-analytics really does annoy me, there's far too many sites where I see it waiting on that for ages after other things have loaded.

Actually right at this second something is waiting on stats.big-boards.com, grr.

Re:How nice of you...

[Millenniumman]

Thanks for the answer.

So even if the websites hosting the ads can tell, do the advertisers check and will they count an adblocked pageview as a regular one?

Re:How nice of you...

[Man Eating Duck]

Short answer: They check, and they only count real impressions :)

When I consulted for an ad-financed site six years ago as a coder, we did it in three different ways:

1) Generally, smaller stores would send us their ad images, and trust us to be honest with them regarding number of impressions and clicks. As it was then a relatively small niche site (skateboarding and snowboarding), we were part of a small community and they had no reason not to. We were honest.

2) Some would have an agreement with a professional advertising firm, which hosted the images and tracked clicks. Some would ask for our numbers as well for comparison.

3) The largest ones would have their own systems, and track everything themselves. They would not give us any insight in their numbers, we had to trust them. They just supplied urls which we included in our scripts.

Obviously the ones paying for the ads wouldn't like to pay for a pageview which never showed their ad, and this made is important for us to be able to provide them with exact numbers. I wrote a small serverside app to track both impressions and clicks. If the user didn't see it, it wasn't counted. The ones doing the tracking themselves wouldn't know about ad-free pageviews in our case. In all cases they would only pay for ads that was actually displayed.

Blocking wasn't much of an issue then anyway, as it usually involved setting up a local proxy or adding to your hosts file.
As I generally don't like ads, and we largely were a community-driven site, we made the ads small and non-intrusive.

The downside to blocking is that it makes life difficult for quality sites like ours was (is :). What irks me is that if sites generally made ads NOT fucking annoying (more like the Google ones for instance), this would still continue to be a viable solution for a small startup site.

As it is, I can't stand browsing without blocking both ads and flash.
Blame it on the marketing droids of the world, they've brought this upon themselves. They should stop whining already.

This turned out to be longer than I intended, but I guess I answered your question :)

Re:How nice of you...

[shaneh0]

You're getting a service that you obviously value (you do use it) at no charge to you.

In exchange for such a service, they display ads.

Would your browsing experience be "so much nicer" without the ads? Of course. Would things load faster. Of course. Does that mean you should circumvent the ads? Only if you want to pay for it outta your pocket.

You can do that at any time, you know. It's very easy.

It's just such a joke to me when someone says "I like this free service. I use it. But it's not good enough. Moreover, the tiny price I am asked to pay (in the currency of your time and your eyeballs) is just too much. I can't be bothered to wait 5 seconds (on a bad day) for my ad to load."

Freeloader.

Re:How nice of you...

[mabinogi]

you're an idiot, that's all there is to it.
I don't care if they show me ads, I'm quite happy for a website to display ads to support them. If they're services I'm interested in, I'll even click on them.
But if the showing of the ads makes the page less useful to me I'm either going to go somewhere else, or find a way to prevent the ads from making it less useful to me.
Anyone who runs a web site should be aware of that.

I could be browsing in Lynx - I wouldn't see any ads then, would that make me a freeloader?

Web content is _supposed_ to be free to look at, that's the _point_. It's up to the content providers to figure out how to sustain providing the content. It's their burden to ensure that the ads work, not mine.

Re:How nice of you...

[shaneh0]

How much content do you think there'd be if there were no ads?

If people can't make money off the web, it would be a place full of retail stores, dissertations and term-papers.

You are a freeloader. You call me names because you don't like to hear the truth, but that doesn't change things.

The only reason you can skate by like you do is because the vast majority of people have, you know, morals, and they're picking up the slack for children like you.

Do you steal your music, too?

If you're over 18, and actually hold down a job, there's no excuse for either.

Re:How nice of you...

[mabinogi]

I told you in every single one of my posts that I do not have a problem with advertising supported content.
I think it's an entirely appropriate way of supporting a web site.
I _don't_ think adding 10 seconds to your rendering time is an appropriate way of supporting your website.
and like I said in my previous post - supporting your website is _your_ problem, not your readers' problem. If you offer the content for free, don't be surprised when people take it for free.

> Do you steal your music, too?
Well no. My music is my music, how can I steal that?
But assuming you meant do I steal [i]other people's[/i] music, then no - I do not, I purchase it. But in that case, the content providers are [i]not[/i] giving it away for free.
As for [i]my[/i] music, I give that away for free, and if I happened to decide to use advertising to support bandwidth costs I'd do so under the understanding that some people would bypass it. Sure, it would make the advertising less effective, but that would be [i]my[/i] problem for using a method so easily bypassed.

Re:How nice of you...

[mabinogi]

gah, it's inevitable that if you post without previewing you'll make some idiotic mistake like using UBB tags instead of HTML...

Q. What if the connection limit was set to 2 ?

[Brit_in_the_USA]

So what happens if a user, or A LOT of users increased their default connection limit to >2 ?

For example, say a popular browser in it's next release had a default of 10?

What would be the effect on servers (small and large)? Would it help everyone? Do servers reject >2 connections by default?

Connection speed

[ipooptoomuch]

I am on a T3 connection at school and I don't notice any speed difference from my home cable connection (3mbit down 256k up). Then again I am comparing Internet Explorer 6 to Firefox 2 at home with all settings maxed out in fasterfox.

This explains why blogger is down....

[cpatil]

Maybe blogger.com went to implement this ? Silly! It's the old hardware problem http://news.zdnet.co.uk/internet/0,39020369,392843 79,00.htm

HTTP connection limits

[Anonymous Coward]

We don't all have googles resources and with broadband connection speeds increasing, many admins are finding it prudent to throttle bandwidth. An additional 10Mbps of transit doesn't come cheap. How many of the people wanting to make more connections are prepared to pay site subscriptions to make these connections worthwhile?

Net Neutrality eat your heart out :-o

Static content in multipart packages?

[AkimAmaklav]

Has anyone played around with multipart/mixed or such replies? These could reduce the number of requests but is there any support for them in browsers?

Re:Static content in multipart packages?

[Anonymous Coward]

See: pipelining

It's disabled per default because it can supposedly cause problems with some servers and transparent proxies. I've had it switched on for a couple of years now and not noticed any major problems. In moz, enable it by way of the following prefs:

network.http.pipelining = true
network.http.pipelining.maxrequests = 6

Also test proxy pipelining if you use HTTP proxies

Re:Static content in multipart packages?

[AkimAmaklav]

I was after a bit different approach. More in line with MMS or MHTML. Packages of content would be prepared on served side and maybe a one package could contain all icons etc. used in site or in case of relatively static site, whole site including pages could be packaged. The internal URLs would then point to elements of multipart package.

At least in mobile world this could be useful. The initial load would be longer (creating data network connection and contacting the server takes quite some time anyway), but subsequent navigation would benefit.

Re:Static content in multipart packages?

[Anonymous Coward]

So essentially you're asking for something similar to browser extensions, tied to a single domain and having no additional priviledges to web content? I think it's a good idea and could allow javascripts to be cryptographically signed. Alas, with pipelining, compression and caching the need to bundle CSS and icons in a zip may be minimal.

Re:Static content in multipart packages?

[Muggins the Mad]

In the bad old days, I used to see multiple icons encoded as one large GIF, then a bit of
javascript to unpack it and display the right things in the right places.

I suspect browser incompatibilities killed that off, but maybe it's do-able again.

- MugginsM

Fucktard

[Anonymous Coward]

You pompous asshat.

Faster downloading

[mixer3]

Ever try to set the timeouts for static content to 40 years in the future. Then the browser won't check to see if there's a new version for all those little images, HTML snippets and javascript files. When you upgrade, just put the new files in a different directory to force the download. Basically take control of the automated download process.

google money, meet toilet

[Anonymous Coward]

google writes research papers which are published on slashdot.

What next? Buy youtube? er..

All the offsite stuff is ads anyway. Block them.

[Animats]

This is an excellent argument for ad blocking. The article never mentions the basic truth - almost all offsite content on web pages is ads. (Of course, this is someone from Google talking, and Google, after all, is an ad-delivery service which runs a search engine to boost their hits.) Web page load is choking on ads. I noted previously that some sites load ads from as many as six different sources. This saturates the number of connections the browser supports. Page load then bottlenecks on the slowest ad server.

So install AdBlock and FlashBlock in Firefox, and watch your browsing speed up.

Web-based advertising looks like a saturated market. Watch for some big bankruptcies among advertising-supported services.

Re:MODS DO YOUR JOBS

[shaneh0]

PARENT IS AN ANONYMOUS COWARD

It's not reading the AMOL data in the VBI?

[Animats]

So MythTV is still guessing, like the ad-skipping VCRs of twenty years ago.

There's better data available. Broadcast TV signals contain considerable metadata. The AMOL data in the VBI and the SID data in the audio clearly identify the program content and source. Here's a encoder for that information, which is inserted to make Nielsen ratings and advertising payments work.

See U.S. patent #5,699,124 for some details of how the data is encoded.

So far, the PVR community doesn't seem to have figured this stuff out, and the specs aren't easy to get, but the data is out there.

Re:It's not reading the AMOL data in the VBI?

[Animats]

Here's a reference on extracting SID data from audio.

Oops, mod parent down

[Animats]

Meant to post that in the MythTV article. Oops.

Web optimization techniques

[bee-17]

Web developers would do well to study existing web acceleration products to see how they work -- they go far beyond gzip and many of their optimizations can be implemented locally.

E.g., Cisco's AVS (formerly Fineground): http://www.cisco.com/en/US/products/ps6492/product s_white_paper0900aecd80321a32.shtml

• implements the multiple DNS name solution suggested by Mr Hopkins
• has a clever way of eliminating browser cache validation requests
• has a mechanism to transparently measure actual (not simulated) user page load times

Other products have similar but, in this age of software patents, slightly different optimizations:

• Juniper's DX series (formerly Redline): http://www.juniper.net/solutions/literature/white_ papers/200142.pdf
• The same is true for F5's web accelerator (formerly Swan).: http://f5.com/solutions/technology/pdfs/smartcachi ng_wp.pdf

Client-side image resizing & absoluteposition

[Anonymous Coward]

Check out this page and it's source. Every img tag has a height & width component. The values are different from the size of the actual image, causing the browser to resize every image. This is insanely stupid. I especially like that the images used as dividers, shown multiple times on the page, are forced to a different size each time: Yellow_back.gif and yellow_back.gif

Do the absolute position tags cause a slowdown in rendering? I would expect that a rendering engine would be optimized for standard html, not absolute page layout. Note that these tags also corrupt the layout of the page when the font size is changed in the browser.

Slashdot Needs to Listen

[Master of Transhuman]

I just spent several minutes - three times - waiting for the front page to load because the browser was sitting there waiting on "runner.splunk.com" to get off its ass and do something.

Guys, splunk does not apparently have the server power or bandwidth to service Slashdot. Get a clue and dump their ads or tell them to buy another server box.

Ninety percent of the time when I'm waiting on a page to load, it's because some ad server is overloaded. The rest of the time it's because the site server itself is overloaded (or "Slashdotted").

Use Firefox - then use Adblock generously.

Tweak Network Settings

[Ranx]

Turn on pipelining and use more connections per host with this Firefox-Add-on

Tweak Network Settings:

http://www.bitstorm.org/extensions/tweak/

Very easy to use: just use the "Power profile".

Ok, now I get it.

[SanityInAnarchy]

Pipelining is: You send a bunch of requests, the server sends a bunch of responses. This is good because it reduces round-trips -- you can send requests without waiting for the replies, making it very useful over high-latency connections. It must send the responses in exactly the order you requested them.

This is potentially bad, because it means a 5k gif can be queued behind a 200k SWF, and there's nothing anyone can do about it once they're queued up like that. The right approach is to use multiple connections -- there may be a bunch of round trips, but most likely, at least one of your connections will be busy, so your pipe stays saturated, and more importantly, things appear to load faster that way -- the smaller parts of the page will all be done quickly, even if someone sticks a 2 meg jpeg in the middle.

The downside of multiple connections is the overhead in opening them -- but if BitTorrent can work, so can this. It might be a harder hit on the server side, though. The other nice thing about pipelining is persistence -- you send your huge batch'o'requests through the same pipe, instead of sending a request, getting a reply, then opening a brand new connection for a new request. But, you can do persistence without pipelining -- open a connection for every file you need (up to your arbitrary browser-defined limits), then as files finish downloading, re-use the existing connections, only closing them when you don't need any more files.

Now, it's possible that some web servers might do better with pipelining, and certainly there are servers that won't do persistence any other way. Pipelining a single connection is easier on the server than handling a dozen connections. But if you both can handle it, disabling pipelining is the way to go.

I wish I could find the place I read this (last night), but I can't. I believe it's linked to off of Opera's explanation page, but I don't remember what that is, either.

Increasing IE simultaneous connections limit

[PSdiE]

The maximum number of simultaneous connections for Windows applications using the WinInet API (including Internet Explorer 4+) is determined by the following registry DWORD values:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\Curr entVersion\Internet Settings\MaxConnectionsPerServer] [HKEY_CURRENT_USER\Software\Microsoft\Windows\Curr entVersion\Internet Settings\MaxConnectionsPer1_0Server]

These two settings affect HTTP 1.0 and 1.1 connections respectively and default to 4 and 2 respectively. More info (including similar tweak for Firefox).

For tweakers that won't leave sleep over hogging extra web server cycles, you can increase these limits to significantly reduce page load times. If the values don't already exist, go ahead and create them (DWORDs). A reboot will be required. The IE dev team have unofficially recommended setting both to 16 (decimal, 10 hex) for best performance.

Of particular note is the direct effect that these settings have on the maximium number of simultaneous file downloads allowed in IE.

~ PSdiE