From WordPress to Gatsby
Background story
I’m a software developer. Through some circumstances — involving a number of patched jeans, mother-in-law, and a beatiful old estate transformed into a Bed and Breakfast place — I’ve ended up creating and maintaining a WordPress site. The initial idea behind using a CMS, such as WordPress, was to enable non-developers to easily update the pages by themselves. It’s a fallacy, you will end up doing that yourself. #TrueStory
The WordPress site had been localized to five different languages, so whenever making any changes — at minimum — I would have navigate in the menus, find the correct pages, and finally make the changes. In addition, you have to keep patching the WordPress installation and all the plugins to try to keep up with all the security issues. So, I thought I’d migrate the site into a statically generated one.
Static site generators
I’ve been a fan of static site generators for a while. In my own blog — the one you are reading right now —
I’ve used Jekyll since 2014.
I’ve also successfully tricked convinced my 65 year-old dad to move his company site
from Drupal (similar CMS as WordPress) to Jekyll.
Now he creates his posts in Sublime Text, and pushes the changes to Github
before executing ./generate-and-deploy.sh from the terminal.
The benefits of static site generators include:
- Security: you have minimized the number of attack vectors. Just a bunch of static files
- Reliability: just a bunch of static files. What could go wrong?
- Deployability: you can host & deploy pretty much anywhere (Apache httpd, Nginx, S3, etc.)
- Developer experience: all the code & logic & content is at your fingertips, just one
git grepaway!
(Assuming you’re using git. And you should) - Performance: your site will be fast⚡️. All the files are already generated.
The main problem of static site generators is that — while being developer friendly — they
most definitely are not user-friendly to the majority of people. However, as my dad is doing git commits and
updating his site from the terminal via rsync, I will ignore this as a trivial obstacle.
If you still need more CMS-kind-of editing capabilities, you might want to check out Netlify.
Taking Gatsby for a spin
The new kid on the block is Gatsby. I had’t used it before, but knowing React made it really fast to get started. In a few days I had pretty much re-implemented the old WordPress site in Gatsby — although we agreed to have only Finnish and English localizations in the new site.
Compared to Jekyll, what really stood out for me, were:
- Modern web (JavaScript) technologies: React, Webpack, GraphQL
and modern JavaScript packed in a ready-made package. Just run
gatsby developand you’ll have a server running with hot-reloading. Need some libraries? Justnpm installand off you go. - Build pipe-line: asset cache-fingerprinting, progressive & responsive images. Out of the box! In my own Blog, with Jekyll, I’ve had to use custom gulp files, and scripts utilizing ImageMagick to achieve something similar.
- PWA capabilities: code and data splitting out-of-the-box, and once loaded Gatsby prefetches resources for other pages so clicking around the site feels incredibly fast. Compared to the standard WordPress installation (without caching), the speed difference in very noticeable.
Lighthouse Audit
Performing a Lighthouse audit to both the Gatsby and the WordPress site, supports the empirical findings of Gatsby being clearly faster. The WordPress site seems to have very fluctuating performance (between 25-75) whereas Gatsby keeps giving a solid 90.
Reasons for not getting perfect scores were:
- Using relatively large
background-imagein the header - Not using HTTPS
- Not using HTTP/2
Is it perfect then?
Nope, not yet at least. The core team has gotten commercial backing, and is currently working to finish a new major version of Gatsby. The biggest issues I encountered with the current version (which most likely are being solved with the next version) are:
- The concept of layouts is “wrong”. You have no control over layout from the page itself (like you do in Jekyll). However, they are removing layouts altogether from next version. Instead it will be React components and GraphQL everywhere.
- Only part of the files are cacheable (read about this in Caching Static Sites). This will also be fixed in the next version.
- When modifying GraphQL queries, I sometimes had to manually remove
.cachedirectory to see the changes.
Also, the current version isn’t really scalable to sites with thousands of pages. But thankfully this will also be adressed in the next version.
Show me the money!
I have migrated the site from WordPress to a Gatsby-backed static site. It is available at www.sinkkala.fi.