Branded web applications can make or break a firm’s reputation. Convenient, smooth running apps encourage users to post positive reviews and recommend the business to their friends. The sluggish ones, on the other hand, often leave customers enraged, voicing their frustration on social media.

Unfortunately for businesses, it’s the feedback from the dissatisfied clients that’s more likely to meet the public eye; social media, and Twitter, in particular, seems very keen on picking up scandals and people’s fury.

In light of this, having a quality web application is among top-priority tasks for businesses around the world. For the sake of engaging clients, firms must dedicate considerable amounts of resources and time to foresee and mitigate issues that might impede upon the performance of their software.

Today, we’ll discuss a few ways companies can ensure their apps aren’t driving people away.

Testing Web Application Performance in the Lab vs. the Real World

Testing Web Application Performance in the Lab vs. the Real World

What’s important to understand from the offset is that there is a tremendous difference between measuring web application performance in the lab and testing it in the “real world.” Web development tools such as DevTools, Lighthouse, and Webpagetest are extremely important as they allow tracking and calibrating development efforts as the project progresses. They give a sense of how certain modifications affect apps, help catch regressions before they damage live production sites, and provide clear breakdowns so that development teams can get to the bottom of every issue and patch it.

What they can’t do, however, is recreate accurately the real-world environment which is always messy and disorganized; there is no tool capable of simulating the abundance of random network configurations and caches conditions that swarm the web.

So, before drafting out strategies on how to fix app’s shortcomings, ensure that there are metrics in place that reflect correctly the user-perceived performance. Define and implement Real User Measurements (RUM) and only track what you assume is important to your client’s and shapes their perception of the app. Ask yourself these questions:

When the app is loading, is there a proper indication that server has responded and the navigation has started? What elements tell our users that the app is working?

Is there a sufficient amount of content rendered in the very beginning and how soon can a user interact with the app in a meaningful way? Is there something blocking the interaction and, if so, why is that?

Is the experience free of jank and lags? Can we be positive that a user’s likely to enjoy the app and find it captivating?

The Actual Web Applications Performance Problems Companies Find Hard to Tackle

The Actual Web Applications Performance Problems Companies Find Hard to Tackle

1. Server Response Time is Too Long

Optimize web pages all you want, but if the server’s sluggish, your web app will unfold slowly and annoy the user. The delays in the content rendering can be caused by a number of factors that include:

  • Sudden traffic influx
  • High usage of resources per each page load
  • Outdated server software; poor configurations
  • Insufficient quality of hosting environment

Note: according to Google, server response time should not exceed 200ms.

What can be done about this?

As a starting point, we suggest identifying how much resources your app consumes for each page load. Then, if needed, proceed to optimize resources:

Gather all external CSS files into one file so that each page of your web app calls fewer resources.
Locate external javascript files in the HTML, or compile them in a single external js file to reduce wasteful calls.
Defer images so that your app doesn’t download every image prior to displaying the initial content.

The next step to improvement is moving to a more advanced web host. You don’t want to be stretching resources that you already have scarce so, if your web app is hosted on a shared account, make sure to switch to a dedicated server.

2. Memory Leaks

The term “memory leak” is used to describe a wide range of communication errors in computer science but, in its most common interpretation, refers to a situation when a bug in the code is causing the app to use progressively more memory over time. In other words, an object in a system eats the resources it isn’t supposed to, to the point where the entire app crashes, suffers slowdowns and high latency and performs poorly overall.

Even when garbage-collected programming languages such as JavaScript are used, which ease dramatically memory management, the leaks can still occur due to unwanted references; these issues can also go unnoticed for a long time as detecting them is quite difficult.

We won’t be delving deeply into the technical subject of app resources leakage, but, in layman’s terms, the explanation of the phenomena would go something like this: whenever a new object is created within an app’s code, an appropriate amount of memory is assigned to it. Once active, each of these processes is monitored by garbage collectors (if we’re still talking about languages like JavaScript) that scan through object graphs, from time to time, to see which objects are still valid. When they found processes that are not referenced by any other processes (or the ones that only have circular references) they pull the memory out of them so there’s no waste.

A leak happens when some object that your app no longer needs continues to consume resources once assigned to it. For some reason, it doesn’t give back the memory that, by now, should be reclaimed for a pool of free memory or the operating system.

Memory leaks could be a sign of bad code. So, to prevent them and avoid having your web application performance jeopardized, it’s best to hire developers who have written similar apps before and understand clearly the importance of proper memory usage.

Preventive practices also include enforcing regular usage of memory management tools such as Google Chrome’s Heap Management and having your development team come up with concrete expectations as to when certain resources in the object graph must be freed. Make sure they track memory distribution religiously and investigate carefully each unexpected result.

If object cleanups are planned ahead, there won’t be a need to insert clean-up stages into applications later on.

3. Database Deadlocks

Finally, web app’s performance can suffer greatly due to database deadlocks. These arise when two threads of execution are trying to access resources locked by each other.

For example, session A within a database is waiting to get access to some recourse that session B is currently holding. At the same time, session B is also “hanging”; it’s expecting to reach the resource owned by session A. The threads are thus both in a wait state and there’s a cyclic dependency between them that allows neither to proceed.

Deadlocks are extremely dangerous as they can:

Undermine user experience. A client might be shown white pages, while the browser continues spinning frantically, and, eventually get the network time-out error on their screen. When they try to resubmit the form and refresh the page, they escalate the issue even further.

Cause system degradation. When deadlocked, threads take longer to respond and while they’re stalling, new requests are likely to pile up in the execution queue. Eventually, the tank will become full and the system will start denying all incoming requests.

Kill an important business transaction. Whenever an SQL database spots a deadlock it reacts by killing one of the deadlocked threads and reverting whatever transaction it was about to complete. By default, the system chooses as a deadlock victim a process that it assumes will take the least resources to roll back. Sometimes, it could abort an important process such as a high-scale business transaction.

When a deadlock alert pops up, it’s crucial that your team conducts a thorough investigation to determine what has caused it. Tools like SQL monitor will help them inspect closely all the deadlock data and allow to review the affected SQL server instance that shows Memory, CPU, Input/Output over a selected time frame.

After the queries are analyzed, it’s time to remedy the issue by query tuning, modifying existing indexes or adding new ones or using some other standard deadlock mitigation measures.

To avoid deadlocks, try:

  • Normalizing database design
  • Blocking users’ input during interactions
  • Reducing lock time
  • Utilizing bound connections
  • Making transaction shorter time-wise

Conclusion

Think about web application performance in a user-centric way. After the app’s code is written, have the performance tested in the lab, then introduced to users, and then validated through Real User Measurements.

Those tracking performance with analytics tools can also assess quickly if the way the app functions affects their business. If, for example, one monitors e-commerce conversions in GA, they can set up reports that explore correlations between ecommerce goal completion and the app’s performance metrics. If the latter influence the former greatly, it’s a clear sign that the enhancement of the app makes business sense and should be prioritized.

Want to learn more about how to create a flawless app for business? Contact our expert for a free consultation right now.