I get a bad feeling in the pit of my stomach when I have to tell someone that there is something deeply wrong with their website—especially when I know that it is too late to fix it. I hate that feeling. And I felt it twice recently.
On one call, I spoke to a friend of a friend who has built a startup non-profit trying to make a difference on our climate crisis. She told me how when they built their software-as-a-service (SaaS) product, she had been advised to build it on Drupal. She felt that she received bad advice. She had since been told that Drupal wasn’t a good platform for a SaaS product.
So they were moving to using Drupal headless and a new version of their product built on React.
“Oh no,” I thought to myself.
This founder managed to separate herself from the perceived mistake of Drupal only to be steered into React groupthink. Despite nearly a decade of well-founded criticism, web developers continue to push React onto unsuspecting product owners.Footnote 1
Why? It is often some combination of “everyone uses React” and it being the tech stack they are familiar with. Of course, that hammer-sees-nails approach is likely what led to Drupal originally.
Unfortunately, it is too late to do anything about it. The app is already in final testing. The new version of the product is supposed to launch within the month.
What am I supposed to say when she asks if the app “at least gets a passing grade?”
The second conversation was with an ecommerce company we’re consulting on performance issues. We’ve identified many places to improve that should have an impact, but the site’s reliance on third-party scripts makes it difficult to help.
For example, they’re using Bolt for their account and checkout experiences. Bolt replaces their ecommerce platform’s built-in checkout process with what amounts to a single page application.
Unfortunately, Bolt downloads 771k of code across four different domains. Bolt causes 4,438 milliseconds of blocking time making it the biggest performance offender.Footnote 2 Bolt is built using React. It is included on every page.
But what can the ecommerce company do about it? They rely on the Bolt checkout to supply features that their ecommerce platform doesn’t provide. They can’t remove it now. Especially not with the holiday season around the corner.
Bolt is just one example. There are numerous third-party scripts they’ve come to rely on that they can’t remove or change. We had hoped to be able to move some scripts to a web worker to reduce the burden on users, but we couldn’t find enough scripts that function in a web worker to make a difference. This was a depressing realization.
The hard work of removing or replacing third party scripts will be a large effort. It may even mean moving to another ecommerce platform that has more tools built in so they don’t have to rely on third-party scripts as much.
Whatever the solution is, it will have to wait until 2024. The technical debt is overwhelming and we’re too late to fix it.
I try to write articles that teach. We like to share what we learn. I like to think people can walk away with ideas on how they can improve their website and their business. I don’t know what takeaways I can offer here. These situations depress me.
How do non-technical founders know if they are getting good advice from the technical people they hire? How do they know if the solutions being proposed work well for them and their users as opposed to being solutions informed primarily by what technology the developers are comfortable with?
How do small ecommerce companies know what impact these third-party scripts will have on their site? Some of these scripts provide key features that the underlying platform doesn’t. All of these small scripts add up and at some point, their site speed and search engine ranking are affected. But by that point, fixing the issues is a major project. The rot has spread throughout the house.
To sum it up, how do you know who you can trust with your online business?
I wish I had a time machine and could go back to when these decisions were being made and help the organizations avoid getting into these positions in the first place. I wish there was more time in the day to help people. If I were independently wealthy, maybe I could just open my calendar and advise anyone who needed it.
So I beg of other technical folks in our industry, please guide people to better solutions even if it isn’t using technology you know—even if it means you won’t get the work. Stop using React as the default. We know enough about its shortcomings by now. And if you’re going to develop a third-party script, put performance at the top of your priority list.
Finally, if you or someone you know needs to talk to someone about their online presence and needs honest, trustworthy advice, please reach out to me. I’d love to help more people avoid phone calls like these ones.
React was never built to be fast. The creators themselves said, “So people started playing around with this internally, and everyone had the same reaction. They were like, ‘Okay, A.) I have no idea how this is going to be performant enough, but B.) it’s so fun to work with.’ Right? Everybody was like, ‘This is so cool, I don’t really care if it’s too slow — somebody will make it faster.’”
No one made it faster. Return to the text before footnote 1