Improving Web Application Performance
Bottlenecks are parts of the web application which limit the performance. These parts in the web application are unable to keep pace given their capacity and a particular amount of work, which in turn slows down the overall performance of the web application.
Some common bottlenecks include CPU, memory, database, disk utilization and network. Different problems will lead you to different solutions. For example, if the network is too slow, you can look into ways to send less data across, such as compressing or caching data in the web browser. If the database is too slow, you can add indexes, optimize queries, make use of stored procedures, and possibly denormalize some of the data. If the CPU is the bottleneck, you can look into getting a faster processor, adding processors, storing/caching data so that it doesn’t need to be calculated, or making improvements to the algorithms being used.
In this post, we will look at some techniques which can be used to improve the performance of web applications. And the focus of the performance improvement effort should be on optimizing the bottlenecks from web application.
HTTP Caching
HTTP caching is a technique used to improve the performance and efficiency of web applications by reducing the need to re-fetch or re-generate resources that have not changed since they were last retrieved. Caching aims to minimize the latency and load on web servers by storing and serving previously fetched resources directly from a cache. Many roundtrips between web browser and web server may be necessary to load a page, and retrieving resources for that page from the web server can take up significant amounts of time.
Web browsers are capable of caching data so that it doesn’t need to be fetched from a web server again. Resources such as CSS or JavaScript files might be shared across multiple pages of your web application. As a user navigates to various pages, they will need these resources multiple times. In addition, users may return to your web application at some point in the future. In both cases, taking advantage of HTTP caching will improve performance and benefit the user.
To take advantage of HTTP caching, each response from your web server must include the appropriate HTTP header directives. The cache policy you decide to implement is ultimately dependent on the application’s requirements and the type of data being served. Each resource may have different requirements related to caching that should be considered.
ETag directives in header of a response can be used to make a validation token. It can be used to check whether an expired resource has changed. Web browser can send the validation token along with a request. If a response has expired from the cache but the resource has not changed, there is no reason to download it again. The server will return a 304 Not Modified response and the web browser will then know that it can renew the response in the cache and use it.
Cache-control directive in a response can control whether the response should be cached, under what conditions it can be cached, and for how long it should be cached. If a response contains sensitive information that you do not want cached, a no-store cache-control directive can be used, which will prevent browsers as well as any intermediate caches (for example, a content delivery network), from caching the response. Alternatively, a response can be marked as private, which will allow caching in a user’s browser but not in any intermediate caches.
A cache-control directive that is slightly different than no-store is the no-cache directive. It is used to specify that a response should not be used from the cache until a check is performed with the server first to see whether the response has changed. The validation token must be used to make this determination, and only if the resource has not changed can the cache be used.
The max-age directive is used to specify the maximum amount of time, in seconds, that a response can be reused from the cache. The value is relative to the time of the request.
Once a response is cached, it will continue to be used unless it expires or the browser’s cache has been cleared in some way. However, there may be times when you want to change a response before it has expired. This can be accomplished by changing the URL of the resource, which will force it to be downloaded.
HTTP Compression
Compression is an important technique for improving performance. It is the use of an algorithm to remove redundancy in a file in order to make it smaller. Smaller response sizes lead to faster data transmission and improved website loading times. HTTP compression is a technique used to reduce the size of HTTP responses transmitted between web servers and clients (such as web browsers). It aims to optimize web performance by compressing text-based resources (e.g., HTML, CSS, JavaScript) before sending them over the network. This improves transfer speed and bandwidth utilization.
And we don’t need to do this programmatically. Web servers and web browsers have implemented compression feature. As long as both the web server and the web browser use same compression method, it can be used. It is just a matter of ensuring that the server is configured properly.
Here are two common HTTP compression methods are widely used:
- Gzip
Gzip compression is a widely supported method for compressing HTTP responses. It works by compressing a resource on the server before sending it to the client. The client’s browser then decompresses the response to obtain the original content. - Brotli
Brotli is a newer compression algorithm developed by Google. It is more efficient than Gzip and provides better compression ratios, leading to smaller response sizes. Brotli is supported in modern web browsers and web servers.
Minifiying Resources
Minifying resources is a technique used to reduce the size of web resources such as HTML, CSS, and JavaScript files by removing unnecessary characters and whitespace without altering their functionality. Although the minified files that result from the process are not as human-readable as their original counterparts, the file size will be smaller, which results in faster downloads and improved page load times.
Get Dolly Aswin Harahap’s stories in your inbox
Join Medium for free to get updates from this writer.
It is a good to keep two versions of code files that are minified: a version that has not been minified for debugging purposes and a minified version for deployment. They can be given different filenames so that it is clear which one is the minified version. For example, aqilix.min.js could be used as the name for the minified version of aqilix.js.
To minify your resources, you can use various tools and libraries specifically designed for minification. Some popular ones include:
- JavaScript Minifiers: UglifyJS, Terser, Closure Compiler.
- CSS Minifiers: CleanCSS, CSSNano, PostCSS with plugins.
- HTML Minifiers: HTMLMinifier, Minify HTML.
But at the moment, there are many modern JavaScript frameworks and build tools automatically minify resources as part of the build process. This includes frameworks like React, Angular, Vue.js, and many others. Minification is often integrated into the build and bundling processes to optimize the size of the JavaScript, CSS, and HTML files that are delivered to the web browser.
Bundling Resources
Bundling resources is an effective technique when we are still using HTTP/1.1. It is a process of combining multiple files of the same type into a single file, which can then be transferred in a single request. The technique of bundling files is sometimes referred to as concatenating files. Fewer HTTP requests lead to faster page load performance. Bundling is a technique that is complementary with minifying files and the two are often used in conjunction with each other.
A downside of bundling resources is that it can cause the cache to be invalidated more frequently. Without bundling, we can control the caching of each individual file. Once we start bundling, if any of the files within the bundle have changed, the entire bundle will need to be downloaded to clients again. If a file that is changed is contained within more than one bundle, it could cause multiple bundles to be downloaded again.
Using HTTP/3 or HTTP/2
In June 2022 a new version of HTTP (HTTP/3) was standardized by the Internet Engineering Task Force (IETF), the organization in charge of defining Internet technologies. Since then, HTTP/3 and the related QUIC protocol have seen a rapid uptake on the public Web.
It is not a complete rewrite of the protocol. The HTTP status codes, verbs, methods, and most of the headers that you are already familiar with from using HTTP/1.1 will continue to be the same.
The most important features of HTTP/3 and HTTP/2 is multiplexing. Multiplexing is the ability to send multiple HTTP requests and receive multiple HTTP responses asynchronously through a single TCP connection. HTTP/3 uses the QUIC transport protocol, which is designed to reduce latency by minimizing connection establishment and handshaking delays. This can result in faster page load times.
HTTP/1.1 does not support multiplexing, which is what led to the various workarounds to improve performance. With HTTP/3 or HTTP2, we should no longer be concatenating files into a small number of large bundles. The expensive cache invalidation of a bundle that is necessary when any of the files in the bundle are changed can now be avoided or minimized.
However, HTTP/3 handles multiplexing more efficiently, reducing head-of-line blocking issues that can occur in HTTP/2. Not all servers and clients support HTTP/3 out of the box, so you may need to check whether your infrastructure and hosting environment are compatible with it. If your environment doesn’t support HTTP/3 yet, just use HTTP/2.
However, as support for HTTP/3 continues to grow, it is becoming an increasingly attractive option for improving web performance and reliability.
Using Content Delivery Networks (CDNs)
Content Delivery Network (CDN) can significantly improve web application performance in several ways. A CDN is a distributed network of servers strategically placed in various geographical locations. It works by caching and delivering content (such as JavaScript, HTML, CSS, image, video, and audio files, and other assets) to users from the nearest CDN server, rather than fetching them from the origin server. In addition to reducing the physical distance between users and content, CDNs improve load times through efficient load balancing, caching, minification, and file compression.
The reliability and redundancy of web applications are increased when a CDN is used because when traffic increases, it can be load balanced among multiple servers. If a server, or even an entire data center, is having technical issues, traffic can be routed to servers that are operational.
CDNs can also help to improve security by mitigating distributed denial-of-service (DDoS) attacks and maintaining up-to-date TLS/SSL certificates. Many CDNs offer DDoS protection services, which help mitigate and absorb malicious traffic, keeping your web application online and accessible during attacks.
To leverage the benefits of a CDN for your web application, you typically need to configure your DNS to route traffic through the CDN’s network and configure caching rules, load balancing, and other settings. CDNs are widely used by websites and web applications of all sizes, from small blogs to large e-commerce platforms and media streaming services, to ensure fast, reliable, and scalable content delivery to users worldwide.
Improving web application performance is crucial for providing a better user experience, reducing bounce rates, and ensuring your web application can handle increased traffic. Those are some techniques include that can be used to improve the performance of web applications, but are not limited to those points.
