This topic describes a monitoring case regarding user experience.

When a user accesses a service, the whole process can be divided into three phases: page production time (server status), page load time, and page run time. To ensure stable online services, the running status of services is monitored on the server. The existing server monitoring system is quite mature, but the monitoring of the page load time and run time status is far from satisfactory. This is because less emphasis is placed on browser monitoring, due to the mistaken belief that monitoring on the server can partially replace browser monitoring. In this case, the system access details cannot be perceived when the system is running online and a user accesses the system. Therefore, it is extremely difficult to identify a front-end problem that online users occasionally encounter.

Business pain points

  • Difficulty in locating performance bottlenecks

    When a user gives feedback that a page loads slowly, it is difficult to quickly find out where the bottleneck is. Is the slow loading of the page caused by a faulty network, resource loading problem, or page Document Object Model (DOM) parsing problem? Is it about the province and country where the user is located, or the user’s browser and terminal? These problems cannot recur quickly to allow locating detailed reasons.

  • Inability to get error details for user access

    After a system goes live, too many JavaScript (JS) errors will prevent the users from using the service normally. If the error details for user access cannot be obtained promptly, are we at risk of losing many users? If a user gives feedback about page usage details, can we recur the use case in the shortest period? Can we retrieve the error details and quickly fix the issue? This gives you a glimpse of the difficulties developers may have.

  • Inability to get asynchronous API call details

    Even if the HTTP status code returned from API calling is 200 every time, it does not necessarily mean that the API is completely normal. If the business logic is abnormal, can it be perceived in time? If all the HTTP status codes returned from API calling are normal, but the whole process consumes a long time, how can we get the whole picture and optimize it? With this kind of information unknown, we cannot identify the issues, and therefore cannot improve user experience.

ARMS-based browser monitoring solution

Based on the massive real-time log analysis and processing services provided by Application Real-Time Monitoring Service (ARMS), the browser monitoring function monitors the access conditions of all real online users and solves the preceding problems.

  • Application overview for identifying exceptions

    You can view the information on the application overview page by using the ARMS browser monitoring function, including application satisfaction rating, JS error rate, page speed, API request success rate, and page view (PV) details. In the following example, the average JS error rate is 6.68%, up 15.56% from last week.

    Browser monitoring overview
  • Performance data trend and waterfall chart

    On the Page Speed page, you can view detailed metrics related to the page performance and the page loading waterfall chart. Then, you can locate the performance bottleneck according to detailed data.

    Performance data trend and waterfall chart
  • JS error rate and error aggregation

    On the JS Error Rate page, you can view a ranking on error rates in descending order and a ranking on error aggregation. Therefore, you can get a straightforward impression about which pages have the highest JS error rate, and which errors are the most common.

    JS error rate and error aggregation
  • API request

    On the API Request page, you can view data on API call success rates and time consumption, understanding every detail of the APIs.

    API request
  • Access details

    On the View Details page, you can view the access details. For example, you can locate an error according to the error information, including stack, file, line, and column.

    Access details