by Warren Gaebel
| Mar 29, 2012
I’ve spent several months researching performance tips on the World-Wide Web. Occasionally I see a comment that one or another tip is a “micro-optimization,” a term that is intended to dismiss it as not worth considering. While I personally don’t like passing on an opportunity to improve performance, I can certainly understand where these comments come from. With today’s time constraints, we can’t spend too much time polishing the hubcaps when the engine needs to be rebuilt.Considering all the tips I’ve been presenting in the monitor.us blog, I think it’s time to step back and get some perspective. What’s important? What should developers and other techies consider first and review often?
Our Site Matters
There are lots of published measurements, averages, and other statistics out there, but when push comes to shove, our site’s measurements are the only ones that count. When our customers tell us that our site’s performance stinks, who cares what the industry average is? Published measurements help us compare our results to everyone else’s, but it’s our measurements that directly impact our users, and it’s our measurements that show whether we succeed or fail.
Action Item #1a: Measure, measure, measure. Set “acceptable” performance levels and monitor the site with Paid Monitor 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.
Perception IS Reality
In 2010, Nicholas Zakas told us that “time to interactivity is the time between the initial page request and when the user can complete an action.” In other words, time to interactivity is the time between requesting something (e.g., clicking on a link or button) and being able to do the next thing (e.g., entering data or selecting options). This is what the users think of as performance. Ultimately, the user’s opinion is the one that matters.
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.
Front-End vs. Back-End
In 2007, Steve Souders noted that “80-90% of the time spent by users waiting for pages to load is spent on the front-end.” He recently revisited this statistic and discovered that the same holds true today. The top ten websites are at 76%, but sites further down the list come in at around 90%.
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.
The KISS Principle
“Keep It Short & Simple” has long been a computer science mantra, but it is seldom implemented in real life. Web pages are so cluttered with pop-ups, images, animations, sounds, and functionality that users have trouble locating what they need on the page. Apart from the usability issue, there is a very real performace hit for all this excess baggage.
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.
Static vs. Dynamic
We all know that static pages download much faster than dynamic web pages, but we keep creating dynamic web pages because we think the users need up-to-the-minute, live data. In many cases, we are right.
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).
Responding to Performance Problems
Action Item #7: Running through a checklist of performance tips is not an appropriate response to a performance problem. Methodically follow these steps instead:
- Benchmark the current performance measurements.
- Determine the cause of the problem.
- Understand the cause of the problem.
- Identify options.
- Evaluate the options.
- Select an option.
- Implement the selected option.
- Benchmark the new performance measurements.
- Evaluate the effectiveness and start over if necessary.
Coding Habits
We all have our own coding style. Our style is the collection of the habits we picked up over the years. Some of those are good habits; some are not. A techie can become a guru and a guru can become a wizard by replacing the bad habits with something better.
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.]
Conclusion
There are many website performance tips hiding in the cloud. Some can make a huge difference; some will have no effect; and some will make the situation worse. The above performance perspectives help us wade through the myriad.
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.
Post Tagged with
