At the start of your CMS project, you should have the performance goals nailed down. This gives everyone in the Web design and coding process a realistic chance to succeed. If you do not provide specific goals, you are not giving your people a chance. The only thing worse than not having targets is increasing the expectations near the end of the project. Keep in mind that your Web site is designed and coded based on the original numbers. If someone changes those numbers, it could result in a substantial redesign.
Creating your performance goals should be a scientific process. If you are already running a Web site and you want to move that Web site to CMS, then you have the data that you require to create your goals. Simply check your Web site statistics and base your performance goals on these numbers. On the other hand, if you are creating a site from scratch or making major alterations, the task is far more involved.
Of course, there is a paradox when you try to estimate your initial performance goals. The closer the testing environment gets to your final site, the more complex the simulation becomes. At some point, you will compromise the efficiency of your test by spending too much time creating the setup. In other words, the closer the simulation gets to the actual site, the less time you save doing the prototype. At some point, you may as well wait for the site to be finished. Nonetheless, this initial testing should be done. Have your developers mock up the best prototype possible. This will give you some confidence that your initial numbers are well founded.
How you determine your performance goals for a new site is a business question. However, there are a number of things that you can do to help nail down realistic goals. Based on the requirements of your site, you can prototype features and then do some performance tests. These tests can be used to help calculate the performance necessary to meet your business needs and your budget.
The following are some of the factors that you should consider when creating your performance goals.
This is the most common interpretation of performance. Web developers often talk about how many "hits" the site can handle. Although the term is used to describe a number of different counting techniques, the principle idea is the same. The intent is to define the number of people who can simultaneously surf the site and still have a decent user experience.
Obviously, this is one of the most important considerations, but it certainly does not give you all the information that you require to draft your performance goals. Do not convince yourself that this one measurement will encompass all your performance needs.
Regardless of whether you separate your production and authoring environments, the number of authors you support will still be a consideration. You may have different performance goals for each environment, but you will want both your site visitors and your authors to have a pleasant experience.
Quite often, the "design-time" performance of CMS sites is neglected. Make sure that your performance tests include some sort of realistic authoring cases.
How your site is used can be as important as how much your site is used. Later in this chapter we will discuss how usage profiles are used in performance testing. If you do not take this into consideration, you could find that most of your traffic is heading to your slowest pages. This will substantially skew your performance numbers.
The type of code that you run on your site will dramatically affect how quickly you can serve pages. In fact, this is probably the single greatest consideration that you have the power to change (other than telling people not to visit your site).
Many sites offer some sort of personalization for their visitors. This is an example of an application that you may wish to run. The action of checking which user is viewing your site will cost you CPU cycles. Other examples include integration with back-end systems and code that makes your Web more visually interesting. One example of this is DHTML menus. They may look cool, but they are adding work to the client browsers.
The balance that you will search for is the amount of functionality that you can offer your users and still keep their interest. If you do not offer them anything, then they might get bored. But if you try to give them too much, your site could slow to a crawl. It is not always easy to find balance. You need to do performance testing and usability testing so that you can make an educated decision.
Given an unlimited budget, virtually any site could meet any performance goals. But this is not the world that we live in. Your performance goals will most likely be constrained by your hardware budget.
Just as with any other bugs, fixing performance problems early in your project will save you a tremendous amount of time and money. According to Steve McConnell's Code Complete (Microsoft Press, 1993), "Microsoft's application division has found that it takes 3 hours to find and fix a defect using code inspection...and 12 hours to find and fix a defect using testing." Test your site early and test it often.
Time is often the trump card in arguments about project plans. You may simply have to concede that your performance is partially dependent upon the amount of optimization that can be done within the time that you are allotted. The last chapter discussed how you could save time in your performance tuning by starting early in the project plan. Design your site with performance in mind. Do not try to add it all at the end.