asp:review
BrowserHawk 10.0
Sophisticated Browser Detection and Logging
By Steven A. Smith
Browser and browser feature detection have been required in many Web applications since the early Netscape versus Internet Explorer days of the 1990s. While it is possible to use custom logic to detect USER_AGENT strings or the Browser object in ASP.NET, it is difficult to keep such techniques current with the latest versions of various browsers. Additionally, with such an approach, one cannot detect how a user s browser or system is actually configured, such as whether certain plug-ins are installed. For real-world applications that simply must work on a variety of browsers, BrowserHawk offers a solution to this problem.
As the developer of a large community Web site (http://ASPAlliance.com) and an advertising network that supports the .NET developer community (http://LakeQuincy.com), I have used BrowserHawk for many years. The latest version, 10.0, continues to offer the core functionality on which I ve come to rely, while adding some interesting new performance monitoring features. Specifically, BrowserHawk s new Page Load Time (PLT) feature offers a way to measure real user-experienced page load times. This information is critical for ensuring Web pages are loading quickly, especially because most users will not tolerate much of a delay before giving up and abandoning a site.
At the Core
BrowserHawk s core function is to detect the user s browser and system configuration. This provides Web developers with an easy way to optimize their site accordingly. BrowserHawk is capable of detecting more than one hundred browser and system settings, some of which are shown in Figure 1. Common uses of BrowserHawk include detecting the presence of a Flash player, detecting the user s connection speed, and detecting whether JavaScript is enabled. Using this information, a page could be written to deliver rich video via a Flash player to users with Flash and a broadband connection, while offering other users alternative content, such as static images or a link to download-required software.
Figure 1: BrowserHawk s Editor
allows browser definition data to be inspected and updated.
In addition to detecting browser settings within the context of a page request, BrowserHawk also offers logging capabilities that provide analytics not possible with traditional Web analytics software. A user ID or session ID can also be associated with this logged data. This is very useful for troubleshooting Web site errors reported by an end user, because support personnel can pull up a detailed profile of the user s browser and system configuration. This information makes it far easier to reproduce an issue.
For this review, I downloaded a copy of BrowserHawk 10.0 from cyScape s Web site and ran the installation executable. The wizard walked me through the set-up procedure, including setting up some Web services required for the (optional) reporting piece of the product. An evaluation key was e-mailed to me and is required as part of the set up (alternately I could request one via BrowserHawk s Web site). As part of the set up, I configured BrowserHawk to automatically retrieve updated browser definition files from BrowserHawk s Web site, ensuring my server would always have the latest settings. At the conclusion of the set up, I launched the installed samples on my local Web server; they ran as expected. One sample displays the most popular settings, as shown in Figure 2.
Figure 2: BrowserHawk shows the most
popular settings detected in one of their samples installed with the product.
In general, BrowserHawk s detection techniques happen almost instantly, without affecting perceived page load times. Some of the Extended Properties require interaction with the user s browser, and can have a noticeable effect on page load time, depending on which properties are being detected. The extensive documentation covers these considerations in detail. Typically, the user s settings are only detected once, after which they are cached, eliminating any delay imposed by the browser feature detection for subsequent requests from that user.
One thing that sets BrowserHawk apart from many other components with which I ve worked is the maturity of the product, as demonstrated by its stability. In the years that I ve been using the product, it has very rarely required any debugging on my part; when it has (in response to Microsoft updates to IIS or Windows, typically), the support from cyScape has been fast and effective.
Page Load Time Detection
Page Load Time (PLT) detection is the biggest new feature in the 10.0 release of BrowserHawk. It is remarkable because it enables logging of actual users load times, as opposed to simulating load times using load testing tools powered by bots. The benefits of this approach should be obvious: real data from real users over real networks, no need to set up and configure numerous bots to simulate user behavior, and the ability to correlate performance data with other user and site metrics. PLT currently supports IE 6+ and FireFox 1.0+, as well as other Gecko-based browsers released since February 2006. It automatically disables itself on unsupported browsers.
Setting up PLT involves adding a few lines of code to each page that you would like to track (or just to your master page or header user control or include file if you want to track many pages in your site). Once this is configured, the response time data is recorded in the configured database as pages are requested. This is achieved via a separate call from the client to a Web service configured for tracking this data, and because it occurs after the page has been loaded, it should be generally transparent to the end user. The actual data recorded depends on what you configure in the code you add to each page, but typically includes the latency, page load time, intra page load time, hittype , and the User ID or Session ID you assign, if desired. See http://www.cyscape.com/products/bhawk/page-load-time.aspx for more information.
Optionally, the captured statistics can be displayed on a page by specifying HTML elements with specified IDs, such as plt_latency. These will be updated with the measured data within the client page, without any additional calls to Web services or server resources. By turning this feature on for certain roles, or displaying these metrics in comments on every page, it can be very easy to check the actual load time for any given live page at run time.
Conclusion
BrowserHawk from cyScape is a very mature, robust, and feature-complete browser analysis tool. It is the leader in the marketplace and provides a simple, maintenance-free approach for detecting each user s browser and system configuration and ensuring your minimum system requirements for the site are met by each visitor. It also provides analytics and unique logging features to help organizations derive more value from their site. BrowserHawk integrates with a .NET-based Web site in just minutes, and is very straightforward to install and get started. A fully functional evaluation is available from the cyScape Web site.
Steven A. Smith (http://aspadvice.com/blogs/ssmith) is a Microsoft Regional Director, ASP.NET MVP, INETA Speaker, and ASPInsider. He has written two books on ASP.NET and runs one of the most popular .NET development communities, http://ASPAlliance.com. Steven and his wife Michelle run Lake Quincy Media, http://lakequincy.com, which manages sponsors and advertising on more than 60 .NET developer Web sites.
Rating:
Web Site: http://www.cyscape.com/products/bhawk/
Price: Starts at US$399
