WIll multiple domains make any website faster?

February 7, 2008 11:44 PM

Will serving images, other files, etc. from more than one domain make an appreciable difference in load time?

I have an html page that loads in 12 images (6 at ~25k each and 6 at ~5k each). There's also associated CSS, javascript, etc. I know that browsers are typically set to load only a couple of resources from the same domain concurrently.

I want to know if I should expect to see a noticeable difference in how quickly the page loads and/or renders if I serve the files from a few different host names. I'm thinking the time and resources for the additional DNS lookups might use up any possible gains. Anyone have more info?

posted by braintoast to computers & internet (12 comments total)

should probably read: Will multiple domains make a website any faster? :)
posted by braintoast at 11:46 PM on February 7

Are these domains hosted on the same webserver? If so, then no. Is the webserver approaching capacity (either bandwidth-wise or CPU-wise)? If not, then no.

If you want to speed up page rendering, be sure to specify WIDTH and HEIGHT for all your images. This will at least let the user's browser reserve space for those elements even if they're not yet loaded.
posted by neckro23 at 12:08 AM on February 8

180 Kb of graphics in 12 files will take the same amount of time to load either way. But something about your design may cause the page to render faster if a certain graphic is loaded sooner. Fewer files or fewer Kb may speed it up, but at only 180 kB, I don't think it will be all that noticeable to most people.
posted by winston at 12:22 AM on February 8

One of the reasons that all three major online map providers (Google, Yahoo, MS) serve their satellite and road map image tiles from sets of four servers (e.g. 0, 1, 2, 3 or 0, 1, 2, 3) is that this effectively raises the typical browser-imposed limit simultaneous connections from four to sixteen per host. I think this may only be a useful technique for sites with a similar requirement for snappy display of numerous small images. I doubt your page with just a few resources will see any noticeable gains.
posted by migurski at 12:24 AM on February 8 [1 favorite]

I'm not at all concerned about file size really... I was just wondering if the idea I have stuck in my head for some reason made any sense.

Just to clarify for the sake of discussion, we'd be talking physically separate servers woth plenty of proc and bandwidth resources available. Let's say hypothetically that we're talking considerable more data...like 30 images at 100K each. How much overhead are additional DNS lookups typically contributing?
posted by braintoast at 12:29 AM on February 8

Mostly the reason why some big sites separate their content over different subdomains is because their architecture separates static and dynamic content.

That way they can use lightweight web servers (eg. Tux) that only support static files for images and css, whilst freeing resources on their "dynamic" webservers (eg. Apache) for their PHP/Perl/Ruby/whatever content.

Following this reasoning, there's no real performance benefit in separating images and stylesheets, as they're both static files. It is still done however to ease maintenance, or for example to host the images on an external service like Amazon's S3.

DNS lookups might offset the performance gains a bit for the first request, but as long as you keep your dns servers responsive, and keep your TTL at a reasonably high level subsequent requests should not suffer from this.

I personally don't think that for your specific scenario you will benefit much from this, even if browsers limit concurrent connections to one domain. The reason types of files are split up over hosts usually are to speed up the processing on the server side. Your Mileage May Vary.

It's easy to test this by creating an account at Amazon and see for yourself if it improves performance. There are also some Firefox extensions and websites that will tell you what your bottleneck is/how your page is downloaded.
posted by lodev at 12:30 AM on February 8 [1 favorite]

thx all...

@migurski - that gives a little more clarity to the foggy idea I had in my head. Makes perfect sense.
posted by braintoast at 12:31 AM on February 8

Long answer: Read Aaron Hopkins's work on the matter. If that doesn't feel like enough, I highly recommend High Performance Web Sites.

Short answer: Listen to migurski.
posted by Coda at 12:34 AM on February 8

Most of the answers so far tell the truth but seem to be ignoring the actual question. Yes, your idea is exactly correct in theory. It is indeed a number-of-hosts 'hack' to get around common browser behavior that limits simultaneous connections (8 in Firefox 2 in IE) and is done very often.

The Dreaded 2 Connection Limit

This is why you often see the apparent silliness of "images.domainname.com" pointed to the same server as "www.domainname.com." (it also helps you expand later by moving just that resource, offloading it from the main "www" server.

That DNS lookup will happen once, not each time, so it will not be much of a hit.

As everyone WANTS to tell you, though, the real-world difference for most sites will be very small.
posted by rokusan at 12:37 AM on February 8 [1 favorite]

Another reason to move your images and other static content on to a separate server is down to cookies. If you restrict your cookies to only be sent to www.example.com, while your static stuff comes from static.example.com, then the cookie will only be sent over the wire once, to your actual web page, and not for every image requested too.
posted by jon4009 at 1:15 AM on February 8

Your question has basically been answered (yes you can use multiple hosts, and with the larger images, I believe you would get a marginal performance benefit), but since you were interested about DNS latency and other considerations I'd add that with with smaller images this isn't always the case - although there's benefit going to two hosts, response time actually *goes up* with more servers for small images. If you're really interested, your best bet will be to write your own tests as this is very much dependent on your own server/DNS setup. It can be quite surprising (you can check out some of the links below to see examples of how you can measure it).

(Your browser/server settings will also affect things. While IE & FF are set to 2 conn/server for HTTP 1.1, FF has 8 conn/server for HTTP 1.0 requests.)

However, if you're *really* interested in optimizing the performance of your site there are much easier things you can do. Firstly, w/ the 12 images, you might want to see what you can turn into sprites or otherwise combine - not only are you paying the latency/connection # costs, but as jon4009 mentioned the HTTP headers being sent (especially if you have cookies) would be a big percentage of your total transfer size for the small images. (You can apply that also to JS and CSS files of course if you're serving a lot of them.)

Also as suggested, moving your static files to a lightweight web server on a domain that isn't serving cookies would get you a big performance boost as well.

YSlow is a great Firefox extension that can help you optimize your site. It gives response times, sizes (including headers), total sizes (cached vs non-cached) and grades/analysis of over a dozen front-end performance factors (gzipping, proper expirations, etags, etc).

For more information, you can check out Yahoo's Exceptional Performance site, that has lots of docs, screencasts, etc. or Steve Souders' companion website for his afore-mentioned High Performance Web Sites book which includes a basic checklist and example files for each one (that you can use as a template for writing your own tests).
posted by lhl at 2:27 AM on February 8

yes yes...I'm very aware of optimization tools and techniques as mentioned by many. Thanks to those that answered the question. You guys rule.
posted by braintoast at 3:01 PM on February 8