WordPress Gutenberg – a guide for developers and digital agencies
Sep 2 / 2020
The same information was announced on the WordPress.org website.
Don’t panic, think about future
There is a good chance that the official support for the Classic Editor will last longer if the number of users stays high. Otherwise it might continue unofficially supporting by the community without the resources of the Automattic team. There is no reason to panic but it doesn’t mean you shouldn’t think and plan ahead. As it seems, Gutenberg is here to stay, and it’s the Classic Editor’s life that is at stake. It’s also worth considering that if Automatic is planning to abandon the Classic Editor at some point, there is a little chance that the creators of other plugins won’t move on, too.
This is why I hypothesize that as for now we don’t have to use the Gutenberg editor for every website. Unless the projects that we are working on, are meant to stay online for a few years. I think, most of them do. If they’re based on Gutenberg, they may benefit from future updates, functionalities, and plugins that will be developed solely for the Gutenberg environment. I think that if we don’t use Gutenberg for our upcoming themes, we run a risk that in 2022+ updates will start causing issues and our clients won’t be able to use new Gutenberg functionalities. Also, installing new plugins or their functionalities might be hindered.
How to use the potential of the Gutenberg editor?
Here at Chop Chop, we mostly develop custom themes for digital agencies and end clients. So our insights come from this particular area of the WordPress world. Preparing for the new situation, we decided that apart from what we were already doing (tailor-made solutions, easy to use backend, and modular development), we will focus the performance and pagespeed of the themes that we develop.
The performance of the site is measured by Google Page Speed Insights and it is a crucial factor nowadays. Users expect a website to work fast and if it doesn’t, there is a chance they’ll leave and increase the site’s bounce rate index. If a site performs poorly in Page Speed Insights, Google’s algorithm may also “punish” it by reducing its position in SEO ranking and increasing the cost of Google Ads directed to that site. No one wants that. A high bounce rate decreases the conversions too. A few years back, Amazon said that every additional second in page load time, reduced their sales by 1%. That would mean a $1.6 billion loss. BBC found that for every additional second in load time, 10% of users leave.
So, what is our take on Gutenberg? To increase the performance, *we don’t load all of the scripts and styles on every page *. We created functions to load only those styles and scripts that are needed for modules used on a given page. We also use traditional methods like minification, cache, asynchronous scripts loading, adding images in webp format, and lazy loading. If you want to learn the technical details of that setup, read more here. To give you a glimpse, we have built an sample site using these solutions and it reached 99/100 on mobile and 100/100 on the desktop in Google Page Speed Insight.
We’ve been used to building modular themes for a long time (those modules are like lego bricks that you can set in any order you want). We believe that this approach is even more relevant in WordPress Gutenberg. The idea is that a page is divided into reusable blocks that can be arranged in various ways to freely create subpages. This means that if a designer prepares about 10 to 20 modules, then they can be used for creating multiple different pages. Even if a site requires some unique landing pages not based on the modules, it can be done too. This is a good balance between making a theme unique and maintaining a sustainable budget.
We make the best of that approach and bring it to a higher level with our digital agencies partners. In collaboration with them, *we create starter themes that have reusable modules *with very basic look and functionality. Those themes are based on the particular Agency’s ideas and needs. Using the starter themes, our partners create designs taking the base modules as a boilerplate. This cuts down the time and money spent on development. We don’t reinvent the wheel every single time. Each of those projects has got additional unique landing pages to make a site stand out among the competition.
What can be problematic about Gutenberg projects?
One important deadlock is on the development side. Even though there is documentation for coding Gutenberg blocks and there are some resources online, they are not as robust as those for classic WordPress. Frankly they are rather scarce. This means that developers who are new to Gutenberg might encounter challenges before they find an efficient way of developing Gutenberg themes. It took us some time, too.
The development time
Creating custom Gutenberg blocks is time-consuming and may far exceed the development time of an equivalent classic WordPress page. Especially if they are meant to be fully interactive in the panel as native Gutenberg blocks, and if developers are new to Gutenberg. This is why we use Advanced Custom Fields to build most of the new blocks. With ACF, blocks can be built much faster and with code that is much more familiar to WordPress developers than the native blocks implementation. We have also created several premade custom blocks and can use them for a given project; and – as we learn what gets used most often – we are building more. They are reusable building blocks that help us save more time the more we use them.
By now you probably can see that the time and cost is a recurring theme of this post.
Another potential deadlock connected to that lies on the design side. We can see that there are many designers in the business that do not grasp the concept of modularity. I understand that some websites are really unique and there’s a reason for them not to use any reusable modules. If that’s the concept and there’s a budget for it, it is fine and it is a kind of projects we really enjoy 😉
The problem that we see from time to time is that some designers are not aware of the modularity concept at all. And understanding it is crucial because a designer with a modularity perspective can have a better control over the project’s budget. They know that if they design every page to be unique, it will require a much bigger development budget. But they can reduce it by using reusable blocks and then direct more resources into creating fancy landing pages, animations, or interactions. IT projects can get pretty expensive and it’s really important to know the consequence of your choices.
There is a quote about the need for adaptation attributed to Charles Darwin. He never said it but it is still true: “It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change”. I wonder to what extent it fits the situation of the Gutenberg and the Classic editors. I think it does, but I leave the judgment to you. For sure, the future of WordPress is tightly connected with Gutenberg. I have a feeling that this train is leaving the station and it is good to be on board from the start. Despite the challenges, it’s going to be an interesting ride.