Replacing react-share with next-share
I will summarize the process of replacing react-share with next-share and briefly outline the investigation into the issue of slow response on this blog.
The response of this blog was quite slow, so I began investigating
I've been concerned about the sluggishness of this blog's response from the beginning. Occasionally, it reaches a critically slow level, taking more than 5 seconds. There were several potential factors contributing to this issue, such as using App Router without much familiarity, relying on Chakra UI which is dependent on client-side components, implementing multilingual support through middleware, not implementing pagination, and since I wanted to prioritize progressing with the "release the smartphone app for now" story I mentioned in another article, I had put this on the backburner.
Warnings were appearing with react-share
There's also talk that Netlify is slow from Japan, but given that I've been able to use their services for free to this extent, I'm extremely grateful. While there might not be much that can be done, I felt there must be something to address before considering changing platforms. As I was examining the logs, I became concerned about the following warning, which seemed to be related to the usage of react-share:
next.js Icon: Support for defaultProps will be removed from function components in a future major release. Use JavaScript default parameters instead.
It appears that react-share is using defaultProps, which seems to be causing an issue.
I hadn't thought that this could be the cause of the performance decline, but even on the local environment, there were times where it took a few seconds. So, I decided to comment out the implementation of react-share, and it appeared to improve.
Moreover, there was an issue where the buttons weren't functioning properly when sharing to X (Twitter) from a smartphone's browser. So, I thought this would be a good opportunity for a replacement.
Trying next-share as a replacement
When I searched for "react sns share," almost all articles were using react-share. However, when I looked for alternatives, I came across a package called next-share. It had been updated recently and seemed to be well-maintained, so I decided to replace it.
I removed react-share and added next-share:
$ yarn remove react-share
$ yarn add next-share
The code changes were minimal, and it's evident that next-share was designed with compatibility in mind.
before
import {
FacebookIcon,
FacebookShareButton,
HatenaIcon,
HatenaShareButton,
LineIcon,
LineShareButton,
TwitterIcon,
TwitterShareButton,
} from 'react-share'
after
import {
FacebookIcon,
FacebookShareButton,
HatenaIcon,
HatenaShareButton,
LineIcon,
LineShareButton,
TwitterIcon,
TwitterShareButton,
} from 'next-share'
I submitted a pull request with these changes, including other minor modifications.
https://github.com/tkugimot/nextjs-microcms-blog-handson/pull/22?w=1
Confirmation after deployment
Naturally, the warnings disappeared. Regarding speed, I didn't conduct thorough performance tests, so I can't provide precise information. However, based on browser observations, it generally returns in around 300ms. Nevertheless, there are still occasional instances where it takes 3-4 seconds or even more than 5 seconds.
Regarding the issue of slow response
When I was using react-share, it was slow even in the local environment. However, after the changes, everything is returned within 100-300ms in the local environment. This means the slow response issue only occurs after deployment, suggesting that the cause is related to communication with the Netlify server. Nevertheless, considering that I'm using their services for free, I'm truly grateful. If I can generate income from side projects in the future, I intend to prioritize investing in this aspect.