The following are basic guidelines for you to use when choosing between executing client-side and server-side components:

1. Components of the application that are shared among clients persist, or carry over from session to session, from session to session should be on the server side.
2. Components that are not shared among clients and that do not persist from session to session must reside on the client side.
3. Components that relate directly to client resources must have a client component. Examples include audio clips, video clips, and animations. Some of these, such as streamed video and audio, may also have server components.
4. Certain components, such as those identifying the connection between the client and server, may be on both the client side and the server side.

You should also consider these additional factors that are involved in deciding where processing should be performed:

1. Server location
2. Response time
3. Client and server processing capacity
4. Reuse of components

You will learn more about these additional considerations in the following table:

CGI is a simple mechanism for implementing portable server-side applications. It has been employed throughout the Web. However, there are a number of problems associated with CGI processing. Its main deficiency is performance. Processing a request that invokes a CGI script requires the spawning of a child process to execute that script (plus another process if the script is written in an interpreted language such as Perl). Furthermore, any initialization and other processing that might be common to all requests must be repeated for every single request. SSI has similar deficiencies when its command processing employs CGI under the hood. It adds the additional performance penalty by requiring servers to parse SSI pages. Most importantly, SSI may represent a serious security risk, especially when not configured correctly by the server administrator. The SSI mechanism is not scalable, and provides only limited opportunities for reuse. With this in mind, a number of other approaches to dynamic content processing arose in the Web server environment.

Efficiency concerns may be addressed by using native server APIs. A native API is simply a mechanism providing direct "hooks" into the Web server's application programming interface. Use of a native API implies the use of compiled code that is optimized for use within the context of a specific Web server environment. From a historical perspeective, NSAPI and ISAPI were two approaches employed by Netscape's Web server software and Microsoft’s IIS, respectively. The problem is that there is no commonality or consistency amongst these native APIs. They are different from each other, and code written for one environment cannot be reused in another. This makes it impossible to implement portable applications.