Web Application Performance: Part One

Professional Services, Technical Blog

Web Application Performance Part One

Web performance is a critical but misunderstood aspect of web application development. This multi-part series will guide you through the essential aspects of web performance, including defining “fast” and determining which metrics we track, how to measure these metrics, and optimization strategies that will help optimize your application’s performance.

What is “fast?”

“We need this website to be fast.”

In some form, this quote is something we hear from clients constantly. It’s a very specific requirement. Or at least it seems to be. In reality, that statement tells us very little. What is “fast?” What does it really mean? Defining measurable goals and creating a framework for defining success is essential when discussing web performance.

Performance must be measured to be managed. Subjective user experience matters, but concrete metrics are needed to track, improve, and validate our work. These metrics can roughly be divided into two categories: speed and smoothness.

Speed

When we consider the “speed” side of the equation, we look at the page load process and use several metrics to measure it. Each metric represents specific moments in the page’s loading lifecycle and has industry-standard targets.

Time to First Byte (TTFB) measures how quickly the server begins sending the response after receiving a request. This metric directly impacts all the other performance milestones, as no other metric can be faster than TTFB. If your TTFB is poor, all your other metrics will be poor. In real-world scenarios, the target is a value of under 600ms. Keep in mind that several factors, such as network latency, server processing, and any backend activities to create the page payload will affect this value.

First Contentful Paint (FCP) is the point in time when the user can see the first rendered content, which can be text, images, or even the background. According to Google, FCP is considered good if it is under 1.8 seconds. Anything between 1.8 and 3 seconds needs improvement; over three seconds is considered poor. FCP does not indicate a full-page load, but it strongly correlates with the sense of page speed as the user starts to see that something is happening.

Largest Contentful Paint (LCP) measures when the page’s main content becomes visible. This usually refers to things such as your hero image, primary heading, and/or main content. Forms or dynamic data structures may be visible but not fully interactive or populated with data. You should target LCP in under 2.5 seconds. Sites with an LCP over four seconds tend to see bounce rates increase by 25%. As you can imagine, LCP is a key metric for content-heavy sites, as it can be affected by dynamic content and optimization.

Time to Interactive (TTI) is the point at which your page is reliably interactive, meaning the main browser thread has enough bandwidth to allow the page to respond quickly to user interaction (i.e., typing input into forms, scrolling data tables, etc.). It is recommended that the TTI be under 3.8 seconds, especially on mobile devices which have limited processing power. As you may suspect, this metric is significantly impacted by JavaScript and JavaScript-heavy libraries such as React, Angular, Vue, etc. To mitigate the impact of these libraries, we’ll discuss strategies like code splitting, critical path optimization, and caching in future installments of this series.

Smoothness

Speed metrics reflect how quickly content loads, but “smoothness” quantifies how stable and responsive the application feels to users. These metrics focus on visual stability and interactivity, which are critical factors that impact user satisfaction and their ability to complete tasks. A great load time won’t be enough if users cannot rely on your web page.

First Input Delay (FID) measures the time it takes for the page to respond to the first user interaction. This could be clicking a button or link or filling out a form. Current web standards say that this should be under 100ms. A delay of 300ms or more will make the site feel sluggish and unresponsive. Like TTI, this metric is heavily influenced by JavaScript execution. Long tasks that block the thread should be avoided, and careful event handling is needed. We’ll discuss this more in a future post in this series.

Cumulative Layout Shift (CLS) measures how much unexpected movement occurs in your layout during page load and runtime. This metric is a score that can be computed by Google Chrome and other tools. A CLS score of under 0.1 is considered good. A score of 0.25 or higher tends to lead to user errors and frustration. Issues related to CLS tend to be caused by dynamically inserted content, lazy-loaded images, or font changes that cause the text to change its flow.

Summary and What’s Next

The numbers above are just guidelines, and different types of applications will have different priorities. An e-commerce site will usually prioritize LCP and TTI, along with the smoothness metrics, as customers want a fast and easy experience. Line of Business (LOB) applications may have users who are okay waiting a few more seconds, as they prefer more dense informational expertise. Understanding the context of what you are building and working with your users to define acceptable performance standards is essential.

In the coming posts, we’ll dive deeper into Core Web Vitals and how to measure them. Future posts will explain how treading in the browser works and performance optimization strategies.

James Bender

James Bender

James Bender is the Application Services Lead at INSPYR Solutions. He has over 25 years of experience focusing on large-scale web applications and speaks at software development conferences worldwide. When not playing with new JavaScript frameworks, he enjoys playing guitar and hockey (but not at the same time).

Contact Us

We’re here for you when you need us. How can we help you today?

Share This Article

Related News & Insights

code Web

From Prompts to Code: A Side-by-Side Comparison of AI Code Generation Engines

JavaScript Coding Tips

Hidden Gems in Modern JavaScript You Should Be Using