CloudCannon Versus WordPress

CloudCannnon Versus WordPress (Product Review by mark l chaves)
CloudCannnon Versus WordPress (Product Review by mark l chaves)

Significant additions done 30 October 2019

First Impressions

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. 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.
  2. 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).
  3. CloudCannon is a cloud CMS for Jekyll. Jekyll is a popular static site generator.
  4. 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!

WordPress Logo (CloudCannon Versus WordPress by mark l chaves)
WordPress Logo (CloudCannon Versus WordPress by mark l chaves)

What I Like About WordPress

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

Too Many Moving Parts (Plugin-arrhea)

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

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

  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

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.

Child Theme Warning (CloudCannon Versus WordPress by mark l chaves)
Child Theme Warning (CloudCannon Versus WordPress by mark l chaves)

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

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

CloudCannon Logo (CloudCannon Versus WordPress by mark l chaves)
CloudCannon Logo (CloudCannon Versus WordPress by mark l chaves)

What I Like About CloudCannon

Transparency

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.

Screen Capture of Ruby Code (CloudCannon versus WordPress Product Review by mark l chaves)
Screen Capture of Ruby Code (CloudCannon versus WordPress Product Review by mark l chaves)

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

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

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.

CloudCannon Content Editor (CloudCannon Versus WordPress by mark l chaves)
CloudCannon Content Editor (CloudCannon Versus WordPress by mark l chaves)

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)

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)

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

What I Don’t Like About CloudCannon

Content Editor

  1. I don’t see a preview button in the editor. I had to publish my draft to see what it would look like.
  2. 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.
  3. 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.
  4. 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?

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

Conclusion (Edit 30 October 2019)

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 ;-)

Written by

I slung code for Fortune 500 companies in a previous life. Now, I write and make some photographs. I’ve moved on to Dev.to. Portfolio on CaughtMyEye.cc

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store