CloudCannon Versus WordPress

Significant additions done 30 October 2019

First Impressions

My very first impression of CloudCannon was oxymoronic at best. It just didn’t make sense at the beginning. To go sling around a lot of code to build things that are already available for WordPress (with no coding required).

I was introduced to CloudCannon by a friend about two months ago. I briefly looked at the CloudCannon site (didn’t know anything about Jekyll yet) and thought,

“Oh no. Do I really need to (re)invent the wheel yet again? Do I really need to code-up an image carousel when there are hundreds of off-the-shelf WordPress carousels out there? I’d rather provide business solutions for my clients than fiddle around with low level code.”

At the same time–I was running into a brick wall trying to squeeze every speed optimisation trick in the book out of WordPress (bloated themes and WordPress hosting companies included). Dealing with these performance headaches made me reminisce about the good old times.

I missed the days when the web was simpler (c. 1995). I pondered, why can’t I go back and use a static webpage for my home page? Why does WordPress stuff everything into the database only spit everything out as a static HTML. Surely, not every page needs to be 100% generated from a database (which is just a big series of flat files).

So, there I was. Looking for (maybe) some sort of hybrid solution when a friend told me their site was hosted on something called CloudCannon.

TL;DR

1. Looking at CloudCannon for the first time, I dreaded the thought of writing by hand an entire website in HTML/CSS/JS. Reinventing a photo gallery or slider seemed like a complete waste.
2. With WordPress, I grew complacent with not having to write much code. But, I suffered on a daily basis, working long hours optimising about a dozen bloated WordPress sites with minimal gains.
3. It’s too early to tell if I’ll be offering CloudCannon as a solution for future clients. But, with Jekyll. There’s no turning back — meaning I’ve decided to move my personal WordPress site to Jekyll on CloudCannon (Nov 2019).
4. CloudCannon is a cloud CMS for Jekyll. Jekyll is a popular static site generator.
5. WordPress is the world’s most popular CMS serving 34% of all websites according to W3Techs at the time of this writing.

Enough whining. Let’s look at the code!

What I Like About WordPress

There is a plethora. Hold on. There is an extravaganza of hosting providers, themes, & plugins. Which is also WordPress’ dark-side. For example, if I need a homepage hero slider, there are many out there to choose from. If I need an image gallery or a modal popup, they are almost always built into a premium theme. I don’t need to go into any code to get these widgets up and running fast.

A lot of the available widgets and plugins are well designed and sexy. They look amazing and they work well. Many are free, freemium, or donation-based.

Having these conveniences can also be a curse. More on that soon.

Having a bunch of hosting provider options is a big benefit. WordPress is the most popular website/web CMS (content management system) platform in the world! Therefore, there is no shortage of finding skilled professionals to support a WordPress site.

If you have the time, skills, and budget, you can have a fast WordPress site that Google PageSpeed loves. I’ll have to say though, achieving this takes near-heroic efforts.

What I Don’t Like About WordPress

WordPress Development == Sloooow Page Refreshes

I really dislike (hate) having to refresh slow loading page builder editors and posts/pages. But, I’m too afraid to install a bloated WordPress development environment and all the third-party plugins that come with it on my laptop.

Too Many Moving Parts (Plugin-arrhea)

There are way too many moving parts in a typical WordPress site. These moving parts change all the time. E.g. WordPress versions, PHP versions, plugin updates, and theme upgrades. Most of my clients install too many plugins.

For example, one of my clients has over 50 plugins. They don’t even know which plugins they really need, and most of them are outdated (one hasn’t been supported for 6 years–no joke). I’m trying to get it down to high thirties, low forties (still too high for my liking). Auditing and pruning plugins is not easy. And, that’s putting it lightly.

It’s been a work in progress for weeks and we’re not done yet. I’ve only managed to prune about a dozen so far. Every WordPress developer knows having too many plugins is a security risk and performance killer.

Uncontrollable Page Bloat

Themes provide little control over what gets loaded on your web pages. More optimised themes give you some control. But, this control is generally not at the page-level, i.e., site-wide control only. Page-level granularity should be a hard requirement for optimising websites.

Standard general purpose themes generate way too many round-trips to the server (135–156 server requests are common). Obviously, 156 server requests are a ridiculous waste of resources for every single page on the site. As a reference, GTmetrix (a leading site performance test tool) says 88 requests are the average.

More Than Enough Rope

Ah, let me count the number of ways to shoot ourselves in the foot. For example, I can add custom CSS to the

1. Appearance > Customise > Additional CSS
2. Theme’s main style.css file
3. Child theme’s style.css file
4. Theme editor
5. Site builder’s page-level Additional CSS code snippet editor
6. Inline CSS in the text editor

Have fun managing changes with this. Let alone trying to find a bug this spaghetti architecture.

Glossed-Over Child Themes

Any experienced WordPress developer knows to always create a child theme for the main theme. Child themes are where theme customisations go.

