High performing, cost-effective alternatives to WordPress

I made it! Article 10 of 10 all about website speed for marketers. I’m an ex-marketer turned dev, supporting businesses with fast websites. Remember, we need fast websites because Google gives us an SEO performance boost and when prospects land on our website they’re more sticky. They don’t bounce off so easily.

So, full disclosure… I will be arguing for a different approach to WordPress (and others that operate in a similar way… e.g. Drupal, Joomla etc.).

Why? Because there are more challenges with speeding up WordPress sites than the other alternatives. That’s not to say that it’s impossible to get a 100/00 performance score for a WordPress website. But the WordPress instances I see of really fast WordPress websites are far outweighed by the instances that I see that are poor performing. There has to be a reason for this… no?

I like WordPress, and I have used it as a solution for my customers. But when SEO and performance are critical (which they should be for the majority of businesses), then I would head down the JamStack route. What’s that? We’ll cover it all below… so read on.

Why is it harder to achieve a fast WordPress website?

Dynamically generated pages are slower

Your web pages don’t exist as pure HTML on a WordPress website. Your content sits in a database. When a URL is requested then WordPress leaps into action and pulls your content out of your database, merges it with layouts (i.e. design files) and returns an HTML page. Great… not great actually, all this takes time. So, WordPress sites are inherently slow because of dynamically generated pages.

Caching is almost always needed to improve performance

Caching is the process of saving dynamically generated pages to a temporary store on the server after they’ve been served once. These stored pages are then returned when other visitors request those pages. This drastically speeds up the returning of pages from WordPress websites. It solves the above problem. All good… yes?

Yes… but, this increases the complexity of your WordPress system with yet another plugin that will need updating. It can mean that newly updated content isn’t visible because the older cached page is still being returned. And finally, the best caching plugins come at a price so this approach can increase the cost of your setup.

Page builders can be a drag on speed

Page builders have transformed the WordPress world. Allowing no-code web designers, marketers and more to be able to create great looking web pages in a much reduced timescale. Due to this, the cost of websites have come down - which is great for marketers. But, some page builders are one of the main reasons for poor performance.

Plugins give the server more to do

Again, a great, quick solution for hard-to-fix website challenges. But this quick-win often comes at a price. Plugins can often really slow down a WordPress site affecting the time to first byte (TTFB). Check out our time to first byte article.

High performance globally isn't straight-forward

Because of the inherent workings of WordPress (I.e. dynamically generated pages) it’s harder (and so more costly) to ensure that your WordPress website is as fast in the UK as it is in Australia. Caching is used to solve this problem, but then you inherit the issues associated with caching.

Scaling

If WordPress websites aren’t setup for scaling, then if they’re hit with a sudden high volume of traffic they can crash. This is because the volume of requests is far greater than the system can handle.

Other downsides not related to performance but worth discussing

• Your content is locked away in a database. It’s harder to extract, backup and migrate
• WordPress is the most attacked and hacked content management system in the world.
• Regular updating of the system and its plugins is critical to avoid issues such as hacking
• Backups need more complex solutions than other available systems

Another way forward - the JamStack

The JamStack stands for Javascript, APIs, and Markup. It encompasses a wide-range of solutions that use Javascript (see article four) to power them. They use APIs to get content and then merge it with layouts using markup (in other words HTML).

JamStack solutions tend to pre-build web pages and/or do a lot of the processing inside of the browser rather than on a backend server. Effectively outsourcing the heavy-weight backend lifting that can often crash a WP site.

JamStack solutions include (but are not limited to)

Static site generators (SSGs)

Software that generates a static HTML version of your website. It does this by merging your content in basic text files with your HTML layouts at the time of editing.

Content can also come from headless content management systems. This means that pure html web pages live on your server… all the server needs to do is to return the HTML. This processing up-front approach is an amazing solution. It’s like having the very best low-maintenance cache in the world - with none of the inherent cache problems. Our Pendigital.co.uk website is an SSG website. Check out the case study if you'd like more information.

Single Page Apps (SPAs):

Imagine your website behaving like an app in the browser. No refreshing of pages. That’s what SPAs can do. When you load an SPA all the different components (such as heroes, carousels etc.) come down with it.

When you navigate to different web pages then those pages are composed in the browser (rather than the backend). Content comes from a backend API sending content as a basic JSON file (basically a text file).

JSON is very lightweight and so loads extremely quickly… far quicker than a dynamically generated HTML page.

Hybrid approach

SSGs that have interactive islands in them. Or SPAs that have statically generated pages on the server and then hydrate. Hydration is the process of downloading the Javascript app behind the scenes. The viewer is immediately provided with a static HTML page. Whilst the viewer is reading the statically generated page the needed Javascript is downloading.

In the early days of SPAs there were issues with indexing of pages for SEO and being slow to load the first time. But these issues have all been addressed via the hybrid option that includes statically generated pages. SPAs can also be setup to render on the server which is akin to the WordPress dynamic page generation.

And, headless content management systems and other CMSs that work with the JamStack have made huge advancements. One example, is CloudCannon. It now comes with a visual editor so you can build and edit pages much like you do with a WP page builder.

What are the performance advantages of JamStack in comparison to WordPress?

There are no dynamic pages generated on a server (unless using server side rendering). Giving a speed boost. This also makes JamStack sites more scalable.

Caching isn’t needed so less complex systems in comparison to WordPress et al.

Plugins are used but they don’t affect the TTFB (time to first byte) of a page. As they’re either running to generate a web page in advance of a url request - as for an SSG site. Or they are running in the browser - as for a SPA site.

High performance globally: Due to their inherent workings both SSGs and SPAs are easier to deploy to servers around the world. And so provide an enormous speed boost across continents.

Other upsides not related to performance

Backups are normally to remote repos such as Github or saved in a remote headless content management system. In most instances of SSGs, your content is in the form of text files (markdown to be exact). For SPAs, your content is normally saved in a headless content management system or could also be in text files.

SSG sites are more secure. They expose less attack areas than WordPress websites. As they only expose pure HTML... frustrating would-be attackers as there isn't much they can do with that!

My recommendation...

My personal approach for a high-performing websites would be:

• For brochure type websites: Then a static site generator (11ty or Jekyll) with CloudCannon looking after the content management and hosting.
• For minor / partial user interaction: Then a static site generator (11ty) with web components. I.e. islands of interactivity. Content managed with CloudCannon or Sanity.
• For systems that need authentication and max user interactivity then a SPA (Angular).

Hope you enjoyed this final article. If you've arrived here via a Google search then check out all our performance articles. And if you need a hand sorting out a slow website then please don't hesitate in getting in touch.

Today's hero animal image is a Peregrine Falcon. It can reach speeds of 300kmh - making it the world's fastest animal. I saved this one until the last article!

And don't forget to follow us: LinkedIn, Twitter and Facebook. See you next time.