radEventListener: a Tale of Client-side Framework Performance

React's popularity isn't without its detractors. The framework's considerable size (around 120 KiB minified) significantly impacts startup times, especially when relying solely on client-side rendering. Even server-side rendering with client-side hydration remains performance-intensive. While React excels in complex state management, its resource demands often outweigh the benefits in simpler applications. This can effectively exclude users with less powerful hardware.

Despite my reservations about React's performance overhead, I appreciate its componentization model and JSX syntax. Server-side rendering (or using Preact, my preferred alternative) remains a valuable asset. However, determining the appropriate client-side usage remains a challenge. This article details my findings on optimizing React performance for a better user experience.

The Context: An RSS Feed App

My RSS feed app, bylines.fyi, uses JavaScript on both the server and client. While I don't inherently dislike client-side frameworks, my experience highlights two recurring issues:

1. Frameworks can obscure the underlying web platform, hindering a deep understanding of when they are truly beneficial.
2. Frameworks don't always guarantee optimal user experiences.

Tim Kadlec's HTTPArchive research on web framework performance reinforces these concerns, revealing React's less-than-stellar performance. My goal was to leverage React's server-side advantages while mitigating its client-side drawbacks.

The Experiment: Mobile Navigation Toggle

My RSS app needed client-side JavaScript for a simple mobile navigation toggle—a classic example of "simple state." I often see React components overused for such simple tasks, leading to unnecessary performance overhead. This experiment, while seemingly trivial, serves as a crucial benchmark for understanding how framework choices scale. It's important to note that most developers wouldn't solely rely on React for such a minor feature, but the results illustrate architectural implications for runtime performance.

Test Conditions

The experiment compared three mobile nav implementations across four devices:

1. Stateful React component: Server-rendered and client-hydrated.
2. Stateful Preact component: Server-rendered and client-hydrated.
3. Stateless Preact component: Server-rendered, not hydrated; using standard event listeners.

Devices included:

1. Nokia 2 Android phone (Chrome 83)
2. ASUS X550CC laptop (Windows 10, Chrome 83)
3. 1st Generation iPhone SE (Safari 13)
4. 2nd Generation iPhone SE (Safari 13)

Metrics

The following metrics were measured for each implementation and device:

1. Startup time: Including framework loading and hydration (React/Preact), or just event listener code (EventListener).
2. Hydration time: A subset of startup time (React/Preact only).
3. Mobile nav open time: Measuring framework overhead in event handling.

Methodology

Testing involved remote debugging and profiling, recording CPU time for each metric across ten iterations per scenario and device. Network performance was not a factor.

Results

Due to the complexity of the data, the results are presented in tabular format showing minimum, maximum, median, and average CPU times. (Detailed tables are available in the accompanying spreadsheet). Key findings include:

• React's high startup and hydration costs: Particularly noticeable on the low-end Nokia 2.
• Preact's improved performance: Significantly faster than React, but still exceeding ideal frame budgets on the Nokia 2.
• Superior event listener performance: Consistently faster than both React and Preact, especially for simple interactions.

Discussion: Shallow Call Stacks

The performance differences stem from the overhead of framework loading and hydration. While some performance trade-offs are inevitable for developer convenience, the balance often tilts too heavily towards developer experience at the expense of the user. The call stacks for React and Preact hydration highlight the significant processing demands, especially for simple tasks. Using native event listeners offers a much more efficient approach for simple state management.

Conclusion and Recommendations

This analysis isn't intended as a React critique, but rather an encouragement to critically evaluate framework choices and their performance impact. Several strategies can mitigate performance issues:

1. Refactor stateful components to stateless components where possible.
2. Avoid client-side JavaScript and hydration for stateless components.
3. Use framework-independent event listeners for simple interactions.
4. Lazily hydrate components using Intersection Observer or requestIdleCallback.
5. Consider Preact as a faster alternative to React.
6. Adapt the user experience for low-memory devices using navigator.deviceMemory.

Prioritize performance testing across a range of devices, ensuring inclusivity for users with varying hardware capabilities. The goal should be a fast and accessible web experience for everyone.

Special thanks to Eric Bailey for editorial feedback and the CSS-Tricks staff for publishing this article.

The above is the detailed content of radEventListener: a Tale of Client-side Framework Performance. For more information, please follow other related articles on the PHP Chinese website!