They market Gatsby as a blazing fast framework. It’s true, but web vitals seem lower these days.
To me, it’s not due to Gatsby but recent changes in score calculations.
I love Gatsby. I think it’s fun, and every time I want to play with React, Gatsby is a pretty cool toolbox. However, there are some caveats, like with any other tool, and depending on your configuration, things could go rough, especially with performances.
I’m neither an advocate nor an ardent critic of Gatsby. I’m just another developer that runs tests and shares thoughts.
While I do take into account web vitals, I don’t like the 100% quest. To me, it’s not meaningful at all. Even Google itself doesn’t get 100%:
Why some developers don’t like Gatsby [anymore]
An “over-engineered” framework
While I understand the idea (I do ^^), people use this expression for anything and everything. Gatsby creators are trying to abstract a high-level of complexity away from developers. Their philosophy is unambiguous:
we’re just getting started. Gatsby is a playground for discovering new building blocks for the web.
It does not make sense for some developers, though, as Gatsby needs to generate and load many files, which paradoxically affects performances, especially the LCP score (Largest Contentful Paint).
Gatsby turns your website into a single page application (SPA) after the first load, so it tries to load as many resources as possible the first time, and then you get this slick and blazing fast navigation.
While performances are without question a critical concern, mainly because not everybody has access to boosted CPU and high-speed Internet connection in this world, you sometimes need a bit of give-and-take to deliver.
The massive range of dependencies
Gatsby’s ecosystem is its strength. There are tones of plugins and themes you can use to speed up development.
Nevertheless, it forces you to add many dependencies, even for the tiniest projects. Even if you know how to do it in “pure” React, reinventing the wheel is not the best strategy, and, IMHO, you miss the whole purpose of the framework.
In addition to this, multiplying plugins and other dependencies may add multiple points of failure, which may be problematic, as some plugins are no longer maintained.
Let’s be honest. It’s not due to Gatsby here. That’s open source in general.
Don’t use React everywhere
Unlike the previous statements, I think it’s a strong argument.
From that perspective, a blog might not be the best place for React as React allows for creating rich interfaces with many interactions.
React has some cost. That’s why you have those fantastic alternatives such as Preact, with just 3kB of code, which is almost ten times less than React.
Compared to simple combinations such as markdown, for example, with Jekyll, it is undoubtedly more complicated to use Gatsby or React in General, and you do load more stuff.
Great plugins to boost performances
Once you have all those potential caveats in mind, there are great Gatsby plugins and resources to mitigate performance issues you might encounter.
For example, you don’t have to use React.
Provides drop-in support for replacing React with Preact
Most of the time, it works, even if Preact doesn’t provide full support for the React ecosystem.
The potential gain is massive!
Remove unused css from css/sass/less/stylus files and modules in your Gatsby project using purgecss.
This one is a must-have plugin. It saves a lot of bytes!
Enable the website to work offline. It’s pretty useful for poor internet connections with many disrupts too.
It’s a radical approach, but it can be beneficial if you don’t need any interactivity and don’t use SPA features. Of course, I recommend it only for specific cases.
I hope you like this post. I wanted to share what I’ve tested and learned recently. The list of Gatsby plugins is not exhaustive at all. There are plenty of other plugins that help, for example, with web fonts.
However, I appreciate the preact plugin, such a great reward!