Image hosting - Same server or different server?

[AjiNIMC]

Hi,

Posting after a long time, need your urgent suggestion/experience.

Purpose: I want to make my site load (even more) faster.

Different Options

1. Host images under the same domain - So no additional three way TCP handshake required.
2. Different subdomain for images - Browser pipelining can be utilized.
3. Different domain altogether - Browser pipelining can be utilize and also can avoid the site wide cookies with every request.

What is your opinion about this?

Thanks,
AjiNIMC

[Susmita]

I have heard about photobucket(.)com. It helps uploading images and videos. In case of many images you can take help of Flock Browser specially made by photobucket to upload images faster. You can share those images through other sites also.

Don’t know this information would be of help for you or not. Just shared.

Thanks

[AjiNIMC]

I have no issues with servers, we have many available but I wanted to get opinion on the policy that can speed up the load time.

[Tubby]

I think it if simply a speed question, stay with the one server. just get as good a sever as you can

I am experimenting with photohosters.com - on hosting images for a new site (southern-cross-register.sumpy.com. but this is certainly not a speed issue, it is a convenence issue. It allows my (and me)users to have full control of their images. I am also interested in the text and OBL's text links. It should also prove to be a time saver for me, as I need not handle the images. It also gives users submitting images, a better sense of freedom and control (this is an important factor for my users). I am also interested in comparisons between search engie approvals, of linking to off site images. (just playing around)

There are a huge number of factors when deciding the many ways you can construct a web site, I can think of half a dozen reasons that would need to be 'balanced' . . I certainly do not have enough insight into your web site to offer any better than,stick with the one site if it is ONLY a speed issue.

[AjiNIMC]

Thanks Tubby for the reply.

http://blogs.msdn.com/ie/archive/2005/04/11/407189.aspx has some good information on HTTP pipelining for IE (FF is similar in nature, only opera has 4 connections).

I have done some experiments with https://addons.mozilla.org/en-US/firefox/addon/3371 on, there is certainly a big improvement.

Looking forward for more replies.

AjiNIMC

[Susmita]

Turn on HTTP keepalives for external objects.

Load fewer external objects.

If your users regularly load a dozen or more uncached or uncacheable objects per page, consider evenly spreading those objects over four hostnames.

When you generate a page, evenly spreading your images over four hostnames is most easily done with a hash function, like MD5. Rather than having all <img> tags load objects from http:(//)static(.)example(.)com/, create four hostnames (e.g. static0.example.com, static1.example.com, static2.example.com, static3.example.com) and use two bits from an MD5 of the image path to choose which of the four hosts you reference in the <img> tag. Make sure all pages consistently reference the same hostname for the same image URL, or you'll end up defeating caching.

Possibly the best thing you can do to speed up pages for repeat visitors is to allow static images, stylesheets, and javascript to be unconditionally cached by the browser. This won't help the first page load for a new user, but can substantially speed up subsequent ones.

Set an Expires header on everything you can, with a date days or even months into the future. This tells the browser it is okay to not revalidate on every request, which can add latency of at least one round-trip per object per page load for no reason.

Instead of relying on the browser to revalidate its cache, if you change an object, change its URL. One simple way to do this for static objects if you have staged pushes is to have the push process create a new directory named by the build number, and teach your site to always reference objects out of the current build's base URL. (Instead of you'd use . When you do another build next week, all references change to .) This also nicely solves problems with browsers sometimes caching things longer than they should -- since the URL changed, they think it is a completely different object.

Source: Optimizing Page Load Time

[AjiNIMC]

Thanks Susmita, I have already gone through these pages, also the RFCs. Just wanted to know first hand experiences to help me decide.

Thanks for the reply.

AjiNIMC

[Susmita]

I have studied, learned and shared.

Thanks to you also.

[prathap75]

Forgetting about all the technicalities involved, I'd prefer to host images on my own server where the site is hosted.
Main reason is Control !! What if the other hosting site is down ?? It would look bad if your site is up and the images dont load. It would be better if the entire site is down.
That is what I feel.......Iam not good on technical aspects but believe that Control must always be in our own Hands !!

[AjiNIMC]

Using a simple softlink (with the same hosting server) and a robots.txt we can bring the manageability to the same level as method 1.

I think the most optimized way of handling images/css/js is having another domain. Can you point any negative point (apart from manageability, we can do it easily with a softlink and robots.txt) with method 3?

Thanks for the reply.

Aji