But I have to ask, why aren’t they just built-in?? Why does a developer or a site owner even have to know that child themes exist? Why do WordPress theme companies deliberately build themes that they know will absolutely break unless the site owner creates a child theme?

That would make too much sense–I mean, that would be the responsible thing to do.

So, we’re forced to supply our own child themes. But, support for child themes isn’t obvious. Creating a child theme is another extra step. It adds more complexity and overhead. And to make things worse, most WordPress site owners have no clue they need to use one.

Optimisation Slavery

My personal WordPress site is pretty simple. Yet, half of my plugins are devoted to performance tuning. I know I’ll need a couple more optimisation plugins before the end of this year. And, Google keeps yelling at me to put my site on a CDN, if I want a good PageSpeed score. Really? All this for a personal website. Insane!

Why Just Have One Page Builder When You Can Have Four?

Let’s make our footprint as big as possible by installing Divi (comes with a back-end editor & visual editor) and maybe Elementor for kicks on top of the Classic Editor and Gutenberg (WordPress built-in page builders). Hmmmm, does anyone else see what’s dreadfully wrong with this picture?

What I Like About CloudCannon

Transparency

I can see all the source HTML I need to see. Rejoice! I can do stuff that WordPress rejects in its editor. E.g.

itemscope itemtype="http://schema.org/Blog"

This tiny piece of code is small, but it packs a punch in the SEO world. WordPress strips out this code every time I’ve tried to add it to my site. Arghhh. With CloudCannon–no worries, mate! In fact the theme this blog is using has this code already in these pages. Now that’s responsible coding! Happy Days :-)

In the WordPress realm, there’s probably a bloated 500 file plugin that will do this tiny little thing for you.

This piece of code below, got me dancing on my kitchen table! In WordPress, trying to include JavaScript only when needed is performing oral surgery. Not so, using Jekyll. In Jekyll, a simple if statement in a custom includes file does the trick, and it’s party time.

The 4 JavaScript files shown above, will get loaded only for a page named masonry. In a typical WordPress site, these files would get painfully loaded for every page whether they are needed or not.

It gets worse. Each file has to be fetched from a remote server. That means the browser and server will talk back and forth four times to get these files loaded. Wait.

There’s more. For each of these JavaScript files, the web server has to ask a remote server to send the file over the net. Wow!

Now, imagine you have a WordPress site that has 52 plugins. Each of these plugins requires their own set of say 2–4 JavaScript files. That would cost each of your WordPress pages 104 to 208 server calls (52*4 = 208).

What’s 208 web server requests for one page among friends? No biggie, eh?

Local Development Environment

I’m back using a version control system! Something I haven’t been able to use in the WordPress universe. And, GitHub rocks!

My live CloudCannon sites, GitHub code repositories, development repositories, and development site are always in sync. Love it. I don’t think I could ever do this with WordPress (smoothly). I wouldn’t even know where to start. With CloudCannon, GitHub is a natural part of the process.

I can build/test/publish customisations quickly. The dev cycle is light-speed fast compared to WordPress.

So, with GitHub and using GitHub Desktop, my two CloudCannon sites are completely portable. I.e., they are already in the cloud, on the web, and on my desktop. I can take them anywhere that runs Jekyll.

Developing websites using local dev env is fast–it’s the way to go. What if I want to move the code to another server or another laptop. Easy. Setup Jekyll and Github Desktop and away you go.

The Jekyll ecosystem is lean. I don’t need to know PHP or phpMyAdmin (MySQL database manager). I don’t need to know SQL. And, the Jekyll culture is an anti-plugin/establishment culture.

Editing Content

The CloudCannon content editor is minimalist (and, a bit primitive compared to WordPress). This can be good/bad. I love a minimal editor. CloudCannon’s editor works fine for me in terms of functionality. But, it might not work for someone used to WordPress because lack of bells & whistles.

Here’s one thing I discovered by accident–CMD-L brings up a link modal right in context. How cool is that! I wish WordPress could do this.

I think the content editor is the weakest link (so far). Read on below to find out why. Before we toss out the baby with the bathwater–we need to give credit to Jekyll’s native document format for blog posts. That’s Markdown. Markdown is incredibly powerful and extremely fast. It’s about as minimal as you can get when it comes to publishing content. I love it. I’m happy to see it and use it again.

Read-up on Markdown here. By the way, if you use WhatsApp or Slack, Try using Markdown in your next message. You’ll look like a pro!

The downside is that Markdown will take some getting used to if all you know are visual editors. The good news is, I bet you will soon be addicted to how much more productive/faster you become (in a short time).

Source Code Editor (Edit: 30 October 2019)

Editing source code directly from CloudCannon is supported with a basic code editor. You get nice syntax highlighter and a built-in source code search. I didn’t see a way to prettify (format) the an entire doc via the editor.

