12 EASY PIECES, PART 5: Drive Space and Bandwidth

Editor's note: This is the fifth in a 12-part, "hands on" series about the wonderful world of adult Website building. The resulting site will have been built by real people who have no Web-building experience and no inside experience in the adult industry. Their names have been changed to protect their real identities and their mainstream business interests.

Xatia and Inspector Gadget signed up for a virtual hosting account that would provide them with 40 megabytes of disk space and two gigabytes of "transfer," or bandwidth usage, per month. That was enough disk space to contain about 800 pages of content - as long as that content was primarily text and a few graphics. Add space- and bandwidth-hogging .jpeg photographs to the mix - especially if those images have to exist on the server in both thumbnail and full-size formats - and the couple expected they might be able to squeeze their site into half that space at most; more realistically, they were looking at being able to afford fewer than 100 pages of content within their site before charges for disk space began to climb. Although this is a good number of pages for an adult pay site, Inspector Gadget and Xatia decided they would have to cull their image collection carefully before posting it to their server.

Of course, optimizing images helps reduce disk space and bandwidth usage, but there's ultimately a trade-off between quantity and quality. When it comes down to his or her own original images, only the site's owner can decide where that line should be drawn - and then only after a good amount of playing with the settings in image processing programs and viewing the finished products on as many monitors and in as many browsers as possible.

Usually more important - and more confusing - for beginning Webmasters is bandwidth. Bandwidth is a big topic in the adult hosting biz, and one of the most misunderstood, especially by "newbies." Essentially, bandwidth is the amount of data that can be transmitted between a site and an end user in a fixed amount of time. Bandwidth included in a hosting contract includes data transfer in both directions (not just from the site to the user), and also may include e-mail (which requires very little bandwidth unless it includes graphics-intensive HTML pages).

A good analogy for bandwidth is water (data) flowing through a pipe (telephone line or fiber-optic channel). When a site's owner has used up all of the bandwidth allotted to him or her in a specified period, he or she must pay to reopen the pipe so more water can flow through it. If the flow of water through the pipe is constantly heavier than the pipe's capacity, the Website owner must pay to switch to a bigger pipe.

Fortunately, a site's bandwidth needs can be anticipated fairly easily once a site begins to take shape, though calculations do require some educated guessing. The process requires only basic math: Estimate the size of each page on the site and multiply the result by the number of page views each page is expected to have.

For example, say the HTML content of the "home" page for a site is 2 kilobytes in size. The page includes two images, each of which is 15K in size, and a banner that measures 10K. The total amount of data that will be transferred - or bandwidth that will be used - each time this page is requested by a visitor is 42K. Multiply this result by the number of views the home page is expected to get per day - say 200 for the sake of argument in this case - and the answer will reveal how much bandwidth will be required by that page each day (in this case, 8.4 megabytes). Multiply that number by 30 to get a rough approximation of one page's bandwidth requirements per month.

In this case, the final figure is 2.52 gigabytes per month, which exceeds Inspector Gadget's and Xatia's allotted usage - and that's just the bandwidth required for the home page. When the remainder of the pages at the site are factored into the equation, the bandwidth usage could get quite out of hand very quickly.

That's why so many free sites depend upon the largess of sponsors who provide them with content and banners that are hosted on the sponsor's server, thereby reducing the bandwidth needs of the poor, downtrodden free-site owner who's just trying to make an honest buck by sending his traffic to the sponsor whose content he's using.

For sites that contain both free and pay sections, though, cutting bandwidth costs is not that easy. As discussed before, images can be trimmed only so much in size before they lose their appeal to visitors. Using hosted content is an option in the free sections of hybrid sites, but won't work in the members-only areas of those sites because content there usually is unique and proprietary.

To reduce bandwidth requirements for pages in areas like these, site owners and designers should try to eliminate all unnecessary graphic elements. That means eliminating banners, cute little buttons, secondary logos, graphic links to other pages within the site - basically anything the user isn't paying to be there to see. All of those things add nice touches to a site, but at least until the site is profitable, can be accomplished just as well and much more inexpensively with well-placed, well-worded text.

Even the names of files can add to their sizes and should be considered carefully, especially if the images will only be seen by members. In free areas, file names can have a positive effect on a page's search engine ranking, so a trade-off exists between benefits there. Behind the members-area curtain, though, file names can and probably should be shortened as much as possible, as most pay site owners don't want search engine robots indexing pages and images in their members-only areas anyway.

What many sites - free, pay, and hybrid - seldom evaluate when trying to cut bandwidth costs is the HTML coding in the pages themselves. Cascading style sheets can help to slenderize a site by placing some attributes shared by most pages into a plain text file to which those pages refer, thereby eliminating some of the attribute assignments otherwise found at the beginning of each HTML page.

In addition, HTML files - especially if created with one of the many popular what-you-see-is-what-you-get software packages that guarantee to make an instant Web design professional out of almost anyone - can, and usually do, add unnecessary code to a page's infrastructure, sometimes bloating it to double the size it needs to be or larger. Learning at least to check HTML code manually before posting a page can dramatically affect its size in a multitude of little ways, for example:

* Use <I> and </I> instead of <EM> and </EM> to start and stop type in an italic face.

* Use <B> and </B> instead of <STRONG> and </STRONG> to start and stop boldface type.

* Use <CENTER> instead of <DIV ALIGN=center> to center an element on a page.

Also, removing tag sets and spaces left behind by the WYSIWYG editor when the designer deleted an element or simply changed his or her mind about typeface can reduce page size remarkably.

After learning at least some of the basics behind site concept, design, and optimization, Xatia and Inspector Gadget decided they were ready to jump in and either sink or swim in the world of the adult Web.

Next: Tools of the trade.

Previously: Servers and operating systems.