Web Technology Performance and Business: Making the Cut

Mitchel Sellers, CEO and Director of Development, IowaComputerGurus, Inc.
212
339
62

Regardless of industry verticals, organizational size, or many other segmenting factors there is one technology concern that is common for all businesses-the performance of business web properties. As technology continues to evolve, our customers and end-users desire more direct feedback and timely responses. Providing online account management, or 24 X 7 supports is no longer an optional service, but a standard business requirement. Technology evolution does not just impact end-users; Search Engines have also seen massive improvements over the past few years that impact what is important to businesses with a web presence. We are beyond the days where Search Engines only look at the words rendered to a page, crawlers look at site structure, standards compliance, page load time, and other performance factors. If you have great content, but poor performance, you can see substantial losses in search originated traffic.

“As technology continues to evolve, our customers/end-users are desiring more direct feedback and timely responses”

Understanding all of this, for those driving an organizations long-term application direction what truly defines a performance optimized application? If you ask the business stakeholders you will get various answers, most of which are highly subjective and hard to quantify. Commonly when I work with customers we will receive responses such as- “It must be fast”, “It must handle our 14,000 concurrent users,” or “It must take less than 3 seconds.” At first glance this seems to be somewhat easy to quantify, however, lets investigate a few common metrics used to analyze and report on page performance.

Common Page Performance Metrics

Having worked with organizations large-and-small I have found that a key to understanding performance is to first understand the metrics that can be used to gauge performance. Once these metrics are understood it is then possible to create a plan to make the best improvements overall.

Average Page Load Time (HTML Only)

This is a metric commonly reported from load testing tools, or by using a utility to request a single page. This number is only focused on loading the HTML that is used to serve the content, rather than the entire response necessary to display content to the users. (Images, CSS, Javascript) Typically the results for this metric will be lower than any other metric reported as it is not a truly realistic value for the users.

Using CIOReview.com as an example I was able to confirm an average HTML only load time of 445 milliseconds.

Average Page Load Time (Full Request)

Taking the HTML only metric and looking at a more realistic value we start to see the Average Page Load Time metric coming together. If you pull up the CIOReview.com website in a web-browser it will NOT appear to load in 445 milliseconds, and that is exactly what this metric is designed to show. To properly calculate load time you need to ensure that all resources are loaded and the browser has been able to fully render the screen.

Revisiting the CIOReview.com homepage we can see a total page load time average of 7.2 seconds. This is the total time to retrieve the page, render in the browser and for all page processing to stop.

Number of HTTP Requests

Directly related to the two prior metrics it is common to report the total number of HTTP Requests needed to complete the rendering of a page. Web browsers can only download a certain amount of items at the same time, therefore a high number of requests results in longer page load times. There is no magic number that is acceptable here, but the more you have, the longer it will take for the entire site to render. It is common to use tools to combine/minify resources to optimize.

To provide a few examples, CIOReview.com requires slightly more than 223 HTTP Requests to render the homepage. Microsoft.com requires less than 80.

Requests/Second or Concurrent Users

The prior referenced metrics illustrate the time necessary to load a single resource, or a single page. As organizations look to optimize for higher traffic loads we will often see metrics reporting either Requests Per Second or the number of current users supported. Both metrics show similar information as it is easy to translate one metric into the other.

Which Metrics to Select and What Target Values?

With a little bit of background into the various metrics, which of these are truly important to your organization? The real answer here will be dictated by your specific organizational needs, but there are a few common rules of thumb.

For Search Engine Performance

Google has a published tool called “Page Speed Insights,” which allows you to analyze the performance of your website against a set of rules they have published. This tool starts to reduce points if any page load request exceeds 200 milliseconds, which gives a good target to aim for.

For User Experience

Various studies have been completed over the past decade, and a common consensus between these studies is that total page load times of greater than 2 seconds result in loss of user attention. There are exceptions to this rule, however, again it is a starting point. Login pages, or complex trigger starting points are cases where longer page load times are acceptable.

Elevating Your Organization

With a better understanding of the metrics that could benefit your organization progress becomes easy to manage and quantify. Baseline and regular performance reviews of web properties, both complex and simple, will ensure that the best presentation is made to your customers. It is important to understand that at the top level performance needs to be embraced as a long term feature and not simply a “one time” project.

Ensuring that users can obtain the information they want, when they want, is the key to any successful organization.

Read Also

Private Virtual Cloud

Tom Youngblom, Director-IT, Associated Milk Producers

Lifecycle Services Solutions Make the Most Out of the New Dynamics AX

Robbie Morrison, VP - Enterprise Group, SBS Group

Driving a Context-Aware Clinical Desktop Experience

Rebecca Kaul, Chief Innovation Officer, University of Pittsburgh Medical Center (UPMC)