When edits are saved, the site is immediately recompiled (a mixed blessing). A bright green check mark at the top of pages confirms a successful build. If this is a drag, then setting up a local environment is the way to go. You should just always have a local with Jekyll because it’s easy to set up and maintain.

Fast File (filter) Search (Edit: 30 October 2019)

Their back end file search is blazing fast and accurate incremental search (results display as you type). This leaves WordPress’ search in the dust. Searching for something in WordPress is excruciatingly slow. You can’t query across all files in WordPress (what kind of CMS is that??). You need to go into pages, posts, portfolio, or media individually! Then, you’ll have to paginate over all the garbage hits — OMG what a time sink. Have fun with those page refreshes.

Real-Time Source Code Baseline Updates (Edit: 30 October 2019)

The CloudCannon site dashboard has a live feed that shows what code changes (recent activity) have been done. As a bonus, the dashboard has a list of recently opened items.

What I Don’t Like About CloudCannon

Here’s a short laundry list of what I don’t like about CloudCannon

Content Editor

1. The content editor is slow. It takes a few seconds to save a post with no images. The editor seems to hog my CPU (it kills my Firefox–my go to browser). Uncomfortably similar to how Divi (popular WordPress page builder) can choke my computer resources. I ran some performance tests and discovered that the Divi page builder editor actually takes up less CPU than CloudCannon’s content editor. I didn’t think this was possible!
2. I don’t see a preview button in the editor. I had to publish my draft to see what it would look like.
3. I don’t see a way to create a draft version of a published post. In WordPress, you can make draft from a published post in one-click.
4. Ironically enough, I don’t see a way to edit HTML/CSS in the CloudCannon editor. You have to get out of the content editor and go into the files directory. Find the blog post Markdown file and bring it up in the code editor.
5. Edit 30 October 2019: Every file save kicks-off a build. This is great for keeping the site always in sync with the code. But, can be a real pain if you are making many quick changes to different files and have a large site. If this is the case, go with a local dev.

Where Are The Jekyll Theme Marketplaces?

Lastly, I don’t see an obvious market or store for Jekyll themes. I (luckily) stumbled upon the two themes that I’m using now.

Edit 30 October 2019: I found some premium Jekyll themes on Themeforest https://themeforest.net/search/jekyll. And more here https://jekyllthemes.io/ and here https://jamstackthemes.dev/ssg/jekyll/.

CSS Sprites

Ah, I would have really loved to use a CSS sprite for this blog post (originally posted on CloudCannon). Using CSS sprites reduce server round trips. Unfortunately, that means I would have needed to write this post in HTML — didn’t want to do. Oh well. You can’t always get what you want. And, therein lies the trade-off. Simple/minimal/Markdown versus HTML/CSS/JS. Maybe prototyping sprites in CloudCannon is my next homework assignment?

Conclusion (Edit 30 October 2019)

CloudCannon and WordPress are 2 competing platforms. They are both bundled with different technologies. A platform is a platform. Meaning a platform gives you something to stand on (by definition). Each will have their trade-offs. Any platform can be abused.

Just like with WordPress, implementing some items in CloudCannon can be super fast depending on the theme you choose. CloudCannon makes reinventing the wheel too easy (should be avoided — takes time and introduces more custom code to maintain).

Here’s a recent real case scenario. A client decided to ditch their new WordPress site and revert to their original Cloudcannon site. One of the first changes they asked me to make was to add a three-column row to feature external blog posts.

It took me about 50 minutes to make this change because there are no pre-built components, and all the existing code was setup for two columns. It took time for me to figure this was the case, then create and test all the new CSS classes.

I also realised I needed to make a test copy of the file I was updating — carefully migrating/deleting afterwards. Then, finally adding the HTML and content.

Adding the content itself took only 10 minutes (including optimising and fitting images). I know back at their WordPress site, this exact change would take less than 15 minutes to do. Drop in a three-column row takes one click. Optimise/upload/add the images. Copy/paste the text. Hit preview. Hit publish. Done.

Both platforms require owners and maintainers to be tech savvy. IMHO, “No Coding (or Experience) Required”, is a myth when it comes to owning a website. It’s only a reality when a non-techie owner hires a techie to build, test, make updates, and support their site.

CloudCannon’s website performance is its ultimate saving grace for me. It’s fast. It keeps Google PageSpeed happy. Less time performance tuning and more time designing/building is always a good thing. And the bloat? Just like WordPress, a CloudCannon site can be a bloated as you want. But, you have much more control of how bloated you want it to be.

P.s. This review was 100% written in Markdown using the Visual Studio Code editor and originally published on my prototype CloudCannon site. No worrying about slow loading, feature heavy, and clunky WYSIWYG or Gutenberg site builders. Some WordPress sites I maintain have the classic editor, Avada/Divi/Elementor, and then Gutenberg of course. With Jekyll and CloudCannon, gone are the days of having a minimum of three page builders installed just for one site: Freedom at last!

If you found this useful, please share it. Or even buy me a cuppa joe. Hint hint ;-)