Action Item #1a: Measure, measure, measure. Set “acceptable” performance levels and monitor the site with Monitis monitors on an ongoing basis. Set up notifications so you can be instantly informed whenever the site’s performance is no longer “acceptable.”
Action Item #1b: Measure and record performance before and after every change. These are our benchmarks. Compare pre-change benchmarks to their post-change counterparts to see how performance was affected.
Action Item #2a: Postpone as much processing as possible until after the page is fully rendered and available to the user. Do below-the-fold processing after above-the-fold processing. [“Above-the-fold” refers to the part of the page the user sees first.]
Action Item #2b: Once everything is downloaded and fully processed, while the user is still reading the page and thinking about his next action, download the components required for the next page. True, this sometimes requires a crystal ball, but sometimes it’s pretty obvious. Make your best guess.
Changes to a page’s layout after it becomes interactive are seen by the user and are thought of as “Oops, I thought the page was ready to use, but it’s not.” By the above definition of time to interactivity, performance just took a hit in the user’s mind.
Action Item #2c: Avoid changing the page’s layout after it becomes interactive.
If servicing a request spends more time on the front end than on the back end, it does not necessarily mean that the front end is less efficient than the back end nor does it mean that the best improvement can be achieved by improving the front end rather than the back end. However, without further information (see action item #1 above), front end processing is probably the best place to start.
Action Item #3: In the absence of contrary evidence, focus on front-end performance before back-end performance.
Action Item #4: Design crisp, clean, focused pages that meet a need rather than meeting every imaginable need. Functionality that is not immediately needed should not be immediately available.
KISS applies to algorithm design and coding, too. Unreadable code can obscure opportunities to simplify.
Action Item #5: Produce highly readable, simplified code. Don’t use highly-convoluted, obscure techniques when the obvious approach offers similar performance. Use code that is understandable by the average programmer rather than code that shows how clever its creator can be.
In some cases, though, we may be able to relax this requirement slightly. If our users can settle for data that is a day old, we can run a background process once a day to incorporate the latest data into newly-recreated static web pages. Of course, we would run this process at the quietest time of the day. Alternatively, this could be run as a low-priority background process to recreate the static pages on an ongoing basis whenever quiet times present themselves.
Action Item #6: Create dynamic web pages only when there is a clear need to do so. Don’t use dynamic web pages to create a number of different forms of a web page when those different forms can be created individually and statically (perhaps manually, perhaps by a background process).
Action Item #8: As a program of ongoing self-development, techies should continually investigate alternate techniques and adopt the ones that are better than their own. [That is the reason why I’ve been presenting performance tips over the past few months. I don’t intend these articles to become a checklist; I offer the tips as suggestions that my readers may want to adopt as habits.]
Above all, remember: Every tenth of a second loses readership. Lost readership = lost customers. Lost customers = lost revenues. If the business loses enough revenue, it’s no longer in business.