Performance in Frontend Systems
Understand performance as a key nonfunctional requirement and its significance in frontend systems.
Nonfunctional requirements (NFRs) define a system’s operational characteristics, such as performance, scalability, accessibility, and maintainability. While functional requirements specify what a system does, NFRs dictate how well it performs under different conditions.
In frontend System Design, NFRs play a critical role in ensuring that applications are functional but also user-friendly, efficient, and sustainable over time. Ignoring NFRs can lead to poor user experience, unscalable architectures, and potential security vulnerabilities. By integrating NFRs early in the development process, we can create frontend systems that are robust, reliable, and optimized for real-world usage.
Nonfunctional requirements in the frontend System Design
Here are some of the most important NFRs in frontend development:
Performance: Ensures applications load quickly and respond efficiently to user interactions.
Accessibility: Ensures that applications are usable by people, even those with disabilities, following standards like
.WCAG WCAG (Web Content Accessibility Guidelines) is a set of international standards developed by the W3C (World Wide Web Consortium) to ensure web accessibility for people with disabilities. Compatibility: Ensures applications work consistently across different browsers, devices, and screen sizes, providing a smooth experience for every user.
Localization and internationalization: Ensures the application supports multiple languages, regional settings, and cultural preferences, allowing users from different regions to have a tailored and contextually relevant experience.
Maintainability: This ensures that the frontend codebase remains well-structured, modular, and easy to modify or extend, allowing for efficient updates and long-term sustainability.
Scalability: The frontend system can handle increasing numbers of users and data without compromising responsiveness, stability, or overall user experience.
Security: Protects the application and its users from potential vulnerabilities and cyber threats, ensuring data integrity, safe interactions, and trustworthiness.
Availability: Ensures the system remains operational and accessible with minimal downtime, providing users with a reliable experience under varying conditions.
In this lesson, we’ll look at performance, how important it is, and what metrics are used to measure the performance of an application, along with factors affecting it.
Performance
When we visit a website, we expect it to load fast and respond quickly. If it’s slow or unresponsive, we often leave, hurting user engagement and even business revenue. Amazon found that every 100 milliseconds of delay costs them 1% in sales. That’s how closely performance and revenue are linked.
Website speed directly affects user experience, engagement, and conversions. A sluggish site frustrates users, while a fast one keeps them interested and encourages them to stay. Performance also matters for search rankings—search engines favor faster sites in their results.
According to studies, customers expect less than 2 seconds of page load time. A threshold of conversion is as follows:
2.4 seconds load time yields a 1.9% conversion rate.
3.3 seconds load time yields a 1.5% conversion rate.
4.2 seconds load time yields a <1% conversion rate.
5.7+ seconds load time yields a <0.6% conversion rate.
Performance is also essential for accessibility and usability. Users on slower networks or lower-end devices should still be able to access and interact with web applications efficiently. Ensuring an optimal experience for all users contributes to broader inclusivity and higher customer retention.
Key performance metrics
To ensure a frontend system performs well, we must measure its efficiency using key performance indicators (KPIs). Some important metrics include:
Time to first byte (TTFB): The time it takes for the first byte of data to reach the user’s application from the server. For example, the first byte could be a small part of an HTML document, such as
<html>
. If it takes too long to arrive, it may indicate a slow backend response, leading to longer perceived wait times.Time to first pixel (TTFP): Measures the time taken for the first pixel to be rendered on the screen. For example, if a web page is completely blank for a while, but then a small dot or background color appears, that is the first pixel being rendered, indicating TTFP.
Note: TTFB (time to first byte) typically occurs before TTFP, which in turn occurs before FCP and so on, as each metric builds on the previous step in the rendering process.
First contentful paint (FCP): The time it takes for the first visible content to appear on the screen. For example, the first visible content could be a logo, navigation bar, or a loading spinner. If a website displays a blank screen for the first three seconds, it has a poor FCP score.
TTFP tracks the first visual change, even if it’s just a background color, while FCP measures when actual content appears (renders), providing a better perception of load speed.
Largest contentful paint (LCP): It measures the time for the largest visible element to load. For example, the largest content is typically a hero image, main heading, or a featured article. A large banner image taking too long to render results in a high LCP score, affecting user perception of speed.
First input delay (FID): It is the delay between a user’s first interaction and the application’s response. For example, if a user clicks a “Sign Up” button and the application takes, let’s say, two seconds to register the action, it indicates poor FID.
Cumulative layout shift (CLS): A metric that quantifies visual stability by measuring unexpected layout shifts. For example, on an e-commerce website, if a user is about to click a “Buy Now” button, but an image loads late and pushes the button down, it results in poor CLS.
Time to first complete (TTFC): Also referred to as time to interactive (TTI), measures the time the web page takes to fully render and become interactive for the user. For example, suppose a web page loads multiple dynamic elements at different times. In that case, TTFC is when all critical resources, such as images, scripts, and styles, are rendered completely on the screen.
Have you ever wondered why some apps feel “instant” while others lag? The answer often lies in how efficiently their frontend is designed and how applications render data. Concepts like asynchronous loading, predictive prefetching, and lazy loading can make a huge difference. We’ll explore these concepts later in the course.
Factors affecting performance
Several factors influence the performance of a frontend system:
Network latency: The time data takes to travel between the client and server can affect the performance. If a website loads content from a distant server, users may experience noticeable delays.
Render-blocking resources: External scripts and stylesheets that prevent content from being displayed, resulting in performance issues. A website with multiple large CSS files may delay rendering until all styles are loaded, causing users to see a blank screen.
Large asset sizes: Heavy images, videos, and fonts can slow page load times. An e-commerce site using high-resolution images without optimization may frustrate users by slowing product page loads.
Inefficient code: Poorly optimized JavaScript,
, and redundant CSS can degrade performance. A web page with unnecessary JavaScript loops on every scroll event can slow interactions and make the user interface (UI) laggy.excessive reflows Reflows occur when the browser recalculates the layout of a web page due to changes in elements, such as resizing, adding/removing nodes, or modifying styles. Third-party dependencies: External libraries and ads can introduce delays in rendering. For example, A website embedding multiple third-party analytics scripts may experience longer load times as each script needs to be fetched and executed.
The following illustration indicates some methods or techniques that can improve the performance of an application, and we’ll discuss them in detail later in the course:
Conclusion
Performance is a crucial nonfunctional requirement (NFR) in frontend system design—it directly affects user experience, engagement, and even business outcomes. To build fast and responsive frontend apps, we need to understand key performance metrics, spot bottlenecks, and apply best practices—like optimizing assets, improving rendering, and making the most of network resources. These are just a few approaches—designing a truly fast and efficient system is challenging and involves understanding many underlying factors.
In this course, we’ll explore proven techniques to build high-performance frontend systems. Performance matters—but it’s not the only goal. Accessibility and compatibility are equally important in frontend system design, and we’ll explore those next.