Performance provides you a deeper understanding of your applications' performance (Android, web, and iOS) and lets you optimize them. The Performance feature collects data from your application and then Countly visualizes this data so that you can review, analyze, and find performance issues within your application and fix them for a better user experience.

Benefits of Performance

Performance is used for monitoring and tracking how web or mobile applications perform from a network and device perspective, helping you identify possible factors that may influence negatively in the user experience. If your application underperforms in the eyes of the user, then you need to action as soon as possible to correct any issues.

Performance lets you track recent issues, the percentage of requests affected, and identify common patterns in certain networks that lead to latency issues.

In general, the performance of networks is measured by the HTTP/HTTPs requests made by your application, while devices are measured by rendering performance. But you can add custom traces to track via your SDKs.

You can further dive into metrics for each of your traces to see individual outliers such as response/load times, success rates, and payload sizes. You can also go deeper into each metric by applying filters and looking into individual samples.

Getting Started

First, you need to integrate the Performance feature into your mobile or web application. Then, you can start capturing the performance data points and see them in Countly immediately.

Note that some data points are captured automatically depending on the SDK you are using.

Data points captured by the SDK are grouped and recorded as a trace by Countly.

Then, make sure Performance Monitoring is enabled. To do so, in Countly, go to Management > Feature Management and enable the Performance Monitoring toggle.

Performance Overview

In the Performance view, you will see three tabs:

1. Overview (opened by default when accessing Performance)
2. Device
3. Network 

Overview Tab

In this tab, you get two kinds of information: Recent Issues and overall Performance Metrics information.

Recent Issues

Performance automatically identifies possible issues in your application for all the device's duration traces and network traces. A trace is marked as an "issue" if it exceeds the threshold value for the trace over the last 30-day period. The default threshold value for all traces is 2 seconds. The metrics used to identify an issue are response time for network traces and duration for device traces.

Recent Issues displays up to 3 issues sorted in descending order by the percentage of affected values. You can access a complete list of issues by clicking on the See All Issues button. 

You can click on each issue to see its detailed view. Additionally, each issue has a 3-dot ellipsis menu on the right with the following options:

• Mute issue: Once you mute the issue, it will no longer appear in the Performance Overview, but you can still access it with See All Issues.
• Edit threshold: You can edit the threshold value for the issue or trace.
• Re-open issue: When you have muted an issue and you are in the All Issues list, use this option to reopen the muted issue, and it will again appear in the Overview tab.

Performance Metrics

The Performance Metrics panel in the Overview tab displays the following information from your app:

1. Top slow rendering screens (only for mobile apps): This chart displays the top slow rendering screens of the application.
2. App start trace (only for mobile apps): This chart displays the aggregate application start density distribution for the selected time period.
3. Network response latency: This chart displays the median response time value for all HTTP/S requests aggregated by country and grouped into three, color-coded categories: Below 2 seconds, Between 2 - 6 seconds, and Above 6 seconds.
4. Network success rate: This chart displays the network success rate over time for all HTTP/S requests combined together.
5. Top slow networks: This chart displays the top slow network traces of the application.

Device Tab

Device traces are stored and tracked in this tab. A device trace is a group of trace samples that reports metrics related to the application's performance on the device. Depending on the application type (mobile or web), different traces will be recorded by the SDK with different resulting metrics.

Traces Collected by a Mobile SDK

The Performance feature for mobile devices (iOS and Android) captures two types of device traces: Duration Traces and Screen Traces. Mobile SDKs have a few reserved trace sample names that are captured automatically by the SDK which are: app_start, app_in_background, app_in_foreground.

Duration Traces

The recorded metric for these traces should be duration. The automatic duration traces captured by the Countly mobile SDKs are:

1. App start: Measures the time taken by the app to become responsive after it is opened.
2. App in background: Measures the time when the app is running in the background.
3. App in foreground: Measures the time when the app is running in the foreground.

Screen Traces

Screen traces span the lifetime of a screen and measure slow and frozen frames. The recorded metrics for these traces should be Slow Rendering Frames (slow_rendering_frames) and Frozen Frames (frozen_frames).

Traces Collected by a Web SDK

The Countly Web SDK uses Boomerang.js, an end-user-oriented web performance testing library, to send traces to the Countly Server. It can collect performance timings, metrics, and characteristics of your user's web browsing experience. The Performance feature for web captures two types of device traces: Duration Traces and Page Load Traces.

Duration Traces

The recorded metric for these traces should be duration. All custom traces for web apps are grouped into duration traces, which is shown when you click on each trace name of the list:

Page Load Traces

The Performance feature captures page load traces automatically for your application and shows them on Countly, which is shown when you click on each trace name of the list.

Recorded metrics for the page load traces are as follows:

1. First paint: Time elapsed between when the user navigates to a page and when any visual change happens. The reserved metric name for this is first_paint.
2. First contentful paint: Time elapsed between when the user navigates to a page and when meaningful content displays, like text or image. The reserved metric name for this is first_contentful_paint.
3. DOM interactive: Time elapsed between when the user navigates to a page and when the page is considered interactive for the user.  The reserved metric name for this is dom_interactive.
4. DOM content loaded event end: Time elapsed between when the user navigates to a page and when the initial HTML document is completely loaded and parsed. The reserved metric name for this is dom_content_loaded_event_end.
5. Load event end: Time elapsed between when the user navigates to a page and when the current document's load event completes. The reserved metric name for this is load_event_end.
6. First input delay: Time elapsed between the user interacting with a page and when the browser is able to respond to that input. The reserved metric name for this is first_input_delay.

Network Tab

This tab records network traces. A network trace is a group of trace samples that reports metrics for the HTTP/S requests issued by your application to the API endpoint. For each endpoint request your application makes, Performance records the following metrics:

1. Response time: Time elapsed between when the request is made and when the response is received. The reserved metric name for this is response_time.
2. Request payload size: Byte size of the request made by the application. The reserved metric name for this is request_payload_size.
3. Response payload size: Byte size of the response downloaded by the application. The reserved metric name for this is response_payload_size.
4. Success rate: Percentage of successful response codes (2xx - 3xx) compared to total responses. The reserved metric name for this is response_code.

Custom Traces

You can create custom traces in your mobile or web application to monitor the performance of specific code in your app. The default metric for all custom traces should always be duration, therefore each custom trace sample should have a duration metric in it, and you can also add your own custom metric using the SDK methods.

Detailed Metric Information

If you navigate deeper into Performance by clicking on any network trace or device trace, you will see a detailed metric view for each metric for that particular trace.

Here you can review each metric, for the selected time period, over time, and an aggregated density distribution. You can also break down the collected data points for the metric using Drill and view detailed information for the metric in the attributes table categorized into Device, Country, City, Region, Platform, Platform Version, App Version, Carrier, Browser, and Browser Version.

Detailed Sample Information

Countly can also provide detailed trace sample information. A trace sample in Countly is a single data point captured by the SDK and recorded in Countly.

From the Detailed Metric View you can navigate further to the Samples view, where you can deep-dive into more granular information for the metric. 

The Samples view provides the aforementioned attributes information for each data point which can be further segmented using Drill (by enabling the toggle and using the filter on the top of the page). This page provides very valuable information if you want to see per-device or per-browser details.