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."

Erm.. huh?

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?

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 [onspeed.com] 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?

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.

Those tenths of seconds add up

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.

Re:Erm.. huh?

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.

HTTP Pipelining

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 [mozilla.org]

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

Re:HTTP Pipelining

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 [operawiki.info]

HTTP/1.1 Design

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

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

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?

Simulation software available?

"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?

You could try using Sloppy [dallaway.com]. 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 [dallaway.com], so this isn't a recommendation or anything. Looks pretty decent, though.

Css and Scripts

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 [dotgnu.info].

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 [flickr.com] 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 [yahoo.com] and application [php.net]).

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

Spreading content across hostnames...

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.

Caching of dynamic content

This [web-caching.com] 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 [google.com], you'll feel better for it.

Pipelining

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

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

Connection Limits

``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.

Requests Too Large

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.

ooh sub domain spam

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

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.

Gmail

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.

Is this really news?

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.

Page load time is still important

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.

"Also, by spreading static content..."

"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.

4 hostnames and security

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.

render time

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?

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.

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

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

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....

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 [zdnet.co.uk]

Static content in multipart packages?

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?

Faster downloading

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.

All the offsite stuff is ads anyway. Block them.

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.

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

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 [norpak.ca] 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.

Web optimization techniques

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 [cisco.com]

• 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 [juniper.net]
• The same is true for F5's web accelerator (formerly Swan).: http://f5.com/solutions/technology/pdfs/smartcachi ng_wp.pdf [f5.com]

Slashdot Needs to Listen

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

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

Tweak Network Settings:

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

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

Re:It's talking about 'percieved performance'

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.