Building Performance into Internet Applications

include file instead of ten. Practically, this is not possible as more than one developer may be working on the same Web page at one time. Segregating logic in several modules can allow developers to work simultaneously. Depending on the working relationship between developers, and team dynamics at the time of the build, a single include file can be generated to receive minimum 304s.

All images and cascading style sheets will be requested exclusively. It is more advisable to have one background image than four images joined to make one background image. It is advisable to have one CSS file than to have three for the same page. It is also recommended that gif and jpg files be optimized with the proper graphical tool. Using 256 colors instead of 32 will increase the file size. For example, saving the "Click Me" image with 32 colors (gif) gives 898 bytes of image size. But saving the same image with 256 (gif) colors will give 2.131K, and saving it as a jpg gives 2.83K of image size. Clearly, if the image quality does not suffer, to save network bandwidth the preferred file format should be gif with 32 colors.

Cascading Style Sheets
Cascading style sheets are a great way to reduce the total number of lines of HTML code. Creating a page using

Cross Boundary COM/COM+ calls
Frequently used object data should be saved within script variables. This will cut down on COM method calls, which are relatively expensive, compared to accessing script variables. COM calls should be minimized from ASP pages to achieve optimal performance. It is better to write a few lines of ASP code than to wrap it within a COM component.

In practice, accessing COM properties or methods can be deceptively expensive. Here is an example, showing some fairly common code (syntactically speaking):

Foo.bar.blah.baz = Foo.bar.blah.qaz(1)

If Foo.bar.blah.zaq = Foo.bar.blah.abc Then ' ...

When this code runs, here's what happens:

1. The variable "Foo" is resolved as a global object.
2. The variable "bar" is resolved as a member of "Foo." This turns out to be a COM method call.
3. The variable "blah" is resolved as a member of "Foo.bar". This, too, turns out to be a COM method call.
4. The variable "qaz" is resolved as a member of foo.bar.blah. Yes, this turns out to be a COM method call.
5. Invoke "Foo.bar.blah.quaz(1)". One more COM method call. Get the picture?
6. Do steps 1 through 3 again to resolve "baz". The system does not know if the call to "qaz" changed the object model, so steps 1 through 3 must be done again to resolve "baz".
7. Resolve "baz" as a member of "Foo.bar.blah". Do the property put.
8. Do steps 1 through 3 again and resolve "zaq".
9. Do steps 1 through 3 yet another time and resolve "abc".

As you can see, this is terribly inefficient and slow. The fast way to write this code in VBScript is

Set myobj = Foo.bar.blah ' do the resolution of blah ONCE

Myobj.baz = myobj.qaz(1)

If Myobj.zaq = Myobj.abc Then '...

If you're using VBScript 5.0 or later, you can write this using the With statement:

With Foo.bar.blah

.baz = .qaz(1)

If .zaq = .abc Then '...

...

End With

Note that this tip also works with VB programming.

Optimized Logging
Server side logging can be expensive. The logging can be done in low, moderate, and high amounts. This is totally based on the architecture and the amount of debugging facility the product asks for. If every subroutine is logging entry and exit points, the cross boundary COM/COM+ calls can become expensive and can undermine