This topic describes the scenarios in which you can implement browser monitoring.

When end users access your website, the whole process can be divided into three phases: page production phase (server-side status), page loading phase, and page running phase. To ensure stable online services, the server monitors the status of these services before an application is published. You may have a full-fledged server-side monitoring system but the monitoring of the page load and run statuses is still unsatisfactory. This is because less emphasis is placed on browser monitoring. Monitoring on the server side is mistakenly regarded as a replacement of browser monitoring. As a result, the details of users who access the system cannot be perceived. Therefore, frontend issues encountered by users are difficult to locate.

Challenges

  • Difficulty in locating performance bottlenecks

    If the loading speed of a page is slow, the performance bottleneck is difficult to identify. The slow page loading speed may be caused by network issues, resource loading issues, or Document Object Model (DOM) parsing issues. The issues may be related to the province and country where the user resides, or the browser and device of the user. These issues cannot be reproduced and the causes cannot be identified.

  • Failure to obtain the details of failed user access requests

    If a large number of JavaScript (JS) errors occur after a system goes online, users cannot use the system as expected. If you cannot obtain the error details at the earliest opportunity, you may lose a large number of users. When a user gives feedback on page usage, you may not be able to immediately reproduce the scenario of the user. Even if you obtain an error message from a user, you may not be able to quickly fix the error. These are difficulties that you may encounter.

  • Failure to obtain the details of asynchronous API calls

    Even if the HTTP status code 200 is returned from an API call, the API may be abnormal. If a business logic exception occurs, you may not be able to identify the exception at the earliest opportunity. If normal responses are returned for all API calls, but the whole process consumes a long time, you may not be able to get the whole picture and reduce the response time. To improve user experience, you must resolve these issues.

ARMS-based browser monitoring solution

Application Real-time Monitoring Service (ARMS) provides the browser monitoring feature based on the capabilities to analyze and process large volumes of real-time logs. You can use the browser monitoring feature to monitor the access requests from all end users and resolve the preceding issues.

  • Check the application overview page to identify exceptions

    You can view the following information on the application overview page: the number of JS errors, JS error rate, number of API errors, API success rate, page views (PVs), and unique visitors (UVs).

    Application overview
  • Performance data trend and waterfall chart

    On the Page Speed page, you can view specific metrics related to the page performance and the waterfall chart of page loading. You can then locate the performance bottleneck based on the detailed data.

    Page Speed
  • JS error rate and frequent errors

    On the JS Error Diagnosis page, you can view a ranking on page error rate and a ranking on frequent errors. Therefore, you can get a straightforward impression about which pages have the highest JS error rate, and which errors are the most frequent.

     JS Error Diagnosis
  • API requests

    On the API Request page, you can view the success rate and response time of API requests. This allows you to obtain the details of API requests.

     API requests
  • Access logs

    On the View Details page, you can view multiple types of access logs.

    Access logs