DEV Community: haitham medhat

React Performance vs. Web Performance: Understanding the Difference

haitham medhat — Fri, 14 Mar 2025 18:09:48 +0000

When discussing performance optimizations, it’s easy to mix up React performance techniques with broader web performance considerations. While they’re related, they actually tackle two different layers:

React Performance
This area focuses on making your React application run smoothly by minimizing unnecessary re-renders and stabilizing the virtual DOM (React’s “Fiber tree”). A common example is props drilling: passing data multiple levels down can lead to extra re-renders if not handled carefully (e.g., by using Context or other state-management solutions). Too many re-renders can degrade the user experience because the browser has to repeatedly update the DOM.

Web Performance
On the other hand, web performance is framework-agnostic and centers on techniques to reduce overall page load times and deliver content more efficiently. This involves:

Optimizing bundle sizes so users aren’t forced to download an excessive amount of JavaScript at once.
Reducing the time-to-first-byte (TTFB) by efficiently handling server responses.
Using pagination or data-fetching strategies to avoid over-fetching large amounts of data and slowing down initial renders.
Essentially, you want to ensure that your users see content as quickly as possible and that your site remains responsive during interaction.

Key Takeaways:

React performance is about optimizing how and when your components update the DOM.
Web performance is about delivering content and resources efficiently, no matter which framework or library you use.
Both matter for a good user experience: a well-optimized React app with huge bundle sizes can still cause slow page loads, and a tiny, fast-loading site with poorly managed React renders can still feel slow once loaded.

Building Better Code: Prioritize Reusability and Maintainability

haitham medhat — Wed, 05 Feb 2025 19:32:16 +0000

When building dynamic structures in your projects, it’s easy to get lost in overthinking. However, if your structure is maintainable and your components are reusable, you’re already on the right track. Let’s explore this concept with a real-world example.
Imagine you're frequently using tables in your code. Each table consists of a header and a body. Ask yourself: is it better to copy and paste that table across every page where it's needed, or to create a dedicated component for the header and body, which you can then include in a master table component?

By implementing a single table component, you can easily render it throughout your application by simply passing the data as props. This approach achieves two critical goals: reusability and adherence to the DRY (Don't Repeat Yourself) principle.

When to Know Your Code is Maintainable?

To assess your code's maintainability, consider how easily you can envision future features and scenarios. If implementing changes in a dynamic way feels straightforward, then your code is likely well-structured. However, if you find yourself adding numerous conditional renderings within a single component to handle custom cases, it might be time to create separate components. This keeps your code clean and maintainable, making it easier to adapt as requirements evolve.

Embracing these principles will help you build scalable and efficient applications that are a pleasure to work with.
By embracing these principles, not only will you build scalable and efficient applications, but you'll also save valuable time as a developer, allowing you to deliver features faster and with greater ease.

𝗚𝗼𝗼𝗱𝗯𝘆𝗲 𝘂𝘀𝗲𝗦𝘁𝗮𝘁𝗲 𝗳𝗼𝗿 𝗟𝗼𝗮𝗱𝗶𝗻𝗴 𝗦𝗽𝗶𝗻𝗻𝗲𝗿𝘀: 𝗛𝗼𝘄 𝘂𝘀𝗲𝗧𝗿𝗮𝗻𝘀𝗶𝘁𝗶𝗼𝗻 𝗠𝗮𝗸𝗲𝘀 𝗔𝘀𝘆𝗻𝗰 𝗢𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀 𝗦𝗺𝗼𝗼𝘁𝗵𝗲𝗿!

haitham medhat — Tue, 04 Feb 2025 21:50:39 +0000

Handling loading spinners during async operations is common, but the traditional approach using useState can lead to redundant re-renders and less organized code.


 const [loading, setLoading] = useState(false);

useEffect(() => {
 const fetchData = async () => {
 setLoading(true);
 try {
 const response = await fetch('/api/data');
 setLoading(false);
 return response;
 } catch (error) {
 setLoading(false);
 }
 }; 
 fetchData();
}, []);

While effective, this method requires manually toggling the state, increasing boilerplate and risking errors.

𝗪𝗵𝘆 𝗨𝘀𝗲 𝘂𝘀𝗲𝗧𝗿𝗮𝗻𝘀𝗶𝘁𝗶𝗼𝗻 𝗜𝗻𝘀𝘁𝗲𝗮𝗱?

With useTransition, you can prioritize updates and streamline loading logic:


 const [isPending, startTransition] = useTransition();
 startTransition(async () => {
 try { 
const response = await axios.post('/api/endpoint', { title, content });
 if (response.data.responseCode === 201) { showSuccessToast(response.data.responseMessage); router.push('/dashboard');
 } 
} 
catch (error) { 
showErrorToast(error?.response|| "An error occurred"); }
 }
);

𝗕𝗲𝗻𝗲𝗳𝗶𝘁𝘀:

No Manual State Management: React handles the isPending state for you.
Fewer Re-Renders: Updates are deferred, improving performance.
Cleaner Code: Focus on the logic, not the spinner.
React’s useTransition is a great tool for enhancing performance and reducing complexity. Have you used it yet? Share your experience!

𝗘𝗻𝗵𝗮𝗻𝗰𝗶𝗻𝗴 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗮𝗻𝗱 𝗥𝗲𝗱𝘂𝗰𝗶𝗻𝗴 𝗟𝗖𝗣 𝗧𝗶𝗺𝗲 𝗶𝗻 𝗡𝗲𝘅𝘁.𝗷𝘀.

haitham medhat — Mon, 03 Feb 2025 20:25:54 +0000

When optimizing the performance of a homepage in Next.js, it's essential to minimize Largest Contentful Paint (LCP) and First Contentful Paint (FCP) times. LCP measures the time it takes for the largest visible element (like an image or block of text) to load, while FCP measures how quickly the first content element appears on screen.
To achieve better performance, reduce LCP and TTFB (Time to First Byte), one effective approach is to split components and lazy load non-critical sections after the initial render. Here's how:

𝟭. 𝗥𝗲𝗻𝗱𝗲𝗿𝗶𝗻𝗴 𝗖𝗿𝗶𝘁𝗶𝗰𝗮𝗹 𝗖𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁𝘀 𝗙𝗶𝗿𝘀𝘁
The first component that appears on your homepage should be visible immediately. For other sections, they can load after the first render, reducing time to display initial content. If you have multiple sections, like six, and only the first one needs to be visible initially, use dynamic imports for the remaining sections.
Example :

import dynamic from "next/dynamic"; 
const Features = dynamic(() => import("./_components/home/Features "), {
 ssr: false,
 loading: () => <p>Loading...</p>,
});

By doing this, you prevent unnecessary JavaScript from loading during the first render, which helps reduce TTFB and speed up FCP.

𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗶𝗻𝗴 𝗟𝗖𝗣 𝘄𝗶𝘁𝗵 𝗜𝗺𝗮𝗴𝗲 𝗣𝗿𝗲𝗹𝗼𝗮𝗱𝗶𝗻𝗴
Images are often responsible for LCP. To improve performance, load important images earlier. The Next.js Image component allows you to set the priority prop on critical images:
This ensures that critical images are fetched as early as possible, reducing LCP times.
𝗥𝗲𝗱𝘂𝗰𝗶𝗻𝗴 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗮𝗻𝗱 𝗖𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁 𝗟𝗼𝗮𝗱
Split your code into smaller, lazily-loaded components. Using dynamic imports with ssr: false delays the loading of non-critical sections, making the page interactive faster and reducing JavaScript execution time.

𝗙𝗶𝗻𝗮𝗹 𝗧𝗵𝗼𝘂𝗴𝗵𝘁𝘀 :- To optimize your homepage's performance: Render critical components first and lazy load others with dynamic imports. Use the priority prop for images to load critical images earlier. Split components and load JavaScript lazily to reduce initial load time. These strategies will improve LCP, FCP, and overall performance, providing a faster and more responsive user experience

𝗪𝗵𝗮𝘁 𝗶𝘀 𝗛𝘆𝗱𝗿𝗮𝘁𝗶𝗼𝗻, 𝗮𝗻𝗱 𝗪𝗵𝘆 𝗗𝗼𝗲𝘀 𝗡𝗲𝘅𝘁.𝗷𝘀 𝗡𝗲𝗲𝗱 𝗜𝘁?

haitham medhat — Sun, 02 Feb 2025 22:11:48 +0000

In Next.js, we often encounter hydration errors, whether caused by our code or an extension that modifies the HTML. But before troubleshooting, it's essential to understand: What is hydration?

When using SSR (Server-Side Rendering) in Next.js, components that fetch only data (let’s call them static components) are rendered as HTML on the server, without client-side interactivity. This means the initial content delivered to the browser is static and non-interactive.

Next.js then downloads the JavaScript bundle and "hydrates" the page by attaching event handlers and restoring interactivity.

In short, hydration is the process of adding back interactivity and event handlers lost during server-side rendering.