Vanilla
Hello everyone, welcome to Pcloudy webinar on banking app performance audit. key metrics to test, track, and fix issues before users notice. So, my name is Vanilla and I'll be the host for today. before we get started, here are a few housekeeping rules. you may have noticed that your line is currently muted and if you have any questions or clarifications, you can use the Q&A option available and we will answer the questions as part of the Q&A session at the end of the webinar.
Vanilla
Also, please note that this webinar is being recorded and we will send the link of the recording to watch again or share with your colleagues later. With that said, let me introduce the speaker for today, Jessica Selvin. Jessica is a lead solution engineer at Pcloudy and she has around 5 plus years of experience in the IT industry. Prior to her role at Pcloudy, she has worked with LTIMindtree as a pre-sales consultant in automation solution design for various industries. She has a keen expertise in data analytics, ML, and various AI tools.
Vanilla
Without further ado, let me hand it to the speaker, Jessica. Over to you.
Jessica Selvin
Thank you, Vanilla, and for that introduction and hello everyone. really excited to present this topic on the banking app performance audit, all right? And yeah, so let's get started. So, firstly, I mean, we divided it into some sections here, logical sections. And the first one we'll be looking into it is what are the hidden cost of banking app performance failures. So, both as a user and as a QA, you might have your own experience with this. for example, when you were doing your own, online or mobile banking, the hurdles that you face or any trust issues that come up in your application, right? So, that's what is the core here is that what we'd be discussing, right? So, the performance failures that kill trust. So, banking users and if you've noticed even when you are using your mobile banking app, you will have very little tolerance for slow or unreliable applications. So, because they're accessing services that involve payments, money, sensitive information. All right, the tolerance for errors is very low. All right, and the first stat that you see here is that 63% of users abandon a banking app if it takes more than 3 seconds to load. All right, so if they see any laggy screens, all right, so they don't just see it as a technical issue. They it directly has an impact on the trust, right? And one in three users would switch to a competitor just because of a bad app experience, right? So, user experience has a direct business cost.
Jessica Selvin
And finally, users are 4.7 times more likely to leave a one-star review after just one app crash or finding out that there was an error in a feature. So, this tells us that users are generally more for I mean, less forgiving of these kind of functionality gaps or stability issues, right? And a crash directly impacts confidence in the application's reliability and security. So, that's the key takeaway here, right?
Jessica Selvin
That performance and stability are not just technical metrics. They are business-critical factors that we need to take into consideration and it has a direct influence on your customer retention, bad reputation, and revenue. And that's why like a proactive approach to performance testing and continuous monitoring are essential to delivering a trustworthy banking experience. So, what are the key aspects that you'll be taking away, with this session, right? So, what are the firstly, what are the performance metrics that actually matter? What are the signals that you should be looking for, with the 60 plus signals that you can have with CPU, memory, UI, UX related metrics, your network, battery, and your other app related metrics like your launch times and so on, right? And then secondly, why trust and security are inseparable in banking apps, right? And how, your performance failures would have an impact on both.
Jessica Selvin
Thirdly, we'll also discuss why emulators don't reflect real-world scenarios as well as real-world user experiences, and why real device testing is essential, particularly when it comes to performance-related metrics. And fourthly, we look at a practical framework for, auditing your app performance before every release. And we'll see how AI-powered root cause analysis and visualizations and reporting can help teams find and fix these issues that would typically take days, but within minutes, right? And you'll have a clear understanding of how to measure, validate, and improve your mobile app experience with confidence.
Jessica Selvin
Right? And we'll also have a live demo of our own Pcloudy's app performance module. So, coming to the section two, where we'll be looking into what are these actual metrics that we're talking about across these different domains of CPU, memory, your UI, network, and so on, right? So, let's have a quick look into each of these and what would be their impact, right? So, one of the biggest mistakes teams make is treating performance as a single metric, right? So, in reality, mobile app performance is a combination of multiple categories, and weakness in just one area can impact your user experience. So, for example, with banking applications, monitoring only response times or launch times isn't enough. So, we would need visibility across six key categories covering more than 60 plus performance metrics.
Jessica Selvin
So, first is the CPU and processing. So, here tracking things like your CPU usage, thread count, frequency, right, your system as well as your app CPU, right, and what could be the impact of that. So, high CPU usage can directly lead to slow screens or lagging interactions and excessive battery drain. All right. Secondly, memory, right, so monitoring your heap usage, memory leaks, right, your Java native code heap, your GPU, all right, all of these, tracking it from the perspective of memory, and having a quick feedback loop with your developers to check if there are any memory leaks, right, all these can directly, I mean, having issues in this area can directly degrade your performance and eventually cause crashes. Thirdly, we have the UI and user experience. So, here is where users This is something that the users would be able to notice, right? So, metrics such as your frame rate, FPS, stability, render time, app not responding issues, right, so all of these would come under the UI/UX layer. And fourthly, we have the network layer, which is very important, particularly in banking apps, which are highly dependent on APIs. So, monitoring latencies, payload sizes, what are the retries or repeated API calls, right, and what is the output and failures, slow loads of any of these APIs would have a direct impact on the user experience. All right, so even a well-built application can feel slow if your APIs or your network performance isn't optimized. And fifthly, we have the battery consumption. So, this is something that again has a direct user impact, right? Users would quickly lose trust in apps that drain the battery, right? And tracking power usage, background activity, and other utilizations to ensure that your app is remaining efficient is also important.
Jessica Selvin
And finally, the application life cycle, right? So, this includes your cold and warm startup times, crash rates, ANRs, and how quickly the app moves between your background to the foreground. All these again have an impact on the user experience. So, looking at all of these as a complete health check across six categories, right? For banking apps excellence, would be one when you take into consideration all these six categories and to deliver truly reliable user experience, all right? And let's just take a practical scenario about how in banking trust has no margin for error, right? and you cannot afford to have a weak link. So, one bad category would break trust even if the other five are perfect. Right? So, for example, if you think about a user doing a transaction of a huge sum, right? And the login is smooth and the balance loads instantly, but when they tap transfer, if their app freezes for a few seconds, the user doesn't really think about whether it could have been a CPU issue or some other background activity. They simply think, "Can I trust this app with my money?" Right? So, it directly translates into a user impact. And so, even one lagging screen at a critical flow or scenario could immediately break trust. Right? So, that's why trust is more cumulative and it's more fragile. Right? And every smooth transaction also inversely builds confidence. Right? And one lag or timeout can erase it instantly. So, users don't experience these metrics that we're talking about.
Jessica Selvin
They experience it as trust and performance testing is what would really protect it. And also, yeah, all this must be aligned with a security first framework as well. In Pcloudy, we are certified in all these different types of certifications, ISO 27001, SOC 2 type 2, and GDPR. Right? So, performance testing must be as secure as the application itself. So, that's why, we need to ensure that while we are evaluating for performance metrics, that we are also being compliant. So, it works hand in hand, particularly in the BFSI sector. So, you cannot trade compliance for speed and performance testing must happen within a security first environment.
Jessica Selvin
Thirdly and importantly, we would look into why emulators cannot really replicate these scenarios and real devices would be the only scenario where you can get the true metrics. All right? Where you can have real network conditions, real infra. Right? And that's the only real way to measure your performance metrics. So, let's just look at and talk about something every mobile QA team eventually has to confront. Right? Emulators and simulators versus real device testing. So, on the surface, emulators can look attractive. They're fast and cheap.
Jessica Selvin
They're easy to spin up in a CI pipeline, but it when but when it actually comes to catching real world bugs before your users do, there's a meaningful gap between an emulator and what they tell you and what actually happens on a physical device. So, let's start on left-hand side and look at what are the limitations of emulators and simulators. So, firstly, in thermal throttling, right? So, real phones heat up under a sustained load, maybe you're running several background apps, gaming, or video streaming, or longer test runs, right? And it would tend to heat up and the CPU actually slows itself down to manage that. Emulators will not be able to replicate that and hence you will not be able to identify any performance issues that come up related to that.
Jessica Selvin
Secondly, battery drain, right? You cannot get accurate battery consumption data from a simulator because there's no real battery involved, right? So, if your app has a memory leak or your background processes draining power, your emulator will not be able to catch that. Thirdly, we have network simulation. So, emulators cannot fake a slow connection, right? They don't capture the real chaos of actual networks, right? Maybe simulating different environments of 3G or handoff between 4G and 5G or a flaky Wi-Fi signal. So, all of these come under real world unpredictability which an emulator will not be able to catch. Fourthly, we have GPU rendering.
Jessica Selvin
So, the graphics pipeline on an emulator runs differently than on real hardware, right? So, you might think your UI is really smooth in testing and then you might get complaints about jerky frames in production. And fifthly, sensors, right? So, things like your biometric authentication, camera-based check scanning, cannot be tested meaningfully on an emulator. And also your OS fragmentation. All right, so emulator typically test one configuration at a time, so you don't get visibility into how your app behaves across dozens of real OS versions and real device combinations, right?
Jessica Selvin
Now, with that challenges that you see in emulators, in real devices you'll be able to achieve all of this, right? You'll get true CPU and thermal behavior under sustained load. All right, you can get accurate battery drain profiling per session. All right, and you can also get real network variants between 3G, 4G, and 5G. And you can also get an authentic GPU frame rendering, so whether your scrolls are actually as smooth as it is was reflecting in the emulators. All right, so all of this is possible in real device testing. So, the point to take away here is that emulators are not useful at all. They're great for maybe like functional tests, checks in early stages of development, right? But for anything involving performance, battery, and network conditions, and you want to achieve true compatibility testing for a wide range of devices, there is no substitute for testing on real devices, right? And that's exactly the gap a platform like Pcloudy is built to close, right? Giving teams on-demand access to real devices so that you're not stuck between choosing speed and accuracy. Again, this is just to give you an idea about the different metrics that you will not be able to achieve on an emulator, but which you can on a real device. I think we've already covered most of these key aspects, but you can see here that in Pcloudy we have 5,000 plus real device browser combinations, and you will be able to achieve and get these real metrics across all these devices.
Jessica Selvin
Next we will look into what is the pre-release performance audit framework you need to have in place. What is the process that would and a repeated audit process that you can have to validate from your app from a performance standpoint. Right? So this is the five step process that we laid out and the idea is straightforward, right? Run this before every release so that you can catch performance regressions before they reach production. So for example the step one is you define your baselines. So before you detect a regression you need to know what normal looks like. So this could differ from industry to industry, right? And for different flows you might have different acceptable thresholds, right? So for example downloading a huge file or account transaction history, maybe that the acceptable timeline for that to load might be higher than say a very critical flow of payment, right? So defining your baselines for your key transactions are important. Right?
Jessica Selvin
And then step two is selecting your device matrix. So the recommendation here is to cover the top 10 devices or and then the top 20, based on your actual user base. So include low end devices as well as higher end devices. Analyze your user base and ensure you're having the right mix of devices and real devices to test on. Step three is running profiling scripts.
Jessica Selvin
So running your automation test suites that are also enabled with our performance capturing data so that you will have a complete snapshot of your functional scenarios as well as your performance metrics. And step four is detecting regressions so you can compare your fresh results against your previous pipeline right and the rule of thumb is anything that exceeds more than 15% gets maybe flagged as a release blocker again this could be modified based on your particular scenario and finally finding the root cause and fixing right so once you flag an error or a something that crossed the threshold having your AI analysis that is used to pinpoint the actual culprit right whether it's on your memory issue or a CPU issue right identifying what could be contributing to that collaborating with the dev and fixing it right so that is the performance audit steps that you can follow and Pcloudy is built performance module is built around this. And also what are the critical user journeys right so this is another important thing to have in mind not every screen would have the same business impact right so for example your login and biometric authentication is very important whereas maybe downloading a statement could be a medium important right and fund transfers are critical of critical importance so identifying what are the key flows that you need to run for your performance testing and what are the impacts it would have from a CPU standpoint as well as from a UI/UX standpoint FPS referring to frames per second right and what could be the potential business impact of that.
Jessica Selvin
Able to you need to be able to identify what are those key flows and run it consistently across your different builds right so that you'll be able to have an idea of whether your performance is improving or degrading over time. Next, coming to our AI-powered root cause analysis, all right, so what would a typical debug process look like without your AI-based RCA, right? So, for example, the testing team might say, "We've observed the payment screen is slow." And then the dev comes back with, "Can we reproduce it?" All right, and the QA spends significant amount of time collecting these logs, screenshots, trying to reproduce it, all right, device metrics, picking it up from different sources, all right, and this alone can take up to 1 or 2 days. And then sharing this and developers manually having to inspect these log entries and trying to correlate events, right? And eventually they might have, come down to what the actual problem could look like, right? And this is a very slow process with a lot of back and forth, and there is no single source of truth, right? Data comes from multiple sources, hence, collaboration between the dev and testing also can be challenging here.
Jessica Selvin
Now, let's look at what it would look like with AI-based RCA from Pcloudy, right? So, the performance test runs would automatically run on these real devices, continuously collecting these metrics, these 60-plus metrics like your CPU usage, your memory consumption, and your network activity. And instead of requiring manual investigation, the AI itself would summarize some of the key issues, all right, and it will be able to highlight them. And also, you would have a single source of truth across these six different categories that we talked about, right? So, you don't have to have multiple data sources which you collect individually. you will have it in a single pane and you'll be able to easily share all these reports and easily shareable as well. So, you'll be able to collaborate very easily across your dev teams. So, without further delay, I would like to directly take you through our demo of our Pcloudy performance testing module and yeah, hope you are Please confirm if you're able to see the demo. Is my screen visible?
Vanilla
Yeah, it is visible. >> Okay, thank you.
Jessica Selvin
Yes. So, this is the landing page of our Pcloudy platform. All right, I will keep the demo more focused on our performance app performance module. However, just to give you an introduction of our platform in general, we are an AI-powered digital experience testing platform. All right, you can access our real mobile devices as well as our browsers. So, we host our browsers and devices across different OEMs and OS versions.
Jessica Selvin
So, for example, you can see we ensure to procure the latest devices and have the latest Android versions and iOS versions and for you to be able to test on. And we also have seamless integration with Appium, Selenium, and all the other popular frameworks. And you will be able to run them and get seamless reporting on our platform and we have integration with your CI/CD pipeline CI/CD tools as well. And we also have a whole range of AI agents, right, for your automation, test case generation, your API testing, and so on.
Jessica Selvin
So, with that, I'll just directly get into our app performance module. So, coming to the performance experience mode, so again, we support both Android and iOS OS OSs for this. You can go ahead and upload your APK or IPA file into this section. And once done, it's already picking an app, so I'm selecting the IKEA app for the purpose of this demonstration.
Jessica Selvin
Once you have uploaded your APK app, you need to click on app performance testing. So what this does is it adds the relevant libraries to your application, instruments it, and then you will be able to select this application to run your performance run. All right. So, once it's done, I can click on that instrumented version of my application, select the device of my choice, right, and then click on start testing. So what is happening now is firstly the real device connection is going to happen, all right, where the device session is getting connected, and the app will get further installed onto the device.
Jessica Selvin
I can also give a tag name to the device, so I'm just giving the application name and saving it. All right. And right now what is happening is the app is measuring the launch time. So if the app will launch multiple times to measure the cold, warm, and hot launch. All right, so cold is when it's you're launching your app right after a device reboot. And a warm is when the activity is still present, but it's no longer there in the background. And hot is when you're bringing it from the background to the foreground. All right, so all these different launch times are getting measured and it will take about 30 seconds or so. So you can see now the app launch measurement has been completed successfully.
Jessica Selvin
And the recording will soon be enabled. So right now what you can do is you do not need to worry about the metrics collection, all right? I simply can go about doing my flows like a user would. All right, I can pick any important transaction, all right?
Jessica Selvin
So I'll just go ahead and complete that flow. So, there's no limit. You can complete your entire flows. All right? For the purpose of this demo, I'm keeping it to an add to cart flow. Yeah. So, once you're done with your flows, right? You can simply just go ahead and finish your session.
Jessica Selvin
All right? And I can go ahead and release the device. So, there's no time limit as such. All right? So, you can finish your entire flow and then go ahead and release the device. And once the device is released, I can come to the report section here. And you can see we have a dedicated performance report here. All right? So, I can just filter out for app performance and then I can go ahead and click on my report.
Jessica Selvin
So, this is how an app performance report would look like. This is the landing page and summary page of my app performance report. So, firstly, you can notice we get an Apdex score. All right? So, this is basically a value that is set between zero to one. All right? And it basically gives you an idea of the responsiveness of your application and it's calculated based on the averaging out of all your API responses. All right? So, this is a score that you get and you can see the range here. It's 0.89 for in this case. And also, you can see the summary of all the details. Like, for example, the device information, session information, app insights, so what was the peak CPU usage, what was my average memory usage, and if there was any app crash, it will give you the number of times it observed the crashes.
Jessica Selvin
Here you can see the different launch times I was talking about, right? The cold launch and the warm launch and the hot launch. right? And if you hover over each of these metrics, you will get the definition of those metrics as well. So, under UI insights, you can see how many janky frames were observed, what is the average frames per second, and what's the frame stability.
Jessica Selvin
You will also get what are the total number of API requests, what is the error rate, and what is the average response time of your APIs, right? So, this is the summary page. You can get a deep dive info into each of these sections that are highlighted here. So, firstly, under app insights, yeah. Here you can see 20+ metrics in a time series chart, right? So, this is a big differentiator for us here at Pcloudy.io. Other cloud platforms are providing this level of detail with 20+ metrics in a time series chart. So, you can see here you can observe the system CPU, the app CPU, and you can also see what was happening in the screen at that time. So, for example, if you observe a spike here, you can see what was happening in the screen at that time. And similarly, you can see what were the total number of frames, out of which how many were janky, right? Smooth frames, what were the frames per second, and also the memory breakdown, right?
Jessica Selvin
So, you can get the GPU usage, what was the total memory usage, right? And the Java heap, the native heap, code heap. So, all of this you can get in a timeline, and you can also move your timeline to any particular timestamp to see what was happening at that point in time. And then you can also get protocol the transmitted packets, the transmitted bytes, and the received packets and bytes as well. And you will also get the battery drain, your voltage and temperature. So, all these system metrics, which typically take several different tools, right, to collate and to have it in a single source of truth, you get it all here in a single pane of view. And from as a user, you have done nothing but just simulate the user flow, right? You have simply done the user flow, whatever it may be, right? And behind the scenes, all these metrics got collected, and you have a detailed visualization and time series chart.
Jessica Selvin
You can also hover the timeline anywhere that you want. Like, for example, if you want to analyze between 29 to 59 seconds, right? You can see what were the network calls that were made at that time, right? So, here you can see there were about 29 network calls. You can view all of them, and you can click on any individual one to get all the details of the network call. So, that is on the app insights.
Jessica Selvin
Next, we have the UI insights. All right? So, this is every single page transition that happened. You can see here, and you'll be able to see what was happening in the UI at that point in time as well. So, supposing So, here if it if it was anywhere more than 3 seconds, it would be considered as a slow page load, and it would be highlighted in a different color. Right? And you can also have a tabular view of this thing.
Jessica Selvin
Next, we have the jank analysis or the frame analysis. So, every single UI frame, you'll be able to see highlighted in a timeline view here. And whatever was on time present would be marked, and anything that was late, and any frame that was dropped as well, will be highlighted, right? So, you'll be able to see that, and also what was the activity layer and the time stamp. So, this is again you useful information that you can again share with your dev teams and concerns stakeholders to quickly collaborate in case there are a high number of drop frames or jerky frames. You can also see the activity breakdown. All right, so for example here the login, the landing page and picking out the item, right? So, the different activity layers in your application, you'll be able to see that and see whether it was fast, rendered fast, normal, or slow.
Jessica Selvin
Next, we have the network breakdown. So, every single API call that was made during the session, right? You will be able to view them all here. All right, and you can click on any individual API and you can get the header information.
Jessica Selvin
You can get the preview as to what it was fetching, the response, and the timing breakdown. So, this you will get for every individual API and you also get API-based analysis. So, in case if there were any insecure connections, all right, or any failed requests, and you'll also be able to see what were the slowest endpoints. All right, so these you can say several of them exceeded more than 2 and 1/2 seconds or so. All right, and if there were any APIs that were missing cache headers, right, or no cache directives, which would lead to repetitive API calls. So, you'll also be able to see the repeated API calls here.
Jessica Selvin
So, you can see what which was the API call and how many times it was repeated. And finally, you'll get the domain charting or the domain distribution of your API calls as well. Finally, we have the log analysis. So, here the AI would go through the entire device and categorize it into different issues. So, supposing there were any crash issues or ANR issues, right, that would be highlighted here along with permission issues as well. So, here you can see it's highlighted those relevant log lines. So, you don't need to go through those several lines of logs.
Jessica Selvin
And also all these reports are shareable. All right, so you can simply share these reports and generate a shareable link and even users who are not registered on Pcloudy will be able to view them. Next, we have the comparison session report as well. So, here you can compare different sessions. So, say I ran a session on an Samsung Galaxy S25 and then an Oppo device, right?
Jessica Selvin
And I want to compare the sessions as well, right? So, you will be able to do that. So, for example, here you can see the score was relatively the same, but you can see the launch times were much faster in Samsung Galaxy S25 compared to the Oppo device. All right, across the cold, warm, and hot launch. And you can also see right, it will also give you insights like session B had more issues than session A and what were the issue counts that were observed. what were the error rates of the APIs, right? And what was the difference in the CPU utilization, memory utilization. So, all of these you'll be able to get a comparative information between two sessions as well. Also, on the app and device information, you'll also get video comparison and the issues identified. Right, so you can see that the baseline session, which was session A running on Samsung Galaxy S25, had issues in the memory, maybe in the janky frames. And in session B, there were issues on the frame skip issues, right? So, you'll be able to com- have a side-by-side comparison between different real devices and conclude any performance impacts based on any OS version change or any change in the manufacturers. You'll also get the status of your network, calls and have a comparisons between your failed requests on session A and session B.
Jessica Selvin
So that is on the comparison report. And finally, what I want to highlight is while I showed you a manual session, you can run the same thing and you can get the same reports on your automation from your automation scripts as well. So for example, you can run your set the capability as app performance as true, all right, and you will be able to run it on our Pcloudy devices, run your automation, your Appium or whatever framework you use, right? We have support for Maestro, Cypress, Espresso, all right, and you can run those scripts on our Pcloudy devices and get these reports and results in the same way. So that is I hope this gives you a good understanding of our app performance capability and how this will help you in your audit process for analyzing your user experience for your application.
Jessica Selvin
So with that, let me get back to the slide. Yeah. So now coming to the checklist, right? So you can see how Pcloudy would help you both in the metrics setup, right? So you'll be able to analyze across those five different categories that we were talking about. Also those flows that are audited, right? You can run your flows be it manually or through automation.
Jessica Selvin
You will get real device coverage both on real iOS and Android devices as well as on lower-end devices as well. And easily, much easier RCA and AI generated root cause analysis for these performance metrics. And to conclude, the key takeaways here is that firstly, understand that signals come across different categories and not just one, right?
Jessica Selvin
So, it could be your CPU, your UI/UX, or your battery, right? So, identifying your performance is optimized across these different categories is important. And next, importantly to remember that in banking, a performance failure reads as a trust and a security failure to users. And thirdly, emulators do not really give you the full picture, right? Every metric, particularly on the thermal battery, your CPU, or your network can only genuinely be measured on real devices.
Jessica Selvin
All right? And having a security-first framework and AI-based root cause analysis compresses those debug cycles from days to minutes. So, I hope this gives give you a good understanding of the framework, and our app performance module to run your audits, and to ensure that you have a smooth user experience at every release. So, with that, I would hand it over for any questions that you may have, and we can take it from there. Thank you so much.
Vanilla
Yeah, so that was a very insightful session, Jessica. So, now we will move on to the Q&A session, and I can see somebody has asked how can you detect performance issues during functional automation runs? Also, somebody else has asked Can I configure my own thresholds? So, these are the questions raised.
Jessica Selvin
Yes. So, on both these aspects, right? So, firstly, the first question on can you run it on functional on your basic automation runs is yes, right? So, you don't need to create separate scripts for performance, all right? So, you can simply enable that capability that we showcased and run your key flows, right? With this capability enabled and you will get the same reports, right? So, you will get your functional reports as well as your app performance reports in the same run. So, that is very much possible. And secondly, can you configure the thresholds? Yes, all right? So, for example, we had marked 3 seconds as a slow load.
Jessica Selvin
We have an option called configure thresholds where you can set the thresholds based on the requirements that you have come to an agreement maybe for your application. Yes, so configuring thresholds is also possible.
Vanilla
That's great. So, another question to you, what can cause CPU spikes in my application? Somebody has raised this question.
Jessica Selvin
Yeah, so there could be several factors, right? That, could be causing a CPU spike. So, firstly, it could first of all be an app-related issue or a device-related issue, right? And now coming to your app-related issues, it could be a memory leak, all right? The code not being optimized, which suddenly causes higher utilization of resources. It could be API, caching or broken API caching. So, when caching is not done properly, this could cause your API calls to be repeatedly, API calls or requests being made and this could slow down, I mean, cause higher consumption of resources like your CPU, right? It could also be maybe images being repeatedly downloaded and decoded if there's not proper caching of that as well. So, there could be several reasons.
Jessica Selvin
So, these are some of the top reasons why typically CPU spike happens when it is an app side issue.
Vanilla
Great. Great. So, let's end the session. I would like to thank Jessica for sharing these valuable nuggets of information in the performance testing space and doing a deep dive into the performance metrics that we need to look into when testing banking apps. Thank you, Jessica.
Jessica Selvin
Thank you so much.
Vanilla
Yeah. So, we also want to thank each one of our participants for joining us for this webinar. I'm sure that some of the insights shared by Jessica may have sparked a few ideas to think through, implement, discuss, or raise questions. So, feel free to reach out to us with any questions by writing to us at info@Pcloudy.com. Or, you can use the chat icon on our website, which is www.Pcloudy.com.
Vanilla
Thank you once again for being an engaging audience. Happy testing.
Jessica Selvin
Thank you.
