Get best of the week

What is web application performance?

image

Some applications load quickly, some slowly, but due to what this happens? Is page load speed the only measure of application performance?

It would be very difficult to answer these and many other questions in one article. So I put together a catalog of links and divided it into categories. But for starters - a little theory about what performance is and when you should think about it.

When performance issues arise


You can develop web applications for years and have virtually no problems with application performance.

But, most likely, problems arise in the following situations:

  1. Big data appears (you need to render large lists or hundreds of thousands of points on the map).
  2. The application becomes large (hundreds of user scenarios, dozens of screens, forms, and so on).
  3. A large number of customers from different regions (for example, 300,000+ customers per day from all over the world).
  4. High competition in the market (for sure, the user will prefer your competitor’s application if it works faster).
  5. A mobile version is needed (browsers on mobile devices are still suffering from performance issues).

What performance consists of


Globally, web application performance issues can be divided into two categories: data transfer and runtime.

  • Data transfer means downloading any resources necessary for the application to work.
  • Under runtime - application operation, rendering and user input processing.

Each of these categories contains a lot of nuances that we often don’t think about, but which distinguish high-quality applications from low-quality ones.

Here are the most popular web application performance metrics (all should be minimal):

Page loading



Runtime


  • User input response time.
  • Interface redraw time.

Although TTFB and TTI are both metrics for page load performance, runtime-related issues can also affect them.

How to search and analyze performance issues


The main toolkit in the developer's arsenal is Chrome DevTools or similar tools, such as Firebug / Firefox developer tools .
Separate articles can be written about them, but we will limit ourselves to the most important points.

Network - allows you to analyze in detail which resources are loaded on the page, from which resources, with what speed and so on. This tool is often used to manually analyze page loading speed.

Performance - in this tab, you can enable recording of code execution calls, input / output operations, and others. In addition, recording can be done with emulation of throttling network and CPU. For example, check the application on weak devices.

Lighthouse - A tool built into Chrome DevTools that launches page loading, records metrics, analyzes them, and even issues recommendations for improving performance.

How to measure / monitor performance


Tools for monitoring the performance of web applications can be divided into two categories: those that take synthetic measurements and those that record performance data from real users.


In addition, there are tools like Webpack-bundle-analyzer that cannot be assigned to these two categories. But with their help, you can measure some parameters that affect performance, such as the size of the bundle.

Data transfer


TCP connection, DNS lookup - you can speed up page loading even due to the correct configuration of connections to the server. In particular, if you use DNS pre-fetching or even IP addresses instead of domain names.

TTFB (Time to First Byte) . The time to get the first byte is an important metric. To speed it up, you should try to implement as little logic as possible on the server before issuing index.html.

HTTP1 vs HTTP2 - HTTP2 can greatly speed up page loading by multiplexing or compressing headers. In addition, a new (relatively) protocol opens up a bunch of features, such as server push.

Domain sharding. If you need to send a lot of HTTP headers for API requests, but not for static requests, then it is better to separate them into different domains.

CDN (content delivery network) will help speed up loading for geographically distributed clients.

Resource prioritization (preload, prefetch, preconnect) is the acceleration of page loading due to the correct resource loading strategy. Browsers allow you to set priorities for different types of resources and download earlier what is important for the first rendering.

Static compression: GZIP and Brotli . Brotli is a compression algorithm that will reduce the static weight and, accordingly, increase the download speed. And here is a great solution from my colleague.

Webp vs Png & Jpg. Webp is a great alternative to Png. In addition to the lower weight of images, Webp is not inferior in quality. Now this format supports approximately 78% of browsers . But even if you need 100% support, you can implement fallback on Png using the picture tag .

Runtime


Tasks, Microtasks . By correctly prioritizing code execution, you can get rid of friezes and speed up the response to user input.

requestIdleCallback is a useful function that allows you to execute code in your free time at the end of the frame (frame / tick) or when the user is inactive. It will help get rid of all the same lags and "freezes".

requestAnimationFrame allows you to properly plan the animation and maximize the chances of rendering 60 frames per second.

ES2015 vs ES5 . ES2015 provides many features more productive than ES5.

Dom manipulation. Manipulations with the DOM are expensive, you need to perform them carefully and meaningfully. For example, do not call querySelector () in a loop if this can be done with a single call.

Render blocking resource . Loading some resources may block rendering. To avoid this, you need to use the attributes defer, async, preload.

60 FPS by pointer-events: none is a great hack with which you can achieve 60 FPS by scrolling the page. It works very simply: all mouse event handlers are disabled during scrolling.

Passive event listener- a way to make the page scroll smoothly on touch screens. In short, the browser has imperfect flow processing for listeners of touch events. If you set the passive parameter when creating the event handler, the browser will clearly understand that the handler will not cancel the scrolling and render, without waiting for it to complete.

Virtual scroll is a smart way not to render large lists, but to generate them when scrolling. Allows you to consume less memory and facilitate scrolling lists.

Avoid large Complex Layouts and Layout Thrashing . Layout / reflow is an expensive operation that does many recalculations of rendering parameters. To avoid their frequent calling, you need to correctly build the layout and manipulate the DOM.

What forces layout / reflow - a cheat sheet where you can find a list of functions and parameters that work with which causes layout / reflow.

Assembly


Tree shaking - remove unused code from the bundle and speed up page loading.

Code splitting - dividing the code into chunks, you can optimize the first load and open the ability to download parts of the code “lazily”.

Obfuscation can reduce the size of the bundle and even help a little to hide your code from prying eyes.

Architecture


Server side rendering is probably the best-known way to make SPA render right away on first boot. This is an important requirement for some search engines (and not only).

Lazy loading images and video ( + native ) - a native solution designed to improve the metrics of the first rendering due to the "lazy" loading of images and videos.

Lazy loading modules / routes is a tool that is found in all popular frameworks and libraries. Allows you to "lazily" load pieces of application functionality.

Caching files with Service workers allows you to cache files in a browser and not download them every time from the server. Perhaps the only way to do offline mode in a browser application.

HTTP caching - Using some HTTP headers you can greatly improve page loading speed and reduce server load.

More articles:


All Articles