Differences between Monitoring via HTTP(S) and via BrowserView/UserView

In short, the UserView and BrowserView platforms load web pages in real browsers and execute all page components.  Monitoring via HTTP(S) uses emulated, synthetic browsers, and only downloading page elements that are requested without rendering.

HTTP(S) monitoring devices utilize HTTP/S requests between a custom synthetic browser and the server to conduct monitoring. While HTTP(S) devices can also be recorded and replayed for monitoring applications, it is specifically useful when monitoring the server performance associated with a web application. Also, HTTP(S) tasks support dynamic variables, cookies, and secure sites. HTTP(S) tasks use a custom process (not a regular browser) to replay the recorded steps, so it is not recommended for websites that heavily use Rich Internet Applications (RIAs), such as JavaScript or AJAX. Since web content might not be embedded into HTTP(S) response (in the case of running AJAX), the HTTP(S) device may trigger a false alert on content validation.

On the other hand, monitoring devices created from the BrowserView and UserView platforms utilize a regular browser to open a web page and replay the task. Therefore, both of them provide content validation in a real browser window, so you can visually check the presence of relevant content. In addition, UserView replays a multi-step path through an application, such as a shopping cart or log-in submission. UserView monitoring is capable of emulating actual browser events during monitoring, such as mouse clicks, text typing, and hovers. These events are executed in a browser window (see image above.). The regular browser aspect of UserView monitoring can be coupled with a virtual keyboard/mouse “picture match” technology, which enables monitoring of very complex web applications running RIAs, including Silverlight, AJAX, Flex, Flash, JavaScript, applets, add-ons, as well as other web page objects that interact dynamically with a browser. Additionally, UserView is able to record a video capture of the page interaction as issues are detected.

How to make a choice

One way to check which type of monitoring is most appropriate is to decide if you want to make sure a web page is available for an end user or to check if its content is rendered properly.

If the URL availability is under question, select HTTP(S) monitoring.

If the content verification matters, select a device from BrowserView or UserView platforms. To make a choice between BrowserView and UserView platforms, simply test the page that you want to monitor. If the page contains JavaScript, which may manipulate the content or load it additionally from your or third-party servers, then opt for a Multiple Step Journey monitoring type from the UserView platform.

Due to these differences in HTTP(S) monitoring and devices provided by BrowserView and UserView platforms, there is also a difference in the response time measured by each device type.

See below for an example of the differences:

The website http://daniel.lorch.cc/docs/ajax_simple/ajax-cool.html? has an edit field. If the number “1” is entered into the edit field, the JavaScript will make a request to http://daniel.lorch.cc/docs/ajax_simple/validate.php, which should return a “Username too short” string and display it as HTML.

Because a UserView (Multiple Step Journey) monitoring script emulates the action of a real browser it will perform the following steps: load the page, find the edit field, and input “1”; the final action is a keyword validation that the “Username too short” string is displayed in the HTML:

HTTP(S) monitoring performs this task differently.  It emulates low level HTTP(S) requests. For example, if the previous UserView monitoring example is converted to a HTTP(S) monitoring process, the monitoring is conducted as two HTTP tasks with GET requests: