Forem: Marko Rajević

Service Workers

Marko Rajević — Sat, 02 Dec 2023 19:30:08 +0000

A Service Worker is a script that runs in the background of a web browser and, they are the answer if you're aiming for:

Fast loading (even in unpredictable network conditions)
Offline access
Real-time push notifications
Background sync

The Service Worker can continue to operate even when the web page is closed, thus allowing for extended functionality that enhances the user experience.

They operate on their thread, separate from the main thread.
Service Workers are restricted to running only over HTTPS for security reasons.
Do not have access to the DOM.

Service Workers are a cornerstone technology for building Progressive Web Apps (PWAs), applications that can be installed on a device and run offline, offering a native-like experience.

And if you're looking to transform your application into a state-of-the-art Progressive Web App (PWA), Service Workers are the pivotal key.
 

Installing and running a Service Worker

First, you'll need to create a JavaScript file that will serve as your Service Worker. Let's call this file service-worker.js. In this file, you can specify what happens when various lifecycle events occur.

// service-worker.js
self.addEventListener('install', (event) => {
    // Perform install steps
    // e.g. caching important files
});

self.addEventListener('fetch', (event) => {
    // Handle fetch events
    // e.g. serving cached files or making a network request
});

// ... other events like 'activate', 'push', etc.

To make your web application use the Service Worker, you need to register it. This is usually done within your main JavaScript file.

// Check if service workers are supported
if ('serviceWorker' in navigator) {
    // Register the service worker
    navigator.serviceWorker.register('/service-worker.js')
        .then((registration) => {
            console.log('Service Worker registered with scope:', registration.scope);
        })
        .catch((error) => {
            console.log('Service Worker registration failed:', error);
        });
}

And that’s it!
Now you are ready to write some logic for your Service Worker. 🚀🚀🚀
 

Service Worker Lifecycle

Registration:

The first step in using a Service Worker is to register it.
This is typically done in your main JavaScript file.
The navigator.serviceWorker.register() method is used for this purpose. It returns a Promise that resolves with a ServiceWorkerRegistration object.

Installation:

After successful registration and download, the Service Worker enters the install phase.
An install event is fired at this point, which you can listen for in the Service Worker script.
If everything in the install event is successful, the Service Worker moves to the next phase. If not, it's discarded.

Activation:

After installation, the Service Worker enters the activate phase.
The activate event is fired, allowing you to perform tasks like cleaning up old caches.
A Service Worker will control pages once it's activated. If there's a currently active Service Worker, the new one won't activate until the current one is released from controlling the pages.

Idle:

After activation, the Service Worker enters an idle state. It's alive but not processing any tasks.
The browser can terminate it to save memory but can be quickly restarted when needed.

Termination:

If a Service Worker is idle for too long or uses too much memory, the browser may terminate it. It will be restarted the next time it's needed.

Update:

When a new version of a Service Worker is available (detected during registration), it's installed in parallel to the current one but won't be activated until the current one releases control.
This ensures that only one version of a Service Worker is active at a time for a given scope.

Redundant:

If there's an error during the installation or if the Service Worker is replaced by a newer version, it enters a redundant state and won't control pages.
 

Service Workers and caching

Service workers help web apps by intercepting network requests and using cached resources. This makes apps load and work faster. When there's no internet, service workers let the app run by getting everything from the cache.
 

The most popular caching strategies are:

Cache First (Cache, falling back to Network):
- The service worker checks the cache first.
- If the requested resource is found in the cache, it's returned immediately.
- If not, the service worker fetches it from the network, caches it for future use, and then returns it to the client.
- This strategy is great for static assets that don't change often.
Network First (Network, falling back to Cache):
- The service worker tries to fetch the resource from the network first.
- If the network request succeeds, the fetched resource is returned.
- If the network request fails (e.g., no internet connection), the resource is fetched from the cache.
- Suitable for resources that update frequently.
Cache Only:
- The service worker retrieves the resource only from the cache.
- If the resource isn't in the cache, an error is returned.
- Useful for resources that are always cached (e.g., core app shell components).
Network Only:
- The service worker bypasses the cache and fetches the resource only from the network.
- Useful for requests that don't need to be cached or can't be cached (e.g., real-time updates).
Cache and Network Race (Fastest):
- The service worker initiates requests to both the cache and the network simultaneously.
- The first response to arrive (either from the cache or the network) is returned.
- Useful when speed is crucial, and you want the fastest source to win.
Stale While Revalidate:
- The service worker returns the resource from the cache immediately (if available) and, in parallel, fetches a fresh copy from the network to update the cache.
- This ensures that the user gets a quick response, and the cache is kept up-to-date for future requests.

 
Example: Stale while Revalidate strategy

const CACHE_NAME = 'my-cache';

self.addEventListener('fetch', event => {
  event.respondWith(staleWhileRevalidate(event.request));
});

async function staleWhileRevalidate(request) {
  const cachedResponse = await caches.match(request);

  // If the response exists in the cache, return it
  if (cachedResponse) {
    // Fetch a fresh copy in the background to update the cache
    updateCache(request);
    return cachedResponse;
  }

  // If not in cache, fetch from network
  return fetch(request);
}

function updateCache(request) {
  fetch(request).then(networkResponse => {
    // Open the cache and put the fresh response in it
    caches.open(CACHE_NAME).then(cache => {
      cache.put(request, networkResponse);
    });
  });
}

Push Notifications

Real-time push notifications with service workers can be a powerful feature for web applications, especially for engaging users with timely updates.
 

How Real-Time Push Notifications works

User Consent: Before sending push notifications, you need to get the user's permission. This is typically done through a prompt asking the user to allow notifications.
Push Subscription: Once the user consents, the service worker subscribes to push notifications using the Push API. This generates a unique endpoint for the user's device.
Sending Notifications: When a notification needs to be sent, your server sends a push message to the push service provided by the browser, which then delivers the message to the correct client.
Receiving Notifications: The service worker receives the push message and can show a notification to the user, even if the web app is not open in the browser at that time.

Use Cases for Push Notifications

Chat Applications: Notifying users of new messages or calls when they are not currently looking at the chat application.
News or Blog updates: Informing users about new articles or breaking news.
Social Media: Updates on new posts, comments, likes, or friend requests.
E-commerce: Alerts about sales, order status updates, or new product launches.

  
Example: show notification with the Service Worker

self.addEventListener('push', function(event) {
  const options = {
    body: event.data.text(),
    // Other options like icon, image, etc.
  };

  event.waitUntil(
    self.registration.showNotification('Notification Title', options)
  );
});

Background Sync

It allows web applications to perform tasks in the background, even when the user is not actively using the app or when the app is not open in a browser tab. It's especially useful for scenarios where data needs to be synchronized with a server or other background tasks need to be executed.
 

How Background Sync works

Queueing: When your web app needs to perform a background task, such as sending data to a server, it creates a background sync event and adds it to a queue managed by the service worker. The event includes details about the task to be performed.
Network Connection: The service worker waits for a suitable network connection to become available.
Execution: Once a suitable network connection is detected, the service worker retrieves the queued background sync events from the queue and executes them.

Use Cases for Background Sync

Form Submissions: Background Sync is useful for ensuring that form submissions are not lost, even if the user loses their connection during the submission process.
Offline Data Sync: One of the most common use cases is offline data synchronization. For example, consider a note-taking app. When a user creates or edits a note while offline, the app can queue these changes as background sync events.
Scheduled Tasks: Background Sync is not limited to data synchronization. It can also be used for scheduling and executing periodic background tasks, such as data cleanup, database maintenance, or any other background processes required by your app.

 
Example: send form data using background sync

// In a React component

function handleSubmit(formData) {
  if (navigator.onLine) {
    // If there is internet connectivity, perform a regular form submission
    sendFormDataToServer(formData)
      .then(() => {
        console.log('Form submitted successfully.');
      })
      .catch((error) => {
        console.error('Form submission failed:', error);
      });
  } else {
    // If there's no internet connectivity, save the data to the IndexedDB
    // and queue it for background sync.
    ... // Save data to the IndexedDB
    handleSyncData();
  }
}

// In a React component

function handleSyncData() {
  if ('serviceWorker' in navigator && 'SyncManager' in window) {
    navigator.serviceWorker.ready
      .then((registration) => {
        return registration.sync.register('sync-data');
      })
      .catch((error) => {
        console.error('Failed to register background sync:', error);
      });
  } else {
    // Fallback for browsers that don't support background sync.
    // You can implement an alternative offline strategy here.
  }
}

// service-worker.js

self.addEventListener('sync', (event) => {
  if (event.tag === 'sync-data') {
    event.waitUntil(syncDataWithServer());
  }
});

function syncDataWithServer() {
  // Retrieve the queued data from the IndexedDB
  const formData = ...

  if (!formData) {
    return;
  }

  return fetch('/api/sync', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(formData),
  })
    .then((response) => {
      if (response.ok) {
        // Data synchronization was successful; you can clear the data from the IndexedDB
        ...
        console.log('Data synced successfully.');
      } else {
        // Handle synchronization failure, e.g., retry or logging errors.
        console.error('Data sync failed:', response.status);
      }
    })
    .catch((error) => {
      console.error('Error while syncing data:', error);
    });
}

Conclusion

The integration of Service Workers into web applications marks a revolutionary step in enhancing user experience and functionality.

By leveraging their ability to work offline, manage caching strategies, and implement push notifications and background sync, Service Workers empower developers to create more resilient and user-friendly web applications.

This technology not only improves the performance of web apps under challenging network conditions but also opens up new possibilities for real-time interactions and data management.

As the web continues to evolve, embracing Service Workers will be essential for developers looking to build progressive, efficient, and engaging web applications.

The journey into the world of Service Workers is an exciting one, filled with opportunities to innovate and improve the way users interact with web technology. 😊

React 18 - performance improvements

Marko Rajević — Sun, 29 May 2022 21:14:14 +0000

Recently React released version 18 with some great features.
In this post we will take closer look at performance related features.

useTransition

It's part of the concurrency concept where you can prioritize state updates.
Urgent state updates can be prioritized over less urgent (blocking) updates.

How to use it and how this new hook improves your app performance will learn in the example which can be found here.

This is our example. It's a simple one, we have a button that opens a modal, and within the modal, we render a list of 500 comments.
500 comments is a lot but this will work just fine on most devices.

import { useState } from "react";
import Comments from "../components/Comments";
import Modal from "../components/Modal";
import data from "../data/index.json";

export default function Home() {
  const [isOpen, setIsOpen] = useState(false);
  const [comments, setComments] = useState([]);

  return (
    <div className="p-4">
      <button
        className="px-4 py-2 border-none rounded-sm bg-blue-800 text-white"
        onClick={() => {
          setIsOpen(true);
          setComments(data);
        }}
      >
        Toggle modal
      </button>
      <Modal
        isOpen={isOpen}
        onClose={() => {
          setIsOpen(false);
          setComments([]);
        }}
      >
        <Comments comments={comments} />
      </Modal>
    </div>
  );
}

But, if we slow down the rendering of the Comment component 😈 things get more interesting.
To achieve that I added for loop to iterate one milion times.

const Comment = ({ name, email, body, className, onClick }: CommentProps) => {
  const soooSloww = [];

  for (let i = 0; i < 1000000; i++) {
    soooSloww.push(i);
  }

  return (
    <article className={className} onClick={onClick}>
      <h3 className="font-semibold">{name}</h3>
      <h4 className="text-gray-500 italic">{email}</h4>
      <p>{body}</p>
    </article>
  );
};

Now, when you click the button to open the modal nothing happens for a few seconds.
That's because the browser is busy rendering slow 500 Comment components.
After some time the modal and the comments are rendered.

From a user perspective, this is very bad UX.
How to improve it?
We can prioritize renders, and in our example, it's more important to first render the modal and after that comments.

useTransition hook returns two variables, pending which is a boolean flag that the transition is not yet finished, and startTransition function where you execute your less important state updates.

const [pending, startTransition] = useTransition();

Now, our example look like this

export default function Home() {
  const [isOpen, setIsOpen] = useState(false);
  const [comments, setComments] = useState([]);
  const [pending, startTransition] = useTransition();

  return (
    <div className="p-4">
      <button
        className="px-4 py-2 border-none rounded-sm bg-blue-800 text-white"
        onClick={() => {
          setIsOpen(true);
          startTransition(() => {
            setComments(data);
          });
        }}
      >
        Toggle modal
      </button>
      <Modal
        isOpen={isOpen}
        onClose={() => {
          setIsOpen(false);
          setComments([]);
        }}
      >
        {pending ? "Loading..." : <Comments comments={comments} />}
      </Modal>
    </div>
  );
}

You can notice that on the button click we update the state to show the modal, which is the action with the higher priority, and update the comments state within the startTransition function which tells React that state update is with lower priority.

Also, we used the pending flag to show a user the' Loading...' text while slow comments are rendered.
Now, after clicking the button you will immediately get the modal which looks like this:

Much better user experience! 😀

useDeferredValue

This hook also tells React that certain state updates have a lower priority.
It is similar to the useTransition and to be honest I'm not sure what are use cases when you should prefer useDeferredValue over useTransition, if you have an idea please let me know in the comments. 👇

Our previous example now looks like this and behaves similarly except we don't have the pending flag.

export default function UseDeferredValues() {
  const [isOpen, setIsOpen] = useState(false);
  const [comments, setComments] = useState([]);
  const commentsToRender = useDeferredValue(comments);

  return (
    <div className="p-4">
      <button
        className="px-4 py-2 border-none rounded-sm bg-blue-800 text-white"
        onClick={() => {
          setIsOpen(true);
          setComments(data);
        }}
      >
        Toggle modal
      </button>
      <Modal
        isOpen={isOpen}
        onClose={() => {
          setIsOpen(false);
          setComments([]);
        }}
      >
        <Comments comments={commentsToRender} />
      </Modal>
    </div>
  );
}

Automatic batching

When you are working with React you should aim to have rerenders as less as possible.
Now React 18 helps you to achieve that with automatic batching.

Earlier versions of React batched multiple state updates only inside React event handlers like onClick or onChange to avoid multiple re-renders and improve performance.

Now, React batches state updates in React events handlers, promises, setTimeout, native event handlers and so on.

const AutomaticBatching = () => {
  const [countOne, setCountOne] = useState(0);
  const [countTwo, setCountTwo] = useState(0);

  console.log("render");

  const onClick = useCallback(() => {
    setCountOne(countOne + 1);
    setCountTwo(countTwo + 1);
  }, [countOne, countTwo]);

  useEffect(() => {
    document.getElementById("native-event").addEventListener("click", onClick);

    return () =>
      document
        .getElementById("native-event")
        .removeEventListener("click", onClick);
  }, [onClick]);

  const onClickAsync = () => {
    fetch("https://jsonplaceholder.typicode.com/todos/1").then(() => {
      setCountOne(countOne + 1);
      setCountTwo(countTwo + 1);
    });
  };

  const onClickTimeout = () =>
    setTimeout(() => {
      setCountOne(countOne + 1);
      setCountTwo(countTwo + 1);
    }, 200);

  return (
    <div className="p-4">
      <ul className="mb-8">
        <li>Count one: {countOne}</li>
        <li>Count two: {countTwo}</li>
      </ul>
      <Button onClick={onClick}>Batching in click event</Button>
      <Button id="native-event" className="ml-4">
        Batching in native click event
      </Button>
      <Button className="ml-4" onClick={onClickAsync}>
        Batching in fetch
      </Button>
      <Button className="ml-4" onClick={onClickTimeout}>
        Batching in timeout
      </Button>
    </div>
  );
};

In this example, you can see that in every event handler we have two state changes but only one rerender. You can notice that with one console.log for each event.

Improved Suspense

Suspense works with React.lazy in that way that suspends component rendering until it's loaded and during that time renders a fallback.

const LazyComponent = lazy(() => import("../components/LazyComponent"));

<Suspense fallback={<div>Loading...</div>}>
  <LazyComponent />
</Suspense>

This is a great way to improve performance in that way you will not include in the initial bundle some parts of the app that you don't need immediately (e.g. modals).

But, Suspense is not a new feature, it existed in the previous versions of React, the new is that now it works with server-side rendering which wasn't the case before.

That's all folks, hope you like the new version of React. 😀
All examples from above can find it here.

React performance - how to

Marko Rajević — Wed, 30 Mar 2022 23:09:53 +0000

In this post, we will go through some techniques and solutions to achieve good performances in your React application.

Dynamic import

Your app doesn't need to be one big bundle because you don't need all parts of your application immediately.

If you build a website with multi-pages you need the current page to be loaded immediately and other later when the user request those.

import { useState } from 'react';
import dynamic from 'next/dynamic';

const Modal = dynamic(() => import('../components/Modal'));

function Home() {
  const [showModal, setShowModal] = useState(false);

  return (
    <div>
      <button onClick={() => setShowModal(!showModal)}>Toggle modal</button>
      {showModal && <Modal />}
    </div>
  )
}

export default Home

Next.js does this by default for you. It will create separate smaller bundles for each of your pages (routes).

Furthermore, you can dynamically load components and parts of the application which are not visible by default like modals or panels.

In the example above code for Modal will not be loaded until the component is rendered which means that your main bundle will be smaller and the initial page load faster.

If you are not using Next.js the same thing you can achieve with React.lazy.

React.memo

One thing that you don't want from your React app is unnecessary rerender 🙂.

If you wrap your component with React.memo you can ensure that your component will rerender only on props or state change, not whenever the component parent rerender.

React.memo compares prev and next props and if those are the same React will skip rendering the component, and reuse the last rendered result.
By default, props are compared shallowly but you can provide your custom comparison function as the second argument.

function MyComponent(props) {
  ...
}
function areEqual(prevProps, nextProps) {
  /*
  return true if passing nextProps to render would return
  the same result as passing prevProps to render,
  otherwise return false
  */
}
export default React.memo(MyComponent, areEqual);

When to use React.memo is up to you, my recommendation is to use it when you have a problem with the performance and rerenders of your component is too expensive.
Also, you can use it by default for the components with a lot of elements, like the lists or the tables.

How to properly use useCallback with React.memo you can check in my previous post here.

Profiler

Measure performances.

A great way to locate the components which are rerendering too many times or render slowly is to use Profiler HOC.
More about it you can read it here.

For the component you want to measure performances you need to wrap it with Profiler component.
Props that you need to pass to the Profiler are id and onRender.

return (
  <App>
    <Profiler id="Navigation" onRender={callback}>
      <Navigation {...props} />
    </Profiler>
    <Main {...props} />
  </App>
);

Also, you can have multiple Profile components at the same time and you can nest them to measure the performances of different components within the same subtree.

onRender callback provides the next, very useful, informations.

function onRenderCallback(
  id, // the "id" prop of the Profiler tree that has just committed
  phase, // either "mount" (if the tree just mounted) or "update" (if it re-rendered)
  actualDuration, // time spent rendering the committed update
  baseDuration, // estimated time to render the entire subtree without memoization
  startTime, // when React began rendering this update
  commitTime, // when React committed this update
  interactions // the Set of interactions belonging to this update
) {
  ...
}

The most important information here is actualDuration, which shows how much time the component is needed for that current render.
Compare this time with baseDuration which is the time needed to render the component and entire subtree without memoization.

useMemo

This hook can help you if you create an object or an array within your component and that creation is time expensive.

It accepts two parameters. The first one is the function that returns the value you want to memoize and the second one is an array of dependencies.
If any of the dependencies change useMemo will recalculate the value, otherwise will return memoized value.

const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);

When to use it?
Well, I think that you can recognize operations that are expensive and can be memoized.
For example, if you have the map function within another map function and you are working with long arrays, that will be slow and it's good to be memoized.
Off course, you can measure how much time is needed for a specific operation and decide based on that.
For this purpose performance.now() can be used.

react-window

React is not very performant when it comes to rendering large lists or grids.

To resolve this problem plugins like react-window can be used.
The strategy is to only render the number of items that are in the viewport.

From the documentation:

It reduces the amount of work (and time) required to render the initial view and to process updates.
It reduces the memory footprint by avoiding the over-allocation of DOM nodes.

import { FixedSizeList as List } from 'react-window';

const Row = ({ index, style }) => (
  <div style={style}>Row {index}</div>
);

const Example = () => (
  <List
    height={150}
    itemCount={1000}
    itemSize={35}
    width={300}
  >
    {Row}
  </List>
);

Good practices

Debounce function.
It's not directly related to React but it can be applied.

If you call a function on an event that often occurs it's a good practice to debounce it.

You can use the debounce function from some library like Lodash or create your own.

function debounce(func, timeout = 250){
  let timer;

  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => { func.apply(this, args); }, timeout);
  };
}

Now, for example, if you need to do something on window resize or scroll, it can be written like this:

useEffect(() => {
  const onResize = debounce(function() {
    // The function's code
  }, 250);
  const onScroll = debounce(function() {
    // The function's code
  }, 250);

  window.addEventListener('resize', onResize);
  window.addEventListener('scroll', onScroll);

  return () => {
    window.removeEventListener('resize', onResize);
    window.removeEventListener('scroll', onScroll);
  }
});

Think how you organize your components.

For example, if you have this component:

const ItemsList = ({ items }) => {
  const [inputValue, setInputValue] = useState('');

  return (
    <div>
      <input type="text" value={inputValue} onChange={(e) => setInputValue(e.target.value)} />
      {items.map((item) => {
        ...
      })}
    </div>
  )
}

The problem with this is that the entire component will rerender on every input change which is not optimal because besides the input there is the list of items as well which stays unchanged.

A better approach would be to move input out of the component and wrap the ItemsList component with React.memo so it can depend only on the items prop.

const ItemsList = React.memo(({ items }) => {
  return (
    <div>
      <input type="text" value={inputValue} onChange={(e) => setInputValue(e.target.value)} />
      {items.map((item) => {
        ...
      })}
    </div>
  )
})

const ParentComponent = () => {
  const [inputValue, setInputValue] = useState('');
  const [items, setItems] = useState([...]);

  return (
    <div>
      <input type="text" value={inputValue} onChange={(e) => setInputValue(e.target.value)} />
      <ItemsList items={items} />
    </div>
  )
}

That's all, have fun and create performant React apps. 😉

Are you using useCallback properly 🤔

Marko Rajević — Sun, 20 Mar 2022 20:16:34 +0000

I didn't up until recently.
On the project my team is working on, we used useCallback for every function prop passed to the child components.
This approach doesn't give you benefits as you may expect.

Our code looked like this (not literally 😀)

const ParentComponent = () => {
  ...
  const onClick = useCallback(() => console.log('click'), [])  

  return <ChildComponent onClick={onClick} />
}

const ChildComponent = ({ onClick }) => {
  return <button onClick={onClick}>Click me</button>
}

Approach without useCallback

const ParentComponent = () => {
  ...
  return <ChildComponent onClick={() => console.log('click')} />
}

The benefits of the first approach compared to the second one are minimal and in some cases considering the cost of useCallback the second approach is faster.

The thing is creating and destroying functions on each rerender is not an expensive operation as you may think and replacing that with useCallback doesn't bring much benefits.

Another reason why we always used the useCallback hook is to prevent the child component rerender if its props didn't change but this was wrong because whenever the parent component rerenders the child component will rerender as well nevertheless the child props are changed or not.

React.memo

If you want to rerender the child component only when its props or state changed you want to use React.memo.
You can achieve the same with PureComponent or shouldComponentUpdate if you are working with class components instead of functional.

If we wrap ChildComponent from our first example with React.memo

const ChildComponent = React.memo(({ onClick }) => {
  return <button onClick={onClick}>Click me</button>
})

when the ParentComponent rerenders and props of the ChildComponent don't change, the ChildComponent will not rerender.

This gives us a good insight when we should use useCallback hook.
useCallback should be used in combination with the React.memo.

I will not say that should be always the case, you can use useCallback without React.memo if you find it useful but in most cases, those two should be the pair. ❤

When to use React.memo

There are no clear instructions on when to do it, someone thinks you should use it always and I'm for the approach "measure performance of your component and optimize it with React.memo if needed".

The components which you can wrap with React.memo by default are those with a lot of children like tables or lists.

Now we will take a look at an example.
You can clone it and try it by yourself from here https://gitlab.com/markoarsenal/use-callback.

It looks like this (very creative 😀)

We have a long list of comments (a good candidate for React.memo) and we have the counter button on the top whose main purpose is to trigger the rerender.

The code looks like this

const Home = () => {
  const [counter, setCounter] = useState(0);
  const onClick = useCallback(() => console.log("click"), []);

  return (
    <Profiler
      id="Home page"
      onRender={(compName, mode, actualTime, baseTime) =>
        console.log(compName, mode, actualTime, baseTime)
      }
    >
      <main className="max-w-5xl p-8 m-auto">
        <div className="flex justify-center mb-8">
          <button
            onClick={() => setCounter(counter + 1)}
            className="px-3 py-1 border border-gray-500"
          >
            Update {counter}
          </button>
        </div>
        <Comments comments={comments} onClick={onClick} />
      </main>
    </Profiler>
  );
};

You can notice Profiler component as a root component, it's this one https://reactjs.org/docs/profiler.html.
We are using it to measure rendering times.
You can notice onRender callback, we are logging a couple of things inside but the most important are actualTime and baseTime. The actualTime is the time needed for component rerender and baseTime is the time to rerender component without any optimizations. So if you don't have any optimizations within your component actualTime and baseTime should be equal.

Comments component looks like this (notice that is wrapped with React.memo)

const Comments = ({ comments, onClick }: CommentsProps) => {
  return (
    <section>
      {comments.map((comment) => {
        return (
          <Comment
            {...comment}
            className="mb-4"
            onClick={onClick}
            key={comment.id}
          />
        );
      })}
    </section>
  );
};

export default memo(Comments);

Now I will run our example with 500 comments in Chrome, hit the "Update" button a few times to cause rerender and post results here.

So, on every rerender we are saving around 30ms which is considerable.

Let's try one more thing, instead of the list of the comments to render one, memoized comment and see what measurements are.

{/* <Comments comments={comments} onClick={onClick} /> */}
<Comment {...comments[0]} onClick={onClick} />

Still, we have time savings but they are neglecting which means that React does not have trouble rerendering those small and simple components, and memoizing those doesn't have much sense.
On the other hand memoizing component that contains a lot of children is something you can benefit from.

Hope you enjoyed reading the article and that now you have a better overview of useCallback and React.memo and when to use them.