Detailed performance analysis
* Paid plan only
Last updated
* Paid plan only
Last updated
The IMQA MPM detailed performance analysis can be checked on the performance heat map of the “Screen performance analysis” - “Statistics” page. The page is displayed if you click a desired cell in the performance heat map or select a section by dragging the mouse. You can analyze native stacks, web resources, and detailed responses in the detailed performance analysis page. Based on such analysis, you can identify performance issues and problems or problematic sectors.
You can also use the User Behavior Analytics to see the full behavioral flow of users on your app where performance issues are found.
Native stack analysis collects call stack information within the application on a regular basis and provides call stack information summary using the heat map in question. For example, if you check the call stack information at the time the screen is rendered, functions like GUI-related functions and image libraries appear as call stacks. Using this function, you can check which functions degrade performance, by identifying the screen that takes long to render or the stack information at the time of high CPU or memory usage.
If each version's mapping file is decrypted through ProGuard settings / dSYM settings, the actual source file and location are displayed accurately. For ProGuard settings / dSYM settings, refer to ‘Using MPM > Project list > Project management > ProGuard / dSYM settings’.
The list shows the device information of the area selected from the performance heat map in the “Screen performance analysis” - “Statistics” page. This page shows various information in the form of a list, including screen, app version, OS version, device, carrier, location, screen response time, and user count. When you open the detailed analysis page, the device information at the top is shown on “Reverse Stack” below. To check other stack information, select other device information. UI rendering time shows the performance data of the sector selected in the “Screen performance analysis” - “Statistics” page.
You can track a user on the selected device in the Device Information List in association with the flow of how the user interacted with your app. You can access the performance information of devices that have experienced performance degradation and identify the route cause before and after the degradation. Click [User Behavior Analytics] to track a screen flow from the session start to session end of the user on the specific device through the “Behavior Analytics” page.
Reverse stack shows the detailed stack information in the form of a reverse stack by summarizing the call stack information of the device information selected from the list for one minute.
Tree View shows detailed call stack information in tree form. The number in (parentheses) shows the percentage (%) of the called function. Functions are enumerated from the last called function in top-down design.
You can estimate the function that is most likely to cause a problem in the tree view, and check the extent to which the problem actually affects the app by reviewing other related functions.
The sunburst graph combines the call stack of all threads and enables you to identify the function that uses the most stack during execution at a glance. If you hover the mouse over the graph, the corresponding function is displayed at the bottom.
You can check how the app was operated during execution using the location where the function was called, the number of functions found, and other function information. Based on this, you can analyze the cause of the performance problem.
❶ All Displays the call stack information for all threads. Mostly, it is used to check the overall function usage.
❷ Activity call Displays information other than the functions indicated as standby (loop or call waiting functions). You can identify the functions that have an actual impact after removing the information with less influence, using active call information.
❸ All threads You can check the entire thread information regardless of UI or non-UI.
❹ UI thread You can analyze the information on the function related to the UI only.
❺ Non-UI thread You can check the information excluding the UI, and identify the function that uses resources in the background.
❻ Resource usage The CPU, memory usage, and network area that are provided with the sunburst graph indicate the average usage of the device during the selected period, and are divided into the OS area and app area.
Only the information of the OS version that supports the collection of the data is collected for the OS area.
In the case of Android, the memory usage value can be different from the information displayed by Android Studio, as only JVM usage is collected.
Data is collected until the point the HTML page triggers the onload event. Here shows the time required to request a resource such as CSS, JavaScript, and image, as well as timing information such as FMP, FCP, and DCL.
Therefore, users can check the external requests that were made until the web page is loaded, and accurately decide a bottleneck sector when loading a page.
The list shows the device information of the area selected from the performance heat map in the “Screen performance analysis” - “Statistics” page. This page shows various information in the form of a list, including screen, app version, OS version, device, carrier, location, UI rendering time, and user count. When you open the detailed analysis page, the device information at the top is shown on “Timeline” below. To check other timeline information, select other device information.
You can track a user on the selected device in the Device Information List in association with the flow of how the user interacted with your app. You can access the performance information of devices that have experienced performance degradation and identify the route cause before and after the degradation. Click [User Behavior Analytics] to track a screen flow from the session start to session end of the user on the specific device through the “Behavior Analytics” page.
Shows the summary of the average page load time and server/network/DOM/loading time. It also shows the summary of device performance information at that time.
Here is what you can see as the full DOM of the document is drawn and loaded. You can view this from the tooltip that appears when you hover over the document request element.
◻︎
Wait
Waiting time to request
◼︎
Network
Network search and movement time
◼︎
Server
Server processing time
◼︎
DOM
DOM parsing time
◼︎
Loading
Painted loading time
◼︎
Content download
File download time
The information available for each resource is as follows. You can check with the tooltip that appears when you hover the mouse pointer over each resource timeline.
◻︎
Waiting
Time to wait before request
︎◼︎
Redirect
Time to redirect HTTP
◼︎
Fetch
Time to wait or look up cache before request
◼︎
DomainLookup
Time to search DNS for IPs corresponding to the domain
◼︎
Connect
Time to connect to a server
◼︎
Request sent
Time to request resources to the server
◼︎
Response
Time taken until the server responds
The following timing information is collected: You can check this with the marker displayed on the timeline.
⬇︎
First-Paint (FP)
FP is the time when the browser renders the first pixels to the screen, rendering anything that is visually different from what was on the screen prior to navigation.
⬇︎
First-Contentful-Paint (FCP)
FCP is the time when the browser renders the first bit of the DOM contents (e.g., text, image, SVG, or element).
⬇︎
First-Meaningful-Paint (FMP)
FMP is the time it takes for a page's primary content to appear on the screen, such as a font application. The measurement standard is different for each browser.
⬇︎
Dom-Content-Loaded (DCL)
The DCL event fires when the initial HTML document has been completely loaded and parsed, without waiting for style sheets, images, and subframes to finish loading.
IMQA MPM collects HTTP response time and response code. You can analyze the HTTP request from the client. The HTTP information is collected from the device in ms (milliseconds). IMQA MPM displays HTTP header information and response codes. You can analyze the response time of a specific URL and check the URL that generates an error code using this information.
IMQA MPM is collecting loading times for components in the React Native structures. When rendering UI using native UI components in React Native, separate analysis is available for a parent component rendered first and the child components imported to and used by the parent component.
The following HTTP related information is collected from the client:
Method
HTTP Method (GET, POST, UPDATE, PUT, DELETE, etc.)
Host
Domain information
Status
HTTP response code
Path
Request URL
Response time
Response time to the HTTP request
