Website Organization Strategy

One of the biggest problems I've always had with maintaining several related websites is that I can never keep my images synched up. One other related problem would be that, if I ever threw an image up onto the web server, and referenced it on another site, it would throw off my web server statistics. A perfect example is the signature graphic I use on the ASP.NET Forums. That would throw of my stats by thousands of visitors every week.

I figured out a really simple solution that lets me keep all my images in one place, keeps my sites synched and running faster, and doesn't throw off my stats. I now keep all my images stored at http://images.interscapeusa.com. This way, my templates at http://demos.interscapeusa.com, http://support.interscapeusa.com, http://interscapeusa.mykb.com, and my test site at http://next.interscapeusa.com can all reference the same images, without hefty changes that have to be made at deployment. If I change a graphic, it's updated automatically everywhere. What's even better is, the browser caches images by request location, so as you navigate across my subdomains, you pick up the browser-cached images, giving the end user a better browsing experience. And my stats are not inflated by page views on www.asp.net or other sites.

Speaking of subdomains, have you ever noticed how, if you type in “www.news.com” in your browser, it takes you to http://news.com.com. That has always kind of confused me. I've always wondered how they do it. Well, the other day, I figured it out, and the answer is kinda lame. They own the domain name “com.com”, and each of their properties is a subdomain of “com.com”. That's kinda messed up, IMO. They already own “news.com” and “builder.com” etc, so why redirect to a confusing subdomain? *shrugs* oh well.

4 Comments

  • I wonder if they have a COM programming section of their site called com.com.com?

  • Quick question. What happens when you want to do a major overhaul on graphics (say, a complete UI change) for your site. Do you just come up with new names for the graphics (like "arrow" or "button") and double the amount of images on your Image site until the application is published?



    Otherwise, you've got no way to introduce new graphics without impacting your production site. Plus, if you did pump in newly designed UI graphics (that are unapproved), you'll have to publish them to a production server without really being approved for production.



    This can lead to issues - especially if you're coming out with a new design that you want to keep hidden from the public (or competitors) until the official unveiling.



    Just a thought.

  • Cool. I just wonder how big your graphics are? Are there any storage concerns with keeping multiple versions? Do you foresee any problems with the web hits you'll receive while testing (specifically running stress testing) on your development apps. as they'll be hitting a production server (even though the graphics are in a different subdirectory)?

  • To be honest, I have 120GB of drive space, and over 1TB of transfer, so I'm not terribly concerned about space or bandwidth. Also, there is a big difference in an application versus a corporate-presence website. We do not build graphics-laden web apps, so it's not really an issue for us. In my experience, no one cares how pretty the site is if it doesn't do it's job. IMO, you get the app working 100% like it needs to, without question, and THEN you spend time making it pretty. Once you do that, you do an effective job of graphics caching, so that they do not affect the performance of the app.

Comments have been disabled for this content.