# Detailed performance analysis 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. ## 1. Native stack analysis 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. ![](https://lh3.googleusercontent.com/Z7aE1TLEsa1lMs5wKt63yWEeeBKuqebeYt-hBVHrbn1doxOW9TmEeoTrcPsqvQ_UPFPmd3H9byubwv-4EDG8nDGIJSwHyle2FxjKHXGazCZrTBA6MrqLSy5Ci_bOK3k2nCKipFD-xZd9HRuiFe6uw_k) {% hint style="info" %} 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’](https://docs.imqa.io/imqa-guide/eng/user-guide/project-list#proguard-dsym-settings). {% endhint %} ### Device information list 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. ### User Behavior Analytics (Reverse Behavior Analytics) 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 - Overview 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. ### Reverse stack - Tree view ![](https://lh4.googleusercontent.com/4slb0-ytiDBC5FI7jN-YaS7Ttg_4rmvE8mC9Ke-EKtZ7nzrtB6_-fdy7dlYEmOxha_KLC-SMoSvB7n_tH4kcetTMVwvoLqvSl-UKljnIIdlwYXIKop487TLtQHRH8wMsDUuBY89WOjMQ1ZSeGNHCH4A) **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. ### Reverse stack - Sunburst view 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. ![](https://lh5.googleusercontent.com/6UNWKivAhbhDzEQyVJ8frrzgaVM7GqFUqeS8ECpa6gDpjffh71iiawfjtPzjeFh08Dt2xYZ9Rjj0oxoQJTJxJO3194czTovAkziuVb8OiKP4wDSku_AyaxCLMWF4rzvjbTyet6e5Lzxo1EVRNyHsyYw) 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. {% hint style="info" %} Only the information of the OS version that supports the collection of the data is collected for the OS area. {% endhint %} {% hint style="info" %} 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. {% endhint %} ## ## 2. Web resource analysis ![](https://lh5.googleusercontent.com/Mh_CSHVlQZasGu8lnmdkvnpRturZR3fVmsnjg3s7ySZbiMpcadwAnzvJL8V732wiAOT7pKJx4gZcTCz0HJGh5SBRCz9w7MQ3aZuV5iE0GV0dardEWzHKr8wLLkL_gKJGgu8CPFTZNXPmgLpQCaBOb1g) 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. ### Device information list 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. ### User Behavior Analytics (Reverse Behavior Analytics) 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.
### Summary information 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. ![](https://lh5.googleusercontent.com/_HJarboUgxqiyle6ZakIqCqXSQW8yrNUPUftQWJ_uiUvS6j-m1Lt_zhlbdfJkJ24KjXPNPf1w4wFg47HKYS4mKUaRWGB-GBVjF5NC0opksECY1ePyiSHiyC50pNm32H6-GshDitg9HQZKJwO5xbyW4o) ### Timeline ![](https://lh5.googleusercontent.com/AnrdsOrKlkAsoWBspGBgnWtrPFmebJpbRFfyi947mGRXRqb00q4qxPSsa6AiIKhtn242cVRfOOITAlCt-SztoXivaCigENPCeTMQu6PsOavYTvECzPULckQWy0r3BuTHdYCxlys3lsZn1pBnfBH2mwU) 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.
IndexLabelDescription
◻︎WaitWaiting time to request
◼︎NetworkNetwork search and movement time
◼︎ServerServer processing time
◼︎DOMDOM parsing time
◼︎LoadingPainted loading time
◼︎Content downloadFile download time
![](https://lh6.googleusercontent.com/_zmKj46vc909lJ-iWZe40D-q6t5hgUI3VDHVEynly1R8JKuny4ZAmoTuaPPEVxRmRnpvawTb-6RA5bcNEHfpC13kFmSNGq6ZjN1iCbuFFPm3tcG5rH68Uv9YtvzaE_teiy3Nod0LNKYfUuAp3kHQUww) 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.
IndexLabelDescription
◻︎WaitingTime to wait before request
︎◼︎RedirectTime to redirect HTTP
◼︎FetchTime to wait or look up cache before request
◼︎DomainLookupTime to search DNS for IPs corresponding to the domain
◼︎ConnectTime to connect to a server
◼︎Request sentTime to request resources to the server
◼︎ResponseTime taken until the server responds
The following timing information is collected: You can check this with the marker displayed on the timeline.
IndexLabelDescription
⬇︎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.
## 3. Detailed response analysis / Component Loading Analysis 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. ![](https://lh3.googleusercontent.com/yfJpbh-v1qnaw03xlCcdK_FtJ5fRUzwiUBIkClSdB6bO9tcJG_cDkeX0DYO08Mtkn-OJa2Y3e1kFxlx3-xeAkX77R1N1LjMDyo50XrBNgM5KL_kU2hcRg71ZDiJwNqe_mXPF9CfpM-moCj8kWuMY4Ec) The following HTTP related information is collected from the client:
LabelDescription
MethodHTTP Method (GET, POST, UPDATE, PUT, DELETE, etc.)
HostDomain information
StatusHTTP response code
PathRequest URL
Response timeResponse time to the HTTP request
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.imqa.io/imqa-guide/eng/user-guide/using-mpm/performance-analysis.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.