It happens. The client changes their mind to have a feature removed from their to-be-launched-minutes-from-now web site. And of course this same client has shown in the past to have a habit of changing their changed mind. Coding that silly content block that just HAD to be where it is (never mind visual balance that was thrown off by having it there) took some time. It would be a shame to waste the effort only to have to re-code it again in the near future. So what do you do? You comment it out.

Don’t do it. At least not with HTML comments.

Page code always comes at a cost. A network transfer cost. What looks like a trivial bit of code that “It doesn’t seem to slow down the page load to me…” adds up over time.

Example: One of our client sites had a weekly page request rate of 60,890 pages a week. The page in question was an 8,487 byte PHP file (remember that PHP bit for later…). It contained 1,348 bytes of commented out code of a “ah, that’s not ready yet, launch without it” feature. 1.3KB doesn’t really sound that bad, does it? But that’s actually ~15% of the file size and that’s multiplied by over 60K+ pages a week… Over the course of a month that’s 313MB of unnecessary data transfer slowing down site visitors viewing experience. And that’s just one client.  Because most of our clients are in a shared hosting environment, one must remember that every CPU cycle, every byte of RAM and every packet of bandwidth that is unnecessarily used up by one site is no longer available for another site to use; a well coded high-performing site can be slowed down by a less efficiently coded site that is running on the same server.
Page load time has an effect on site visitors.  We know it from our own experience. If a site is too slow, we’ll will say “forget it, I’ll go elsewhere”. If a site is fast, then we’ll say “OK… let’s see what’s here”.
Speed encourages “site stickiness”. Visitors lingering on a site enhance brand awareness. And that’s what we really do at GS Design, right?  But that doesn’t mean that one should delete one’s code, do away with comments or have an endless number of confusing index.bak, index.tmp, index.bak2, index.bak.bak.bak.spam.bakedbeans.spam.bak.tmp.bak files.

The tip here, at last is, use server side comments.

Most of our sites are coded in PHP. A few others are in ASP or JSP. Very few pages we code are actually straight .HTML files. By using server side comments…

< ? /* Awesome news */ ?>

…the code is still usefully available to be added back into the site at a later date, yet is not being presented as part of the PHP processed page. So, no network transfer, a faster loading page. ASP has similar commenting features but isn’t nearly so nice - multi-line comments aren’t possible. So one has to do something like.

< %
'
'Awesome news!
'
%>

Not as convenient but still useful. JSP? Yep, that works more like PHP.

< % /* Awesome news!*/ % >
Server side comments. So YouTube videos will start quicker. Making for a faster Internet for all of us.

A List Apart is conducting a survey of the web making profession.

“Calling all designers, developers, information architects, project managers, writers, editors, marketers, and everyone else who makes websites. It is time once again to pool our information so as to begin sketching a true picture of the way our profession is practiced worldwide.”

I stumbled across this useful list of 100 social media blogs. This could be helpful as our clients continue to ask us for guidance in this area. Enjoy.

http://www.virtualhosting.com/blog/2007/top-100-social-media-and-social-networking-blogs/